@leeovery/claude-technical-workflows 2.1.33 → 2.1.35

package/skills/start-review/references/select-plans.md

@@ -4,11 +4,40 @@
 
 ---
 
-This step only applies for `single` or `multi` scope chosen in Step 3.
+This step only applies for `single`, `multi`, or `all` scope chosen in Step 3.
+
+#### If scope is "analysis"
+
+Select which reviews to analyze.
+
+#### If multiple reviews exist
+
+> *Output the next fenced block as markdown (not a code block):*
+
+```
+· · · · · · · · · · · ·
+Which reviews to analyze?
+
+- **`a`/`all`** — All reviewed plans
+- **`s`/`select`** — Choose specific reviews
+
+Select an option:
+· · · · · · · · · · · ·
+```
+
+**STOP.** Wait for user response.
+
+If `select`, present numbered list of reviewed plans for the user to choose from (comma-separated numbers).
+
+#### If single review exists
+
+Automatically proceed with the only available review.
+
+→ Proceed to **Step 5**.
 
 #### If scope is "all"
 
-All reviewable plans are included. No selection needed.
+All reviewable plans are included. No selection needed. Each plan will be reviewed independently.
 
 → Proceed directly to **Step 5**.
 

package/skills/start-review/scripts/discovery.sh

@@ -9,6 +9,8 @@ set -eo pipefail
 
 PLAN_DIR="docs/workflow/planning"
 SPEC_DIR="docs/workflow/specification"
+REVIEW_DIR="docs/workflow/review"
+IMPL_DIR="docs/workflow/implementation"
 
 # Helper: Extract a frontmatter field value from a file
 # Usage: extract_field <file> <field_name>
@@ -113,6 +115,85 @@ fi
 
 echo ""
 
+#
+# REVIEWS
+#
+echo "reviews:"
+
+reviewed_plan_count=0
+# Track which plan names have been reviewed (space-separated)
+reviewed_plans=""
+
+if [ -d "$REVIEW_DIR" ]; then
+    # Check for any review directories with r*/review.md
+    has_reviews="false"
+    for topic_dir in "$REVIEW_DIR"/*/; do
+        [ -d "$topic_dir" ] || continue
+        if ls -d "$topic_dir"r*/review.md >/dev/null 2>&1; then
+            has_reviews="true"
+            break
+        fi
+    done
+
+    echo "  exists: $has_reviews"
+
+    if [ "$has_reviews" = "true" ]; then
+        echo "  entries:"
+
+        for topic_dir in "$REVIEW_DIR"/*/; do
+            [ -d "$topic_dir" ] || continue
+            topic=$(basename "$topic_dir")
+            # Count r*/ versions
+            versions=0
+            latest_version=0
+            latest_path=""
+            for rdir in "$topic_dir"r*/; do
+                [ -d "$rdir" ] || continue
+                [ -f "${rdir}review.md" ] || continue
+                rnum=${rdir##*r}
+                rnum=${rnum%/}
+                versions=$((versions + 1))
+                if [ "$rnum" -gt "$latest_version" ] 2>/dev/null; then
+                    latest_version=$rnum
+                    latest_path="$rdir"
+                fi
+            done
+
+            [ "$versions" -eq 0 ] && continue
+
+            # Extract verdict from latest review.md
+            latest_verdict=""
+            if [ -f "${latest_path}review.md" ]; then
+                latest_verdict=$(grep -m1 '\*\*QA Verdict\*\*:' "${latest_path}review.md" 2>/dev/null | \
+                    sed -E 's/.*\*\*QA Verdict\*\*:[[:space:]]*//' || true)
+            fi
+
+            # Check for synthesis: look for review-tasks-c*.md in implementation dir
+            has_synthesis="false"
+            if ls "$IMPL_DIR/$topic"/review-tasks-c*.md >/dev/null 2>&1; then
+                has_synthesis="true"
+            fi
+
+            # Track reviewed plans
+            if ! echo " $reviewed_plans " | grep -q " $topic "; then
+                reviewed_plans="$reviewed_plans $topic"
+                reviewed_plan_count=$((reviewed_plan_count + 1))
+            fi
+
+            echo "    - topic: \"$topic\""
+            echo "      versions: $versions"
+            echo "      latest_version: $latest_version"
+            echo "      latest_verdict: \"$latest_verdict\""
+            echo "      latest_path: \"$latest_path\""
+            echo "      has_synthesis: $has_synthesis"
+        done
+    fi
+else
+    echo "  exists: false"
+fi
+
+echo ""
+
 #
 # WORKFLOW STATE SUMMARY
 #
@@ -122,6 +203,14 @@ echo "  has_plans: $([ "$plan_count" -gt 0 ] && echo "true" || echo "false")"
 echo "  plan_count: $plan_count"
 echo "  implemented_count: $implemented_count"
 echo "  completed_count: $completed_count"
+echo "  reviewed_plan_count: $reviewed_plan_count"
+
+# Determine if all implemented plans have been reviewed
+all_reviewed="false"
+if [ "$implemented_count" -gt 0 ] && [ "$reviewed_plan_count" -ge "$implemented_count" ]; then
+    all_reviewed="true"
+fi
+echo "  all_reviewed: $all_reviewed"
 
 # Determine workflow state for routing
 if [ "$plan_count" -eq 0 ]; then

package/skills/start-specification/SKILL.md

@@ -2,7 +2,7 @@
 name: start-specification
 description: "Start a specification session from concluded discussions. Discovers available discussions, offers consolidation assessment for multiple discussions, and invokes the technical-specification skill."
 disable-model-invocation: true
-allowed-tools: Bash(.claude/skills/start-specification/scripts/discovery.sh), Bash(mkdir -p docs/workflow/.cache), Bash(rm docs/workflow/.cache/discussion-consolidation-analysis.md), Bash(.claude/hooks/workflows/write-session-state.sh)
+allowed-tools: Bash(.claude/skills/start-specification/scripts/discovery.sh), Bash(mkdir -p docs/workflow/.state), Bash(rm docs/workflow/.state/discussion-consolidation-analysis.md), Bash(.claude/hooks/workflows/write-session-state.sh)
 hooks:
   PreToolUse:
     - hooks:

package/skills/start-specification/references/analysis-flow.md

@@ -65,10 +65,10 @@ When forming groupings:
 
 Create the cache directory if needed:
 ```bash
-mkdir -p docs/workflow/.cache
+mkdir -p docs/workflow/.state
 ```
 
-Write to `docs/workflow/.cache/discussion-consolidation-analysis.md`:
+Write to `docs/workflow/.state/discussion-consolidation-analysis.md`:
 
 ```markdown
 ---

package/skills/start-specification/references/display-analyze.md

@@ -87,7 +87,7 @@ Proceed with analysis?
 
 If cache is stale, delete it first:
 ```bash
-rm docs/workflow/.cache/discussion-consolidation-analysis.md
+rm docs/workflow/.state/discussion-consolidation-analysis.md
 ```
 
 → Load **[analysis-flow.md](analysis-flow.md)** and follow its instructions.

package/skills/start-specification/references/display-groupings.md

@@ -8,7 +8,7 @@ Shows when cache is valid (directly from routing) or after analysis completes. T
 
 ## A. Load Groupings
 
-Load groupings from `docs/workflow/.cache/discussion-consolidation-analysis.md`. Parse the `### {Name}` headings and their discussion lists.
+Load groupings from `docs/workflow/.state/discussion-consolidation-analysis.md`. Parse the `### {Name}` headings and their discussion lists.
 
 → Proceed to **B. Determine Discussion Status**.
 
@@ -160,7 +160,7 @@ Every meta option (Unify, Re-analyze) MUST include its description lines.
 
 #### If user picks "Unify all"
 
-Update the cache: rewrite `docs/workflow/.cache/discussion-consolidation-analysis.md` with a single "Unified" grouping containing all concluded discussions. Keep the same checksum, update the generated timestamp. Add note: `Custom groupings confirmed by user (unified).`
+Update the cache: rewrite `docs/workflow/.state/discussion-consolidation-analysis.md` with a single "Unified" grouping containing all concluded discussions. Keep the same checksum, update the generated timestamp. Add note: `Custom groupings confirmed by user (unified).`
 
 Spec name: "Unified". Sources: all concluded discussions.
 
@@ -170,7 +170,7 @@ Spec name: "Unified". Sources: all concluded discussions.
 
 Delete the cache:
 ```bash
-rm docs/workflow/.cache/discussion-consolidation-analysis.md
+rm docs/workflow/.state/discussion-consolidation-analysis.md
 ```
 
 → Load **[analysis-flow.md](analysis-flow.md)** and follow its instructions.

package/skills/start-specification/references/display-specs-menu.md

@@ -139,7 +139,7 @@ Menu descriptions are wrapped in backticks to visually distinguish them from the
 
 If cache is stale, delete it first:
 ```bash
-rm docs/workflow/.cache/discussion-consolidation-analysis.md
+rm docs/workflow/.state/discussion-consolidation-analysis.md
 ```
 
 → Load **[analysis-flow.md](analysis-flow.md)** and follow its instructions.

package/skills/start-specification/scripts/discovery.sh

@@ -10,7 +10,7 @@ set -eo pipefail
 
 DISCUSSION_DIR="docs/workflow/discussion"
 SPEC_DIR="docs/workflow/specification"
-CACHE_FILE="docs/workflow/.cache/discussion-consolidation-analysis.md"
+CACHE_FILE="docs/workflow/.state/discussion-consolidation-analysis.md"
 
 # Helper: Extract a frontmatter field value from a file
 # Usage: extract_field <file> <field_name>

package/skills/technical-implementation/references/invoke-task-writer.md

@@ -20,6 +20,7 @@ Pass via the orchestrator's prompt:
 4. **Plan format reading adapter path** — `../../technical-planning/references/output-formats/{format}/reading.md`
 5. **Plan format authoring adapter path** — `../../technical-planning/references/output-formats/{format}/authoring.md`
 6. **plan-index-schema.md** — `../../technical-planning/references/plan-index-schema.md`
+7. **Phase label** — `Analysis (Cycle {N})`
 
 ---
 

package/skills/technical-planning/SKILL.md

@@ -59,7 +59,7 @@ this, or is there a more complete version?
 Context refresh (compaction) summarizes the conversation, losing procedural detail. When you detect a context refresh has occurred — the conversation feels abruptly shorter, you lack memory of recent steps, or a summary precedes this message — follow this recovery protocol:
 
 1. **Re-read this skill file completely.** Do not rely on your summary of it. The full process, steps, and rules must be reloaded.
-2. **Read all tracking and state files** for the current topic — plan index files, review tracking files, implementation tracking files, or any working documents this skill creates. These are your source of truth for progress.
+2. **Read all tracking and state files** for the current topic — plan index files, review tracking files, implementation tracking files, or any working documents this skill creates. These are your source of truth for progress. Check for scratch files at `docs/workflow/.cache/planning/{topic}/`. If a scratch file exists, you are mid-authoring for that phase — resume the approval loop in author-tasks.md.
 3. **Check git state.** Run `git status` and `git log --oneline -10` to see recent commits. Commit messages follow a conventional pattern that reveals what was completed.
 4. **Announce your position** to the user before continuing: what step you believe you're at, what's been completed, and what comes next. Wait for confirmation.
 5. **Check `task_list_gate_mode`, `author_gate_mode`, and `finding_gate_mode`** in the Plan Index File frontmatter — if `auto`, the user previously opted in during this session. Preserve these values.
@@ -126,8 +126,9 @@ Reset `task_list_gate_mode`, `author_gate_mode`, and `finding_gate_mode` to `gat
 
 1. Read **[output-formats.md](references/output-formats.md)**, find the entry matching the `format:` field in the Plan Index File, and load the format's **[authoring.md](references/output-formats/{format}/authoring.md)**
 2. Follow the authoring file's cleanup instructions to remove Authored Tasks for this topic
-3. Delete the Plan Index File
-4. Commit: `planning({topic}): restart planning`
+3. Delete the scratch directory if it exists: `rm -rf docs/workflow/.cache/planning/{topic}/`
+4. Delete the Plan Index File
+5. Commit: `planning({topic}): restart planning`
 
 → Proceed to **Step 1**.
 

package/skills/technical-planning/references/author-tasks.md

@@ -4,13 +4,25 @@
 
 ---
 
-This step uses the `planning-task-author` agent (`../../../agents/planning-task-author.md`) to write full detail for a single task. You invoke the agent, present its output, and handle the approval gate.
+This step uses the `planning-task-author` agent (`../../../agents/planning-task-author.md`) to write full detail for all tasks in a phase. One sub-agent authors all tasks, writing to a scratch file. The orchestrator then handles per-task approval and format-specific writing to the plan.
 
 ---
 
-## Author the Task
+## Section 1: Prepare the Scratch File
 
-### Invoke the Agent
+Scratch file path: `docs/workflow/.cache/planning/{topic}/phase-{N}.md`
+
+Create the `docs/workflow/.cache/planning/{topic}/` directory if it does not exist.
+
+---
+
+## Section 2: Invoke the Agent (Batch)
+
+> *Output the next fenced block as a code block:*
+
+```
+Authoring {count} tasks for Phase {N}: {Phase Name}...
+```
 
 Invoke `planning-task-author` with these file paths:
 
@@ -19,36 +31,65 @@ Invoke `planning-task-author` with these file paths:
 3. **Cross-cutting specs**: paths from the Plan Index File's `cross_cutting_specs:` field (if any)
 4. **task-design.md**: `task-design.md`
 5. **All approved phases**: the complete phase structure from the Plan Index File body
-6. **Task list for current phase**: the approved task table
-7. **Target task**: the task name, edge cases, and ID from the table
-8. **Output format authoring reference**: path to the format's `authoring.md` (e.g., `output-formats/{format}/authoring.md`)
+6. **Task list for current phase**: the approved task table (ALL tasks in the phase)
+7. **Scratch file path**: `docs/workflow/.cache/planning/{topic}/phase-{N}.md`
 
-### Check Gate Mode
+The agent writes all tasks to the scratch file and returns.
 
-The agent returns complete task detail following the task template from task-design.md. What the user sees is what gets logged.
+---
 
-> *Output the next fenced block as markdown (not a code block):*
+## Section 3: Validate Scratch File
 
-```
-{task detail from planning-task-author agent}
-```
+Read the scratch file and count tasks. Verify task count matches the task table in the Plan Index File for this phase.
+
+#### If mismatch
+
+Re-invoke the agent with the same inputs.
+
+#### If valid
+
+→ Proceed to **Section 4**.
+
+---
+
+## Section 4: Check Gate Mode
 
 Check `author_gate_mode` in the Plan Index File frontmatter.
 
 #### If `author_gate_mode: auto`
 
-**Auto mode removes the approval pause — not the sequential process.** Each task is still invoked, authored, and logged one at a time, in order. Do not batch, skip ahead, or create multiple tasks concurrently.
-
 > *Output the next fenced block as a code block:*
 
 ```
-Task {M} of {total}: {Task Name} — authored. Logging to plan.
+Phase {N}: {count} tasks authored. Auto-approved. Writing to plan.
 ```
 
-→ Skip to **If approved** below.
+→ Jump to **Section 6**.
 
 #### If `author_gate_mode: gated`
 
+→ Enter **Section 5**.
+
+---
+
+## Section 5: Approval Loop
+
+For each task in the scratch file, in order:
+
+#### If task status is `approved`
+
+Skip — already approved from a previous pass.
+
+#### If task status is `pending`
+
+Present the full task content:
+
+> *Output the next fenced block as markdown (not a code block):*
+
+```
+{task detail from scratch file}
+```
+
 **Task {M} of {total}: {Task Name}**
 
 > *Output the next fenced block as markdown (not a code block):*
@@ -56,8 +97,8 @@ Task {M} of {total}: {Task Name} — authored. Logging to plan.
 ```
 · · · · · · · · · · · ·
 **To proceed:**
-- **`y`/`yes`** — Approved. I'll log it to the plan.
-- **`a`/`auto`** — Approve this and all remaining task authoring gates automatically
+- **`y`/`yes`** — Approved. I'll write it to the plan.
+- **`a`/`auto`** — Approve this and all remaining tasks automatically
 - **Or tell me what to change.**
 - **Or navigate** — a different phase or task, or the leading edge.
 · · · · · · · · · · · ·
@@ -65,36 +106,69 @@ Task {M} of {total}: {Task Name} — authored. Logging to plan.
 
 **STOP.** Wait for the user's response.
 
+#### If approved (`y`/`yes`)
+
+Mark the task `approved` in the scratch file. Continue to the next task.
+
+#### If `auto`
+
+Mark the task `approved` in the scratch file. Set all remaining `pending` tasks to `approved`. Update `author_gate_mode: auto` in the Plan Index File frontmatter.
+
+→ Jump to **Section 6**.
+
 #### If the user provides feedback
 
-Re-invoke `planning-task-author` with all original inputs PLUS:
-- **Previous output**: the current task detail
-- **User feedback**: what the user wants changed
+Mark the task `rejected` in the scratch file and add the feedback as a blockquote:
 
-Present the revised task in full. Ask the same choice again. Repeat until approved.
+```markdown
+## {task-id} | rejected
+
+> **Feedback**: {user's feedback here}
+
+### Task {seq}: {Task Name}
+...
+```
+
+Continue to the next task.
 
 #### If the user navigates
 
-→ Return to **Plan Construction**.
+→ Return to **Plan Construction**. The scratch file preserves approval state.
 
-#### If `auto`
+---
+
+### Section 5b: Revision
 
-Note that `author_gate_mode` should be updated to `auto` during the commit step below.
+After completing the approval loop, check for rejected tasks.
 
-→ Proceed to **If approved** below.
+#### If no rejected tasks
 
-#### If approved (`y`/`yes` or `auto`)
+→ Proceed to **Section 6**.
 
-> **CHECKPOINT**: If `author_gate_mode: gated`, verify before logging: (1) You presented this exact content, (2) The user explicitly approved with `y`/`yes` or equivalent — not a question, comment, or "okay" in passing, (3) You are writing exactly what was approved with no modifications.
+#### If rejected tasks exist
 
-See **[plan-index-schema.md](plan-index-schema.md)** for field definitions and lifecycle.
+> *Output the next fenced block as a code block:*
+
+```
+{N} tasks need revision. Re-invoking author agent...
+```
+
+→ Return to **Section 2**. The agent receives the scratch file with rejected tasks and feedback, rewrites only those, and the flow continues through validation, gate check, and approval as normal.
+
+---
+
+## Section 6: Write to Plan
 
-1. Write the task to the output format (format-specific — see authoring.md)
-2. If the Plan Index File frontmatter `ext_id` is empty, set it to the external identifier for the plan as exposed by the output format.
-3. If the current phase's `ext_id` is empty, set it to the external identifier for the phase as exposed by the output format.
-4. Update the task table in the Plan Index File: set `status: authored` and set `Ext ID` to the external identifier for the task as exposed by the output format.
-5. Advance the `planning:` block in frontmatter to the next pending task (or next phase if this was the last task)
-6. If user chose `auto` at this gate: update `author_gate_mode: auto` in the Plan Index File frontmatter
+> **CHECKPOINT**: If `author_gate_mode: gated`, verify all tasks in the scratch file are marked `approved` before writing.
+
+For each approved task in the scratch file, in order:
+
+1. Read the task content from the scratch file
+2. Write to the output format (format-specific — see the format's **[authoring.md](output-formats/{format}/authoring.md)**)
+3. Update the task table in the Plan Index File: set `status: authored` and set `Ext ID` to the external identifier for the task as exposed by the output format
+4. If the Plan Index File frontmatter `ext_id` is empty, set it to the external identifier for the plan as exposed by the output format
+5. If the current phase's `ext_id` is empty, set it to the external identifier for the phase as exposed by the output format
+6. Advance the `planning:` block in frontmatter to the next pending task (or next phase if this was the last task)
 7. Commit: `planning({topic}): author task {task-id} ({task name})`
 
 > *Output the next fenced block as a code block:*
@@ -103,4 +177,14 @@ See **[plan-index-schema.md](plan-index-schema.md)** for field definitions and l
 Task {M} of {total}: {Task Name} — authored.
 ```
 
+Repeat for each task.
+
+---
+
+## Section 7: Cleanup
+
+Delete the scratch file: `rm docs/workflow/.cache/planning/{topic}/phase-{N}.md`
+
+Remove the `docs/workflow/.cache/planning/{topic}/` directory if empty.
+
 → Return to **Plan Construction**.

package/skills/technical-planning/references/output-formats/tick/about.md

@@ -39,8 +39,9 @@ tick init
 Add to `.gitignore`:
 
 ```
-.tick/.store
+.tick/cache.db
 .tick/lock
+.tick/.tasks-*.jsonl.tmp
 ```
 
 ## Structure Mapping
@@ -66,7 +67,7 @@ Tasks are stored in a `.tick/` directory at the project root:
 ```
 .tick/
 ├── tasks.jsonl     # Append-only source of truth (git-friendly)
-├── .store          # SQLite cache (auto-rebuilt, do not commit)
+├── cache.db        # SQLite query cache (auto-rebuilt, do not commit)
 └── lock            # File lock for concurrent access
 ```
 

package/skills/technical-planning/references/output-formats/tick/graph.md

@@ -2,6 +2,8 @@
 
 Tick has native support for priority and blocking dependencies with cycle detection. This file is used by the graphing agent after all tasks have been authored.
 
+**Natural ordering principle**: Tasks execute in natural order (by priority, then creation date) when no dependencies override it. The dependency grapher only adds edges that change execution order — if tasks are already in the right sequence, explicit dependencies add noise without value. See also the dependency grapher agent's "When NOT to add a dependency" rules.
+
 ## Priority
 
 | Level | Name | Value |

package/skills/technical-planning/references/output-formats/tick/reading.md

@@ -59,3 +59,5 @@ tick ready --parent <topic-id>
 ```
 
 If `tick ready` returns no results, either all tasks are complete or remaining tasks are blocked.
+
+**Natural ordering convention**: `tick ready` always returns results in the correct execution order — by priority, then creation date. Consumers should take the first result as the next task. Because creation date preserves authoring order, sequential intra-phase tasks execute in natural order without needing explicit dependencies. Only add dependencies when the correct order differs from the natural order.

package/skills/technical-planning/references/plan-construction.md

@@ -118,31 +118,27 @@ Phase {N}: {Phase Name} — task list confirmed. Proceeding to authoring.
 
 ## Author Tasks for the Phase
 
-Work through each task in the phase's task table, in order.
+Tasks are authored in a single batch per phase. One sub-agent authors all tasks for the phase, writing to a scratch file. The orchestrator then handles approval and writing to the plan format. Never invoke multiple authoring agents concurrently. Never batch beyond a single phase.
 
-### Sequential authoring (mandatory)
+#### If all tasks in the phase have status `authored`
 
-Tasks **must** be authored one at a time, in order. Each task's authored detail builds context for the next — later tasks benefit from decisions, patterns, and structure established by earlier ones. This applies regardless of gate mode. Auto-gate removes the approval pause, not the sequential process.
-
-**Never** invoke multiple Step B agents concurrently. **Never** batch or skip ahead.
-
-#### If the task status is `authored`
-
-Already written.
+All tasks already written.
 
 > *Output the next fenced block as a code block:*
 
 ```
-Task {M} of {total}: {Task Name} — already authored.
+Phase {N}: {Phase Name} — all tasks already authored.
 ```
 
-Continue to the next task.
+→ Continue to the next phase.
+
+#### If any tasks in the phase have status `pending`
 
-#### If the task status is `pending`
+→ Go to **Step B** for the entire phase.
 
-→ Go to **Step B** with this task.
+After Step B returns, all tasks in the phase are authored.
 
-After Step B returns, the task is authored. Continue to the next task.
+If the user navigates mid-approval, the scratch file preserves approval state. On return, resume from the first non-approved task.
 
 #### When all tasks in the phase are authored
 
@@ -178,4 +174,4 @@ Load **[define-tasks.md](define-tasks.md)** and follow its instructions as writt
 
 ## Step B: Author Tasks
 
-Load **[author-tasks.md](author-tasks.md)** and follow its instructions as written. This step authors **one task** and returns.
+Load **[author-tasks.md](author-tasks.md)** and follow its instructions as written. This step authors **all tasks for the phase** via a batch agent and returns.

package/skills/technical-planning/references/review-integrity.md

@@ -47,7 +47,7 @@ Read the plan end-to-end — carefully, as if you were about to implement it. Fo
    - Task dependencies are explicit and correct — each dependency reflects a genuine data or capability requirement
    - No circular dependencies exist in the task graph
    - Priority assignments reflect graph position — foundation tasks and tasks that unblock others are prioritised appropriately
-   - An implementer can determine execution order from the dependency graph and priorities alone
+   - Tasks within a phase execute in natural order (by task ID) unless dependencies or priorities override it. Do not flag missing dependencies for sequential intra-phase tasks where natural order already produces the correct sequence. Only flag dependency issues where: execution would happen in the wrong order without an explicit dependency, a cross-phase dependency is missing, or a convergence point (task needing multiple predecessors) lacks explicit edges.
 
 5. **Task Self-Containment**
    - Each task contains all context needed for execution

package/skills/technical-review/SKILL.md

@@ -49,6 +49,12 @@ having it provides better context for the review.
 
 The specification is optional — the review can proceed with just the plan.
 
+#### If review mode is "analysis-only"
+
+Analysis of existing review findings was requested. The review has already been completed.
+
+→ Go directly to **Step 6**.
+
 ---
 
 ## Resuming After Context Refresh
@@ -123,45 +129,15 @@ Load **[invoke-task-verifiers.md](references/invoke-task-verifiers.md)** and fol
 
 ---
 
-## Step 4: Product Assessment
-
-Load **[invoke-product-assessor.md](references/invoke-product-assessor.md)** and follow its instructions as written.
+## Step 4: Produce Review
 
-**STOP.** Do not proceed until the product assessor has returned.
+Load **[produce-review.md](references/produce-review.md)** and follow its instructions as written.
 
 → Proceed to **Step 5**.
 
 ---
 
-## Step 5: Produce Review
-
-Aggregate findings from both stages into a review document using the **[template.md](references/template.md)**.
-
-Write the review to `docs/workflow/review/{topic}.md` (single) or `docs/workflow/review/{scope-description}.md` (multi/all).
-
-**QA Verdict** (from Step 3):
-- **Approve** — All acceptance criteria met, no blocking issues
-- **Request Changes** — Missing requirements, broken functionality, inadequate tests
-- **Comments Only** — Minor suggestions, non-blocking observations
-
-**Product Assessment** (from Step 4) — always advisory, presented alongside the verdict.
-
-Commit: `review({topic}): complete review`
-
-Present the review to the user.
-
-Your review feedback can be:
-- Addressed by implementation (same or new session)
-- Delegated to an agent for fixes
-- Overridden by user ("ship it anyway")
-
-You produce feedback. User decides what to do with it.
-
----
+## Step 5: Review Actions
 
-## References
+Load **[review-actions-loop.md](references/review-actions-loop.md)** and follow its instructions.
 
-- **[invoke-task-verifiers.md](references/invoke-task-verifiers.md)** — How to dispatch QA verifier agents
-- **[invoke-product-assessor.md](references/invoke-product-assessor.md)** — How to dispatch the product assessor agent
-- **[template.md](references/template.md)** — Review output structure and verdict guidelines
-- **[review-checklist.md](references/review-checklist.md)** — Per-task verification criteria (read by agents), plan completion checks, writing feedback guidance