skillboardUpdated every 6 hours
skillboardImplement, build, create, or add any feature, endpoint, page, component, or functionality. Use this skill whenever the user asks you to write new code or make code changes — whether it's adding an API endpoint, building a UI page, creating an export feature, wiring up a webhook, implementing a search/filter, or any other hands-on coding task. This is the default skill for all 'build this', 'add this', 'create this', 'wire up', 'implement' requests. Covers the full cycle: clarify requirements, plan if needed, write code, verify, and review. Do NOT use for pure research, debugging, documentation, or explanation — only when the user wants working code delivered.
ultrathink.
Cook is an incremental loop: break work into tasks, implement one, verify it works, move to the next. The key discipline is that nothing is "done" until there's evidence it works — but how you verify adapts to the situation.
If the request is clear, start. If it's ambiguous or multi-faceted, ask clarifying questions. If the work is large or multi-path, plan first (/give-plan). Otherwise, just start.
For a small single-concern request, just implement, verify, and continue.
For multi-step work or collaboration, use .claude/scripts/tasks.py to track concrete outcomes. Task files persist in .tasks/, so a fresh context can pick up where the last one left off.
Every task requires three fields: title, desc, expected. Read the authoring rubric before writing tasks — bad tasks are worse than no tasks:
.claude/scripts/tasks.py --help for the short-form rubric and examples.claude/scripts/tasks-authoring.md for the full guide.claude/scripts/tasks.py --task-file <slug> add "<title>" "<desc>" "<expected>"
.claude/scripts/tasks.py --task-file <slug> list
.claude/scripts/tasks.py --task-file <slug> verify <id> "<evidence>"
.claude/scripts/tasks.py --task-file <slug> done <id>
Pick the next unblocked task, make the change, then hand off to a tester and (for risky work) a reviewer — isolated teammates that judge the change independently. See .claude/skills/test/teammate.md and .claude/skills/review-code/teammate.md for how to spawn them.
/cook owns implementation. The tester owns verification. Give the tester:
You can still add durable tests, fixtures, or stable selectors when they belong to the product change itself. Do not stuff temporary verification tactics into /cook just to get through one run.
Before invoking verification, confirm the edits actually landed on disk. If the change you expect is missing from the diff, fix that first; a passing check against unchanged code is worthless evidence.
Do not mark a task done on confidence alone. The tester proves the behavior. The reviewer checks that the implementation is correct, scoped, and aligned with the repo. For risky or non-trivial work, spawn a reviewer before marking the task complete.
Update task status as you go so the execution trail stays trustworthy.
After the task list is complete, review the combined diff before declaring success. Cross-task issues often appear only in the final aggregate: mismatched assumptions, naming drift, incomplete ripple updates, or verification that was too narrow. Spawn a reviewer for this final pass.
When done, summarize:
$ARGUMENTS
Copy a source-pinned command for your client. You run it yourself.
Destination: .claude/skills/cook · pinned to the source commit
git clone https://github.com/avibebuilder/claude-prime.git
cd claude-prime
git checkout 80bcfa48ccd599df9316954a24f9249be4c703fc
mkdir -p ".claude/skills/cook"
cp -r ".claude/skills/cook" ".claude/skills/cook"Review the source before running. This copies files into your project; it is not a one-click install and does not verify runtime safety.
Scanner static-checks@0.1.0 · commit 80bcfa48ccd5. Static checks cannot prove runtime safety – review the source and the exact diff before installing. How checks work.
No static rules matched. This is not a safety guarantee.