ask-kent

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

Place the situation on the main flow at a step.
Name the next /skill to type, and why the near-miss is wrong.
Say where a human decision sits (architecture, recap classification, merge).
Stop. Do not start the work. Do not invoke the skill you named.
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.

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.
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.
Build. /orchestrate delegates this. A small change you just do.
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.
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.