Ask Smitt

You don't remember every skill, so ask.

A flow is a path through the skills. Most paths run along one main flow, and two on-ramps merge onto it. Everything else is standalone.

Repository setup

Use setup-federated-workflow to configure a repository's Code Host, Work Tracker, Routing Labels, and Domain Orientation before using configured planning and delivery. For several repositories, it can establish a Domain Federation or join an existing one. Confirm domain ownership, Home, and Ticket Origins through setup. Review and accept the configuration into every participating repository's configured Base Branch before treating it as authoritative.

The main flow: idea → ship

The route most work travels. You have an idea and want it built. If the effort is too large or uncertain to settle in one session, start with the wayfinder on-ramp below, then return at to-spec once its decisions are settled.

1. grill-with-docs — sharpen the idea by interview. Start here when you have a codebase: it applies the project's domain language and returns every confirmed language or architecture change with the sharpened result. In this flow, the current conversation retains that result as planning authority for to-spec. (No codebase? Use grill-me — see Standalone. Both run the same grilling primitive; grill-with-docs adds domain modeling.)
2. Branch — can you settle every question in conversation? If a question needs runnable evidence, detour through prototype, bridged by handoff in both directions (see Phase boundaries):
   • handoff out, then open a separate task against that file,
   • run prototype,
   • handoff back what you learned, and reference it from the original planning task.
3. Branch — is this a multi-task build?
   • Yes → to-spec (turn the conversation into a spec), then to-tickets to split it into tracer-bullet tickets, each declaring its blocking edges. On a local tracker that's one file per ticket under .scratch/<feature>/issues/; on a real tracker the edges become native blocking links. Use deliver-spec for the prepared specification's shared branches and final review, or deliver-ticket for one eligible ticket.
   • No → implement right here, in the same task.

Context hygiene

Keep steps 1–3 in one task so the grilling, spec, and tickets build on the same reasoning. Automatic compaction may summarize earlier turns as the task grows. That is continuation within the same task, not a handoff. Before leaving a phase, capture decisions that the next phase cannot safely reconstruct in the flow's durable artifacts.

Implementation starts from complete ticket authority, whether the ticket changes one repository or several. It does not need the planning task's full conversation.

Review, acceptance, and closeout

deliver-ticket owns one eligible ticket per activation. It coordinates isolated repository deliveries, repository Standards reviews, publication, cross-repository validation, and whole-bundle Spec review. It hands the ticket back open and unassigned as ready-for-human, recording completed merges and remaining human actions.

deliver-spec schedules prepared tickets in separate contexts, runs independent tickets in parallel, and closes each ticket only when its completion criteria pass. It retains shared branches and validates the assembled specification for final human review and merge. Resume it with the same Specification for interruptions or final-review corrections without a mandatory new ticket. Specification closeout remains explicit.

Use change-walkthrough to explore a result and review-feedback to draft or publish authorized feedback. Returning the ticket for correction is an explicit review-feedback operation. Use code-review for a separate review of fixed repository targets and pr to write a PR or MR description.

After acceptance and any required deployment verification, invoke closeout to record completion, transition the ticket, and remove verified disposable worktrees and branches. For an interrupted coordinated delivery, invoke deliver-ticket with the same ticket reference so it can reconcile existing state before resuming.

On-ramps

A starting situation that generates work, then merges onto the main flow.

• Bugs and requests piling up → triage. It moves issues through triage roles and produces agent-ready issues for a separately invoked deliver-ticket run.

  Triage is only for issues you didn't create — bug reports, incoming feature requests, anything that arrives raw. Tickets that to-tickets produced are already agent-ready, so don't triage them.

• A huge, foggy effort — a greenfield project or a huge feature build, too big for one session → wayfinder, the most cognitively demanding flow here. When the way from here to the destination isn't visible yet, it charts a shared map of decision tickets on the issue tracker. Each ticket has one claimant; independent ready research may proceed in parallel, while dependent decisions wait for their blockers — producing decisions, not deliverables — until the fog is pushed back and the way is clear. Where grill-with-docs sharpens an idea you can hold in one session, wayfinder is for the idea you can't — and it's slower and denser, so save it for exactly that, never a well-scoped feature.

  When the map clears, it hands off, it doesn't build: merge onto the main flow at to-spec, which collapses the map's linked decisions into a buildable plan, then to-tickets. Each resulting ticket can use implement across all repositories it authorizes for change. Looping the map straight into implement skips the collapse and throws linked detail away — do that only when the effort turned out genuinely small and receives explicit execution authority.

Codebase health

Not feature work — upkeep.

• improve-codebase-architecture — run whenever you have a spare moment to keep the codebase good for agents to operate in. It surfaces deepening opportunities; picking one generates an idea you can take into the main flow at grill-with-docs. The survey finds the candidates; codebase-design designs the selected one.

Phase boundaries

A phase is a coherent stretch of work such as grilling, specification, implementation, or review. At the boundary between phases, choose by ownership and destination:

1. Continue in the current task when the next phase advances the same objective in the same working context and benefits from the reasoning already here. Use this path normally through grilling, to-spec, and to-tickets.
2. Let automatic compaction continue the task when earlier turns are summarized automatically. Compaction does not create a new task or transfer ownership. Continue from the summary, checking durable artifacts when exact decisions matter.
3. Use handoff for another task or repository when the work needs a new owner, a separate task history, or a different repository context. The handoff file carries the relevant decisions and evidence across that boundary. A prototype in its own task or repository is the standard case.
4. Delegate a concrete, bounded subtask to a subagent when it can run independently and report back without taking ownership of the parent task. Give it an explicit deliverable and exclusive scope. Keep integration and phase decisions in the parent task.

Do not create a handoff merely because automatic compaction occurred. Do not delegate an open-ended phase whose result needs ongoing steering or whose authority belongs in the parent task.

Standalone

Off the main flow entirely.

• grill-me — the same relentless interview as grill-with-docs, but for when you have no codebase. Stateless: it saves nothing locally, builds no CONTEXT.md. Reach for it to sharpen any plan or design that doesn't live in a repo.
• wait-what — re-pitch the last answer when it did not land: add the missing context, use Simplified Technical English, and preserve the applicable canonical domain vocabulary.
• teach — learn a concept over multiple sessions, using the current directory as a stateful workspace.
• writing-for-agents — reference for writing documents agents consume, including skills and agent instructions.