acstack 0.52.1 → 0.52.3

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

@@ -1,6 +1,6 @@
 ---
 name: pre-commit-review
-description: "Deep code quality review of all changes since last commit. Checks for hardcodes, single-source-of-truth violations, scalability issues, edge cases, and project convention drift using dynamic project awareness (living specs, codebase search, surrounding code). Also flags adjacent code rot worth cleaning up. Auto-invocable in two contexts – (1) when working autonomously through a task list and about to commit (e.g., user said \"implement all tasks and commit\"), use --auto-fix mode; (2) when the user manually invokes /commit and this skill has not already run on the current changes, use INTERACTIVE mode (default). Manual invocation via /pre-commit-review also uses interactive mode by default."
+description: "Deep code quality review of all changes since last commit. Checks for hardcodes, single-source-of-truth violations, scalability issues, edge cases, and project convention drift using dynamic project awareness (living specs, codebase search, surrounding code). Reports adjacent cleanup as advisory, requiring user approval before edits. Auto-invocable in two contexts – (1) when working autonomously through a task list and about to commit (e.g., user said \"implement all tasks and commit\"), use --auto-fix mode; (2) when the user manually invokes /commit and this skill has not already run on the current changes, use INTERACTIVE mode (default). Manual invocation via /pre-commit-review also uses interactive mode by default."
 argument-hint: "[--auto-fix] [scope description]"
 ---
 
@@ -42,7 +42,7 @@ LLM decided to commit during autonomous work -> auto-fix.
 1. SNAPSHOT  – collect the diff and understand what changed
 2. DISCOVER  – learn project conventions dynamically
 3. REVIEW    – analyze changes against conventions and requirements
-4. ADJACENT  – check surrounding code for related rot
+4. ADJACENT  – note related cleanup encountered during review (advisory)
 5. REPORT    – synthesize findings
 6. FIX       – auto-fix or interactive proposal waves
 ```
@@ -75,7 +75,9 @@ For nonbehavioral edits, review accuracy and run prose lint when Markdown change
 ## Step 2: DISCOVER – Learn project conventions (parallel)
 
 Follow the shared Implementation discipline in `orchestrator/AGENTS.md` for delegation and required independent review.
-Investigate these dimensions directly or through useful delegation.
+Investigate relevant dimensions directly or through useful delegation.
+Bound each review to changed behavior, connected risks, and the question assigned.
+Reuse valid check evidence under the shared policy instead of repeating completion commands.
 Discover current conventions rather than hardcoding them.
 
 Read `../../output-styles/ac-writing-style.md` relative to this skill directory; apply its shared standard to code design as well as explanations.
@@ -95,9 +97,8 @@ Report: list of project conventions and patterns relevant to these changes.
 
 ```
 Search the codebase for established patterns related to the changes.
-For each changed function/component, search for similar implementations:
-  Search for function signatures, class names, and patterns from the diff
-  Find files with similar naming conventions
+When conventions are unclear, search for representative implementations related to the change.
+Reuse patterns already established in this review rather than repeating discovery for every function.
 Identify: how does the rest of the codebase handle similar things?
 Report: established patterns, common approaches, naming conventions observed.
 ```
@@ -106,8 +107,9 @@ Report: established patterns, common approaches, naming conventions observed.
 
 ```
 For each changed file, read:
-- The full file (to see surrounding code context)
-- Connected callers and dependencies (read beyond signatures where needed to understand responsibilities and interface costs)
+- Changed bodies and surrounding context needed to understand them
+- Connected callers and dependencies needed to assess responsibilities, interface costs, and plausible failures
+- Expand to full files or wider paths when findings justify it
 - Config that governs this area (linter rules, compiler config, etc.)
 Report: local conventions, related code patterns, existing abstractions nearby.
 ```
@@ -116,7 +118,8 @@ Synthesize findings into a convention profile for the review.
 
 ## Step 3: REVIEW – Analyze changes (parallel)
 
-Review every dimension below, directly or through useful delegation.
+Assess which dimensions below apply, then review them to the depth justified by plausible failures.
+Keep deep scrutiny for affected auth, security, resource lifecycle, concurrency, and performance paths; do not apply unrelated categories mechanically.
 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.
 
@@ -146,10 +149,12 @@ Examine the diff for:
 - Missing useful boundaries or pass-through layers that add no useful boundary
 - Complex conditionals that could be simplified
 - Code that would be hard for a new developer to understand
-- Performance concerns (N+1 queries, unnecessary re-renders, blocking I/O)
+- Performance concerns (N+1 queries, unnecessary re-renders, blocking I/O, unbounded memory or work)
+- Resource lifecycle failures (leaked handles, listeners, subscriptions, or tasks; missing cleanup or cancellation)
 
 Do not require nesting or wrappers; neither line count nor indirection measures design quality.
 Support design findings with effects on connected callers and dependencies.
+Ask whether callers need fewer facts, each rule has one owner, and the interface hides complexity rather than relocating it.
 
 For each finding, report:
   FILE:LINE | SEVERITY (MUST/SHOULD/CONSIDER) | WHAT | WHY | SUGGESTED FIX
@@ -183,48 +188,42 @@ The lint exits 0 even when it reports findings. It groups findings by file with
 
 Review each warning in context before treating it as a defect. Preserve necessary technical terms, quotations, and wording that would lose accuracy if changed. Report confirmed clarity or convention problems as `SHOULD | PROSE`, with the `file:line` and their effect on the reader.
 
-## Step 4: ADJACENT – Check surrounding code for rot
+## Step 4: ADJACENT – Report cleanup as advisory
 
-For each file with findings, examine the surrounding code and immediate imports for related issues.
-Delegate when useful, with non-overlapping scopes.
+Note closely related cleanup encountered while reviewing connected code. Do not launch
+an extra scan of whole files and imports solely to find more work.
 
-```
-File [path] has these issues in the changed code: [summary].
-Read the FULL file and its direct imports.
-Find any OTHER instances of the same categories of problem in this file
-or closely related files – even if they weren't part of this commit's changes.
-These are "while we're here" cleanup opportunities.
+Report as: `ADVISORY | ADJACENT | FILE:LINE | WHAT | WHY | SUGGESTED FIX`.
+Keep these suggestions separate from delivery-blocking findings. Neither review mode
+authorizes adjacent edits by default, including `--auto-fix`.
 
-Report as: ADJACENT | FILE:LINE | WHAT | WHY | SUGGESTED FIX
-```
+If cleanup is worth doing, ask the user whether to add it to scope. Approved work may
+run in parallel on non-overlapping files or isolated worktrees; do not make it a
+dependency of the main change. Never run conflicting writers in the same checkout.
 
-Only flag adjacent issues that are **closely related** to the current changes (same file,
-same module, or same pattern). Stay narrowly scoped.
+A defect that prevents requested behavior or exposes a consequential risk is not
+merely cleanup. Classify it by impact and fix it within scope or report the blocker.
 
 ## Step 5: REPORT – Synthesize findings
 
-Merge all findings. Deduplicate. Sort by:
+Deduplicate in-scope findings and sort by:
 
 1. MUST FIX (correctness, security, will-break-in-prod)
 2. SHOULD FIX (convention violations, readability, maintainability)
-3. CONSIDER (style preferences, minor improvements, adjacent rot)
+3. CONSIDER (style preferences, minor improvements)
 
-For each finding, make sure it has:
+Keep adjacent suggestions in a separate advisory list using Step 4's format.
+For each in-scope finding, make sure it has:
 
 - `file:line` reference
-- Category tag (HARDCODE, SSOT, SCALABILITY, READABILITY, EDGE-CASE, PROSE, ADJACENT)
+- Category tag (HARDCODE, SSOT, SCALABILITY, READABILITY, EDGE-CASE, PROSE)
 - Severity (MUST / SHOULD / CONSIDER)
 - Clear 1-sentence description of the problem
 - Why it matters (1 sentence)
 - Suggested fix (concrete, actionable – code snippet or approach)
 
-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].
-Think through 2-3 possible fixes, evaluate trade-offs, and recommend the best approach.
-Consider: does a fix here require changes in other files? What's the minimal change?
-```
+For deeper analysis, investigate directly or delegate the problem, file, and context.
+Compare useful alternatives and recommend the smallest complete fix, including affected callers.
 
 ## Step 6: FIX – Auto-fix or interactive waves
 
@@ -237,7 +236,7 @@ Consider: does a fix here require changes in other files? What's the minimal cha
 | -------- | ------------------------------------------------------ | ------------------------------------------------------------------ |
 | MUST     | Will cause bugs, security issues, or prod failures     | Hardcoded secrets, unhandled null on critical path, race condition |
 | 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               |
+| CONSIDER | In-scope improvement opportunity, not urgent           | Minor style, could-be-cleaner patterns                            |
 
 ## Review responsibilities and tool checks
 

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

@@ -2,18 +2,18 @@
 
 Step 6 of `SKILL.md` in auto-fix mode.
 
-For each finding (MUST first, then SHOULD, then CONSIDER):
+Fix in-scope findings (MUST first, then SHOULD, then CONSIDER). Adjacent cleanup
+stays advisory unless the user approves it; auto-fix is not approval to expand scope.
 
-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
+1. Apply the shared Implementation discipline in `orchestrator/AGENTS.md`, directly or through a task-executor
+2. Run focused checks for the fix and affected behavior
+3. If the fix breaks something, revert only your own conflicting changes and try another approach
+4. Move to the next finding
 
-After all fixes, run full verification using commands from `.acstack/project.yaml`:
+One verification owner gathers required completion evidence for the final revision,
+reusing valid results under Build verification in `orchestrator/AGENTS.md`.
+Do not repeat all completion commands for every finding.
+Approved adjacent work may run in parallel with non-overlapping ownership or isolated
+worktrees, without blocking the main change.
 
-```bash
-# Run the project's configured test, lint, and typecheck commands
-# Read these from project.yaml – do not hardcode
-```
-
-Report a summary of the fixes.
+Report fixes, evidence, blockers, and advisory suggestions separately.

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

@@ -2,7 +2,13 @@
 
 Step 6 of `SKILL.md` in interactive mode, the default.
 
-Present findings in **waves of up to 4** using the question tool (AskUserQuestion on Claude Code). On a host without one, use a numbered list in chat. Group related findings together.
+Present in-scope findings in **waves of up to 4** using the question tool (AskUserQuestion on Claude Code). On a host without one, use a numbered list in chat. Group related findings together.
+
+Keep adjacent suggestions in a separate advisory list, not the required fix waves.
+If one is worth pursuing, ask for explicit approval to add it to scope. "Fix all"
+for the main review does not include that advisory list. Approved cleanup may run
+in parallel with non-overlapping ownership or isolated worktrees, without delaying
+the main change.
 
 Format each wave like:
 
@@ -17,9 +23,9 @@ I found these issues in your changes. For each, choose: FIX / SKIP / DISCUSS
    Duplicated error handling pattern – same try/catch in 3 functions.
    Suggested fix: Extract shared wrapper function.
 
-3. [CONSIDER | ADJACENT] `path/to/component.tsx:88`
-   Existing code (not your change) has a magic string – should use constant.
-   Suggested fix: Add constant, use in both places.
+3. [SHOULD | READABILITY] `path/to/component.tsx:88`
+   The new helper exposes parsing state its caller should not need.
+   Suggested fix: Return the parsed result and keep parsing state internal.
 
 4. [SHOULD | EDGE-CASE] `path/to/manager.py:120`
    No null check on response before accessing `.status`.
@@ -32,4 +38,5 @@ After user responds:
 
 - 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"
+- Continue until all in-scope findings are addressed or the user says "done" / "skip the rest"
+- Use focused checks while fixing; one verification owner gathers final completion evidence under the shared policy, reusing valid results

package/skills/quick-fix/SKILL.md

@@ -94,15 +94,13 @@ Apply the shared policy to the minimal fix.
 
 ## Step 6: Verify
 
-Run build verification using commands from `.acstack/project.yaml`:
+Use focused regression checks while fixing. One verification owner gathers the
+required final checks from `.acstack/project.yaml` under Build verification in
+`orchestrator/AGENTS.md`, reusing valid evidence rather than rerunning commands
+for every fix or handoff.
 
-```bash
-# Run the project's configured test, lint, and typecheck commands
-# Read these from project.yaml – do not hardcode
-```
-
-Use the configured frontend gates under the shared policy.
-Do not proceed with failed required checks or unverified configured browser behavior.
+Preserve configured frontend gates. Do not claim completion with failed or blocked
+required checks or unverified configured browser behavior.
 
 
 ## Step 7: Report

package/skills/terminal-workspace/SKILL.md

@@ -67,7 +67,7 @@ above them. Eleven of those sections install thirteen tools between them:
 - Five tools the user drives day to day: herdr, gh-dash, diffnav, lazygit and harlequin. tuicr joins them once a review starts
 - Five tools that support them: delta, tuicr, yazi, mermaid-ascii and glow
 - Two helpers of ACStack's own: acstack-md, and the acstack-clip and acstack-open pair
-- The pi coding agent, with ACStack and pi-subagents installed into it
+- The pi coding agent, with ACStack and ac-teams installed into it
 
 The twelfth, `neovim`, installs nothing. It writes one file into a neovim config
 the user already has. `neovim` and `pi` both start off, because each writes into a config the user built.

package/skills/terminal-workspace/components.md

@@ -13,7 +13,7 @@ Read this file when the user asks what a component does, which key turns it on,
 | tuicr | Reviews a pull request inside the terminal. | `tuicr.enabled` |
 | lazygit | Stages, commits, amends and pushes, on one key. | `lazygit.enabled` |
 | harlequin | A SQL editor in the terminal, on one key. Installed by uv, and launched by acstack-db. | `harlequin.enabled` |
-| pi | A coding agent in the terminal, with ACStack, pi-subagents and the user's own pi settings installed into it. Installed by npm, and starts off. | `pi.enabled` |
+| pi | A coding agent in the terminal, with ACStack, ac-teams and the user's own pi settings installed into it. Installed by npm, and starts off. | `pi.enabled` |
 | neovim | A dot in the LazyVim statusline for a buffer with unsaved changes, and copy over SSH through OSC 52. Installs nothing, writes one file, and starts off. | `neovim.enabled` |
 | yazi | A file manager, with markdown drawn live by acstack-md. One key sends the hovered file to the machine the user sits at. | `yazi.enabled` |
 | markdown | Markdown with its mermaid diagrams drawn as text, or served to a browser. Installs acstack-md, mermaid-ascii and glow. | `markdown.enabled` |

package/skills/terminal-workspace/config-choices.md

@@ -54,7 +54,7 @@ Then ask about these settings, in this order:
     - Tell such a user to delete their own file to hand the dot to this component
 - **`pi.enabled`**: off by default. Turn it on for a user who runs pi, the coding agent, or wants ACStack inside it
     - `apply` installs pi with npm when it is missing, then installs ACStack into it, pinned to this plugin's version
-    - `apply` always installs `pi-subagents` too, because ACStack on pi cannot launch a subagent without it
+    - `apply` always installs `ac-teams` too, for agent delegation, shared tasks, and messaging
     - `apply` adds one line to pi's context file in `~/.pi/agent` (`AGENTS.md` by default) that lets pi delegate when an ACStack skill says to
     - `pi.compact_tools` and `pi.agentic_retro` add pi-compact-tools and agentic-retro's pi extension, both on by default
         - agentic-retro's extension needs the agentic-retro plugin first, and `apply` says so when it is missing

package/skills/terminal-workspace/turn-off-and-update.md

@@ -25,7 +25,7 @@ and leaves the rest of the user's neovim config alone. Neither `disable` nor
 `pi` undoes only what `apply` added, because pi's config is the user's:
 
 - It removes the pi packages `apply` installed, and keeps any the user installed first
-- It releases the four settings and `toolActivation`, unless the user has changed one since
+- It releases the settings and keybinding it wrote, unless the user has changed one since
     - A value `apply` replaced goes back to what the user had, and a key `apply` added goes
 - It puts back an ACStack pin `apply` moved forward, unless the user has moved it since
 - It removes the delegation block from pi's context file, and the user's text stays byte for byte
@@ -84,8 +84,8 @@ bash "$SETUP" upgrade yazi delta   # only these
 
 pi adds four rows of its own:
 
-- `pi`, `pi-subagents` and `pi-compact-tools` compare against npm, and `upgrade` runs `pi update` for each
-    - A package the user pinned, such as `npm:pi-subagents@1.0.0`, reports `unknown`, because `pi update` never moves it
+- `pi`, `ac-teams` and `pi-compact-tools` compare against npm, and `upgrade` runs `pi update` for each
+    - A package the user pinned, such as `npm:ac-teams@1.0.0`, reports `unknown`, because `pi update` never moves it
 - `pi-acstack` compares ACStack's pin in pi against this plugin's version, with no network at all
     - `upgrade pi-acstack` moves the pin forward, and so does `apply`
     - Neither moves a pin newer than this plugin, because the user chose it

package/skills/test-conventions/SKILL.md

@@ -24,8 +24,8 @@ Mirror the source directory structure. Example: `src/auth/sessions.py` → `test
 - Cross-cutting integration tests → `<tests-dir>/integration/`
 - Shared fixtures → `<tests-dir>/conftest.py` (Python) or shared setup files
 - Use markers for slow/integration tests (configured in `test_markers.exclude`)
-- Run with the `commands.test` command from project.yaml
-- Baseline: `.acstack/.test-baseline` – count must never drop
+- Use the project's test runner for focused checks; the verification owner gathers full completion evidence under `orchestrator/AGENTS.md`
+- When test collection is configured, compare `.acstack/.test-baseline` if present; investigate removed coverage and honor project baseline requirements
 
 ## Layer 2: Frontend Unit Tests