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/naimkatiman/continuous-improvement/intent-driven-developmentnpx skills add naimkatiman/continuous-improvement --skill intent-driven-developmentgit clone --depth 1 https://github.com/naimkatiman/continuous-improvementWhat 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.00139 | $0.02581 |
| Opus 5 | $0.00069 | $0.01290 |
| Sonnet 5 | $0.00028 | $0.00516 |
| Haiku 4.5 | $0.00014 | $0.00258 |
Grade A, and why
intent-driven-development 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 — 162 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/intent-driven-development: scope the change before you build it
Law 2 says the plan is sacred: once a goal and its acceptance conditions are agreed, you do not silently drift from them. The cheapest way to honor that is to make the plan verifiable in the first place. A goal phrased as "make export work" cannot be held sacred because nobody can tell when it is met. This skill converts an ambiguous or high-impact request into observable acceptance criteria (AC-001, AC-002, ...) with named verification methods, so "done" is a fact two people would agree on, and a criterion can never be quietly dropped mid-build.
It produces useful criteria without turning specification into ceremony: inspect available context first, expose only genuine ambiguity, and choose verification that fits the work and its risk.
When to activate
- The user asks to clarify a feature, define acceptance criteria, or de-risk a change before implementation.
- The request touches security, authentication, persistent data, migrations, external APIs, or compliance.
- The user wants a handoff artifact another agent or team can implement without inventing requirements.
- The request is ambiguous enough that the expected outcome is not yet observable or testable.
- The user types
/intent-driven-development, "define acceptance criteria", "scope this change", or "make this testable".
Do not activate for trivial edits, one-line fixes, active debugging, code review, or implementation requests whose acceptance conditions are already clear.
How it works
- Inspect context first. Read the repository, docs, schemas, and test infrastructure for technical facts before asking any question. Treat product and business constraints as something only the user or a product artifact can supply.
- Choose depth. Quick Capture (3-7 criteria, low or moderate risk) or Full Acceptance Brief (security, data, migration, cross-system, or handoff).
- Ask minimally. Only ask questions whose answers cannot be inferred and that materially change scope or behavior. Group related questions into one batch.
- Write observable criteria. Each AC-NNN names a scenario, a trigger, an expected observable result, a prohibited side effect when meaningful, a verification method, and a priority. Do not use "correctly" or "securely" without defined evidence.
- Proceed or hand off. For a clear request with no blocking risk, record the criteria and continue. For a risky change, present the blockers and wait for confirmation.
- Hold the plan sacred. If a criterion cannot be met due to a constraint found mid-build, do not silently drop or work around it. Mark it
[revised], state the constraint, adjust scope or verification, increment the revision number, and re-present only the changed criteria before continuing.
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 · 162 lines · 139 tokens per session scan A cf5d9ccf28b6
intent-driven-development is a skill published in the GitHub repository naimkatiman/continuous-improvement (7 stars, last pushed 7d ago), licensed MIT. It adds 139 tokens to every session and 2,581 once invoked, about $0.0007 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
html-ppt-zhangzara-coral
OpenDesign's community-growth campaign across GitHub, Discord, and X: the loops, the content calendar, and the pipeline math. Built as a decision-grade marketing & GTM deck for growth team, community lead.
hr-onboarding
A new-hire onboarding plan as a single page — first week schedule, buddy + manager intro, learning track, equipment checklist, and "you're set when…" outcomes. Use when the brief mentions "onboarding", "new hire", "first week plan", or "入职".
html-ppt-hermes-cyber-terminal
OpenDesign + BYOK: choosing and wiring your own model, hands-on — cost, quality, and the routing decision. Built as a decision-grade AI literacy deck for engineers, IT, applied-AI teams.
html-ppt-taste-brutalist
16:9 HTML deck in tactical-telemetry / CRT-terminal taste. Deactivated-CRT charcoal slides, white-phosphor monospace, hazard-red accent, scanline overlay, ASCII syntax, density over decoration. Distilled from Leonxlnx/taste-skill brutalist-skill (Tactical Telemetry mode).
git-ai-search
Search and restore AI conversation context from git history.
doca-dma
Use this skill when the user is doing hands-on DOCA DMA programming — bringing up a docadma context, configuring the single docadmataskmemcpy task type, sizing buffers via the docadmacaptaskmemcpy queries, setting LOCALREADONLY / LOCALREADWRITE permissions on source / destination docammap regions (plus docammapexport…