anyone-can-architect 0.2.0 → 0.3.0

package/README.md

@@ -12,7 +12,7 @@
 
 <p align="center"><strong>English</strong> · <a href="README.zh-CN.md">简体中文</a></p>
 
-<p align="center"><img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
+<p align="center"><a href="https://www.npmjs.com/package/anyone-can-architect"><img alt="npm version" src="https://img.shields.io/npm/v/anyone-can-architect?color=CB3837"></a> <img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
 
 ---
 
@@ -35,7 +35,8 @@ flowchart LR
     Brownfield --> Design
     Design --> Implement["/aca-implement<br>build code from the docs"]
     Implement --> Review["/aca-review<br>check against the design"]
-    Review --> Release["/aca-release<br>merge and tag"]
+    Review --> Test["/aca-test<br>run minimal tests"]
+    Test --> Release["/aca-release<br>merge and tag"]
 ```
 
 ---
@@ -84,6 +85,7 @@ In Codex, type `$` instead of `/`, for example `$aca`
 | `/aca-walkthrough` | Walks you through the design docs in plain language and fixes issues on the spot |
 | `/aca-implement` | Builds the code and tests from the design docs |
 | `/aca-review` | Reviews the design docs or the code in the current scope |
+| `/aca-test` | Selects and runs minimal tests based on the implementation or change blast radius |
 | `/aca-repo-audit` | Checks the whole repo for broken links, contradictions and drift between docs and code |
 | `/aca-release` | Merges the verified version into main and tags it |
 | `/aca-feedback` | Files a GitHub issue when a rule does not fit your project |
@@ -104,5 +106,5 @@ Run `bash tests/run-tests.sh` before opening a pull request
 
 ---
 
-> 📦 **Anyone Can Architect v0.2.0**
-> 🤝 Powered by [Anyone Can Architect](https://github.com/ruozi/anyone-can-architect) v0.2.0 · Repo-Type: `guideline`
+> 📦 **Anyone Can Architect v0.3.0**
+> 🤝 Powered by [Anyone Can Architect](https://github.com/ruozi/anyone-can-architect) v0.3.0 · Repo-Type: `guideline`

package/README.zh-CN.md

@@ -12,7 +12,7 @@
 
 <p align="center"><a href="README.md">English</a> · <strong>简体中文</strong></p>
 
-<p align="center"><img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
+<p align="center"><a href="https://www.npmjs.com/package/anyone-can-architect"><img alt="npm version" src="https://img.shields.io/npm/v/anyone-can-architect?color=CB3837"></a> <img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
 
 ---
 
@@ -35,7 +35,8 @@ flowchart LR
     Brownfield --> Design
     Design --> Implement["/aca-implement<br>按文档构建代码"]
     Implement --> Review["/aca-review<br>对照设计审查"]
-    Review --> Release["/aca-release<br>合并并打 Tag"]
+    Review --> Test["/aca-test<br>运行最小化测试"]
+    Test --> Release["/aca-release<br>合并并打 Tag"]
 ```
 
 ---
@@ -85,6 +86,7 @@ npx anyone-can-architect install --lang zh
 | `/aca-walkthrough` | 用业务语言带你走读设计文档，当场修正问题 |
 | `/aca-implement` | 按设计文档构建代码与测试 |
 | `/aca-review` | 审查当前范围的设计文档或代码 |
+| `/aca-test` | 按实现或改动影响范围选取并运行最小化测试 |
 | `/aca-repo-audit` | 检查全仓的断链、矛盾及文档与代码的偏移 |
 | `/aca-release` | 将已验证的版本合入 main 并打 Tag |
 | `/aca-feedback` | 规则不适合你的项目时，提交 GitHub Issue |

package/VERSION

@@ -1 +1 @@
-0.2.0
+0.3.0

package/axioms/README.md

@@ -8,4 +8,4 @@
 | Writing | [writing.md](writing.md) | design "Doc Writing" chapter<br>walkthrough / review / repo-audit body<br>Top of each doc design | Doc structure, concepts and references, chapters and sections, lines and tables, characters — "how to write" |
 | Completeness (Boil the Ocean) | [boil-the-ocean.md](boil-the-ocean.md) | specify "Solution Design" chapter | If you can achieve 100%, do not settle for 80% |
 
-Skill-level axioms apply only to skills with design responsibilities, implement / release / feedback handle execution only and receive no injection
+Skill-level axioms apply only to skills with design responsibilities, implement / test / release / feedback handle execution only and receive no injection

package/axioms/writing.md

@@ -7,7 +7,7 @@
 - Present the whole first, then expand on the details, see the [Pyramid Principle](../SSOT.md#2-structure)
 - When stating a judgment, give the conclusion first, then the supporting evidence
 - Merge heading levels that add no information
-- Use numbered lists for items with a sequence or priority, and indent multiple attributes under each item
+- Use numbered lists for items with a sequence or priority; when a step contains sub-items, start the step with a bold phrase stating its purpose and indent specific operations and conditional branches under it
 - Use tables only for content with multiple rows of the same structure, more than two attributes per row, and no sequence between rows
 - Write list items as complete sentences
 - When an item has branches, indent the branches under that item

package/dist/antigravity/aca/SKILL.md

@@ -43,8 +43,9 @@ flowchart TD
 | `/aca-specify` | Reason through new requirements or improve existing designs, then proceed to Design after confirming the solution |
 | `/aca-design` | Write and check design docs within the current scope, then determine the next scope or complete the overall closeout |
 | `/aca-walkthrough` | Walk through design docs in business language, confirm design decisions unit by unit, and correct identified issues on the spot after confirmation |
-| `/aca-review` | Determine the review subject and scope, review the design or check implementation compliance with the design, without modifying the docs or code under review |
-| `/aca-implement` | Plan the file structure based on the design, then implement and verify code and tests according to module dependencies |
+| `/aca-review` | Determine the review subject and scope, statically review the design or code and test implementation, without modifying the docs or code under review or running code |
+| `/aca-implement` | Plan the file structure based on the design, then write production code and test code according to module dependencies |
+| `/aca-test` | Select and run minimal tests based on the current implementation scope or the design boundary crossed by changes, testing only without modifying files |
 | `/aca-repo-audit` | Check repository documentation and verify the implementation as needed, with read-only access and no changes |
 | `/aca-release` | Close out according to the repository release workflow, merge into main, and lock in an annotated Tag |
 | `/aca-feedback` | Collect deviations from governance rules and submit an Issue after explicit authorization |

package/dist/antigravity/aca-design/SKILL.md

@@ -22,7 +22,7 @@ Change only documentation, not code
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.gemini/config/skills/aca/SSOT.md#2-structure)
 - When stating a judgment, give the conclusion first, then the supporting evidence
 - Merge heading levels that add no information
-- Use numbered lists for items with a sequence or priority, and indent multiple attributes under each item
+- Use numbered lists for items with a sequence or priority; when a step contains sub-items, start the step with a bold phrase stating its purpose and indent specific operations and conditional branches under it
 - Use tables only for content with multiple rows of the same structure, more than two attributes per row, and no sequence between rows
 - Write list items as complete sentences
 - When an item has branches, indent the branches under that item

package/dist/antigravity/aca-implement/SKILL.md

@@ -3,12 +3,11 @@ name: aca-implement
 description: |
   1. Set implementation goals and completion criteria based on the design
   2. Plan the responsibilities and structure of source code and test files based on module boundaries and internal design
-  3. Orchestrate implementation and verification tasks by module dependencies
+  3. Orchestrate implementation tasks by module dependencies
   4. Create all directories and file placeholders according to the plan
-  5. Assign sub-agents by module dependencies, implement in parallel wherever possible, and run black-box and white-box tests
-  6. Commit the corresponding changes after each module passes verification
-  7. Integrate the commits of verified modules
-  8. Complete overall verification and check the completion criteria for the goal
+  5. Assign sub-agents by module dependencies and write production code along with black-box and white-box test code in parallel wherever possible
+  6. Commit the corresponding changes and integrate after each module is complete
+  7. Check the completion criteria for the goal and hand off to review and testing
   Change only code and tests
 ---
 <!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
@@ -16,22 +15,21 @@ description: |
 
 # aca-implement
 
-Implement code and tests according to the design docs for the current scope
-Change only code and tests, not design docs
+Write production code and test code according to the design docs for the current scope
+Change only code and tests, without modifying design docs or running tests
 
 ## 1 Principles
 
 1. **Goal-driven**
    Use confirmed delivery goals to determine the implementation scope and task priorities
-   Use completion criteria and their verification evidence to determine whether the goals are met
+   Judge implementation completion by coverage of the design requirements
 2. **Dependency-driven parallelism**
    Use dependencies to determine the implementation order
-   Run tasks in parallel wherever possible when their dependencies are satisfied and they have no shared resource conflicts
-3. **Test-driven**
-   Use external contracts and internal design to determine test expectations
-   Drive implementation with tests and use both black-box and white-box tests to verify design requirements
-4. **Scope constraints**
-   Keep implementation and refactoring within the confirmed design scope
+   Advance tasks in parallel wherever possible when their dependencies are satisfied and they have no file conflicts
+3. **Code and tests in sync**
+   Write production code along with black-box and white-box test code in sync based on external contracts, internal design, and test design
+4. **Write only, no test execution**
+   Write or modify code and tests only during implementation, and hand off test execution to `/aca-test`
 
 ## 2 Workflow
 
@@ -41,14 +39,9 @@ flowchart TD
     Plan --> Prepare["Implementation Preparation · §4"]
     Prepare --> Implement["Implementation and Integration · §5"]
     Implement -- All remaining tasks are blocked and no tasks are in progress --> Report
-    Implement --> Modules{All module tasks are complete and integrated}
+    Implement --> Modules{All module tasks for the current scope are complete and integrated}
     Modules -- No --> Implement
-    Modules -- Yes --> Verify["Overall Verification · §6"]
-    Verify --> Complete{All completion criteria for the current scope are verified as satisfied}
-    Complete -- No, the design is clear and fixes are possible within the current scope --> Implement
-    Complete -- No, remaining verification can continue --> Verify
-    Complete -- No, remaining fixes or verification are blocked --> Report
-    Complete -- Yes --> Report(["Output and Next Step · §7"])
+    Modules -- Yes --> Report(["Output and Next Step · §6"])
 ```
 
 ## 3 Goals and Task Orchestration
@@ -57,49 +50,53 @@ Read the design docs, project configuration, existing code, and tests for the cu
 Check the workspace state and recent commits to verify current implementation progress and existing changes
 Preserve existing changes outside the scope of this implementation
 
-1. List deliverables and their completion criteria based on the confirmed design and implementation scope
-2. Compare delivery requirements with existing code and tests, and list what to reuse, modify, add, or remove
-3. List the tests to run for this implementation based on the black-box and white-box test designs
-   Specify the environments and fixtures these tests require
-4. List the modules involved in this implementation and their dependencies based on the design
-   Modules include submodules at all levels: top-level modules come from architecture, and submodules come from the internal composition of their direct parent's class-design
-5. Specify whether each test uses real dependencies or test doubles based on the test design
-   Check the readiness of required dependencies
-6. Plan the source code and test file structure based on module boundaries, internal design, and repository conventions
-   List all source code and test directories and files within the current implementation scope
-7. Specify each file's responsibilities, owning module, and dependencies
-   Check whether each file has a single responsibility and whether responsibilities overlap
-   Adjust file boundaries when responsibilities are not singular or overlap
-8. Split implementation preparation, module implementation, integration, and overall verification into tasks
-   Use modules in the design as the smallest units of implementation, verification, and commits
-   When submodules exist, create separate tasks for each submodule and the parent's composition implementation, with the parent task depending on all its submodule tasks
-9. Specify each task's dependencies, owner, and completion criteria
-10. Use the goal or task management capabilities provided by the current AI Agent environment to maintain the overall goal and task progress
-    Record each task's status: pending implementation, in progress, complete, or blocked
-    Record verification evidence and the next action for each task
-    When resuming a task, check task records, the workspace, and recent commits
-    Update task status based on the findings and continue implementation
+1. **Specify deliverables and completion criteria**
+   - List deliverables and their completion criteria based on the confirmed design and implementation scope
+2. **Compile the code and test change list**
+   - Compare delivery requirements with existing code and tests, and list what to reuse, modify, add, or remove
+3. **Orchestrate the corresponding test scope**
+   - List the test cases and fixtures to write or update in this run based on the black-box and white-box test designs
+   - Record the units under test and test case scope corresponding to the current implementation scope for direct execution by `/aca-test`
+4. **Identify modules and dependencies**
+   - List the modules involved in this implementation and their dependencies based on the design
+   - Modules include submodules at all levels: top-level modules come from architecture, and submodules come from the internal composition of their direct parent's class-design
+5. **Plan the source code and test file structure**
+   - Plan the source code and test file structure based on module boundaries, internal design, and repository conventions
+   - List all source code and test directories and files within the current implementation scope
+6. **Check file responsibilities and boundaries**
+   - Specify each file's responsibilities, owning module, and dependencies
+   - Check whether each file has a single responsibility and whether responsibilities overlap
+   - Responsibilities are not singular or overlap: adjust file boundaries
+7. **Split module implementation and integration tasks**
+   - Split implementation preparation, module implementation, and integration into tasks
+   - Use modules in the design as the smallest units of implementation and commits
+   - When submodules exist, create separate tasks for each submodule and the parent's composition implementation, with the parent task depending on all its submodule tasks
+   - Specify each task's dependencies, owner, and completion criteria
+8. **Maintain task status and progress**
+   - Use the goal or task management capabilities provided by the current AI Agent environment to maintain the overall goal and task progress
+   - Record each task's status: pending implementation, in progress, complete, or blocked
+   - When resuming a task, check task records, the workspace, and recent commits, update task status, and continue implementation
 
 ## 4 Implementation Preparation
 
-1. Add all missing source code and test directories and file placeholders for the current scope according to the plan
-   Reuse existing files directly and create new files as empty files
-   Delete files explicitly marked for removal in the plan only after verifying that they no longer serve a valid responsibility
-   When a file's purpose, dependencies, or deletion scope cannot be confirmed, retain it and verify with the developer
-   Start module implementation only after all file placeholders are in place
-2. The main agent assigns separate workspaces to sub-agents
-   Allocate test resources according to the test design to ensure parallel tasks do not interfere with each other
-   Synchronize the prepared file structure to each workspace
-3. Provide each sub-agent with the following task context
+1. **Create directories and file placeholders**
+   - Add all missing source code and test directories and file placeholders for the current scope according to the plan
+   - Reuse existing files directly and create new files as empty files
+   - Delete files explicitly marked for removal in the plan only after verifying that they no longer serve a valid responsibility
+   - File purpose, dependencies, or deletion scope cannot be confirmed: retain the file and verify with the developer
+   - Start module implementation only after all file placeholders are in place
+2. **Assign separate workspaces**
+   - The main agent assigns separate workspaces to sub-agents
+   - Synchronize the prepared file structure to each workspace
+3. **Dispatch task context to sub-agents**
    - The overall implementation goal, the functionality to complete for the current module, and the scope of changes
    - Links to relevant chapters covering the structural basis, interfaces, internal design, and test cases for the current module and its dependencies
      The structural basis for top-level modules is architecture, and the structural basis for submodules is the internal composition of the parent's class-design
    - The readiness of each dependency and the arrangements for real dependencies or test doubles in tests
    - The workspace path, starting commit, files permitted for modification, and applicable repository conventions
-   - Test environments and fixtures, verification commands, and module completion criteria
-   - Change only code and tests
+   - Modify only production code and test code, without modifying design docs or running tests
    - Follow the [Exception Handling](#52-exception-handling) requirements
-   - Return changed files, commit records, verification commands and results, unverified items, and reasons for blockers
+   - Return changed files, commit records, corresponding test scope, and reasons for blockers
 
    When files owned by other tasks or shared files are involved, first ask the main agent to coordinate
 
@@ -107,63 +104,48 @@ Preserve existing changes outside the scope of this implementation
 
 ### 5.1 Implementation Loop
 
-1. The main agent selects module tasks whose dependencies are satisfied
-   Assign tasks that can run in parallel to sub-agents
-2. Implement and verify each module according to the test design
-   1. Prepare and run tests
-      Reuse, write, or update black-box and white-box tests for the module's current scope according to the design
-      When new or changed design requirements are not yet implemented, confirm that the corresponding tests fail
-      For refactoring that preserves behavior, first run the corresponding tests to establish a verification baseline
-   2. Complete and verify changes within the module's current scope according to the design
-      Follow repository conventions for implementation details not specified by the design
-      When the repository has no corresponding conventions, use the simplest implementation that meets the design
-      When the design includes a Lark (Feishu) card mockup, implement it according to [Lark Card Mapping](~/.gemini/config/skills/aca/skills/references/lark-card-mapping.md)
-      Run module tests and confirm that all pass
-   3. Refactor as needed and verify again
-      After refactoring, rerun module tests and confirm that all pass
-   When an unexpected test failure occurs and the design is clear, fix the code and rerun the affected tests
-3. Check black-box and white-box test results and other completion criteria for the module's current scope
-   Once all criteria are satisfied, stage and commit only the current task's changes
-4. The main agent checks module commits and verification evidence
-   Integrate the module's commits after confirming that it meets the completion criteria
-   Run tests for affected modules and integration tests between modules on the integrated code
-5. The main agent updates task status, verification evidence, and dependency readiness
-   Record the reasons for blocked tasks and the conditions for resuming them
-   Synchronize integrated dependency commits that have passed verification to module workspaces that require real dependencies
-   If tasks remain that can be implemented, return to step 1
-   If no tasks can be assigned and tasks are still in progress, wait for execution results
-   After all module tasks are complete and integrated, proceed to [Overall Verification](#6-overall-verification)
-   If all remaining tasks are blocked and no tasks are in progress, report the incomplete status according to [Output](#7-output)
+1. **Dispatch parallelizable module tasks**
+   - The main agent selects module tasks whose dependencies are satisfied and assigns tasks that can run in parallel to sub-agents
+2. **Write module production code and test code**
+   - Reuse, write, or update black-box and white-box test code and fixtures for the module's current scope according to the design
+   - Complete production code changes within the module's current scope according to the design
+   - Follow repository conventions for implementation details not specified by the design, or use the simplest implementation that meets the design when the repository has no corresponding convention
+   - When the design includes a Lark (Feishu) card mockup, implement it according to [Lark Card Mapping](~/.gemini/config/skills/aca/skills/references/lark-card-mapping.md)
+   - Organize code structure as needed to keep responsibilities singular and boundaries clear
+3. **Check module completion criteria and commit**
+   - Check that interface contracts, internal mechanisms, and black-box and white-box test code for the module's current scope are all written according to the design
+   - Stage and commit only the current task's changes
+4. **Integrate module commits**
+   - The main agent checks the file scope and completion status of module commits
+   - Integrate the module's commits after confirming that it meets the completion criteria
+5. **Update progress and advance**
+   - The main agent updates task status, implemented module scope, and dependency readiness
+   - Record the reasons for blocked tasks and the conditions for resuming them
+   - Synchronize integrated dependency commits to downstream module workspaces
+   - Tasks remain that can be implemented: return to step 1
+   - No tasks can be assigned and tasks are still in progress: wait for execution results
+   - All module tasks for the current scope are complete and integrated: proceed to [Output](#6-output)
+   - All remaining tasks are blocked and no tasks are in progress: report the incomplete status according to [Output](#6-output)
 
 ### 5.2 Exception Handling
 
-1. When the design is missing, contains conflicts, or cannot be implemented, the agent executing the task pauses affected tasks
-   Sub-agents report the issue and its scope of impact to the main agent
-   The main agent verifies the issue and its scope of impact, then reports them to the developer
-   When the solution needs additions or revisions, recommend using `/aca-specify`
-   Continue unaffected independent tasks
-2. When issues are found in other repositories, the main agent verifies them and reports the issues and their impact to the developer
-   Do not modify other repositories without authorization
+1. **Handle missing or conflicting designs**
+   - When the design is missing, contains conflicts, or cannot be implemented, the agent executing the task pauses affected tasks
+   - Sub-agents report the issue and its scope of impact to the main agent
+   - The main agent verifies the issue and its scope of impact, then reports them to the developer
+   - When the solution needs additions or revisions, recommend using `/aca-specify`
+   - Continue unaffected independent tasks
+2. **Handle cross-repository issues**
+   - When issues are found in other repositories, the main agent verifies them and reports the issues and their impact to the developer
+   - Do not modify other repositories without authorization
 
-## 6 Overall Verification
+## 6 Output
 
-After all module tasks are complete and integrated, the main agent performs overall verification for the current delivery scope
-Run module tests, integration tests, system tests, builds, and static checks according to the implementation plan
-Execute the test cases specified in the design and verify the runtime results of the subject under test
-Passing builds or static checks cannot replace behavioral test results
-
-When issues are found for which the design is clear and fixes are possible within the current scope, return to [Implementation and Integration](#5-implementation-and-integration)
-Rerun affected verification after fixes
-Check each completion criterion against the overall goal
-Update task records with verification results and unverified items
-
-## 7 Output
-
-When all completion criteria for the current scope are verified as satisfied, mark the goal and tasks as complete
+When all completion criteria for the current scope are satisfied, mark the goal and task status as complete
 If incomplete, report remaining work, reasons for blockers, and actions to resume
-After this implementation is complete, use `/aca-review` to review the implementation within this scope
-Provide Review with the overall goal, corresponding design, implementation scope, and comparison baseline
-Identify the commits and uncommitted changes under review, and provide verification results and evidence
+After this implementation is complete, use `/aca-review` to run an implementation review on this scope
+Provide Review and subsequent `/aca-test` with the overall goal, corresponding design, implementation scope, orchestrated test scope, and comparison baseline
+Identify the commits and uncommitted changes under review
 Use the following format for the final report, filling in the title and results according to the actual status
 
 ```markdown
@@ -173,9 +155,8 @@ Use the following format for the final report, filling in the title and results
 | --- | --- |
 | Goal | <overall goal and completion criteria satisfaction> |
 | Scope | <implementation scope and module progress> |
-| Changes | <main implementation changes> |
-| Verification | <test execution, build, and static check results> |
-| Unverified | <unverified scope / none> |
+| Changes | <main production code and test code changes> |
+| Test scope | <units under test and test case scope orchestrated for /aca-test> |
 | Commits | <commit records / uncommitted> |
 | Blockers | <blockers and reasons / none> |
 | Recommendations | <extension recommendations / none> |

package/dist/antigravity/aca-release/SKILL.md

@@ -201,9 +201,9 @@ If execution cannot continue in Chapters 4 through 7, report completed facts, th
    Cross-check that the Anyone Can Architect footer matches the current Anyone Can Architect version, immediately follows the repository version line, and is the last line
    Cross-check that the final commit contains the complete design, implementation, and tests for this scope
 3. Complete final verification
-   Complete the verification required by the repository release workflow on the final commit
+   Complete the verification required by the repository release workflow and the `/aca-test` test scope on the final commit
    Record verification results and the corresponding commit
-   When reusing existing results, state which reuse conditions are met and the basis for their correspondence to the final commit
+   When reusing existing `/aca-test` or verification results, state which reuse conditions are met and the basis for their correspondence to the final commit
    If artifacts are involved, cross-check their traceability to this commit
    Verification artifacts cannot replace evidence of completed delivery
 4. Determine whether release locking is allowed
@@ -368,7 +368,8 @@ Select one immediately executable action based on the incomplete items
 | Execution conditions are missing | Meet the conditions, then check the status against [release preparation](#3-release-preparation) and resume |
 | The design solution still needs reasoning | `/aca-specify` Reason through the solution |
 | The revision solution is clear and only doc changes are needed | `/aca-design` Revise the docs |
-| Implementation issues | `/aca-implement` Fix and verify |
+| Implementation issues | `/aca-implement` Fix code or tests |
+| Tests or final verification incomplete | `/aca-test` Run verification, then resume the release |
 | Merge conflicts | Resolve and commit the conflicts, then rerun the [pre-merge audit](#43-pre-merge-audit) |
 | Push, cleanup, or announcement is still incomplete | Resume from the corresponding incomplete step |
 | Everything is complete and no follow-up items remain | Report that there are no pending tasks |

package/dist/antigravity/aca-repo-audit/SKILL.md

@@ -34,7 +34,7 @@ Use `/aca-review` when you need to judge whether business goals and design solut
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.gemini/config/skills/aca/SSOT.md#2-structure)
 - When stating a judgment, give the conclusion first, then the supporting evidence
 - Merge heading levels that add no information
-- Use numbered lists for items with a sequence or priority, and indent multiple attributes under each item
+- Use numbered lists for items with a sequence or priority; when a step contains sub-items, start the step with a bold phrase stating its purpose and indent specific operations and conditional branches under it
 - Use tables only for content with multiple rows of the same structure, more than two attributes per row, and no sequence between rows
 - Write list items as complete sentences
 - When an item has branches, indent the branches under that item
@@ -181,16 +181,17 @@ When an implementation audit is included, cross-check all design items in scope
 
 ### 5.2 Runtime Verification
 
-1. Determine verification requirements
-   Read the full test and build commands specified by the repository
+1. **Determine verification requirements**
+   Determine the test and build commands required for the current scope according to the boundary rules in `/aca-test` and the repository `release` doc
+   Run full tests and builds by default when the repository does not specify tiered verification
    Check the required environment, configuration, and fixtures
-2. Run verification or reuse its results
-   Reuse existing results if they cover the required verification and the content under review, tests, fixtures, configuration, dependency environment, and commands have not changed
+2. **Run verification or reuse its results**
+   Reuse existing `/aca-test` or build results if they cover the required scope and the commit under review, tests, fixtures, configuration, dependency environment, and commands have not changed
    State the original verification results and the basis for reuse in the report
-   Run the corresponding verification in an isolated environment if the reuse conditions are not met
+   Run the required tests and builds in an isolated environment following the execution rules of `/aca-test` if the reuse conditions are not met
    Static reading cannot replace verification by execution
    Do not modify project source code, design docs, or commit history during verification
-3. Record results and handle exceptions
+3. **Record results and handle exceptions**
    Record the results and supporting evidence when verification passes
    Verify diagnostics and record confirmed issues when verification fails
    Mark the corresponding verification as incomplete and explain why if the environment is unavailable or execution is not possible
@@ -223,7 +224,7 @@ When an implementation audit is included, cross-check all design items in scope
 | Incomplete | Pass conditions are not met, and no confirmed must fix items exist |
 
 Required checks include reading documentation, mechanical checks, and content checks in the current scope
-When an implementation audit is included, they also include all consistency cross-checks, full tests, and builds
+When an implementation audit is included, they also include all consistency cross-checks and the tests and builds required for the current scope
 When both must fix items and incomplete checks exist, set the verdict to action required and list the incomplete items
 Optional trim does not affect a pass
 
@@ -273,7 +274,8 @@ Choose one immediately executable action based on the nature of the issues and t
 | Verification prerequisites are missing | Meet the prerequisites, then continue this audit through `/aca-repo-audit` |
 | The solution still needs reasoning | Use `/aca-specify` to reason through the solution |
 | The revised solution is clear and only docs need changes | Use `/aca-design` to revise the docs |
-| Implementation deviates | Use `/aca-implement` to fix and verify |
+| Implementation deviates | `/aca-implement` Fix code or tests |
+| Tests or builds incomplete | `/aca-test` Run verification |
 | Audit passes | Return to the caller and continue with the confirmed arrangements |
 
 Audit the affected scope again after the issues are corrected