claude-code-my-workflow is a forkable setup for using Claude Code to produce and review academic papers, slides, data analyses, and replication packages. Researchers use its agents, skills, rules, hooks, and quality checks to coordinate these tasks and verify their results. The catalogue entries define the reusable workflow components for Claude Code.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add pedrohcgs/claude-code-my-workflow --skill issuesgit clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pedrohcgs/claude-code-my-workflow/issues)<a href="https://agentmods.dev/skills/pedrohcgs/claude-code-my-workflow/issues"><img src="https://agentmods.dev/badge/skills/pedrohcgs/claude-code-my-workflow/issues/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pedrohcgs/claude-code-my-workflow/issues"><img src="https://agentmods.dev/badge/skills/pedrohcgs/claude-code-my-workflow/issues.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00147 | $0.02340 |
| Opus 5.5 | $0.00059 | $0.00936 |
| Sonnet 5.5 | $0.00029 | $0.00468 |
| Haiku 4.5 | $0.00015 | $0.00234 |
Grade A, and why
issues scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 18d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/issues — the project's to-do list and memory, in GitHub issues
Every problem worth fixing becomes an issue: a claim in the paper that misleads, a table that disagrees with the code, a bug, an improvement for later. The open issues are the to-do list. When a fix lands, the issue is closed with a comment that says what was wrong, what was tried — including what did not work — and how it was fixed. Read back months later, the closed issues are the project's memory: auditable, searchable, and the same on every machine and for every co-author, which a chat transcript or a local notes file is not.
This skill makes the habit cheap. It never posts anything without showing the draft first and getting a yes.
When to use
- After a review —
/review-paper,/seven-pass-review,/adjudicate-review, or findings you list yourself — to turn each confirmed problem into its own issue. - When starting or resuming work — to see what is open for the paper, section or files at hand, and pick the next thing.
- When a fix has landed — to close its issue with a record of what happened.
Modes
file <report|text> — turn findings into issues
The input is a findings JSON from the review runtime, a review report, or problems described in the conversation.
- Pre-flight.
gh auth statusmust succeed. Thengh repo view --json visibility,nameWithOwner: on a PUBLIC repository, say plainly that every issue will be public — unpublished results, referee-sensitive weaknesses and co-authors' drafts would be visible to anyone — suggest a private repository for paper work, and create nothing without an explicit yes to that. - One issue per root cause, for problems that matter. Merge findings that share a cause; split a finding that bundles two problems. File confirmed findings that affect correctness or a stated requirement; list the rest to the user as optional rather than filling the tracker with reviewer noise.
- Deduplicate against open and closed issues — this is enforced, not optional. Every new
issue is created through
scripts/file-issue.py(step 5), which runs several searches first: the title's most distinctive words together, the top three alone in titles, every--searchterm you pass (a section name, a table label, a function), and up to three file paths the issue names — at most eight searches, and any dropped are reported. A match gets a comment on the existing issue (reopen it if the problem is back), not a new issue. - Draft each issue.
- Title: the problem as a checkable statement — "Intro overstates the sample: 3,412 in §1 vs 3,142 in Table 1", not "Fix intro".
- Body: What's wrong (file:line or section, with the exact quote), Why it matters,
Done when (the acceptance test), Source (the report path and
git rev-parse --short HEAD). - Labels:
bug,documentationorenhancement, plus an area label such aspaper,codeorslidesif the project uses them (create one on first use withgh label create).
- Show every draft as one numbered list, then create only the ones the user approves, each
with
python3 scripts/file-issue.py --title "…" --body-file <draft> [--label …] [--search "…"]. Exit 3 means it found possible duplicates and created nothing: read each (gh issue view N), comment on the one that is the same problem, or — if the new issue is distinct from all of them — re-run with--checked N,M. The issue body then records which searches ran and which candidates were judged distinct. Exit 2 means the search could not run, and nothing was created. A rawgh issue createis denied by theissue-guardhook for the same reason. Report the new numbers.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 18d ago First seen · 151 lines · 147 tokens per session scan A 6b64bb7ae436
issues is a skill published in the GitHub repository pedrohcgs/claude-code-my-workflow (1,662 stars, last pushed 18d ago), licensed MIT. It adds 147 tokens to every session and 2,340 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-28.
Other skills, from other repositories
catchup
Summarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.
gh-issues
Use when creating, searching, updating, or managing GitHub issues via CLI. Triggers: "issue", "create issue", "gh issue", "task tracking", "context", "handoff", "resume task", "session context", "save progress", "active tasks", "in-progress", "my tasks", "open issues". Covers: gh commands, bulk operations, JSON/jq…
workspace-sync
Centralized workflow log repository sync.
credential-setup
Automatic GitHub credential detection and verification.
issue-patrol
Automated GitHub issue scanning, triage, and fix loop.
r-econometrics
Run IV, DiD, and RDD analyses in R with proper diagnostics.