/inventing

name: inventing
description: Use when the user asks to build a feature or component, add functionality, or change behavior, before any implementation code is written.

Inventing

Turn a request into an approved design with as little ceremony as the request allows. Intent comes first: know what the user wants to accomplish and what success looks like before you pick an approach. Who orchestrates is chosen first: with a human orchestrator the human approves the plan once, before it runs; with an AI orchestrator nothing is asked. After that, nothing stops you except destructive, outward-facing (push, merge, publish) or security-sensitive actions.

1. Size the request, in one line

Announce it: "This looks bounded, so I'll ask one batch of questions and show a short design here." The user can override.

• **Trivial** (a few tool calls: a typo, a rename, a one-line fix): do it. Exit this skill. With a human orchestrator, say the change in one line and wait for the human's yes in chat; only an orchestrated build needs a review plan.
• **Bounded** (a change to a flow that already exists in the repo): short in-chat design, one approval.
• **Architectural** (a new project or subsystem, or changes to interfaces others depend on): one combined design and plan doc, one approval.
• **Spike** ("can we...", "is it possible...", throwaway is fine): say what you will try in 2 sentences and try it. The output is an answer, not code you keep.

Hidden complexity found mid-task upgrades the size. Say so and step up. If the request describes several independent subsystems, say that first and brainstorm only the first one.

2. Explore and ask, once

Read the relevant code and recent commits first. Use an Explore agent (it runs on Haiku) for broad sweeps. Do not ask what the repo or the request already answers.

If purpose, constraints or success criteria are still missing, ask them in ONE `AskUserQuestion` call: up to 4 questions, multiple choice where possible, your recommended option first. For architectural work, include the plan `detail` choice in the same batch: `contracts`, `tests` or `full`. Recommend `full` when the core is algorithmic or risky, otherwise `tests` (the default). Add the orchestrator choice to that same call as one single-choice question, options `Human orchestrator: I approve the plan before it runs` and `AI orchestrator: hands off, it does everything` (details in `../swarm/orchestrator.md`); never ask it when the request settles it, and in a headless run default to AI with a `Ruling:`. Once the request is known, and BEFORE recording it, run `bash <skill-dir>/../swarm/scripts/superlite-cli session ensure --slug <topic>`. Follow `SESSION`/`REDIRECT`. On `ASK untracked=<N> slug=<s>: <files>` (exit 4) ask in ONE AskUserQuestion "Stash with <s>" / "Keep in the folder" / "Always stash (this repo)" / "Always keep (this repo)"; for an "Always" choice run `bash <skill-dir>/../swarm/scripts/superlite-cli session untracked stash|keep` first, then rerun with `--untracked stash|keep`. On `ASK move slug=<s>` (exit 4) ask "Move it" / "Not now", then do what the `on yes:` / `on no:` line says (rerun with `--move yes` on "Move it"; on "Not now" stop, nothing changed); if the hook printed `superlite sync:`, offer "Bring main in now" / "Later" via `superlite-cli session sync --slug <s>` (`--later`; on exit 5 dispatch a fixer, then `--continue` or `--abort`). Then record it: `bash <skill-dir>/../swarm/scripts/superlite-cli orchestrator set human|ai`. Add one more single-choice question to that same call, never a separate question round: "Run the whole test suite at finish?" with options `No, affected tests only (Recommended)` and `Yes, once at finish`; bounded work asks it with the in-chat design. With no batch, the review plan lists it under "Decisions you can change" and the approving reply may set it. Never one question per message. Bounded work gets at most one batch. If nothing is missing, ask nothing and restate your understanding in the design instead.

Grill (after discovery, existing code)

Run this in feature, debug and review modes, once the code is read: feature after research (code map), debug after the cause is reproduced, review after the target and its diff are read. Not in small, MVP or regular builds on an empty folder.

• Ask for cost saved, not for completeness. Cost is tasks, files, tests, agents, prototype rounds, rewrites, and the tier the work needs. Rank each candidate question by what its answer removes or cheapens, and ask only those that change the plan's size, direction or tier. A good answer either shrinks the plan ("does this need to exist?", "reuse X instead of building Y?", "which parts can wait?", "is the smaller version enough?") or makes the work mechanical enough for a cheaper agent ("one pattern for all five call sites?", "copy the existing X exactly?", "exact names and values?"). The recommended option is the cheapest one that still meets the goal; when it narrows what the user asked for, say so in the question. Decide the rest as `Ruling:` or `Assumption:`.
• Ask nothing the code, the code map or the request already answers; state the finding. Skip the grill when nothing material is open.
• Round 1 is the whole frontier in ONE `AskUserQuestion`: at most 4 questions, recommended option first, so one click accepts all. Round 2 only for questions round 1's answers opened, in feature mode only. Never a round 3.
• "I don't know" or "you decide" is an answer: `Assumption:` and move on. A look-and-feel question is not grilled: `Prototype decides:`.
• Human orchestrator: ask. AI orchestrator: grill yourself. Write the same round 1 questions, answer each from the code map and best default, run round 2 on what that opens (the same caps apply to what you write), and record each as `Ruling: <decision> (because <reason>)`. The AI orchestrator does not ask the full-suite question: `Ruling: full suite no (because affected runs cover the change and the user was n