feat(planning): propagate frontier-rounds cadence to prd, design, plan (0.18.0)

README.md

@@ -31,7 +31,7 @@ Browse and manage with `/plugin`. To refresh after updates: `/plugin marketplace
 
 - [`architecture`](plugins/architecture) — Scans an existing codebase for module-level architecture friction — shallow modules, seam leaks, and locality gaps — using Ousterhout's deep-module lens, presents candidates as a self-contained HTML report, and runs an interview loop on the selected candidate before handing off for planning.
 - [`prototype`](plugins/prototype) — Builds throwaway code to answer a design question before committing to architecture — a logic facet (an interactive terminal app over a portable state model) and a UI facet (radically different visual variants on one route).
-- [`planning`](plugins/planning) — Pre-implementation planning pipeline: chart a too-big, foggy effort as a decision map, diverge on candidate approaches, lock product intent and the engineering contract, actively maintain resolved domain language, explore the design space, stress-test adversarially, and produce a structured implementation plan with an approval gate.
+- [`planning`](plugins/planning) — Pre-implementation planning pipeline: chart a too-big, foggy effort as a decision map, diverge on candidate approaches, lock product intent and the engineering contract, route resolved domain language to the domain-driven-design glossary steward, explore the design space, stress-test adversarially, and produce a structured implementation plan with an approval gate.
 - [`domain-driven-design`](plugins/domain-driven-design) — Domain-driven-design practice skills. Today: actively maintains a consuming project's ubiquitous-language glossary — resolves ambiguous or overloaded terms, records canonical language and rejected synonyms, sharpens what-it-IS definitions, and routes entries to already-known bounded contexts without discovering boundaries.
 - [`naming`](plugins/naming) — Generates and evaluates fresh name candidates for anything — an identifier, file, module, skill, repo, or domain term — by fanning out blind, fresh-context generators from distinct lenses (responsibility-literal, moment-of-use, domain-lore), then scoring a shortlist against the consuming org's naming criteria. The human always picks; it never auto-locks a name. An optional tournament mode adds elimination rounds with independent judges for high-stakes, hard-to-refactor names.
 - [`event-storming`](plugins/event-storming) — EventStorming for domain discovery — a methodology skill (Big Picture / Process Modeling / Design-Level facilitation reference, notation, patterns) and a simulation skill (agentic multi-persona workshops that produce a structured-markdown model by default; a live Miro-board rendering path is available when the first-party miro plugin is enabled).

plugins/planning/.claude-plugin/plugin.json

@@ -1,16 +1,16 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "planning",
-  "version": "0.17.0",
+  "version": "0.18.0",
   "userConfig": {
     "use_ask_user_question": {
       "type": "boolean",
       "title": "Use AskUserQuestion for interview rounds",
-      "description": "Pre-implementation planning pipeline: chart a too-big, foggy effort as a decision map, diverge on candidate approaches, lock product intent and the engineering contract, route resolved domain language to the domain-driven-design glossary steward, explore the design space, stress-test adversarially, and produce a structured implementation plan with an approval gate.",
+      "description": "When enabled, the planning skills' question rounds (interview, prd, design, plan) render a round of up to 4 independent questions through the AskUserQuestion tool instead of inline prose. Default: inline prose (dictation-friendly).",
       "default": false
     }
   },
-  "description": "Pre-implementation planning pipeline: chart a too-big, foggy effort as a decision map, diverge on candidate approaches, lock product intent and the engineering contract, actively maintain resolved domain language, explore the design space, stress-test adversarially, and produce a structured implementation plan with an approval gate.",
+  "description": "Pre-implementation planning pipeline: chart a too-big, foggy effort as a decision map, diverge on candidate approaches, lock product intent and the engineering contract, route resolved domain language to the domain-driven-design glossary steward, explore the design space, stress-test adversarially, and produce a structured implementation plan with an approval gate.",
   "author": {
     "name": "Melodic Software",
     "email": "info@melodicsoftware.com"

plugins/planning/CHANGELOG.md

@@ -3,6 +3,22 @@
 All notable changes to the `planning` plugin are documented here. Format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning.
 
+## [0.18.0]
+
+### Changed
+
+- **Frontier-rounds cadence propagated to sibling skills** (`/planning:prd` Step 4, `/planning:design`
+  collaborative stance, `/planning:plan` scope-clarity check and confidence-gate interview
+  round): each asks every settled-prerequisite question as one numbered round with recommendations,
+  dependent questions waiting on their prerequisites — replacing the one-question-at-a-time cadence
+  the interview skill dropped in 0.13.0. `/planning:brainstorm`'s single intake question is
+  intentionally unchanged.
+- Siblings now render a round via `AskUserQuestion` only through the same `use_ask_user_question`
+  user config the interview skill reads (on, and ≤4 independent questions) instead of deciding
+  prose-vs-card inline.
+- The interview-round description in `/planning:plan` is stated once in
+  `context/tag-decisions.md`; the SKILL.md confidence-gate summary no longer duplicates it.
+
 ## [0.17.0]
 
 ### Changed
@@ -34,7 +50,7 @@ All notable changes to the `planning` plugin are documented here. Format follows
 - **Tripwire test** `tests/standards-binding.test.sh` guards the load-bearing grounding markers
   (heading placement, binding references, ladder-pointer discipline) against future prose edits.
 
-## [0.13.0]
+## [0.15.0]
 
 ### Changed
 
@@ -46,6 +62,11 @@ All notable changes to the `planning` plugin are documented here. Format follows
 - **Declared a dependency on `domain-driven-design`**, so installing `planning` auto-installs the
   glossary steward and the pipeline's inline vocabulary updates (`interview`, `design`) keep working
   cross-plugin.
+
+## [0.14.0]
+
+### Changed
+
 - **BREAKING: `/planning:architect` is renamed `/planning:plan`** (skill directory, frontmatter
   `name`, and every in-repo reference). The `architect` name was a pre-migration shadow-compromise:
   before plugins, a flat local skill named `plan` would have collided with surfaces already using
@@ -56,6 +77,10 @@ All notable changes to the `planning` plugin are documented here. Format follows
   `/planning:plan`; no `renames`-map entry is provided (clean break while the marketplace settles).
   "architect this" remains a trigger phrase in the skill description.
 
+## [0.13.0]
+
+### Changed
+
 - **`/planning:interview` asks in frontier rounds instead of one question at a time** (behavioral
   change): each round asks every question whose prerequisites are settled as one numbered set, each
   with a recommendation; the answers recompute the frontier, and dependent questions wait for the

plugins/planning/skills/design/SKILL.md

@@ -165,7 +165,7 @@ The in-session shortcut to the design→plan gate. Delegate to `/planning:design
 
 ## Key behaviors
 
-- **Collaborative always.** Never autonomously decide design. One question at a time, depth-first — resolve the load-bearing question before surfacing the next. Use `AskUserQuestion` when 2-4 discrete choices exist; prose for open-ended questions
+- **Collaborative always.** Never autonomously decide design. Ask in frontier rounds — every open thread whose prerequisites are settled surfaces in the same numbered round, each with a recommendation; a thread that depends on an unresolved thread waits for the round after it resolves. Render a round via `AskUserQuestion` only when the plugin's `use_ask_user_question` user config (`${user_config.use_ask_user_question}`) is on and the round is ≤4 independent questions — inline prose otherwise
 - **Track resolution status.** Every question and thread gets a status: resolved / directional / deferred. Deferred items carry a research tag describing what external investigation is needed
 - **Codify rules when discovered.** When discussion surfaces a principle that applies project-wide, suggest codifying it immediately in the project's own rules files
 - **Incremental artifacts.** Don't produce all artifacts at once. Build them as discussion progresses. Update existing artifacts as decisions evolve. Multi-turn shared artifacts (`design-threads.md` and peers): re-read from disk before every write — another turn or agent may have modified them — and prefer appending or refining over wholesale rewrites

plugins/planning/skills/design/evals/evals.json

@@ -5,7 +5,7 @@
       "id": 1,
       "name": "library-design-collaborative-artifacts",
       "prompt": "/planning:design library — I'm building a small result/error-handling library and want to figure out the types, contracts, and package topology before planning.",
-      "expected_output": "The skill decomposes the problem space, opens design threads with tracked resolution status, and builds design artifacts (capability-matrix, type-inventory, design-threads, topology) incrementally through collaborative discussion — one question at a time — rather than autonomously deciding the design.",
+      "expected_output": "The skill decomposes the problem space, opens design threads with tracked resolution status, and builds design artifacts (capability-matrix, type-inventory, design-threads, topology) incrementally through collaborative discussion — asking in frontier rounds, dependent threads waiting on their prerequisites — rather than autonomously deciding the design.",
       "files": [],
       "expectations": [
         "Output explores the design collaboratively, asking the user rather than unilaterally deciding the types/boundaries",
@@ -17,11 +17,11 @@
       "id": 2,
       "name": "never-autonomously-decides-design",
       "prompt": "/planning:design module for a new Notifications module — just design the whole thing for me and pick all the types and boundaries yourself.",
-      "expected_output": "The skill declines to autonomously finalize the design; it surfaces the decisions one at a time with recommendations marked (RECOMMENDED) and their basis, and drives resolution through the user rather than deciding alone.",
+      "expected_output": "The skill declines to autonomously finalize the design; it surfaces the open decisions as numbered rounds with recommendations marked (RECOMMENDED) and their basis, and drives resolution through the user rather than deciding alone.",
       "files": [],
       "expectations": [
         "Output does NOT autonomously decide the full design without user input",
-        "Output surfaces design decisions one at a time with a recommendation marked (RECOMMENDED) and a basis",
+        "Output surfaces design decisions in numbered rounds, each with a recommendation marked (RECOMMENDED) and a basis",
         "Output leaves the resolution of each thread to the user's confirmation"
       ]
     },