agentleFS
Sign inStart free
avibebuilderavibebuilder/claude-prime/.claude/skills/cook/SKILL.md

cook

Skill119 starsChanged 6 months agoMITView on GitHub

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

14 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use csv-translator, upgrade-app and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • pass-with-high-scoreSkill

    csv-translator

    Specialized skill for translating large CSV files. It follows a multi-step process of planning, counting lines, splitting large files into manageable chunks, translating chunks, merging, and finally importing translations into Android resource files. Use when the user needs to translate a CSV file, especially large ones.

    Also in 3 projects that use this

  • pass-with-high-scoreSkill

    upgrade-app

    Automates the process of upgrading the app version. Bumps versionCode and versionName in build.gradle.kts, updates the changelog, verifies the build, commits, pushes, and creates a GitHub release. Use when the user says "upgrade app", "release new version", or "bump version".

    Also in 3 projects that use this

  • apetrovSkill

    github-issue-manager

    Manage GitHub issues in the current repo via gh CLI. Use when asked to look up, inspect, design/plan, create, or implement a specific GitHub issue; or to update issue title/body/labels/state with explicit confirmation.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If the request is clear, start.

    line 15
  2. Very specific:

    Every task requires three fields: title, desc, expected.

    line 25
  3. Distinctive:

    Before invoking verification, confirm the edits actually landed on disk.

    line 49
  4. Distinctive:

    Do not mark a task done on confidence alone.

    line 51
  5. Distinctive:

    Update task status as you go so the execution trail stays trustworthy.

    line 53
  6. Distinctive:

    After the task list is complete, review the combined diff before declaring success.

    line 57

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

ultrathink.

How cook works

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.

Before you start

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.

The loop

1. Break into tasks only when it helps

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>

2. Implement → Verify → Review → Next

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:

  • the user-visible claim or acceptance criteria
  • the files or behavior you changed
  • the most likely regression surface
  • any constraints that matter

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.

3. Review the whole change set

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.

4. Report

When done, summarize:

  • what changed
  • how each claim was verified
  • decisions that materially shaped the implementation
  • any follow-up the user should know about

Request

<request>$ARGUMENTS</request>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free