Wedge · 3/5
Planning & Roadmapping
Specs that hold up under attack.
knowledge engine: coming · standalone skills shipped
The problem
A spec read by its author looks airtight. Everyone else has to guess at the parts the author filled in from memory — and that's where the regressions, the missed edge cases, and the 'we never agreed on that' arguments live. The fix isn't a longer spec; it's a structured red-team before review. Same goes for the metric goal driving the plan: if you can't decompose it into the inputs that move it, you're planning against a vibe.
The level-up path
Three sharp standalone skills cover the load-bearing planning moves:
spec-stress-test— reads your PRD as an adversary. Edge cases, failure modes, race conditions between requirements, unstated assumptions, ranked by severity. Produces the attack list; you fix the spec.metrics-tree— decomposes the goal driving the plan. Top metric, input metrics, leading indicators, instrumentation gaps. The “move this first” pick is grounded in the tree, not a guess.tradeoff-frame— for the contested scoping calls inside the plan. Names the real axes, one-way vs two-way door, the evidence that would actually decide it.
A note on the knowledge engine
There is no corpus-backed engine for Planning in v1 — see the
principles. Roadmap drift is a craft problem, not a graph problem.
If a planning-side engine earns its place, it will land later. Until
then, the three skills above plus a versioned roadmap.md in your
workspace go further than most teams’ current practice.
Visual setup walkthrough
npx mogkit init my-planning-workspace.- Paste a PRD into
spec-stress-test. Get back the attack list. - Paste the goal (e.g. “improve week-1 activation”) into
metrics-tree. Get back the input metrics and the single one to move first. - For contested scope calls, paste the options into
tradeoff-frame. - Write the spec yourself. It’s sharper than the version before the attack list landed.
Skills to install
spec-stress-test
intermediate standalone planning
Red-teams a PRD or spec — surfaces edge cases, failure modes, race conditions between requirements, unstated assumptions, and what the user sees when each thing fails — ranked by severity. Produces the attack list; the PM fixes the spec.
metrics-tree
intermediate standalone strategy
Turns a fuzzy goal into a structured metrics tree — the top metric, its defining equation, the input metrics that compose it, the leading indicators, and the single metric most worth moving first — without inventing a number the PM hasn't measured.
tradeoff-frame
intermediate standalone conflict
Frames a contested decision honestly — names the real axes of disagreement, what each option optimizes versus sacrifices, whether the decision is a one-way or two-way door, and the evidence that would actually move a reasonable person. Frames; does not pick.
All of these install automatically when you run
npx mogkit init.
Material
A curated path. Not a link dump.
by Melissa Perri
Why "shipping more features" is the wrong question and what teams that escape it do instead. Foundational for roadmap and prioritization work.
Hacking Growth book
by Sean Ellis & Morgan Brown
The North Star metric and the input-metrics framing — the methodology behind `metrics-tree`.