acstack 0.52.0 → 0.52.2

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/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