compound-workflow 1.6.2 → 1.6.4

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "compound-workflow",
-  "version": "1.6.2",
+  "version": "1.6.4",
   "description": "Clarify -> plan -> execute -> verify -> capture workflow: commands, skills, and agents for Claude Code",
   "author": {
     "name": "Compound Workflow"

package/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "compound-workflow",
-  "version": "1.6.2",
+  "version": "1.6.4",
   "description": "Clarify -> plan -> execute -> verify -> capture workflow for Cursor",
   "author": {
     "name": "Compound Workflow"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "compound-workflow",
-  "version": "1.6.2",
+  "version": "1.6.4",
   "description": "Clarify → plan → execute → verify → capture. One Install action for Cursor, Claude, and OpenCode.",
   "license": "MIT",
   "repository": {

package/src/.agents/commands/workflow/brainstorm.md

@@ -18,6 +18,8 @@ it.
 discussion-first facilitation (one-question-then-prompts), approach
 exploration patterns, and YAGNI principles.
 
+It is critical that you follow this workflow in order; do not skip or shortcut steps.
+
 ## Guardrails
 
 - Do not write or modify application code.

package/src/.agents/commands/workflow/compound.md

@@ -27,6 +27,8 @@ Do not create drafts, notes, or intermediate files.
 After the primary solution doc is written, optional post-capture actions (by explicit user choice) may update other references (e.g. patterns indexes).
 </critical_requirement>
 
+It is critical that you follow this workflow in order; do not skip or shortcut steps.
+
 ## Usage
 
 ```bash
@@ -49,14 +51,16 @@ After the primary solution doc is written, optional post-capture actions (by exp
 - **Implementation insight:** For feature work, confirm implementation is complete and there is a reusable learning or pattern to capture (no "problem solved" requirement for this path).
 - If critical context is missing, ask targeted questions and wait. Then **invoke the `compound-docs` skill** (it defines required fields, validation gates, and template).
 
-### 2. Optional enrichment (before write)
+### 2. Required research (before write)
+
+Research is required and must run in subagents. Do not perform research in-context. Run all research via Task (subagent). If the environment cannot run the Task, state that and perform a minimal in-context fallback, then proceed to capture.
 
-Run only agents that exist in this `.agents` workspace. **Enrichment is read-only**—it informs the doc content but must not write files.
+Run only agents that exist in this `.agents` workspace. **Research is read-only**—it informs the doc content but must not write files.
 
-- Related docs: `Task learnings-researcher(<symptom/module/root cause keywords>)`
-- Optional: `Task best-practices-researcher(<topic>)`, `Task framework-docs-researcher(<topic>)`
+- **Required:** `Task learnings-researcher(<symptom/module/root cause keywords>)` (related docs).
+- **Conditional** (when the topic warrants, e.g. framework usage or cross-cutting patterns): `Task best-practices-researcher(<topic>)`, `Task framework-docs-researcher(<topic>)`. When run, these must also run as Tasks.
 
-Complete enrichment before assembly. Report which ran vs skipped.
+Complete research before assembly. Report which enrichments ran (required: learnings-researcher; conditional: best-practices, framework-docs) and which were skipped.
 
 ### 3. Capture
 
@@ -105,14 +109,14 @@ User may optionally run `document-review` on the created doc. If the repo has do
 
 ## Success output (shape)
 
-Report which optional enrichments ran vs skipped. Then output the path of the created file. Present the **`compound-docs` decision menu** (see skill) and wait for user choice—do not substitute a shorter custom menu.
+Report which enrichments ran (required: learnings-researcher; conditional: best-practices, framework-docs) and which were skipped. Then output the path of the created file. Present the **`compound-docs` decision menu** (see skill) and wait for user choice—do not substitute a shorter custom menu.
 
 Example summary (generic, portable):
 
 ```
 ✓ Documentation complete
 
-Optional enrichments: related-docs ran|skipped, best-practices ran|skipped, framework-docs ran|skipped
+Enrichments: learnings-researcher (required) ran|skipped; best-practices ran|skipped; framework-docs ran|skipped
 
 File created: docs/solutions/<category>/YYYY-MM-DD-<module-slug>-<symptom-slug>.md
 

package/src/.agents/commands/workflow/plan.md

@@ -15,6 +15,8 @@ Transform feature descriptions, bug reports, or improvement ideas into well-stru
 
 Contract precedence: if this command conflicts with other workflow docs, follow `docs/principles/workflow-baseline-principles.md`, then `src/AGENTS.md`, then this command.
 
+It is critical that you follow this workflow in order; do not skip or shortcut steps.
+
 This workflow MUST choose a planning fidelity and confidence level before final plan construction:
 
 - Fidelity: `Low | Medium | High`
@@ -833,7 +835,7 @@ Write the complete plan file to `docs/plans/YYYY-MM-DD-<type>-<slug>-plan.md`. T
 
 Confirm: "Plan written to docs/plans/[filename]"
 
-**Auto technical review (when Fidelity is Medium or High):** After writing the plan file, if the declared **Fidelity is Medium or High**, automatically run technical review: run **Task planning-technical-reviewer(plan_path)** when the environment can run the Task, or load the `technical-review` skill so the subagent is used when available. Use the plan path just written. If Fidelity is Low, skip this step; the user can still choose "Technical review" from Post-Generation Options or call `/workflow:tech-review` later.
+**Technical review (required when Fidelity is Medium or High):** After writing the plan file, if the declared **Fidelity is Medium or High**, you **must** run technical review—it is not optional. Run **Task planning-technical-reviewer(plan_path)** using the plan path just written. Do not perform technical review in-context unless the environment cannot run the Task; if you fall back, state "planning-technical-reviewer unavailable; running direct technical review (degraded bias resistance)" and then load the `technical-review` skill and run it in-context. If Fidelity is Low, skip this step; the user can still choose "Technical review" from Post-Generation Options or call `/workflow:tech-review` later.
 
 **Non-interactive mode:** When the invocation is non-interactive (e.g., `workflow:plan` run by automation, CI, or with an explicit non-interactive flag/convention), skip AskQuestion calls and do not present Post-Generation Options. For determinism, the repo should define the flag or convention (e.g., in `AGENTS.md` Repo Config Block or a documented env var). Still **declare** Fidelity, Confidence, Solution scope, Spike evaluation, Spikes needed, Research mode, and Open questions in the required announcement format before writing the plan. Use these defaults when user input is unavailable: fidelity = Medium, confidence = Medium, solution_scope = full_remediation, spike evaluation = not-required unless risky-work triggers are present, spikes needed = n/a when spike evaluation is not required, research mode = local + external for Medium/High risk topics else local only. Proceed directly to writing the plan file and then exit or return the plan path as output.
 
@@ -863,6 +865,8 @@ Examples:
 
 ## Post-Generation Options
 
+Technical review (above) is required for Medium/High fidelity and must be run via subagent when available.
+
 After writing the plan file, use **AskQuestion** to present these options:
 
 **Question:** "Plan ready at `docs/plans/YYYY-MM-DD-<type>-<slug>-plan.md`. What would you like to do next?"

package/src/.agents/commands/workflow/review.md

@@ -13,6 +13,8 @@ Contract precedence: if this command conflicts with other workflow docs, follow
 
 **If the user provides a document path** (e.g. a plan or spec): redirect to the `technical-review` skill for technical correctness (no edits), and/or the `document-review` skill to refine the document. This command does not review documents.
 
+It is critical that you follow this workflow in order; do not skip or shortcut steps.
+
 Guardrails (unless explicitly requested):
 
 - Do not modify code or documents

package/src/.agents/commands/workflow/tech-review.md

@@ -11,6 +11,8 @@ Run technical review on a feature approach or plan document. Checks technical al
 
 Contract precedence: if this command conflicts with other workflow docs, follow `docs/principles/workflow-baseline-principles.md`, then `src/AGENTS.md`, then this command.
 
+It is critical that you follow this workflow in order; do not skip or shortcut steps.
+
 ## Inputs
 
 - **Plan path (optional):** `$ARGUMENTS` — path to the plan file (e.g. `docs/plans/YYYY-MM-DD-<type>-<slug>-plan.md`).
@@ -19,10 +21,11 @@ Contract precedence: if this command conflicts with other workflow docs, follow
 ## Execution
 
 1. Resolve the plan document (from argument, context, or discovery).
-2. Load the `technical-review` skill and run it on that plan. The skill runs **Task planning-technical-reviewer(plan_path)** when the environment can run the Task, then synthesizes the verdict and findings queue.
+2. **Run technical review as a subagent (mandatory when supported).** Load the `technical-review` skill and run it on that plan. You **must** attempt the independent pass via a subagent first: run **Task planning-technical-reviewer(plan_path)** (e.g. `mcp_task` with subagent_type and the plan path). Do **not** perform the planning-technical-reviewer pass in-context unless the environment cannot run the Task; if you fall back, you **must** state "planning-technical-reviewer unavailable; running direct technical review (degraded bias resistance)". After the subagent (or fallback) pass, synthesize the verdict and findings queue.
 3. After technical review, if the user agrees to changes, recommend loading `document-review` to update the plan, then proceed to build when ready.
 
 ## Guardrails
 
+- **Subagent mandatory when available.** You must run the planning-technical-reviewer pass as a subagent (Task / mcp_task) when the environment supports it. Do not run in-context unless the environment cannot run the Task; if you do, disclose the degraded mode.
 - Do not modify the plan in this command; technical review is read-only. Apply changes via document-review or user edit.
 - Do not create commits, push branches, or create pull requests.

package/src/.agents/commands/workflow/triage.md

@@ -16,6 +16,8 @@ Output of this command is the only executable queue for `/workflow:work`.
 
 Contract precedence: if this command conflicts with other workflow docs, follow `docs/principles/workflow-baseline-principles.md`, then `src/AGENTS.md`, then this command.
 
+It is critical that you follow this workflow in order; do not skip or shortcut steps.
+
 ## Inputs
 
 - Default: triage all active todos under `todos/` (`pending` + `ready`)

package/src/.agents/commands/workflow/work.md

@@ -15,6 +15,8 @@ This command takes a plan file and executes it systematically. The focus is on c
 
 Contract precedence: if this command conflicts with other workflow docs, follow `docs/principles/workflow-baseline-principles.md`, then `src/AGENTS.md`, then this command.
 
+It is critical that you follow this workflow in order; do not skip or shortcut steps.
+
 Non-goals (unless explicitly requested):
 
 - Creating commits