specrails-core 3.8.0 → 4.0.0

package/templates/commands/specrails/implement.md

@@ -59,6 +59,36 @@ which openspec && openspec --version
 
 {{TEST_RUNNER_CHECK}}
 
+#### 5. Agent discovery
+
+Scan the agents directory to determine which agents are installed:
+
+```bash
+ls .claude/agents/sr-*.md 2>/dev/null | sed 's|.*/||;s|\.md$||' | sort
+```
+
+Store the result as `AVAILABLE_AGENTS` (a list of agent IDs). The pipeline adapts dynamically to the installed agents:
+
+| Agent | Role | Required? | Phase(s) affected |
+|-------|------|-----------|-------------------|
+| sr-architect | Architecture & design | **Core** (always present) | 3a |
+| sr-developer | Full-stack implementation | **Core** (always present) | 3b |
+| sr-reviewer | Generalist quality gate | **Core** (always present) | 4b |
+| sr-merge-resolver | Merge conflict resolution | **Core** (always present) | 4a |
+| sr-product-manager | Product exploration | Optional | 1 |
+| sr-test-writer | Test generation | Optional | 3c |
+| sr-doc-sync | Documentation sync | Optional | 3d |
+| sr-frontend-developer | Frontend implementation | Optional | 3b (routing) |
+| sr-backend-developer | Backend implementation | Optional | 3b (routing) |
+| sr-frontend-reviewer | Frontend review | Optional | 4b |
+| sr-backend-reviewer | Backend review | Optional | 4b |
+| sr-security-reviewer | Security analysis | Optional | 4b |
+| sr-performance-reviewer | Performance analysis | Optional | 4b |
+
+**Gate rules** (applied throughout the pipeline):
+- If an optional agent is NOT in `AVAILABLE_AGENTS`, **skip** that phase/sub-step silently and note `"<agent> not installed — skipping"`.
+- Core agents are guaranteed to exist. If a core agent is missing, **STOP** and print: `[error] Core agent <name> not found. Run /specrails:enrich or reinstall.`
+
 ### Summary
 
 Print a setup report:
@@ -71,9 +101,10 @@ Print a setup report:
 | OpenSpec | ok | ... |
 | Dependencies | ok | ... |
 | Test runner | ok | ... |
+| Agents | N installed | core: 4/4, optional: M |
 ```
 
-**Pass `TEST_CMD` (or equivalent) and `BACKLOG_AVAILABLE` forward** — all later phases must use these.
+**Pass `TEST_CMD`, `BACKLOG_AVAILABLE`, and `AVAILABLE_AGENTS` forward** — all later phases must use these.
 
 ---
 
@@ -250,8 +281,8 @@ Write the initial state file:
   "phases": {
     "architect": "pending",
     "developer": "pending",
-    "test-writer": "pending",
-    "doc-sync": "pending",
+    "test-writer": "<'pending' if sr-test-writer ∈ AVAILABLE_AGENTS, else 'skipped'>",
+    "doc-sync": "<'pending' if sr-doc-sync ∈ AVAILABLE_AGENTS, else 'skipped'>",
     "reviewer": "pending",
     "ship": "pending",
     "ci": "pending"
@@ -296,7 +327,9 @@ If `PIPELINE_STATE_AVAILABLE=false`: skip all state updates silently.
 
 ## Phase 1: Explore (parallel)
 
-**Only runs if Phase 0 found no backlog issues AND user passed area names.**
+**Only runs if Phase 0 found no backlog issues AND user passed area names AND `sr-product-manager` ∈ `AVAILABLE_AGENTS`.**
+
+If `sr-product-manager` is not installed, skip Phase 1 and Phase 2 entirely. Print: `[phase-1] sr-product-manager not installed — skipping exploration. Proceeding with provided input.`
 
 For each area, launch a **sr-product-manager** agent (`subagent_type: sr-product-manager`, `run_in_background: true`).
 
@@ -470,21 +503,64 @@ Before launching any developer agent, run a trivial Bash command to confirm Bash
 
 #### Choosing the right developer agent
 
-For each feature, analyze the tasks' layer tags:
+For each feature, read `openspec/changes/<name>/tasks.md` and classify every task by its layer tags and file references.
+
+**Step 1 — Classify tasks into layers:**
 
-{{DEVELOPER_ROUTING_RULES}}
+For each task, determine its layer from:
+1. **Explicit layer tags** in tasks.md (e.g., `[frontend]`, `[backend]`, `[core]`, `[infra]`, `[docs]`, etc.)
+2. **File references** under `**Files:**` entries — apply the same extension/path rules used in Phase 4b:
+   - Frontend: `.jsx`, `.tsx`, `.vue`, `.svelte`, `.css`, `.scss`, `.html`, or paths under `components/`, `pages/`, `views/`, `ui/`, `client/`, `frontend/`, `app/`, `public/`, `static/`, `assets/`
+   - Backend: `.py`, `.go`, `.java`, `.rb`, `.php`, `.rs`, `.cs`, `.sql`, or paths under `server/`, `api/`, `routes/`, `controllers/`, `services/`, `models/`, `db/`, `backend/`, `migrations/`
+   - Mixed/other: everything else (shell scripts, config files, markdown, YAML, etc.)
+
+Produce three sets: `FRONTEND_TASKS`, `BACKEND_TASKS`, `OTHER_TASKS`.
+
+**Step 2 — Route tasks to developer agents:**
+
+Evaluate available developer agents in `AVAILABLE_AGENTS` and apply these rules in priority order:
+
+| Condition | Agent(s) selected | Mode |
+|-----------|-------------------|------|
+| ALL tasks are frontend-only AND `sr-frontend-developer` ∈ `AVAILABLE_AGENTS` | **sr-frontend-developer** | Single agent for all tasks |
+| ALL tasks are backend-only AND `sr-backend-developer` ∈ `AVAILABLE_AGENTS` | **sr-backend-developer** | Single agent for all tasks |
+| Mix of frontend + backend tasks AND both layer-specific developers available | **sr-frontend-developer** for `FRONTEND_TASKS`, **sr-backend-developer** for `BACKEND_TASKS`, **sr-developer** for `OTHER_TASKS` | Parallel agents per layer |
+| Frontend tasks exist AND `sr-frontend-developer` available, but no backend-specific developer | **sr-frontend-developer** for `FRONTEND_TASKS`, **sr-developer** for remaining | Parallel agents |
+| Backend tasks exist AND `sr-backend-developer` available, but no frontend-specific developer | **sr-backend-developer** for `BACKEND_TASKS`, **sr-developer** for remaining | Parallel agents |
+| No layer-specific developers available (fallback) | **sr-developer** | Single agent for all tasks |
+
+Store the result as `DEVELOPER_ROUTING`: a map of `{agent_id: [task_list]}`.
+
+**Step 3 — Print routing decision:**
+
+```
+## Developer Routing
+
+| Agent | Tasks | Reason |
+|-------|-------|--------|
+| sr-frontend-developer | Task 1, Task 3 | Frontend-only tasks (React components) |
+| sr-backend-developer  | Task 2, Task 4 | Backend-only tasks (API endpoints) |
+| sr-developer          | Task 5         | Mixed layer (config + infra) |
+```
+
+Also store `DEVELOPER_AGENTS_USED` (the set of developer agent IDs actually launched) — Phase 4b will use this for reviewer selection.
 
 #### Launch modes
 
-**If `SINGLE_MODE`**: Launch in the main repo, foreground.
+For each entry in `DEVELOPER_ROUTING`, launch the assigned developer agent with its task subset.
+
+**If `SINGLE_MODE` and only one agent in routing**: Launch in the main repo, foreground.
+**If `SINGLE_MODE` but multiple agents in routing**: Launch agents sequentially in the main repo (one at a time, foreground), passing only their assigned tasks.
 **If multiple features**: Launch in isolated worktrees (`isolation: worktree`, `run_in_background: true`).
 
 Wait for all developers to complete.
 
-**Pipeline state:** update `developer` → `done`. Also update `implemented_files` in the state file with the complete list of files created or modified by the developer agent(s). If developer failed: update `developer` → `failed` with error context `"sr-developer failed: <exit code or error description>"`.
+**Pipeline state:** update `developer` → `done`. Also update `implemented_files` in the state file with the complete list of files created or modified by the developer agent(s). If developer failed: update `developer` → `failed` with error context `"<agent-id> failed: <exit code or error description>"`.
 
 ## Phase 3c: Write Tests
 
+**Guard:** If `sr-test-writer` ∉ `AVAILABLE_AGENTS`, skip this phase. Print: `[phase-3c] sr-test-writer not installed — skipping test generation.` Update pipeline state: `test-writer` → `skipped`. Proceed to Phase 3d.
+
 Launch a **sr-test-writer** agent for each feature immediately after its developer completes.
 
 Construct the agent invocation prompt to include:
@@ -519,6 +595,8 @@ If a test-writer agent fails or times out:
 
 ## Phase 3d: Doc Sync
 
+**Guard:** If `sr-doc-sync` ∉ `AVAILABLE_AGENTS`, skip this phase. Print: `[phase-3d] sr-doc-sync not installed — skipping doc sync.` Update pipeline state: `doc-sync` → `skipped`. Proceed to Phase 4.
+
 Launch a **sr-doc-sync** agent for each feature after its tests are written.
 
 Construct the agent invocation prompt to include:
@@ -643,7 +721,9 @@ After all features are processed, print the preliminary report:
 - <file> (features: <a>, <b> — conflicting section: "<heading>")
 ```
 
-**Step 5a: Smart conflict resolution** (skip if `SINGLE_MODE=true` or `DRY_RUN=true`)
+**Step 5a: Smart conflict resolution** (skip if `SINGLE_MODE=true` or `DRY_RUN=true` or `sr-merge-resolver` ∉ `AVAILABLE_AGENTS`)
+
+If `sr-merge-resolver` is not installed, print: `[smart-merge] sr-merge-resolver not installed — skipping automatic resolution. Fix conflicts manually.` and skip to Step 5b.
 
 If `MERGE_REPORT.requires_resolution` is non-empty:
 
@@ -728,27 +808,43 @@ Set `BACKEND_FILES` = files matching backend rules.
 
 **Overlap rule:** a file may appear in both `FRONTEND_FILES` and `BACKEND_FILES` (e.g., a Next.js API route at `pages/api/`). Both reviewers will scan it independently.
 
-If `FRONTEND_FILES` is empty: set `FRONTEND_REVIEW_REPORT = "SKIPPED"` and skip frontend-reviewer launch. Note: "No frontend files detected."
-If `BACKEND_FILES` is empty: set `BACKEND_REVIEW_REPORT = "SKIPPED"` and skip backend-reviewer launch. Note: "No backend files detected."
+#### Step 2: Determine which reviewers to launch
+
+A layer reviewer is launched when **both** conditions are met:
+1. There are files to review for that layer (file classification) **OR** the corresponding layer developer was used in Phase 3b (`DEVELOPER_AGENTS_USED`)
+2. The reviewer agent is installed (`∈ AVAILABLE_AGENTS`)
+
+| Reviewer | Launch condition | Skip reason |
+|----------|-----------------|-------------|
+| sr-frontend-reviewer | (`FRONTEND_FILES` non-empty OR `sr-frontend-developer` ∈ `DEVELOPER_AGENTS_USED`) AND installed | No frontend files + no frontend developer used, or not installed |
+| sr-backend-reviewer | (`BACKEND_FILES` non-empty OR `sr-backend-developer` ∈ `DEVELOPER_AGENTS_USED`) AND installed | No backend files + no backend developer used, or not installed |
+| sr-security-reviewer | Installed | Not installed |
+| sr-performance-reviewer | Installed | Not installed |
+
+If a reviewer is skipped, set its report variable to `"SKIPPED"` and note the reason.
 
-#### Step 2: Launch Layer Reviewers in Parallel
+#### Step 3: Launch Layer Reviewers in Parallel
 
-Launch all applicable layer reviewers in parallel (`run_in_background: true`):
+Launch all applicable layer reviewers in parallel (`run_in_background: true`).
 
-**sr-frontend-reviewer** (if `FRONTEND_FILES` is non-empty):
+**sr-frontend-reviewer** (if applicable per Step 2):
 - Pass `FRONTEND_FILES_LIST`: the list of files in `FRONTEND_FILES`
 - Pass `PIPELINE_CONTEXT`: brief description of what was implemented
 
-**sr-backend-reviewer** (if `BACKEND_FILES` is non-empty):
+**sr-backend-reviewer** (if applicable per Step 2):
 - Pass `BACKEND_FILES_LIST`: the list of files in `BACKEND_FILES`
 - Pass `PIPELINE_CONTEXT`: brief description of what was implemented
 
-**sr-security-reviewer** (always):
+**sr-security-reviewer** (if applicable per Step 2):
 - Pass `MODIFIED_FILES_LIST`: the complete list of all files created or modified during this run
 - Pass `PIPELINE_CONTEXT`: brief description of what was implemented
 - Pass the exemptions config path: `.claude/security-exemptions.yaml`
 
-Wait for all launched layer reviewers to complete before proceeding to Step 3.
+**sr-performance-reviewer** (if applicable per Step 2):
+- Pass `MODIFIED_FILES_LIST`: the complete list of all files created or modified during this run
+- Pass `PIPELINE_CONTEXT`: brief description of what was implemented
+
+Wait for all launched layer reviewers to complete before proceeding to Step 4.
 
 Parse status lines from each completed reviewer:
 - `FRONTEND_REVIEW_STATUS: ISSUES_FOUND` or `CLEAN` → set `FRONTEND_STATUS`
@@ -757,7 +853,7 @@ Parse status lines from each completed reviewer:
 
 If a layer reviewer fails or times out: set the relevant report variable to `"ERROR: reviewer did not complete"` and continue.
 
-#### Step 3: Launch Generalist Reviewer
+#### Step 4: Launch Generalist Reviewer
 
 Construct the generalist reviewer's invocation prompt with layer reports injected. Set each variable to the full output of the corresponding reviewer, or to the string `"SKIPPED"` if that reviewer was not launched:
 

package/templates/commands/specrails/propose-spec.md

@@ -49,6 +49,8 @@ Output ONLY the following structured markdown. Do not add any preamble or explan
 
 After generating the proposal, read `.specrails/backlog-config.json` to determine `BACKLOG_PROVIDER` and `BACKLOG_WRITE`.
 
+If `.specrails/backlog-config.json` does not exist, default to `provider=local` and `write_access=true`. Initialize `.specrails/local-tickets.json` if it does not exist (empty store with `schema_version: "1.0"`, `revision: 0`, `next_id: 1`, `tickets: {}`).
+
 ### If provider=local — Create Local Ticket
 
 Create a local ticket from the proposal output:

package/templates/settings/integration-contract.json

@@ -50,8 +50,6 @@
       "models.preset": "string — balanced | budget | max",
       "models.defaults.model": "string — sonnet | opus | haiku (overrides preset)",
       "models.overrides": "Record<string, string> — per-agent model (highest priority)",
-      "quick_context.product_description": "string — product description seed for VPC discovery",
-      "quick_context.target_users": "string — target users seed for VPC discovery",
       "agent_teams": "boolean — install team-review and team-debug commands"
     }
   },

package/templates/skills/sr-implement/SKILL.md

@@ -59,6 +59,36 @@ which openspec && openspec --version
 
 {{TEST_RUNNER_CHECK}}
 
+#### 5. Agent discovery
+
+Scan the agents directory to determine which agents are installed:
+
+```bash
+ls .claude/agents/sr-*.md 2>/dev/null | sed 's|.*/||;s|\.md$||' | sort
+```
+
+Store the result as `AVAILABLE_AGENTS` (a list of agent IDs). The pipeline adapts dynamically to the installed agents:
+
+| Agent | Role | Required? | Phase(s) affected |
+|-------|------|-----------|-------------------|
+| sr-architect | Architecture & design | **Core** (always present) | 3a |
+| sr-developer | Full-stack implementation | **Core** (always present) | 3b |
+| sr-reviewer | Generalist quality gate | **Core** (always present) | 4b |
+| sr-merge-resolver | Merge conflict resolution | **Core** (always present) | 4a |
+| sr-product-manager | Product exploration | Optional | 1 |
+| sr-test-writer | Test generation | Optional | 3c |
+| sr-doc-sync | Documentation sync | Optional | 3d |
+| sr-frontend-developer | Frontend implementation | Optional | 3b (routing) |
+| sr-backend-developer | Backend implementation | Optional | 3b (routing) |
+| sr-frontend-reviewer | Frontend review | Optional | 4b |
+| sr-backend-reviewer | Backend review | Optional | 4b |
+| sr-security-reviewer | Security analysis | Optional | 4b |
+| sr-performance-reviewer | Performance analysis | Optional | 4b |
+
+**Gate rules** (applied throughout the pipeline):
+- If an optional agent is NOT in `AVAILABLE_AGENTS`, **skip** that phase/sub-step silently and note `"<agent> not installed — skipping"`.
+- Core agents are guaranteed to exist. If a core agent is missing, **STOP** and print: `[error] Core agent <name> not found. Run /specrails:enrich or reinstall.`
+
 ### Summary
 
 Print a setup report:
@@ -71,9 +101,10 @@ Print a setup report:
 | OpenSpec | ok | ... |
 | Dependencies | ok | ... |
 | Test runner | ok | ... |
+| Agents | N installed | core: 4/4, optional: M |
 ```
 
-**Pass `TEST_CMD` (or equivalent) and `BACKLOG_AVAILABLE` forward** — all later phases must use these.
+**Pass `TEST_CMD`, `BACKLOG_AVAILABLE`, and `AVAILABLE_AGENTS` forward** — all later phases must use these.
 
 ---
 
@@ -213,8 +244,8 @@ Write the initial state file:
   "phases": {
     "architect": "pending",
     "developer": "pending",
-    "test-writer": "pending",
-    "doc-sync": "pending",
+    "test-writer": "<'pending' if sr-test-writer ∈ AVAILABLE_AGENTS, else 'skipped'>",
+    "doc-sync": "<'pending' if sr-doc-sync ∈ AVAILABLE_AGENTS, else 'skipped'>",
     "reviewer": "pending",
     "ship": "pending",
     "ci": "pending"
@@ -259,7 +290,9 @@ If `PIPELINE_STATE_AVAILABLE=false`: skip all state updates silently.
 
 ## Phase 1: Explore (parallel)
 
-**Only runs if Phase 0 found no backlog issues AND user passed area names.**
+**Only runs if Phase 0 found no backlog issues AND user passed area names AND `sr-product-manager` ∈ `AVAILABLE_AGENTS`.**
+
+If `sr-product-manager` is not installed, skip Phase 1 and Phase 2 entirely. Print: `[phase-1] sr-product-manager not installed — skipping exploration. Proceeding with provided input.`
 
 For each area, launch a **sr-product-manager** agent (`subagent_type: sr-product-manager`, `run_in_background: true`).
 
@@ -431,21 +464,64 @@ Before launching any developer agent, run a trivial Bash command to confirm Bash
 
 #### Choosing the right developer agent
 
-For each feature, analyze the tasks' layer tags:
+For each feature, read `openspec/changes/<name>/tasks.md` and classify every task by its layer tags and file references.
+
+**Step 1 — Classify tasks into layers:**
 
-{{DEVELOPER_ROUTING_RULES}}
+For each task, determine its layer from:
+1. **Explicit layer tags** in tasks.md (e.g., `[frontend]`, `[backend]`, `[core]`, `[infra]`, `[docs]`, etc.)
+2. **File references** under `**Files:**` entries — apply the same extension/path rules used in Phase 4b:
+   - Frontend: `.jsx`, `.tsx`, `.vue`, `.svelte`, `.css`, `.scss`, `.html`, or paths under `components/`, `pages/`, `views/`, `ui/`, `client/`, `frontend/`, `app/`, `public/`, `static/`, `assets/`
+   - Backend: `.py`, `.go`, `.java`, `.rb`, `.php`, `.rs`, `.cs`, `.sql`, or paths under `server/`, `api/`, `routes/`, `controllers/`, `services/`, `models/`, `db/`, `backend/`, `migrations/`
+   - Mixed/other: everything else (shell scripts, config files, markdown, YAML, etc.)
+
+Produce three sets: `FRONTEND_TASKS`, `BACKEND_TASKS`, `OTHER_TASKS`.
+
+**Step 2 — Route tasks to developer agents:**
+
+Evaluate available developer agents in `AVAILABLE_AGENTS` and apply these rules in priority order:
+
+| Condition | Agent(s) selected | Mode |
+|-----------|-------------------|------|
+| ALL tasks are frontend-only AND `sr-frontend-developer` ∈ `AVAILABLE_AGENTS` | **sr-frontend-developer** | Single agent for all tasks |
+| ALL tasks are backend-only AND `sr-backend-developer` ∈ `AVAILABLE_AGENTS` | **sr-backend-developer** | Single agent for all tasks |
+| Mix of frontend + backend tasks AND both layer-specific developers available | **sr-frontend-developer** for `FRONTEND_TASKS`, **sr-backend-developer** for `BACKEND_TASKS`, **sr-developer** for `OTHER_TASKS` | Parallel agents per layer |
+| Frontend tasks exist AND `sr-frontend-developer` available, but no backend-specific developer | **sr-frontend-developer** for `FRONTEND_TASKS`, **sr-developer** for remaining | Parallel agents |
+| Backend tasks exist AND `sr-backend-developer` available, but no frontend-specific developer | **sr-backend-developer** for `BACKEND_TASKS`, **sr-developer** for remaining | Parallel agents |
+| No layer-specific developers available (fallback) | **sr-developer** | Single agent for all tasks |
+
+Store the result as `DEVELOPER_ROUTING`: a map of `{agent_id: [task_list]}`.
+
+**Step 3 — Print routing decision:**
+
+```
+## Developer Routing
+
+| Agent | Tasks | Reason |
+|-------|-------|--------|
+| sr-frontend-developer | Task 1, Task 3 | Frontend-only tasks (React components) |
+| sr-backend-developer  | Task 2, Task 4 | Backend-only tasks (API endpoints) |
+| sr-developer          | Task 5         | Mixed layer (config + infra) |
+```
+
+Also store `DEVELOPER_AGENTS_USED` (the set of developer agent IDs actually launched) — Phase 4b will use this for reviewer selection.
 
 #### Launch modes
 
-**If `SINGLE_MODE`**: Launch in the main repo, foreground.
+For each entry in `DEVELOPER_ROUTING`, launch the assigned developer agent with its task subset.
+
+**If `SINGLE_MODE` and only one agent in routing**: Launch in the main repo, foreground.
+**If `SINGLE_MODE` but multiple agents in routing**: Launch agents sequentially in the main repo (one at a time, foreground), passing only their assigned tasks.
 **If multiple features**: Launch in isolated worktrees (`isolation: worktree`, `run_in_background: true`).
 
 Wait for all developers to complete.
 
-**Pipeline state:** update `developer` → `done`. Also update `implemented_files` in the state file with the complete list of files created or modified by the developer agent(s). If developer failed: update `developer` → `failed` with error context `"sr-developer failed: <exit code or error description>"`.
+**Pipeline state:** update `developer` → `done`. Also update `implemented_files` in the state file with the complete list of files created or modified by the developer agent(s). If developer failed: update `developer` → `failed` with error context `"<agent-id> failed: <exit code or error description>"`.
 
 ## Phase 3c: Write Tests
 
+**Guard:** If `sr-test-writer` ∉ `AVAILABLE_AGENTS`, skip this phase. Print: `[phase-3c] sr-test-writer not installed — skipping test generation.` Update pipeline state: `test-writer` → `skipped`. Proceed to Phase 3d.
+
 Launch a **sr-test-writer** agent for each feature immediately after its developer completes.
 
 Construct the agent invocation prompt to include:
@@ -480,6 +556,8 @@ If a test-writer agent fails or times out:
 
 ## Phase 3d: Doc Sync
 
+**Guard:** If `sr-doc-sync` ∉ `AVAILABLE_AGENTS`, skip this phase. Print: `[phase-3d] sr-doc-sync not installed — skipping doc sync.` Update pipeline state: `doc-sync` → `skipped`. Proceed to Phase 4.
+
 Launch a **sr-doc-sync** agent for each feature after its tests are written.
 
 Construct the agent invocation prompt to include:
@@ -604,7 +682,9 @@ After all features are processed, print the preliminary report:
 - <file> (features: <a>, <b> — conflicting section: "<heading>")
 ```
 
-**Step 5a: Smart conflict resolution** (skip if `SINGLE_MODE=true` or `DRY_RUN=true`)
+**Step 5a: Smart conflict resolution** (skip if `SINGLE_MODE=true` or `DRY_RUN=true` or `sr-merge-resolver` ∉ `AVAILABLE_AGENTS`)
+
+If `sr-merge-resolver` is not installed, print: `[smart-merge] sr-merge-resolver not installed — skipping automatic resolution. Fix conflicts manually.` and skip to Step 5b.
 
 If `MERGE_REPORT.requires_resolution` is non-empty:
 
@@ -689,27 +769,43 @@ Set `BACKEND_FILES` = files matching backend rules.
 
 **Overlap rule:** a file may appear in both `FRONTEND_FILES` and `BACKEND_FILES` (e.g., a Next.js API route at `pages/api/`). Both reviewers will scan it independently.
 
-If `FRONTEND_FILES` is empty: set `FRONTEND_REVIEW_REPORT = "SKIPPED"` and skip frontend-reviewer launch. Note: "No frontend files detected."
-If `BACKEND_FILES` is empty: set `BACKEND_REVIEW_REPORT = "SKIPPED"` and skip backend-reviewer launch. Note: "No backend files detected."
+#### Step 2: Determine which reviewers to launch
+
+A layer reviewer is launched when **both** conditions are met:
+1. There are files to review for that layer (file classification) **OR** the corresponding layer developer was used in Phase 3b (`DEVELOPER_AGENTS_USED`)
+2. The reviewer agent is installed (`∈ AVAILABLE_AGENTS`)
+
+| Reviewer | Launch condition | Skip reason |
+|----------|-----------------|-------------|
+| sr-frontend-reviewer | (`FRONTEND_FILES` non-empty OR `sr-frontend-developer` ∈ `DEVELOPER_AGENTS_USED`) AND installed | No frontend files + no frontend developer used, or not installed |
+| sr-backend-reviewer | (`BACKEND_FILES` non-empty OR `sr-backend-developer` ∈ `DEVELOPER_AGENTS_USED`) AND installed | No backend files + no backend developer used, or not installed |
+| sr-security-reviewer | Installed | Not installed |
+| sr-performance-reviewer | Installed | Not installed |
+
+If a reviewer is skipped, set its report variable to `"SKIPPED"` and note the reason.
 
-#### Step 2: Launch Layer Reviewers in Parallel
+#### Step 3: Launch Layer Reviewers in Parallel
 
-Launch all applicable layer reviewers in parallel (`run_in_background: true`):
+Launch all applicable layer reviewers in parallel (`run_in_background: true`).
 
-**sr-frontend-reviewer** (if `FRONTEND_FILES` is non-empty):
+**sr-frontend-reviewer** (if applicable per Step 2):
 - Pass `FRONTEND_FILES_LIST`: the list of files in `FRONTEND_FILES`
 - Pass `PIPELINE_CONTEXT`: brief description of what was implemented
 
-**sr-backend-reviewer** (if `BACKEND_FILES` is non-empty):
+**sr-backend-reviewer** (if applicable per Step 2):
 - Pass `BACKEND_FILES_LIST`: the list of files in `BACKEND_FILES`
 - Pass `PIPELINE_CONTEXT`: brief description of what was implemented
 
-**sr-security-reviewer** (always):
+**sr-security-reviewer** (if applicable per Step 2):
 - Pass `MODIFIED_FILES_LIST`: the complete list of all files created or modified during this run
 - Pass `PIPELINE_CONTEXT`: brief description of what was implemented
 - Pass the exemptions config path: `.claude/security-exemptions.yaml`
 
-Wait for all launched layer reviewers to complete before proceeding to Step 3.
+**sr-performance-reviewer** (if applicable per Step 2):
+- Pass `MODIFIED_FILES_LIST`: the complete list of all files created or modified during this run
+- Pass `PIPELINE_CONTEXT`: brief description of what was implemented
+
+Wait for all launched layer reviewers to complete before proceeding to Step 4.
 
 Parse status lines from each completed reviewer:
 - `FRONTEND_REVIEW_STATUS: ISSUES_FOUND` or `CLEAN` → set `FRONTEND_STATUS`
@@ -718,7 +814,7 @@ Parse status lines from each completed reviewer:
 
 If a layer reviewer fails or times out: set the relevant report variable to `"ERROR: reviewer did not complete"` and continue.
 
-#### Step 3: Launch Generalist Reviewer
+#### Step 4: Launch Generalist Reviewer
 
 Construct the generalist reviewer's invocation prompt with layer reports injected. Set each variable to the full output of the corresponding reviewer, or to the string `"SKIPPED"` if that reviewer was not launched:
 

package/.claude/skills/openspec-apply-change/SKILL.md

@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.1.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly