Implement approved work with ak:cook

Use ak:cook to turn clear requirements or an approved implementation plan into a tested, reviewed code change. The Skill inspects the current project, keeps the implementation tied to observable acceptance criteria, and reports the evidence you need to decide whether the result is complete.

Choose ak:cook when the scope is ready

Use ak:cook when

• You have a feature, refactor, or maintenance task with a defined outcome.
• The important constraints, non-goals, and acceptance criteria are known.
• You have an approved plan and want to execute it against the current codebase.
• You want implementation, focused testing, and code review in one coordinated workflow.

Choose another workflow when

• The desired outcome or solution is still unclear. Start with ak:brainstorm, then use ak:plan when the direction is settled.
• You are investigating a concrete bug, failing test, or CI failure. Use ak:fix, which requires root-cause evidence before choosing a correction.
• You only need independent verification. Use ak:test for testing or ak:code-review for review without starting a new implementation.
• You need advice rather than workspace changes. Use an advisory or question workflow first.

Prepare the project and runtime

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Open a project where you are comfortable allowing the assistant to edit files and run the project's validation commands.
• Preserve unrelated work, and make the intended file or module boundary clear.
• Provide either concrete requirements or the path to an approved plan.
• Read the repository instructions and any project-specific safety requirements that should govern the run.

ak:cook is packaged for all three supported Engineer targets:

See Runtime adapters for scope, delivery, and component-level differences.

Run the Skill

If you omit a mode flag, the Skill runs interactively; you can also select it explicitly with --interactive. It pauses at major review gates so you can inspect findings, approve the plan, request changes, or stop.

/ak:cook "Add POST /api/feedback with existing authentication, return 202, store no new data, add focused tests, and do not commit or deploy"

/ak:cook "Add POST /api/feedback with existing authentication, return 202, store no new data, add focused tests, and do not commit or deploy"

$ak:cook "Add POST /api/feedback with existing authentication, return 202, store no new data, add focused tests, and do not commit or deploy"

You can also pass an approved plan path. Use /ak:cook ./plans/feedback-endpoint/plan.md in Claude Code or Cursor, and $ak:cook ./plans/feedback-endpoint/plan.md in Codex. The Skill reuses the plan's outcome and acceptance criteria, then checks the current project evidence before making changes.

Choose an execution mode deliberately

Use explicit options when execution shape matters. Do not use --auto or --no-test merely to move past an unresolved decision or failure. When --yagni is selected, the Skill passes the literal flag to downstream Skills and delegated work so the opt-in survives each handoff.

Describe the work clearly

A useful request gives the Skill five things:

• Outcome: State the user-visible or system-visible behavior to deliver.
• Constraints: Name the patterns, modules, compatibility requirements, or tools the implementation must preserve.
• Non-goals: Exclude tempting adjacent work that would expand the scope.
• Acceptance criteria: Give observable checks for success, including expected errors and edge cases.
• Authority boundary: State whether Git, publication, deployment, external services, sensitive data, or destructive actions are outside the run.

For the feedback endpoint example, a strong input says to reuse current authentication and API patterns, return 202, avoid a new persistence layer, cover authorized and unauthorized requests, and stop before commit or deploy. That is more actionable than “build a feedback API” because it defines both the result and the boundaries.

Understand what happens during a run

You should observe a concise progression rather than an unexplained block of edits:

1. The Skill confirms the contract. It captures or reuses the outcome, constraints, non-goals, and acceptance criteria, and asks only about a material missing decision.
2. The Skill inspects the project. It identifies the stack, relevant files, existing patterns, project instructions, nearby documentation, and public contracts that the change could affect.
3. The Skill creates or loads a plan. Research is included when the selected mode needs it. In interactive modes, you review the plan before implementation.
4. The Skill implements the approved scope. Work follows plan order and discovered project conventions, with progress tied back to the active plan when one exists.
5. The Skill verifies the change. Testing runs by default, and code review is mandatory in every mode. Failures, regressions, or contract changes remain visible rather than being silently worked around.
6. The Skill finalizes the evidence. It reconciles plan progress, evaluates documentation impact, summarizes changed files and checks, and asks before entering a separate Git workflow.

The workflow may use specialized Agents to inspect, implement, test, debug, or review parts of the task. Their internal instructions are not the deliverable; the user-facing result is the scoped change and its evidence.

Keep approval and safety with you

The Skill will not decide these matters for you:

• Whether a changed requirement or public contract is acceptable.
• Whether a failing or skipped test is an acceptable release risk.
• Whether a regression should be fixed, reverted, isolated behind compatibility behavior, or explicitly accepted.
• Whether credentials or sensitive data may be sent to an external service.
• Whether the result should be committed, pushed, opened as a pull request, merged, published, or deployed.

If verification finds an unintended side effect, the run should stop and show what changed, why it happened, and bounded recovery choices. Do not use --no-test, --auto, or a broad force operation to hide that evidence.

Verify the result

A complete run should give you:

• A scoped implementation diff that follows the project's existing patterns.
• Tests added or updated where needed, plus the commands and results used for verification unless you explicitly selected --no-test.
• Mandatory code-review findings and the disposition of any blocker or warning.
• Evidence that acceptance criteria were checked and nearby behavior did not regress.
• Updated plan progress when the run started from or created a plan.
• A concise final report naming changed files, validation, remaining risks, and any action that still needs your approval.

Treat the run as complete only when the acceptance criteria are met, relevant tests and repository checks pass, code review has no unresolved blocker, and you accept the resulting diff. With --no-test, completion must explicitly record that test evidence is missing; code review alone does not prove the implementation works.

Troubleshoot or continue

Continue with the Engineer Kit overview, compare Runtime adapters, or use the CLI reference for exact AgentKit lifecycle commands.

Understand the plan reminder boundary

Engineer exports the cook-after-plan reminder on wildcard Stop only; it does not ship a SubagentStop registration for this reminder. When no active plan is bound, the Hook exits 0 with empty stdout, regardless of model. When a plan is active, it emits valid, nonblocking JSON shaped as {"continue":true,"systemMessage":"..."}. Empty stdin stays silent, and malformed nonempty stdin is handled fail-open instead of blocking the session.

Know the current limits

• The Skill can only use tools, credentials, runtimes, and project access that are available in the current session.
• Runtime projection is capability-specific. The same Skill workflow does not imply identical Hooks, Agent behavior, plan tooling, or UI across runtimes.
• Cursor slash invocation is user-verified evidence. It does not establish full Cursor parity, and the Engineer statusline remains unavailable there.
• Codex runs the Skill through native discovery, but some Engineer Hook groups cannot be projected and its statusline is unavailable.
• Runtime-specific Hook projection does not change this Skill's workflow or grant the reminder authority to block completion.