cook

Name: cook
Author: avibebuilder

109stars17forks

How to install cook?

avibebuilder/claude-prime/cook

$npx -y skills add avibebuilder/claude-prime --skill cook

Installs into the current project.

Summary

Implement, 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,

Files · 1

View on GitHub

SKILL.md

1	ultrathink.
2
3	## How cook works
4
5	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.
6
7	## Before you start
8
9	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.
10
11	## The loop
12
13	### 1. Break into tasks only when it helps
14
15	For a small single-concern request, just implement, verify, and continue.
16
17	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.
18
19	Every task requires three fields: `title`, `desc`, `expected`. Read the authoring rubric before writing tasks — bad tasks are worse than no tasks:
20
21	- `.claude/scripts/tasks.py --help` for the short-form rubric and examples
22	- `.claude/scripts/tasks-authoring.md` for the full guide
23
24	```
25	.claude/scripts/tasks.py --task-file <slug> add "<title>" "<desc>" "<expected>"
26	.claude/scripts/tasks.py --task-file <slug> list
27	.claude/scripts/tasks.py --task-file <slug> verify <id> "<evidence>"
28	.claude/scripts/tasks.py --task-file <slug> done <id>
29	```
30
31	### 2. Implement → Verify → Review → Next
32
33	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.
34
35	`/cook` owns implementation. The tester owns verification. Give the tester:
36	- the user-visible claim or acceptance criteria
37	- the files or behavior you changed
38	- the most likely regression surface
39	- any constraints that matter
40
41	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.
42
43	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.
44
45	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.
46
47	Update task status as you go so the execution trail stays trustworthy.
48
49	### 3. Review the whole change set
50
51	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.
52
53	### 4. Report
54
55	When done, summarize:
56	- what changed
57	- how each claim was verified
58	- decisions that materially shaped the implementation
59	- any follow-up the user should know about
60
61	## Request
62
63	<request>$ARGUMENTS</request>

People who liked this also viewed

6 picks

Type

cook

109stars17forks

View on GitHub

How to install cook?

avibebuilder/claude-prime/cook

$npx -y skills add avibebuilder/claude-prime --skill cook

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	ultrathink.
2
3	## How cook works
4
5	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.
6
7	## Before you start
8
9	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.
10
11	## The loop
12
13	### 1. Break into tasks only when it helps
14
15	For a small single-concern request, just implement, verify, and continue.
16
17	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.
18
19	Every task requires three fields: `title`, `desc`, `expected`. Read the authoring rubric before writing tasks — bad tasks are worse than no tasks:
20
21	- `.claude/scripts/tasks.py --help` for the short-form rubric and examples
22	- `.claude/scripts/tasks-authoring.md` for the full guide
23
24	```
25	.claude/scripts/tasks.py --task-file <slug> add "<title>" "<desc>" "<expected>"
26	.claude/scripts/tasks.py --task-file <slug> list
27	.claude/scripts/tasks.py --task-file <slug> verify <id> "<evidence>"
28	.claude/scripts/tasks.py --task-file <slug> done <id>
29	```
30
31	### 2. Implement → Verify → Review → Next
32
33	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.
34
35	`/cook` owns implementation. The tester owns verification. Give the tester:
36	- the user-visible claim or acceptance criteria
37	- the files or behavior you changed
38	- the most likely regression surface
39	- any constraints that matter
40
41	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.
42
43	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.
44
45	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.
46
47	Update task status as you go so the execution trail stays trustworthy.
48
49	### 3. Review the whole change set
50
51	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.
52
53	### 4. Report
54
55	When done, summarize:
56	- what changed
57	- how each claim was verified
58	- decisions that materially shaped the implementation
59	- any follow-up the user should know about
60
61	## Request
62
63	<request>$ARGUMENTS</request>

People who liked this also viewed

6 picks

Type