Choose a practical Skill workflow

Start from a real delivery situation, run the smallest useful Skill chain, and carry reviewed artifacts through each gate.

A workflow is useful when one Skill cannot safely own the whole outcome. Start from the situation you have now, choose the shortest chain that produces the required evidence, and stop at every human or authority gate.

Use the five-stage shape

Most reliable chains follow this shape:

understand → decide → execute → verify → deliver

Collapse stages when the task is small. A one-file edit with clear acceptance criteria may need only ak:cook --fast; an authentication or payment change still needs separate planning, security, testing, and review.

Choose by situation

What you have now	Start here	Practical recipe
Clear feature, refactor, or UI change	Software delivery	brainstorm when needed → plan → cook → test → code-review
Unclear requirements or a high-impact design decision	Planning and research	scout/research → brainstorm → gated plan → approval
Reproduction, error, failed test, or flaky behavior	Debug and fix	debug → cause-aligned fix → regression test → review
Local branch or open PR ready for review	Review and ship	pending/PR review → fix loop → tests → authorized ship
Auth, payment, public API, secrets, or infrastructure change	High-risk delivery	domain Skill → gated plan → implementation → security → independent review
Screenshot, design brief, React UI, or performance issue	Frontend delivery	design → implementation → browser evidence → review
Three or more independent workstreams	Parallel delivery	parallel plan → isolated ownership → integration → independent verification
Launch, funnel, campaign, or content program	Marketing growth	evidence → plan → scoped production → measurement
Product delivery and launch must stay aligned	Cross-Kit product launch	Marketing brief → Engineer evidence → launch reconciliation

If you cannot identify the row, use ak:agentkit with the outcome, constraints, and authority boundary. Once the route is clear, invoke the owning Skill directly.

Invoke one step at a time

Claude Code and Cursor use /ak:<skill>. Codex uses $ak:<skill> when that Skill is available on the Codex adapter.

/ak:plan --hard "Add offline draft recovery; preserve the document format; stop before implementation"

$ak:plan --hard "Add offline draft recovery; preserve the document format; stop before implementation"

Do not paste an entire chain as one prompt. Review the output of each step, then pass its approved artifact and remaining constraints to the next Skill.

Carry a practical handoff

Use this compact contract between steps:

Goal and observable outcome:
Approved scope and non-goals:
Evidence and decisions:
Artifact produced (path or link):
Checks passed and failed:
Open risks or questions:
Authority granted for the next step:
Next gate and stop condition:

Use Engineer ak:handoff or Marketing ak:handoff when another session, owner, runtime, or Kit continues the work.

Distinguish `ak:advise` from `--advice`

Surface	Use it for	What it does not do
ak:advise	Interview and reframe a fuzzy problem before planning	It does not implement or approve work.
`--advice` on supported workflow Skills	Add advisory checkpoints inside brainstorm, plan, cook, fix, or vibe	It does not remove review, safety, or authority gates.

For a high-impact feature, a practical advised chain is:

/ak:advise "Reframe the problem and identify the decision we must make"
/ak:plan --hard "<accepted outcome>" --advice
# Review the generated plan.
/ak:cook @<plan-path> --tdd --advice
/ak:test
/ak:code-review --pending

Skip the standalone advisory interview when requirements are already crisp. Use --advice selectively for elevated risk or a difficult decision, not on every trivial edit.

Avoid common workflow mistakes

Avoid	Prefer
A five-Skill chain for a tiny edit	One `ak:cook --fast` request with explicit acceptance checks
Starting implementation while the plan still has unresolved decisions	Resolve or explicitly defer the decision, then approve the plan
Treating a failed test as permission to weaken the criteria	Return the evidence to the implementation or fix step
Running `ak:ship` before review and tests	Complete the review/verification gates first
Routing to an unavailable Skill	Check the Kit inventory or use `ak:agentkit`/`ak:find-skills`
Continuing after the same failure twice	Escalate to a focused debug pass with captured evidence

Resume from the failed gate with new evidence. Restart the whole workflow only when the accepted outcome, core approach, or acceptance criteria changed.