Implement technical work with ak:cook

Use ak:cook in Marketing Kit to implement a clear technical task or an approved implementation plan in the current project. The Skill scouts the codebase, creates or loads a plan, changes files, tests the result by default, and requires code review before finalization.

This is a code-delivery workflow even though it is resolved through Marketing Kit. Use Marketing domain Skills for campaign strategy, copy, audience research, or creative production; use ak:cook when the deliverable is an implementation such as a landing-page component, analytics integration, or marketing automation code change.

Choose ak:cook when technical scope is ready

Use ak:cook when

• The desired code behavior, constraints, non-goals, and acceptance criteria are known.
• You have an approved plan and want to execute it against current project evidence.
• A marketing surface needs a technical feature or refactor with focused tests and code review.
• You accept scoped workspace edits and validation commands.

Choose another workflow when

• The desired marketing outcome or approach is unclear. Start with ak:brainstorm.
• You need a Marketing-owned implementation or CRO plan without implementation. Use ak:plan.
• You have a concrete bug or failing check. Use ak:fix, which proves the root cause before changing code.
• You want advice without workspace mutation. Use ak:ask.
• The deliverable is campaign content or a marketing asset rather than code. Choose the relevant domain Skill from the Marketing Kit.

Prepare the project and authority boundary

Before starting:

• Complete Onboarding and confirm Marketing Kit is installed for the runtime and scope in use.
• Open a project where the assistant may edit files and run its checks.
• Preserve unrelated work and name the intended files, modules, and public contracts.
• Provide either concrete requirements or an approved plan path.
• Read repository instructions and state whether Git, network calls, provider accounts, publication, deployment, and sensitive data are outside the run.

Run the Skill

/ak:cook "Add consent-aware UTM capture to the existing signup form, reuse the current analytics adapter, add focused tests, and do not commit, publish, or deploy"

/ak:cook "Add consent-aware UTM capture to the existing signup form, reuse the current analytics adapter, add focused tests, and do not commit, publish, or deploy"

$ak:cook "Add consent-aware UTM capture to the existing signup form, reuse the current analytics adapter, add focused tests, and do not commit, publish, or deploy"

You can also pass an approved plan path, such as /ak:cook ./plans/utm-capture/plan.md in Claude Code or Cursor and $ak:cook ./plans/utm-capture/plan.md in Codex.

Choose the execution mode deliberately

Do not use --auto or --no-test to bypass a missing decision, failed check, or side effect.

Describe technical work precisely

Give the Skill five elements:

• Outcome: The user-visible or system-visible behavior to implement.
• Constraints: Existing patterns, consent and privacy rules, compatibility, modules, and tools that must be preserved.
• Non-goals: Adjacent campaign, analytics, content, or infrastructure work that is excluded.
• Acceptance criteria: Observable behavior, error cases, tests, and repository checks.
• Authority boundary: Whether Git, network/provider access, live accounts, publication, deployment, spend, or destructive actions are excluded.

Understand the delivery stages

1. Capture or reuse the contract. The workflow records outcome, constraints, non-goals, and acceptance criteria.
2. Detect the mode. Explicit flags take priority; a plan path selects plan execution; otherwise the default is interactive.
3. Scout the project. The Skill finds the stack, relevant files, patterns, tests, documentation, plans, and public contracts.
4. Research and plan. Research runs when the mode calls for it. A reviewed plan exists before implementation, including in --fast mode.
5. Implement the approved scope. Work follows plan order and current project conventions. Parallel work requires clear file ownership.
6. Simplify when signaled. A large live diff can trigger a scoped simplification pass without changing behavior.
7. Test and review. Tests run unless --no-test is selected. Code review is mandatory in every mode and checks acceptance, regressions, public contracts, project patterns, and repository errors.
8. Finalize evidence. The workflow reconciles plan state, evaluates docs impact, reports changed files and checks, and enters Git work only through a separate approval flow.

Keep approval and external effects separate

If a test or review exposes a regression, changed public contract, or side effect, the workflow should stop and show what broke, why, and bounded choices. Do not hide the evidence with --no-test, --auto, or a force operation.

Verify the output and evidence

A complete run should provide:

• A scoped implementation diff following existing project patterns.
• Tests added or updated where needed, plus commands and fresh results unless --no-test was explicitly selected.
• Code-review findings and the disposition of every blocker or warning.
• Evidence for each acceptance criterion and a blast-radius check for affected behavior.
• Updated plan progress when the run used a plan.
• A final report naming changed files, checks, remaining risks, and approvals still required.

The implementation is not complete merely because files changed. Relevant tests and repository checks must pass, review must have no unresolved blocker, and you must accept the diff. With --no-test, record that functional test evidence is missing.

Troubleshoot the run

Know the current limits

• The source workflow is code- and implementation-oriented; Marketing Kit does not turn it into a general campaign executor.
• It can only use tools, credentials, project access, and validation commands available in the session.
• Runtime projection is capability-specific, so Agent delegation, Hooks, task tracking, and UI can differ.
• The workflow does not guarantee conversion, revenue, campaign performance, provider behavior, or deployment success.
• Stable and beta contain identical ak:cook source content and invocations.

Continue with ak:plan to prepare work, ak:fix for a concrete defect, or the Marketing Kit overview for domain workflows.