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 jpantsjoha/ai-native-developer-experience --skill spec-first-deliverygit clone --depth 1 https://github.com/jpantsjoha/ai-native-developer-experienceWrote 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/jpantsjoha/ai-native-developer-experience/spec-first-delivery)<a href="https://agentmods.dev/skills/jpantsjoha/ai-native-developer-experience/spec-first-delivery"><img src="https://agentmods.dev/badge/skills/jpantsjoha/ai-native-developer-experience/spec-first-delivery.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.00037 | $0.00766 |
| Opus 5 | $0.00018 | $0.00383 |
| Sonnet 5 | $0.00007 | $0.00153 |
| Haiku 4.5 | $0.00004 | $0.00077 |
Grade A, and why
spec-first-delivery 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 — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec-First Delivery
Review the spec harder than the code. The cheapest place to be wrong is the spec.
The harness runs in this order: spec → plan → tasks → code. Skipping the spec is not faster — it is a deferred rewrite.
When to use
- Any new feature or epic with more than ~1 day of effort
- Infrastructure or architectural changes
- Anything involving a new external dependency, data boundary, or API contract
- Any time an agent offers to "just start coding"
Procedure
- Establish the vision artifact — confirm the project's vision document exists and is current (e.g.
docs/VISION.mdor equivalent per project structure). If not, create or update it before proceeding. - Write the feature spec — document: what, why, who (user/actor), constraints, acceptance criteria, and out-of-scope. Reject vague specs ("improve performance") in favour of measurable ones ("p99 latency < 200 ms under 1k rps").
- Author or reference the HLD — a high-level design covering: components affected, data flows, integration points, and failure modes. Diagrams preferred (C4 or sequence).
- Create or update ADRs — one ADR per significant technical decision. Format: Context → Decision → Consequences (trade-offs). Number sequentially (
ADR-NNN). - Document constraints up front — security requirements, data residency, budget ceiling, compliance scope, team skill set. Constraints missed here surface as blockers late.
- Validate spec completeness — the spec is done when: acceptance criteria are testable, the failure mode is named, rollback is considered, and cost impact is estimated.
- Only then: generate the implementation plan and tasks. Hand the spec (not a prompt) to the agent.
Outputs
requirements/FEATURE_SPEC.md(or equivalent per project structure)architecture/decisions/ADR-NNN-<short-title>.md(one per decision)architecture/HLD-<feature>.md(if not already covered)- Updated project roadmap (e.g.
docs/ROADMAP.mdor equivalent per project structure) with new tasks or milestones
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 · 51 lines · 37 tokens per session scan A b76394092dc6
spec-first-delivery is a skill published in the GitHub repository jpantsjoha/ai-native-developer-experience (11 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 37 tokens to every session and 766 once invoked, about $0.0002 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-30.
Other skills, from other repositories
last30Days
Resolve "last30Days" to a concrete ISO date range relative to your run time — a rolling 30-day window ending today. Returns inclusive civil dates plus exact UTC instants so you have temporal context without computing dates by hand. Read-only: no writes, no network. Use before a "last 30 days" / trailing-month task…
thisWeek
Resolve "thisWeek" to a concrete ISO date range relative to your run time — this week so far (Monday → today). Returns inclusive civil dates plus exact UTC instants so you have temporal context without computing dates by hand. Read-only: no writes, no network. Use before a week-to-date task (this week's activity…
comet-hotfix
A quick workflow for fixing an existing bug in Comet, a tool that manages structured code changes. It moves through opening the change, building, checking, and archiving it.
comet-verify
Comet Phase 4: Verify and Close. Invoke with /comet-verify. Verify implementation matches design, handle development branch.
comet-design
A workflow guide for turning an existing software change into a detailed technical design document. It builds on earlier proposal and design files and defines implementation risks, tests, and edge cases.
comet-hotfix
Comet preset path: Bug fix / hotfix. Skip brainstorming, directly open → build → verify → archive. Applicable for behavior fixes, scenarios not involving new capability design.