Ask Kent

You don't remember every skill, so ask.

A flow is a path through the skills. Most work travels one main flow. Everything else is a close call or a skip.

How to answer

1. Place the situation on the main flow at a step.
2. Name the next /skill to type, and why the near-miss is wrong.
3. Say where a human decision sits (architecture, recap classification, merge).
4. Stop. Do not start the work. Do not invoke the skill you named.
5. If a claim about another skill matters, read that SKILL.md first. This map is a secondary source. The skill file wins.

This is a hand-written map of this repo. Do not scan skills/, do not route over repo-local skills (Kody's conduct, remix, …), and do not route over another author's skills. Cursor's cloud-agent /orchestrate plugin is a different skill from this repo's /orchestrate.

If they already know the skill, tell them to invoke it. /ask-kent has nothing useful to add.

The main flow: idea → ship

The route most work travels.

flowchart TD
	sit[Situation] --> decide{Need options first?}
	decide -->|yes| rnr["/review-and-recommend"]
	decide -->|no| big{Large or parallel?}
	big -->|yes| orch["/orchestrate"]
	big -->|no| plan{Non-trivial system change?}
	orch --> plan
	plan -->|yes| vplan["/visual-recap plan"]
	plan -->|no| build[Build]
	vplan --> build
	build --> recap{PR + worth a system map?}
	recap -->|yes| vrecap["/visual-recap recap"]
	recap -->|no| ship["/ship-pr"]
	vrecap --> ship

Decision-shaped ask? Need evidence-backed options before implementing → /review-and-recommend. It stops and waits.

1. Branch: is this large, multi-stream, or too much for one agent?

   • Yes → /orchestrate. Two modes: be the orchestrator (plan, delegate, review, integrate), or spawn one if you are a cheap/fast model. Frontier model orchestrates; cheap/fast models implement. You do the QA — never declare done from sub-agent reports.
   • No → stay in this session and build it. Fan-out that does not pay is orchestration theater.

2. Branch: is the change non-trivial? System primitives, architecture, contracts, review-critical behavior.

   • Yes → /visual-recap in plan mode before you implement. Classify against docs/contributing/architecture/primitives.yaml in the working repo. Lowest-risk outcome: the plan requires no primitive change — say so.
   • No → skip. A tiny, obvious diff reviews faster as a plain diff.

3. Build. /orchestrate delegates this. A small change you just do.

4. PR exists → /visual-recap in recap mode. Reads git diff <base>...HEAD, not memory. Replaces a plan-mode block. Re-run after significant new commits.

5. Babysit until it's landed → /ship-pr. Mark ready, wait on CI (composes loop-on-ci / fix-ci), address valid review feedback, rebase if needed. Merge only if asked or the change is low risk. Always Discord-summarize via kody:@kentcdodds/discord/send-shipped-pr — never raw post-message, never guess token cost.

Keep plan → recap → ship in the repo that owns the PR. /orchestrate is the parent session; implementer context is disposable.

Situation → route

Your situation	Type this	Not this
Decision-shaped ask before implementing	/review-and-recommend	Jumping to build or /visual-recap
Idea is big, parallel, or multi-stream	/orchestrate	Building it all yourself
You are a cheap/fast model handed a large task	/orchestrate (spawn a smarter orchestrator)	Doing the bulk coding
Planning a non-trivial change	/visual-recap (plan)	Recap mode — the work does not exist yet
PR needs a system-level summary	/visual-recap (recap)	Plan mode — read the diff
Tiny, obvious diff	skip visual-recap	A recap nobody will open
CI, review, merge, Discord summary	/ship-pr	Re-explaining the babysit loop
Need to run Kody execute / call Kody packages	/prefer-local-kody-execute	Hosted MCP execute as the default
Already know the skill	that skill	/ask-kent
Working repo has no primitives.yaml	say so; don't fake a recap	Inventing primitive ids
Not Kent / no Kody Discord exports	fork ship-pr or skip Discord	Pretending the Discord step will work

Close calls

The useful part of this map. One concrete test each.

• /review-and-recommend vs just build. Does a human need to pick among real options first? If yes, review and wait. If the path is obvious, build.
• /orchestrate vs just build. Can one agent finish the critical path in this window without file conflicts? If yes, build. Fan out only when independent workstreams clearly beat one implementer.
• This /orchestrate vs Cursor's plugin. Same slash name, different job. This skill keeps sub-agents in one environment, splits models, and has you QA. Cursor's plugin fans work across cloud agents via its own SDK. This map only names this repo's skill.
• visual-recap plan vs recap. Does the work exist? Plan describes the intended change. Recap describes the diff. Never recap from session memory.
• visual-recap vs skip. Would a reviewer benefit from a system map before the diff? If no, skip. Recap is review overhead.
• ship-pr vs "just merge it". Need the CI/review loop and the Discord summary? That's /ship-pr. Merge is a branch inside it, not a different skill.
• /prefer-local-kody-execute vs hosted MCP execute. Shell + Node ≥ 22 + kody login or KODY_API_TOKEN? Prefer CLI --local. Hosted is fallback when local is inappropriate.

Preconditions

The router names skills; it does not install them. npx skills add kentcdodds/kcd-skills (or --skill <name>). Skills with disable-model-invocation: true (ask-kent, orchestrate) still exist — type the slash command anyway.

• /visual-recap needs docs/contributing/architecture/primitives.yaml in the working repo, plus gh auth to upsert the PR block.
• /ship-pr needs gh auth and Kent's Kody packages (kody:@kentcdodds/github, kody:@kentcdodds/discord). The Discord step is Kent-specific. Prefer CLI local execute for those calls (see /prefer-local-kody-execute).
• /prefer-local-kody-execute needs Node ≥ 22, @kodycodes/cli, and auth via kody login (interactive) or KODY_API_TOKEN (CI / Cloud Agents). Feature flags: mcp-api-tool + local-execute.
• /orchestrate needs a harness that can spawn sub-agents.

It's working if

• It ends by naming what to type and stops, instead of starting the work.
• The route says where you review or verify, not just a list of skill names.
• Close skills get one concrete test for why the other is wrong.
• Any load-bearing claim about another skill shows up as a read of that SKILL.md.
• You recognize your situation, not the nearest generic scenario.