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 agentmods add skills/atman-33/workhub/develop-small-featurenpx skills add atman-33/workhub --skill develop-small-featuregit clone --depth 1 https://github.com/atman-33/workhubWhat 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 | $0.00050 | $0.01061 |
| Opus 5 | $0.00025 | $0.00531 |
| Sonnet 5 | $0.00010 | $0.00212 |
| Haiku 4.5 | $0.00005 | $0.00106 |
Grade A, and why
develop-small-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 2d 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 — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Develop Small Feature
Implement the feature or fix described below, carrying it through the full branch → TDD → static checks → user verification → commit → PR lifecycle.
This skill is scoped to small, well-scoped changes (a handful of files, a
settled approach). For large or uncertain work — spanning many files, needing
real debugging/trial-and-error, or warranting a deep review — use
heavy-implementer and/or the code-review/simplify skills directly
instead of forcing this flow.
Spec: $ARGUMENTS
If no spec is given as an argument, use the specification already established in this conversation (the user's most recent instructions, requirements already discussed, or an agreed-on OpenSpec change). Do not ask the user to repeat themselves if the spec is already clear from context; ask only if it is genuinely ambiguous.
Steps
-
Feature branch. Run
git branch --show-current.- If already on a branch other than the repository's default branch (e.g.
an existing
feature/*branch), stay on it — do not switch. - If on the default branch, invoke the create-feature-branch skill to create and switch to a new feature branch derived from the spec.
- If already on a branch other than the repository's default branch (e.g.
an existing
-
Implement, test-first. Invoke the tdd skill to implement the change (red → green → refactor), delegating the work to the implementer agent by default. Do not use
heavy-implementerunless the user explicitly asks for it, orimplementerreports (or a retry shows) that the change needs cross-file debugging/trial-and-error it can't resolve — in that case escalate the rest of the work toheavy-implementer, which can drive its own TDD loop directly. -
Static checks. Delegate to test-runner to run the target repo's lint/format/check commands (e.g.
npm run checkfor this marketplace) and report pass/fail. Let auto-fixable issues (formatters) be fixed directly; for remaining lint errors, delegate the fix to implementer and re-run the checks.- This intentionally replaces a full code-review/simplify pass — this
skill targets small changes where lint + tests + the user's own look are
enough. If the diff turns out larger or riskier than expected, tell the
user and suggest running the
code-revieworsimplifyskill manually.
- This intentionally replaces a full code-review/simplify pass — this
skill targets small changes where lint + tests + the user's own look are
enough. If the diff turns out larger or riskier than expected, tell the
user and suggest running the
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.
- 2d ago First seen · 91 lines · 50 tokens per session scan A 47ff7db85fd4
develop-small-feature is a skill published in the GitHub repository atman-33/workhub (2 stars, last pushed 3d ago), licensed MIT. It adds 50 tokens to every session and 1,061 once invoked, about $0.0003 per session on Opus 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-08-31.
Other skills, from other repositories
trellis-finish-work
Wrap up the current session: verify quality gate passed, remind user to commit, archive completed tasks, and record session progress to the developer journal. Use when done coding and ready to end the session.
writing-skills
Use when a user is creating or revising a ReadMD Skill and needs a test-first writing workflow.
aetox-testing
ออกแบบกลยุทธ์และแผนทดสอบ, testing pyramid, กลยุทธ์รายชั้น (API, data pipeline, frontend, infra), จัดลำดับ critical path/edge/security บวกวินัย TDD (red-green-refactor) และกับดักเทสต์ที่ควรเลี่ยง ทริกด้วย "ควรเทสต์ยังไง", "test plan", "เขียนเทสต์ให้".
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
gonavi-cli
Operate databases through the GoNavi headless CLI — the gonavi executable shipped in verified GitHub Release archives. Covers listing/adding/importing saved connections, running SQL queries against saved connections or ad-hoc connection files, exporting result sets to csv/json/md/html/xlsx, batch-executing SQL files…
new-pr-and-branch
Create a new branch, commits changes, then opens pr against the dev branch.