plankit
plankit
Turn a rough idea (a feature, a project, a spec, a PRD) into a structured plan document you can act on. plankit is generative: it brainstorms the approach, settles the decisions needed for a coherent draft, and writes a NNNN-plan-<slug>-YYYY-MM-DD.md grounded in the real codebase (not a guess). It is the front of a flow, plankit drafts → grillkit hardens → issuekit files where a project tracks work in GitHub Issues, and plankit drafts → grillkit hardens → implementkit builds where it doesn't. Either way the plan it writes is the exact input the next step expects. plankit plans only: it never writes application code and never creates issues.
When this fires
The user wants to think a piece of work through before building it: "plan this feature", "brainstorm a plan / PRD / spec", "write a plan doc", "help me think through X first", "/plankit". One distinction matters:
- It is not the adversarial interrogator. That's grillkit. plankit asks enough to draft a coherent plan and records the thin spots as open questions; grillkit is what pressure-tests them one decision at a time.
Procedure
1. Capture the idea
Get the concept, the problem it solves, who it's for, and the outcome that means success. The success outcome is the goal behind the request, meaning what the work is for and not only what it builds ("keep the app crash-free", not "fix this crash"), plus a target: the number that shows it worked. If the input is a one-liner, ask a few scoping questions (use AskUserQuestion when available). Those are generative "what are we building and why", not adversarial "what did you miss". Ask one round at most, and only about the four items the input leaves open.
Ask for the target; propose one only from a baseline. Ask the user for their number first. When they have none, propose one only from a baseline the user gives or a file you can read (a CI report, a benchmark output, a dashboard export), and label it with both: Target: p95 load under 200 ms (proposed; baseline 4.8 s from ci/bench.json). This skill has no shell, so it never measures a baseline itself. With no baseline, write Target: open, no baseline and carry that line to Open questions, so grillkit settles it instead of an invented number. When no number fits the work, record why and name what does show it worked ("docs-only change, so the check is a lint pass"); "not applicable" names nothing and fails the step.
Done when the concept, the problem, the user, and the success outcome each have a one-line answer, from the input or from the user, and the success outcome carries a target, a Target: open, no baseline line, or a reason no number fits that names what does show it worked.