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 natnew/awesome-ai-scientists --skill feature-specgit clone --depth 1 https://github.com/natnew/awesome-ai-scientistsWrote 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/natnew/awesome-ai-scientists/feature-spec)<a href="https://agentmods.dev/skills/natnew/awesome-ai-scientists/feature-spec"><img src="https://agentmods.dev/badge/skills/natnew/awesome-ai-scientists/feature-spec/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/skills/natnew/awesome-ai-scientists/feature-spec"><img src="https://agentmods.dev/badge/skills/natnew/awesome-ai-scientists/feature-spec.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.00082 | $0.00532 |
| Opus 5.5 | $0.00033 | $0.00213 |
| Sonnet 5.5 | $0.00016 | $0.00106 |
| Haiku 4.5 | $0.00008 | $0.00053 |
Grade A, and why
feature-spec 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 1mo 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.
What it actually says
Feature Spec
Workflow
1. Find the next phase
Read specs/roadmap.md. The next phase is the first section whose items are all [ ]. Note its name to derive the branch and directory name.
2. Create the branch
git checkout -b phase-N-<kebab-name>
3. Interview the user — BEFORE writing any files
Use AskUserQuestion with exactly 3 questions in one call:
| Header | Question focus |
|---|---|
| Scope | What the feature collects, exposes, or does — fields, behaviour, data shape |
| Decisions | Key implementation choices — storage, visibility, validation, UX pattern |
| Context | Tone, constraints, or anything shaping the spec — copy style, stack limits, open questions |
Do not write any files until the user has answered all three questions.
4. Read guidance files
Read specs/mission.md and specs/tech-stack.md before drafting.
5. Create the spec directory
Name: specs/YYYY-MM-DD-<feature-name>/ using today's date.
requirements.md
- Scope section: what is and is not included; field/data table if applicable
- Decisions section: choices made and why (draw from user answers)
- Context section: tone rules, stack pointers, existing patterns to follow
plan.md
- Numbered task groups appropriate to the feature (for example: Data → Components → Page & Route → Navigation → Tests)
- Each group has numbered sub-tasks; groups should be independently implementable
validation.md
- Automated: project test and typecheck commands pass; specific assertions required
- Manual: walkthrough, behaviour, edge cases
- Tone check if the feature has user-facing copy
- Definition of done
Constraints
- Respect the existing tech stack defined in
specs/tech-stack.md— no new dependencies without user approval - Follow existing conventions and patterns already established in the codebase
- Keep feature scope focused and independently shippable
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.
- 1mo ago First seen · 60 lines · 82 tokens per session scan A a1a97378945d
feature-spec is a skill published in the GitHub repository natnew/awesome-ai-scientists (20 stars, last pushed 5d ago), licensed MIT. It adds 82 tokens to every session and 532 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
git-workflow
Git workflow patterns including branching strategies, commit conventions, merge vs rebase, conflict resolution, and collaborative development best practices for teams of all sizes.
run-work
Execute a work unit end-to-end: sequence tasks by dependency, implement, test between tasks, commit, and track progress. Use to deliver a complete feature in one session. Invoked as /agiflow:run-work . Uses getworkunit, listtasks, updatetask, getworkunitprogress.
writing-modpack-changelog
Use when cutting a modpack release. Creates /docs/release-changelog.md if absent; appends a new version section with grouped changes. Triggers - 'cut a release', 'release notes', 'changelog', 'v1.2.3 changes', 'what changed since last version'.
claude-devfleet
Orchestrate multi-agent coding tasks via Claude DevFleet — plan projects, dispatch parallel agents in isolated worktrees, monitor progress, and read structured reports.
git-worktree-isolation
A Git workflow that gives each development task its own worktree, which is a separate working directory linked to a branch. It keeps parallel tasks and experiments apart from the main checkout.
review-prs
Triage open PRs — screen from the diff, delegate the admission judgment to audit-the-list, then merge or close on GitHub. Fire when the maintainer asks to review PRs, process the PR queue, or judge whether a specific PR should be merged.