Menu
Plan the next step as a brief grounded in vision, principles, and experience — then carry it into the spec
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Reconstruct a knowledge base from git as an encoder-decoder — a bidirectional structure pass over the whole history, parallel causal-masked sub-agents that recover each slice's why, a merge, then rumination against git until it converges
Dispatch a discussion or idea into the knowledge base — split by perspective, sort by maturity
Cross-check the knowledge base for coherence and alignment, detect rot, and tidy — proposing, never committing on its own
Human-initiated — consolidate a ripe draft out into the long-term tier (the symmetric OUT to capture's IN)
Create the knowledge base through layered, low-pressure conversation
| name | knowie-next |
| description | Plan the next step as a brief grounded in vision, principles, and experience — then carry it into the spec |
| user-invocable | true |
| argument-hint | [a direction or feature; empty = infer from vision + recent commits] |
Turn the knowledge base into a structured plan for the next step, and carry the why into the spec tool so it's obeyed during implementation.
draft/ for ripe items first. Before planning, scan draft/ for any topic mature enough to graduate (recognition chain: a design settled enough to commit → its exit is the vision roadmap; an experience/insight verified enough → consolidate). Surface these — never silently build a design straight from draft/; a design must become a roadmap item (the human-commit gate) before it's implemented.knowledge/skills/ — a learned skill that does this step → recommend using it, don't re-plan it from scratch. Missing a relevant one is worse than one extra (retrieval recall is the bottleneck for adherence).Every line cites where it comes from; skip a line if empty.
The next step is the best move, not necessarily the roadmap's sequential item. next may re-prioritize, jump roadmap order, or flag a re-route (a committed route found wrong → say so and make admitting it cheap). Justify the jump from the three perspectives like any recommendation. Guardrail: a new route still passes the gate (draft → roadmap) before it's built — jumping ≠ bypassing the commit gate.
Next: [name] — [one-line] · roadmap position: [phase / milestone]
After the brief, if step 1 found ripe draft/ items, end with the option:
"Before we start, promote these first? (design → roadmap, then build it through the roadmap; insight → consolidate.)" — list them. The human decides; you propose. This is the gate that keeps a design from being built straight out of draft/. (For a focused, human-initiated consolidate outside planning, that's /knowie-consolidate.)
Promoting is a dispatch, not a relocation (see core: Consolidating is dispatch) — direction → roadmap/experience, recurring concept → concepts/, brainstorming scene → episodes/, transition → history/. A new roadmap item carries acceptance criteria (verifiable) and a two-way link to its design draft. The draft is not deleted — it stays as the in-flight design rationale until the item is done (then it reflows + retires, judge §4). Only the pieces already dispatched elsewhere (concept, transition) leave the draft.
If the planned step is a repeated manual operation with no skill yet → flag it a skill candidate (prevention: skill it before doing it manually again; capture records it, the human confirms). next is the earliest, cheapest catch of repetition — before the next manual redo. (judge catches what slips through, later.)
Every recommendation traces to vision / principles / experience. Nothing from thin air — if there's no relevant knowledge for a point, say so explicitly.