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.
git clone --depth 1 https://github.com/shashankreddy509/claude-tdd-kitWrote 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/commands/shashankreddy509/claude-tdd-kit/ship)<a href="https://agentmods.dev/commands/shashankreddy509/claude-tdd-kit/ship"><img src="https://agentmods.dev/badge/commands/shashankreddy509/claude-tdd-kit/ship.svg" alt="Measured on agentmods" 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.00000 | $0.03153 |
| Opus 5 | $0.00000 | $0.01577 |
| Sonnet 5 | $0.00000 | $0.00631 |
| Haiku 4.5 | $0.00000 | $0.00315 |
Grade A, and why
ship 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 7d 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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Encodes the "stage and commit" ritual: verify (receipt gate) → scope → branch → write the commit message from what is actually staged → commit → push → open PR to the default branch → move the Jira issue to In Review. NO merge (merging is the reviewer's call). NO tag (deploys are project-specific and out of scope).
Argument (optional): explicit file paths to include. If omitted, auto-scope to this session's feature files.
Project config — resolve at runtime, never hardcode
Read the project's CLAUDE.md for a line of the form:
Jira: cloudId=<uuid> key=<KEY>
That line is the ONLY source for the project key. No line → the repo has no Jira wiring: skip every Jira step (steps 2 and 8's transition), ship the PR anyway, and say so in the report.
Resolve the Jira MCP dialect before any Jira call — see references/jira-mcp.md. It returns the tool names for this machine and whether cloudId is a parameter at all. Where it is required, the cloudId=<uuid> above supplies it; never guess one and never carry one over from another project — a wrong cloudId transitions some other project's ticket. Where the dialect has no cloudId, ignore that half of the line. No Atlassian MCP resolved → log the skip line from that file, ship the PR anyway, and report which transition was skipped.
Fallback when the line is absent but the user names a key, dialect A only: mcp__atlassian__getAccessibleAtlassianResources to resolve the cloudId. Still ambiguous → ask; do not pick one.
Transition ids are per-project and change — always list transitions with the resolved tool and match on to.name, never a hardcoded id. Same for the browse URL: derive it from the resolved site, not a literal host.
Steps
- Read the pipeline receipt — gate the ship on it. Find the ticket key (branch slug, the user's argument, or the Jira issue for this work) and read
tasks/receipts/<TICKET>.json. The pipeline writes it; keys areticket,plan,sha(HEAD at the last stage written — staleness detection),red/green(cmd+ the REAL processexit+at),review(critical,warnings,unverified,warning_listoffile:line whatstrings), an optionalgatingblock (required,seeded,readback), andstage(red|green|reviewed|complete). A receipt is a record, not a permission slip — never hand-write or edit one to get past this gate.
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.
- 7d ago First seen · 126 lines · 0 tokens per session scan A 9f47733ccbe6
ship is a command published in the GitHub repository shashankreddy509/claude-tdd-kit (2 stars, last pushed 15d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 3,153 tokens. 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-08-31.
Other commands, from other repositories
orc
Parallel multi-agent orchestration for complex features.
parallel-task
Execute bulk modifications across codebase with parallel agents and safety guarantees.
commit-push-pr
An automated Git workflow that checks a project, synchronizes documentation, commits changes, and can create or merge a GitHub pull request. A pull request is a request for teammates to review and add changes to a shared codebase.
quick-commit
A quick Git command for committing and pushing a small code change. Git is the tool that records code versions and sends them to a shared repository.
pr
Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes.
afp
Prioritise feature - assigns ID, moves to backlog (shortcut for feature-prioritise).