acstack 0.49.2 → 0.50.1

package/skills/implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: implement
-description: Execute implementation work via the TDD pipeline (test-writer -> task-executor -> task-checker). A map is a stored graph of question and work nodes. Claims afk nodes – away from keyboard, meaning nodes an agent settles alone – from the map frontier, the nodes ready to be worked now, when a map exists; runs the same discipline directly on the request when none does. A unit of work carries its own size – one node is a quick change, forty is a long effort, and nothing declares which. Invoke whenever the way is clear and something needs building, changing or extending, however small. Use quick-fix instead when something is broken and needs a root cause found, and map instead when decisions still need settling before anyone can build.
+description: Implement clear requests with adaptive testing and verification under the shared Implementation discipline in orchestrator/AGENTS.md. A map is a stored graph of question and work nodes. Claims afk nodes – away from keyboard, meaning nodes an agent settles alone – from the map frontier, the nodes ready to be worked now, when a map exists; runs the same discipline directly on the request when none does. A unit of work carries its own size – one node is a quick change, forty is a long effort, and nothing declares which. Invoke whenever the way is clear and something needs building, changing or extending, however small. Use quick-fix instead when something is broken and needs a root cause found, and map instead when decisions still need settling before anyone can build.
 argument-hint: "[map name, or the request to implement]"
 ---
 
@@ -12,19 +12,13 @@ $ARGUMENTS
 
 ## What this skill does
 
-Implements work under the TDD pipeline. The unit of work is a map node when a
-map exists, and the request itself when none does – same discipline either
-way. Progress lives on the tracker as claims and resolutions; there is no
-checkbox file to maintain.
+- Apply the shared Implementation discipline in `orchestrator/AGENTS.md`
+- Use a map node as the work item when a map exists, otherwise use the request itself
+- Keep tracker claims and resolutions as the progress record
+- Choose delegation for confidence or independent scopes rather than a fixed sequence
 
 ## Steps
 
-Before step 1, copy the eight step headings below into your todo list word
-for word. They go ahead of any task-specific items. A step you skip stays in
-the list, marked `skip: <reason>`.
-
-When step 5 runs on a node, copy its eight numbered steps the same way.
-
 ### 1. Find the work
 
 Check the configured tracker for maps (`workflow.maps.tracker` in
@@ -107,69 +101,21 @@ Claim each node as you start it:
 
 Nodes describe behaviour, not paths. **Resolve paths at claim time**.
 
-Before any code change, dispatch parallel read-only codebase-search subagents
-over the relevant code. Use `Explore` on Claude Code and `scout` on pi.
-
-Use as many as there are distinct places to look, not a fixed count. Act on
-what they find.
-
-Downstream pipeline subagents start fresh. Pass the source, test, and doc paths
-you already discovered into each test-writer, task-executor, task-checker, audit,
-polish, and verifier prompt. Tell them to read those paths directly instead of
-searching the codebase again.
+Investigate relevant source, callers, tests, and docs directly or through useful delegation.
+Pass discovered paths and requirements to any delegated agents to avoid repeated searches.
 
 ### 5. Execute within the claim
 
-The pipeline's state lives inside the claim, not on the node. For each
-claimed node (or the bare request), run the Implementation discipline to
-completion:
-
-1. **test-writer subagent** – tests from the node's behaviour description.
-   Under strict they must all fail before step 2 runs. Skip step 1 for pure
-   config or setup work with no testable behaviour.
-
-2. **task-executor subagent** – make the tests pass. Executor CANNOT modify
-   test files.
-
-3. **Format** – run `commands.format` over the files the work touched. A
-   `null` value means this project has no format step.
-
-    Report a non-zero exit. It never counts as a failed implementation.
-
-4. **task-checker subagent** – verify the build compiles, lints, and
-   typechecks. Verify tests pass, the full suite passes, and test count >=
-   baseline. Also check the mock audit, TDD isolation, and integration
-   wired.
+Apply the shared Implementation discipline to the claimed node or bare request.
 
-    When `acstack/project.yaml` configures `frontend` and frontend files
-    changed, the checker also runs the frontend build, lint, and unit
-    tests.
+- Choose useful checks before nontrivial edits
+- Test, implement, format, and verify against requirements
+- Get independent review when the shared policy requires it
+- Read `design-pass.md` when the design gate is on and configured frontend files changed
+- Delegate configured real-browser verification after the required gates pass
+- Fix failures and repeat the affected checks
+- Release a stalled claim (`--status open`) when the session must stop
 
-5. **`/impeccable audit`** – report design findings on the changed frontend
-   files. Steps 5 to 7 run only when three conditions hold: the design gate
-   is on, `acstack/project.yaml` configures `frontend`, and frontend files
-   changed.
-
-6. **`/impeccable polish`** – fix the same files, from the audit findings.
-
-7. **task-checker subagent, second run** – verify the code polish changed.
-
-    Read `design-pass.md` before steps 5 to 7. It holds who types the
-    commands, how to read the gate, and what polish must leave alone.
-
-8. **frontend-verifier subagent** – verify the UI in a browser. The
-   verifier runs after the second checker passes, only when
-   `acstack/project.yaml` configures `frontend`, frontend files changed,
-   and `workflow.frontend_verification` is true.
-
-`workflow.tdd.strict: false`, relaxed TDD, runs step 2 before step 1 and
-skips nothing. Read `relaxed-tdd.md` when the project sets it. It holds how
-the test-writer and the checker's gate change.
-
-If either checker run fails, route back to the executor with the feedback.
-If the work stalls or the session must stop mid-node, release the claim
-(`--status open`). The node is plainly open again, and you need no phase
-breadcrumb.
 
 **Decision log**: on afk nodes, append one row per decision point to
 `<main checkout>/acstack/.decisions/<name>.tsv`. A decision point is a fork chosen, a
@@ -178,14 +124,12 @@ unit verified, a revert, or a blocker.
 Read `decision-log.md` before the first row. It holds how to find the main
 checkout, the columns, and the `.gitignore` the directory needs.
 
-**Parallelism**: afk nodes run unlimited and in parallel. When 2+ frontier
-nodes touch non-overlapping files, launch an agent team where each teammate
-owns one node and its file set. Otherwise, or on a host without agent teams,
-work them sequentially.
+**Parallelism**: use teams when independent nodes benefit from parallel work.
+Assign non-overlapping files, and schedule shared-file changes sequentially.
 
 ### 6. Resolve
 
-When the checker passes, resolve the node in one call:
+When required verification passes, resolve the node in one call:
 
 ```bash
 ~/.claude/acstack/bin/acstack node update <id> --map <name> --status resolved \
@@ -216,8 +160,7 @@ pass before claiming the next node.
 ### 8. Completion
 
 Stop when the afk frontier is empty, or when only `hitl` nodes remain (hand
-those to `/acstack:map`). With no map, stop when the checker passes and Step
-7 verification is green.
+those to `/acstack:map`). With no map, stop when required verification is green.
 
 Report: nodes resolved, tests passing, lines added/removed. Remind the user:
 `/acstack:commit` to commit – spec sync extracts the durable record from the
@@ -225,21 +168,11 @@ diff.
 
 ## Key rules
 
-- **TDD pipeline is mandatory** – test-writer -> task-executor ->
-  task-checker -> frontend-verifier (frontend only). Only pure config work
-  skips the test-writer.
-  `workflow.tdd.strict: false` reorders the first two and skips neither.
-
-    With the design gate on, the audit and polish pass and a second
-    task-checker run sit between the first checker and the verifier
-
-- **Executors CANNOT modify test files** – if tests are wrong, report it.
-- **The tracker is the progress record** – claim on start, resolve on pass,
-  release on stall. No checkbox files, no phase fields.
+- Apply `orchestrator/AGENTS.md` as the shared verification policy
+- Respect separate test ownership when chosen
+- Claim on start, resolve after verification, and release on stall
+- Investigate before editing, directly or through useful delegation
 
-- **Explore before writing** – parallel read-only codebase-search subagents
-  over the relevant code, sized to the node, before any edit. Use `Explore` on
-  Claude Code and `scout` on pi.
 
 - **Resume is a query** – picking up where you left off means asking the
   tracker what is workable now, not reconstructing history. A fresh session

package/skills/implement/decision-log.md

@@ -9,7 +9,7 @@ row.
 Write one row per decision point, never one per action:
 
 - **A fork chosen** – two ways to build something, and you picked one
-- **A unit verified** – a node's checker passed, or a build verification went green
+- **A unit verified** – a node's verification passed, or a build verification went green
 - **A revert** – you undid work, and the row names what triggered it
 - **A blocker** – something stopped the node, and the row names it
 

package/skills/implement/design-pass.md

@@ -1,32 +1,170 @@
-# The audit and polish pass
+# The design pass
 
-Step 5 in `SKILL.md` runs the pipeline in eight numbered steps. `SKILL.md`
-states when steps 5 to 7 run. This file holds how to run them.
+The parent session owns audit and polish; frontend checks remain required even when the session delegates no task-checker.
 
-5. **`/impeccable audit`** – report design findings on the changed frontend
-   files. The audit edits nothing. It needs no browser.
+```mermaid
+flowchart TD
+    P["Before UI edits<br/>Load design context"] --> A["Discover frontend files"]
+    A --> B["Run static checks and detector"]
+    B -->|clear| C["Parent session<br/>Audit"]
+    B -->|findings| F["Fix and recheck"]
+    F --> B
+    C --> D["Parent session<br/>Polish"]
+    D --> E["Recheck final code"]
+    E -->|failure| F
+    E -->|pass| G["Configured real-browser verification"]
+```
 
-    You type the command yourself. impeccable's plugin loads it into your chat
-    as a markdown playbook.
+## 0. Load design context before a UI edit (mandatory)
 
-    Read the design gate with `~/.claude/acstack/bin/acstack design-gate`.
+impeccable is a third-party design plugin. It holds the project's design context, meaning the files that state the design rules and the token definitions a UI file follows.
 
-    The file list is the one the checker derived in its section 5.5, from
-    `git status --porcelain -- <frontend.directory>`.
+Load that context before your first edit under `frontend.directory`. Load it once per task.
 
-6. **`/impeccable polish`** – fix the same files. Polish reads the audit
-   findings as its backlog. It edits source.
+**Check the design gate first**
 
-    You type this command yourself too.
+The design gate is the set of optional checks impeccable adds to acstack's pipeline. `workflow.design_review` in `acstack/project.yaml` turns the gate on. Ask acstack for the answer:
 
-    Tell polish to leave a factual claim in copy untouched. Tell it to list
-    every such claim in its report.
+```bash
+~/.claude/acstack/bin/acstack design-gate --json
+```
 
-    Only `polish` runs from the audit's "Recommended Actions". Tell the audit
-    to name each other command against the finding that earned it.
+- exit code 0 means the gate is on
+- exit code 1 means the gate is off
 
-    Name `harden`, `clarify`, `adapt`, `optimize`, and `onboard` in your
-    completion report, so the user can pick one later.
+The command prints one JSON object:
 
-7. **task-checker subagent, second run** – polish changed the code, so verify
-   it again. This run happens only when polish ran.
+```json
+{"on": true, "reasons": ["..."], "impeccable": {"version": "4.2.0", "launcher": "/abs/path/to/scripts/impeccable"}}
+```
+
+The `impeccable` field holds the launcher path. It holds `null` only when the gate is off.
+
+When the gate is off, edit exactly as you do today. Make no impeccable call, and skip the rest of this section.
+
+**Load the context once per task**
+
+When the gate is on, run the launcher path the JSON printed:
+
+```bash
+<launcher> context --target <file>
+```
+
+- `<launcher>` is the `impeccable.launcher` path from the design-gate JSON
+- `context` is a verb of impeccable's bundled launcher binary, not of its npm command-line tool
+- `<file>` is the first file you edit under `frontend.directory`
+
+Run this command once for the whole task. impeccable's own skill says to follow the directives it prints and never to rerun the command.
+
+**Directives you act on**
+
+- `RESOLVED_CONTEXT` – JSON naming where the project's design files live, such as the token definitions you reuse
+
+**Directives you report instead**
+
+Each directive below asks for work you do not own. Put it in your report and carry on with the edit.
+
+- `CONTEXT_STALE` – the loaded context is out of date. Never rerun `context`
+- `NO_PRODUCT_MD` and `PRODUCT_INIT_REQUIRED` – both point at impeccable's `init`, which owns `PRODUCT.md`
+- `INCUMBENT_WORLD_UNDOCUMENTED` and `WORLD_DISCOVERY_REQUIRED` – both point at impeccable's `document`, which owns `DESIGN.md`
+- `UPDATE_AVAILABLE` – never run impeccable's `update` in the same turn, because it rewrites files this session is reading
+- `MANUAL_DETECTOR_REQUIRED` – report it to the verification owner, who runs the detector under `skills/implement/design-pass.md`
+
+**File ownership**
+
+You never write `PRODUCT.md` or `DESIGN.md`. impeccable's `init` interviews the user and writes `PRODUCT.md`. acstack's sync skill runs impeccable's `document` at commit time, which refreshes `DESIGN.md`.
+
+Edit only assigned files, including tests when the task assigns no separate test owner.
+
+**impeccable checks the files you write**
+
+impeccable installs its own PostToolUse hook, a check Claude Code runs right after a file write. The hook reads each UI file you write. You never run that check yourself.
+
+## 1. Discover frontend files
+
+- Follow the shared Implementation discipline in `orchestrator/AGENTS.md`
+- The verification owner gathers the file list, completes static checks, and handles the detector
+    - A delegated task-checker may own this work, but its presence is optional
+- Read `acstack/project.yaml` before deriving paths
+    - This pass requires a configured `frontend`
+    - `frontend.directory` defaults to `frontend/` when omitted
+    - If the project configures no frontend, warn that `frontend.directory` is missing and skip this pass
+- Derive one changed-file list for the checks, detector, audit, and polish
+
+```bash
+git status --porcelain -- <frontend.directory>
+```
+
+- Include modified, added, and untracked files (`??`)
+- Drop paths carrying a `D` status because the detector cannot read deleted files
+- Treat a missing directory or unmatched pathspec as an empty list
+- Skip this pass when the list is empty
+- Run configured frontend checks when the list contains files
+    - `frontend.commands.build`
+    - `frontend.commands.lint`
+    - `frontend.commands.test`
+- Leave browser interaction to `frontend-verifier` after the required gates pass
+
+## 2. Run the design detector
+
+- Check the design gate before running the detector
+
+```bash
+~/.claude/acstack/bin/acstack design-gate
+```
+
+- Exit code 0 prints `on`
+- Exit code 1 prints `off: <reason>`
+- Record the gate state and skip the detector, audit, and polish when the gate is off
+- When the gate is on, run the nonadvisory detector over the discovered file list
+    - The detector reads files without starting a browser
+    - It searches upward from each target for `DESIGN.md`
+
+```bash
+npx impeccable detect --json --no-advisory <file> [<file>...]
+```
+
+- Use this run to set the verdict
+    - Exit code 0 passes
+    - Exit code 2 fails verification
+        - Report each finding with its file and line, then send it to the implementation owner
+    - Any other exit code means the detector could not run
+        - Report a warning with the command output and continue verification
+        - Detector unavailability alone does not fail the task
+- Run the advisory detector only after the nonadvisory run exits 0
+
+```bash
+npx impeccable detect --json <file> [<file>...]
+```
+
+- Use the same file list and report each `"advisory": true` finding as a note
+- Omit the notes when none exist
+- Advisory findings never change the verdict or require implementation changes
+- Exit codes 0 and 2 hold usable advisory output
+- Report other exit codes as advisory-run warnings and continue
+
+## 3. Audit and polish
+
+- Run audit and polish only when the design gate is on and configured frontend files changed
+- Complete applicable static checks and resolve detector failures before audit
+- The parent session is the session directing this work, including direct implementation without delegation
+- A delegated checker returns the discovered file list and findings to the parent without editing files
+- The parent session must type `/impeccable audit` over the discovered file list
+    - Audit edits nothing and needs no browser
+    - Ask audit to name each recommended command against its finding
+- The parent session must type `/impeccable polish` over the same files using the audit findings
+    - Slash playbooks expand only in the session that types them
+    - Leave factual claims in copy untouched during unattended polish
+    - Ask polish to list every factual claim it left alone
+- Run only `polish` from the audit's recommended commands
+    - `harden`, `clarify`, `adapt`, `optimize`, and `onboard` require a human decision
+    - Repeat recommended command names with their findings in the completion report
+
+## 4. Recheck final code
+
+- The parent sends polished code back to the independent checker when the workflow chose one
+    - The checker reruns affected tests, static checks, and the detector without editing files
+- Without a delegated checker, the parent reruns those checks on the polished code
+- Resolve failures before browser verification
+- Delegate `frontend-verifier` on final code when the project enables configured browser verification
+- Report actual checks and results, including detector warnings and advisory findings

package/skills/map/SKILL.md

@@ -176,13 +176,11 @@ the list, marked `skip: <reason>`.
    the node's diagram shape, never its route):
     - `hitl` nodes: run grilling rounds over them. A round is the whole hitl
      frontier.
-    - `afk` nodes: claim and run without the user. Unlimited, and in parallel
-     when independent. Research goes to read-only codebase-search subagents:
-     `Explore` on Claude Code and `scout` on pi.
+    - `afk` nodes: claim and run without the user. Choose direct work or useful delegation
+     under the shared Implementation discipline in `orchestrator/AGENTS.md`.
 
      Implementation work follows `/acstack:implement`'s procedure – it owns
-     the claim-execute-resolve flow, the explorer dispatch, and the TDD
-     pipeline. Do not restate that flow here. Invoke it.
+     the claim-execute-resolve flow and adaptive verification. Do not restate that flow here. Invoke it.
 
 4. **Claim, then resolve** – `afk` nodes only. A `hitl` resolution happens
    inside the grilling round, with no claim step. Both are compositions over
@@ -196,8 +194,7 @@ the list, marked `skip: <reason>`.
    <what was decided or done, and why>"
    ```
 
-   The pipeline's state lives inside the claim, not on the node – there is no
-   phase field to maintain. If the work stalls or fails, release the claim
+   Work stays inside the claim, with no per-phase bookkeeping. If the work stalls or fails, release the claim
    (`--status open`) and the node is plainly open again.
 
 5. **After every resolution**, in order:

package/skills/pre-commit-review/SKILL.md

@@ -40,9 +40,9 @@ LLM decided to commit during autonomous work -> auto-fix.
 
 ```
 1. SNAPSHOT  – collect the diff and understand what changed
-2. DISCOVER  – learn project conventions dynamically (parallel subagents)
-3. REVIEW    – analyze changes against conventions + best practices (parallel subagents)
-4. ADJACENT  – check surrounding code for related rot (parallel subagents)
+2. DISCOVER  – learn project conventions dynamically
+3. REVIEW    – analyze changes against conventions and requirements
+4. ADJACENT  – check surrounding code for related rot
 5. REPORT    – synthesize findings
 6. FIX       – auto-fix or interactive proposal waves
 ```
@@ -69,15 +69,16 @@ Categorize changed files into scopes using the project configuration:
 - **tests**: files under `directories.tests` from project.yaml
 - **other**: everything else
 
-If no meaningful code changes exist (only docs, config, assets), report "No code changes to review" and exit. Run the prose lint from Step 3 before you exit, when Markdown files changed.
+Judge changes by effect, including behavior changed through config, assets, or shipped guidance.
+For nonbehavioral edits, review accuracy and run prose lint when Markdown changed.
 
 ## Step 2: DISCOVER – Learn project conventions (parallel)
 
-Launch **3 parallel read-only codebase-search subagents** to build a dynamic understanding of the project's current conventions.
-Use `Explore` on Claude Code and `scout` on pi.
-Do NOT hardcode conventions – discover them fresh each time.
+Follow the shared Implementation discipline in `orchestrator/AGENTS.md` for delegation and required independent review.
+Investigate these dimensions directly or through useful delegation.
+Discover current conventions rather than hardcoding them.
 
-**Subagent A – Living Specs & Architecture:**
+**Living specs and architecture:**
 
 ```
 Read the living specs relevant to this change:
@@ -88,7 +89,7 @@ Read the living specs relevant to this change:
 Report: list of project conventions and patterns relevant to these changes.
 ```
 
-**Subagent B – Codebase Patterns via Search:**
+**Codebase patterns:**
 
 ```
 Search the codebase for established patterns related to the changes.
@@ -99,7 +100,7 @@ Identify: how does the rest of the codebase handle similar things?
 Report: established patterns, common approaches, naming conventions observed.
 ```
 
-**Subagent C – Local Context & Config:**
+**Local context and configuration:**
 
 ```
 For each changed file, read:
@@ -109,15 +110,15 @@ For each changed file, read:
 Report: local conventions, related code patterns, existing abstractions nearby.
 ```
 
-Synthesize the three reports into a **convention profile** – the set of expectations
-review subagents measure changes against.
+Synthesize findings into a convention profile for the review.
 
 ## Step 3: REVIEW – Analyze changes (parallel)
 
-Launch **3 parallel review subagents**, each examining a different quality dimension.
-Every subagent receives the diff AND the convention profile from Step 2.
+Review every dimension below, directly or through useful delegation.
+Give delegated reviewers the diff and the convention profile from Step 2.
+Assess coverage against requirements instead of assuming a task-checker already assessed it.
 
-**Subagent 1 – Hardcodes & SSOT:**
+**Hardcodes and single source of truth:**
 
 ```
 Examine the diff for:
@@ -132,7 +133,7 @@ For each finding, report:
   FILE:LINE | SEVERITY (MUST/SHOULD/CONSIDER) | WHAT | WHY | SUGGESTED FIX
 ```
 
-**Subagent 2 – Scalability & Readability:**
+**Scalability and readability:**
 
 ```
 Examine the diff for:
@@ -148,7 +149,7 @@ For each finding, report:
   FILE:LINE | SEVERITY (MUST/SHOULD/CONSIDER) | WHAT | WHY | SUGGESTED FIX
 ```
 
-**Subagent 3 – Edge Cases & Robustness:**
+**Edge cases and failure handling:**
 
 ```
 Examine the diff for:
@@ -178,9 +179,8 @@ Add each finding to the review as `SHOULD | PROSE`, at the `file:line` it names.
 
 ## Step 4: ADJACENT – Check surrounding code for rot
 
-For each file with findings from Step 3, launch a **read-only codebase-search subagent**.
-Use up to 3 subagents in parallel.
-Each subagent examines the rest of that file and its immediate imports for the same categories of issue.
+For each file with findings, examine the surrounding code and immediate imports for related issues.
+Delegate when useful, with non-overlapping scopes.
 
 ```
 File [path] has these issues in the changed code: [summary].
@@ -197,7 +197,7 @@ same module, or same pattern). Stay narrowly scoped.
 
 ## Step 5: REPORT – Synthesize findings
 
-Merge all subagent findings. Deduplicate. Sort by:
+Merge all findings. Deduplicate. Sort by:
 
 1. MUST FIX (correctness, security, will-break-in-prod)
 2. SHOULD FIX (convention violations, readability, maintainability)
@@ -212,7 +212,7 @@ For each finding, make sure it has:
 - Why it matters (1 sentence)
 - Suggested fix (concrete, actionable – code snippet or approach)
 
-If any finding needs deeper analysis to determine the right fix, launch a **planning subagent**:
+If a finding needs deeper analysis, investigate directly or delegate with this brief:
 
 ```
 This code has [problem]. The file is [path]. Here's the surrounding context: [context].
@@ -233,11 +233,11 @@ Consider: does a fix here require changes in other files? What's the minimal cha
 | SHOULD   | Violates conventions, hurts maintainability, tech debt | SSOT violations, unclear naming, missing error handling on I/O     |
 | CONSIDER | Improvement opportunity, not urgent                    | Adjacent rot, minor style, could-be-cleaner patterns               |
 
-## What this skill does not check
+## Review responsibilities and tool checks
 
 - **Formatting/style** – linters and formatters handle this
 - **Type errors** – typecheckers handle this
-- **Test coverage** – task-checker handles this
+- Assess test adequacy under the shared Implementation discipline, even when no task-checker ran
 - **UI rendering** – frontend-verify handles this
 - **Security scanning** – dedicated security tools handle credentials in committed code
 

package/skills/pre-commit-review/auto-fix.md

@@ -4,7 +4,7 @@ Step 6 of `SKILL.md` in auto-fix mode.
 
 For each finding (MUST first, then SHOULD, then CONSIDER):
 
-1. Launch a **task-executor subagent** with the finding + suggested fix
+1. Apply the shared Implementation discipline in `orchestrator/AGENTS.md` to the finding, directly or through a task-executor
 2. Verify the fix doesn't break anything (run lint, typecheck, and test commands from project.yaml)
 3. If fix breaks something, revert and try alternate approach
 4. Move to next finding

package/skills/pre-commit-review/interactive.md

@@ -30,6 +30,6 @@ Reply with numbers to fix (e.g., "1,2,4") or "all" or "skip all", and any notes
 
 After user responds:
 
-- Fix selected items via task-executor subagents (parallelize independent fixes)
+- Fix selected items under the shared Implementation discipline in `orchestrator/AGENTS.md`, directly or through useful delegation
 - Present next wave if more findings remain
 - Continue until all findings addressed or user says "done" / "skip the rest"

package/skills/quick-fix/SKILL.md

@@ -18,9 +18,9 @@ If `$ARGUMENTS` is empty, ask the user to describe what's broken.
 
 ## Before you start
 
-Copy the seven step headings below into your todo list word for word. They go ahead of any task-specific items. A step you skip stays in the list, marked `skip: <reason>`.
+Read the shared Implementation discipline in `orchestrator/AGENTS.md`.
+Choose checks and delegation under that policy while investigating the bug.
 
-When Step 5 runs, copy its four numbered steps the same way.
 
 ## Step 1: Understand the problem
 
@@ -37,11 +37,11 @@ If the user provided an error message or stack trace, note the key details (file
 
 ## Step 2: Explore the codebase
 
-**Do NOT skip this step.** Delegate exploration to subagents:
+Investigate directly or delegate when another agent improves confidence:
 
-1. **Locate the code**: Launch a read-only codebase-search subagent to find the files involved. Use `Explore` on Claude Code and `scout` on pi. Read only a file you can already name.
+1. **Locate the code**: Find the files involved, including existing regression coverage
 
-2. **Read the integration points**: Have the subagent read the broken function's callers and callees, not just the function. Understand:
+2. **Read the integration points**: Read the broken function's callers and callees, not just the function:
     - What calls this code? (upstream)
     - What does this code call? (downstream)
     - What data flows through it? (inputs/outputs)
@@ -69,7 +69,7 @@ Based on the exploration, identify the root cause – not just the symptom.
 Bad: "The function returns null" (symptom).
 Good: "The function returns null because the query filter uses `org_id`, but the test user's org isn't in the result set" (root cause).
 
-If the root cause isn't clear after exploration, escalate to deeper investigation with parallel debug subagents. Don't guess.
+If the root cause remains unclear, investigate further or seek independent help rather than guessing.
 
 ## Step 4: Plan the fix
 
@@ -83,12 +83,14 @@ If the fix touches more than 3 files, pause. Confirm the scope with the user –
 
 ## Step 5: Implement via the Implementation discipline
 
-Follow the standard pipeline:
+Apply the shared policy to the minimal fix.
+
+- Reproduce the bug with a failing regression test before fixing it when practical
+- Confirm the intended failure, then implement the fix
+- Explain any departure from tests-first work
+- Preserve regression protection and separate test ownership when chosen
+- Follow `../implement/design-pass.md` when its frontend design gate applies
 
-1. **test-writer** – Write a failing test that reproduces the problem (if testable behavior exists). Skip for pure config/infra fixes.
-2. **task-executor** – Implement the minimal fix to make the test pass. Executor CANNOT modify test files.
-3. **task-checker** – Verify: task tests pass, full suite passes, test count >= baseline, no regressions.
-4. **frontend-verify** – Only if the fix touches frontend files (check `frontend.directory` in project.yaml).
 
 ## Step 6: Verify
 
@@ -99,15 +101,9 @@ Run build verification using commands from `acstack/project.yaml`:
 # Read these from project.yaml – do not hardcode
 ```
 
-**STOP – if the fix touches frontend files, you MUST visually verify before proceeding to Step 7.**
-
-If the project has a frontend verification agent or browser verification configured, use them. Otherwise, take a browser screenshot and think through:
-
-1. **Expected vs actual** – What should the change look like? Does the screenshot match?
-2. **Gaps** – Is anything missing, wrong, or showing the wrong data/labels/formatting?
-3. **General UX** – Anything weird? Overlapping elements, bad spacing, truncation, unprofessional appearance?
+Use the configured frontend gates under the shared policy.
+Do not proceed with failed required checks or unverified configured browser behavior.
 
-If verification finds a problem, fix it. Verify again. Do NOT proceed to Step 7 with unverified frontend changes.
 
 ## Step 7: Report
 
@@ -118,8 +114,10 @@ Problem: <one-line description>
 Root cause: <what was actually wrong>
 Fix: <what changed and why>
 Files modified: <list>
-Tests: <added/modified/passing>
-Regressions: none
+Verification: <actual commands and results>
+Blocked checks: <checks that could not run and why, or none>
+Missing regression protection: <behavior left unprotected, or none identified>
+Remaining risks: <known risks and uncertainty, or none identified>
 ```
 
-Remind the user to `/commit` when they're satisfied.
+Remind the user to `/acstack:commit` when they're satisfied.