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/pjuniszewski/cook/feature-developmentnpx skills add PJuniszewski/cook --skill feature-developmentgit clone --depth 1 https://github.com/PJuniszewski/cookWhat 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.00017 | $0.07101 |
| Opus 5 | $0.00009 | $0.03550 |
| Sonnet 5 | $0.00003 | $0.01420 |
| Haiku 4.5 | $0.00002 | $0.00710 |
Grade A, and why
feature-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.
This is a copy
98% identical to cook — 171 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 1,169 lines — stays where its author put it; the contents beside it link to each section on GitHub.
feature-development skill
⛔ CRITICAL: PLANNING ONLY - NO CODE
/cook produces ONLY an artifact file. Do NOT implement any code.
- ❌ NO adding/modifying source files
- ❌ NO creating classes, functions, or components
- ❌ NO running implementation tests
- ❌ NO writing actual code beyond file path references
- ❌ NO "Implementation" step in todo list
- ✅ ONLY produce the artifact file (
cook/*.cook.md)
After cooking is complete, user will separately request implementation.
Correct todo list for /cook:
- Create artifact file (FIRST!)
- Product review - scope & acceptance criteria
- UX review - interaction design
- Architecture review - technical approach
- Security review - risk assessment
- QA review - test plan
- Finalize artifact
WRONG - do NOT include:
- ❌ Implementation
- ❌ Write code
- ❌ Any coding step
⚡ IMMEDIATE FIRST ACTION - EXECUTE NOW
Your VERY FIRST tool call MUST be Write to create the artifact file.
Execute this Write call IMMEDIATELY:
Write(
file_path="cook/<feature-slug>.<YYYY-MM-DD>.cook.md",
content="<full skeleton below>"
)
BLOCKED ACTIONS until artifact exists:
- ❌ Read (any file)
- ❌ Glob/Grep (any search)
- ❌ Task/Explore (any agent)
- ❌ Bash (any command)
ONLY ALLOWED first action: Write artifact file.
A PreToolUse hook will BLOCK other tools until artifact exists.
# Cooking Result
## Dish
<1-2 sentence description of what we're building>
## Status
raw
## Cooking Mode
well-done
## Current Phase
Step 0.0 - Artifact Created
## Ownership
- Decision Owner: _TBD_
- Reviewers: _TBD_
- Approved by: _TBD_
---
# Phase 0 - Project Policy & Context
## Sources Scanned
| File | Status | Key Rules |
|------|--------|-----------|
| CLAUDE.md | _Pending_ | |
| README.md | _Pending_ | |
| .claude/agents/*.md | _Pending_ | |
## Hard Rules (must not be violated)
_Pending..._
## Preferred Patterns
_Pending..._
## Detected Conflicts
_Pending..._
## Policy Alignment Risk
_Pending..._
---
# Step 1 - Read the Order
## Feature Summary
_Pending..._
## Affected Modules/Components
| Module | Impact | Risk Level |
|--------|--------|------------|
| | | |
## Dependencies
_Pending..._
## Microwave Blocker Check
_Pending..._
---
# Step 2 - Ingredient Approval (Product Review)
## Product Decision
_Pending: Approved / Rejected / Deferred_
## Scope
### In Scope
- _Pending..._
### Out of Scope
- _Pending..._
### Non-goals
- _Pending..._
## User Value
_Pending..._
## Assumptions
- _Pending..._
---
# Step 3 - Presentation Planning (UX Review)
## UX Decision
_Pending: Required / Not Required_
## User Flow
_Pending..._
## UI Components Affected
| Component | Change Type | Notes |
|-----------|-------------|-------|
| | | |
## Accessibility Considerations
_Pending..._
---
# Step 4 - Implementation Plan
## Architecture Decision
### Selected Approach
_Pending..._
### Alternatives Considered
| Option | Pros | Cons | Decision |
|--------|------|------|----------|
| Option A | | | Rejected: _reason_ |
| Option B | | | **Selected**: _reason_ |
### Trade-offs
- Sacrificing: _what we give up_
- Gaining: _what we get_
## Patch Plan
### Files to Modify
| File | Change | Risk |
|------|--------|------|
| | | |
### Commit Sequence
1. _commit message_
2. _commit message_
### High-risk Areas
- _area needing extra attention_
---
# Step 5 - QA Review
## Test Plan
### Test Cases
| # | Scenario | Given | When | Then |
|---|----------|-------|------|------|
| 1 | Happy path | | | |
| 2 | Edge case | | | |
| 3 | Error case | | | |
### Edge Cases
- _edge case 1_
- _edge case 2_
### Acceptance Criteria
- [ ] Given _context_, when _action_, then _result_
- [ ] Given _context_, when _action_, then _result_
### Regression Checks
- _existing feature to verify_
---
# Step 6 - Security Review
## Security Status
- Reviewed: _yes/no_
- Risk level: _low/medium/high_
## Security Checklist
| Check | Status | Notes |
|-------|--------|-------|
| Input validation | _Pending_ | |
| Auth/authz | _Pending_ | |
| Data exposure | _Pending_ | |
| Injection vectors | _Pending_ | |
## Issues Found
_Pending..._
---
# Step 7 - Documentation
## Documentation Updates
| File | Change Needed |
|------|---------------|
| | |
## New Documentation Needed
_Pending..._
---
# Risk Management
## Pre-mortem (3 scenarios required)
| # | What Could Go Wrong | Likelihood | Impact | Mitigation |
|---|---------------------|------------|--------|------------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
## Rollback Plan
1. _step 1_
2. _step 2_
## Blast Radius
- Affected users/modules: _list_
- Feature flag: _yes/no (name)_
- Rollout strategy: _immediate/gradual/canary_
---
# Decision Log
| Date | Phase | Decision | Rationale |
|------|-------|----------|-----------|
| <today> | Step 0.0 | Artifact created | Starting cook flow |
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 · 1,169 lines · 17 tokens per session scan A 9c836360e5e1
feature-development is a skill published in the GitHub repository PJuniszewski/cook (13 stars, last pushed 6mo ago), licensed MIT. It adds 17 tokens to every session and 7,101 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 98% identical to cook, differing in 171 lines, and is treated as a copy.
Other skills, from other repositories
performance-optimization
Optimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks.
doubt-driven-development
Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now…
test-driven-development
Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
ci-cd-and-automation
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
context-engineering
Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump…