Borrowing it
Nothing to install: this file belongs to tensorbee/rdocx. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/tensorbee/rdocx/main/.claude/commands/implement-feature.mdgit clone --depth 1 https://github.com/tensorbee/rdocxWrote 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/tensorbee/rdocx/implement-feature)<a href="https://agentmods.dev/commands/tensorbee/rdocx/implement-feature"><img src="https://agentmods.dev/badge/commands/tensorbee/rdocx/implement-feature/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/commands/tensorbee/rdocx/implement-feature"><img src="https://agentmods.dev/badge/commands/tensorbee/rdocx/implement-feature.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.00013 | $0.02097 |
| Opus 5.5 | $0.00005 | $0.00839 |
| Sonnet 5.5 | $0.00003 | $0.00419 |
| Haiku 4.5 | $0.00001 | $0.00210 |
Grade A, and why
implement-feature 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 6d 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 — 185 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/implement-feature F-XXX
Turn the failing stubs from /start-feature into a passing implementation,
against the design plan as the contract.
Steps
-
Re-read the contract.
.claude/plans/F-XXX-design.mdand its citeddocs/hld/sections. Then.claude/scratch/F-XXX-progress.mdif resuming. Use the exact approved signatures, numeric conversions and XML placements. If source inspection contradicts a compatibility claim or exposes an invalid content model, stop the affected change, revise the contract and resolve material decisions before proceeding. Do not code around a flawed plan or silently weaken its acceptance gate.On resume, compare the local plan and applicable canonical commands/skills with the current canonical sprint revisions. Read the authoritative files from the canonical worktree or Git objects. Record their commit or content identity, the material differences and applicability to existing work in the existing progress file. A claim Base alone does not identify a later approved contract. An unresolved semantic difference pauses only affected work. Do not reset, force-checkout or rebase a dirty worker, copy sprint trackers into it, or edit another owner's worktree. Its owner reconciles source safely through the normal workflow. Reuse unaffected local evidence.
-
Confirm the state. The F-ID is
in-progress, the branch issprint/sNN, and the stubs exist and fail. -
Work the checklist in order. Implement the numbered acceptance rows, preserving the consumer map and test matrix. Inspect every caller of shared policy: defaults, context, owner selection and scope must agree where the contract says so. Compare actual relevant outputs, including positioned rendering, before/after update and save/reopen. Add a missing discriminating control when a new interaction is found. Keep unchanged-input consumers and refusal/atomicity controls valid. Use scoped
cargo checkbetween edits. For cached read facts, inspect direct native assignments and callback bodies, including publishers that keep owner identity or revision unchanged. Prepare updated facts or invalidate them before publishing changed source. Exercise a real value-changing operation of that kind and compare held, fresh, native and saved/reopened reads without weakening the promised handle lifetime. Batch related focused regressions sharing a test binary when practical, rather than compiling the same large binary separately for each added case. Retain individual outcomes and rerun the cases affected by each source fix. Run the narrowest useful test target, not the workspace. Never defer a check needed to resolve an actual implementation uncertainty merely to batch it.
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.
- 6d ago Changed · +108 lines 389382a6e2b4
- 11d ago Changed · +7 lines 90691bfdf0f3
- 26d ago First seen · 70 lines · 13 tokens per session scan A 456a1435765a
implement-feature is a command published in the GitHub repository tensorbee/rdocx (44 stars, last pushed yesterday), licensed MIT. It adds 13 tokens to every session and 2,097 once invoked, about $0.0001 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-10-04.
Other commands, from other repositories
prototype
You are building a proof-of-concept for the current Grainulator sprint. Read CLAUDE.md for sprint context and claims.json for existing research claims.
qa-changes
This skill should be used when the user asks to "QA a pull request", "test PR changes", "verify a PR works", "functionally test changes", or when an automated workflow triggers QA validation of code changes. Provides a structured methodology for setting up the environment, exercising changed behavior, and reporting…
verify
Run repository verification using the verification-loop skill.
modernize-transform
Transform one legacy module to the target stack — idiomatic rewrite with behavior-equivalence tests.
constraints
A command for defining a project's quality standards through a short interview and a written CONSTRAINTS.md file. It records checks, thresholds, exceptions, and commands for enforcing them.
check-dev
Type-check a Z specification with fuzz.