anyone-can-architect 0.2.0 → 0.3.0

package/dist/cursor/aca-review/SKILL.md

@@ -9,7 +9,7 @@ disable-model-invocation: true
 # aca-review
 
 Review the design docs or code implementation in the current scope and determine pass, needs changes, or incomplete
-Do not modify design docs, project source code, or test code
+Do not modify design docs, project source code, or test code, and do not run the code or tests under review
 Use `/aca-repo-audit` for the repository-wide audit before release
 
 ## 1 Principles
@@ -18,11 +18,11 @@ Use `/aca-repo-audit` for the repository-wide audit before release
 
 1. **Source-driven review**
    Review the design against confirmed requirements and applicable rules
-   Review the implementation against the confirmed design
+   Review the code and test implementation against the confirmed design
 2. **Independent judgment**
    Form conclusions independently for each review task
 3. **Evidence-based verdict**
-   Determine issues and review conclusions from item-by-item verification results and evidence
+   Determine issues and review conclusions from item-by-item verification results and facts in code and docs
 4. **Scope constraints**
    Limit review conclusions to the current scope
 
@@ -37,7 +37,7 @@ The writing axiom applies to reviews of design doc prose and the wording of revi
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.cursor/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
@@ -81,7 +81,7 @@ Reference: [ASD-STE100](~/.cursor/skills/aca/SSOT.md#1-writing-rules)
 ```mermaid
 flowchart TD
     Start([Receive review request]) --> Scope["Confirm review scope and execution models · §3"]
-    Scope --> Check["Determine review type and run the corresponding checks · §4"]
+    Scope --> Check["Determine review type and prepare sources · §4"]
     Check --> Audit["Orchestrate and run independent reviews for the selected review type · §5"]
     Audit --> Verify["Recheck and summarize · §6"]
     Verify --> Issues{"Confirmed must-fix items exist · §7"}
@@ -95,81 +95,78 @@ flowchart TD
 
 ### 3.1 Subject, Scope, and Prerequisites
 
-1. If the developer has specified the review subject and scope, follow that specification first
-   Otherwise, use the review subject and scope already specified by the caller
-2. If the subject or scope is unclear, determine it from current workspace changes and recent relevant commits
-   Read the descriptions and diffs of recent relevant commits to understand the intent and content of the changes
-3. If the review subject or scope is still unclear, ask the developer to specify it
-4. Record the review subject, scope, and comparison baseline
-   Specify the commits under review and any uncommitted changes included in the review
-5. Run `bash ~/.cursor/skills/aca/bin/aca-repo-type-check` to check the repo type
-   If the repo type is missing or invalid, mark the repo-type spec check as incomplete and recommend running `/aca-init`
-   If the repo type is not yet supported, mark the repo-type spec check as incomplete and note that the corresponding rules are missing
-6. If the input does not include the design doc location, locate it through the documentation entry in the root README
-   If the review source material or files under review cannot be located, ask the developer to provide their locations
-   Until the locations are clear, mark checks that depend on this content as incomplete
-
-7. Read the general review source material
-   Read the confirmed problems, goals, and change scope for this review
-   If the repo type is valid and supported, read the corresponding Repo Type rules
-   Read `CONTEXT.md` and check the business concepts and definitions involved in this review
-   Read the design docs for the current scope and follow references to read any additional docs needed for understanding and verification
+1. **Confirm the review subject and scope**
+   - Developer has specified the review subject and scope: follow that specification first
+   - Developer has not specified them: use the review subject and scope already specified by the caller
+   - Subject or scope is still unclear: determine it from current workspace changes and recent relevant commits, reading the descriptions and diffs of recent relevant commits
+   - Review subject or scope still cannot be determined: ask the developer to specify it
+2. **Record the comparison baseline**
+   - Record the review subject, scope, and comparison baseline
+   - Specify the commits under review and any uncommitted changes included in the review
+3. **Check the repo type**
+   - Run `bash ~/.cursor/skills/aca/bin/aca-repo-type-check` to check the repo type
+   - Repo type is missing or invalid: mark the repo-type spec check as incomplete and recommend running `/aca-init`
+   - Repo type is not yet supported: mark the repo-type spec check as incomplete and note that the corresponding rules are missing
+4. **Locate and read general review sources**
+   - When the input does not include the design doc location, locate it from the documentation entry in the root README, or ask the developer for its location if it cannot be located and mark checks that depend on this content as incomplete until the location is clear
+   - Read the confirmed problems, goals, and change scope for this review
+   - If the repo type is valid and supported, read the corresponding Repo Type rules
+   - Read `CONTEXT.md` and check the business concepts and definitions involved in this review
+   - Read the design docs for the current scope and follow references to read any additional docs needed for understanding and verification
 
 ### 3.2 Agent and Model Selection
 
-1. Scan the current AI Agent environment and other AI Agent environments already available on this machine
-   Record the Agent tool types and actual model identifiers in each environment and compare them with the main agent
-   Use existing tool entry points, configuration, and model lists to verify invocation methods and availability
-   Installation or configuration alone does not prove that an environment can be invoked
-   Mark information that cannot be verified as unknown
-2. Propose execution combinations based on the scan results
-   Prefer callable flagship models and assess flagship status using information that can currently be verified
-   Prefer combinations whose Agent environment and model both differ from those of the main agent
-   Do not prescribe a brand, model, or order of attempts
-   If no other suitable and callable candidate is available, propose using the current model
-3. Show each candidate's Agent, model, availability, invocation method, and differences from the main agent
-   Explain the recommendation and available alternative combinations, and ask the developer to confirm
-   Run the review only after the developer confirms
-   Reuse the existing confirmation if the confirmed selection and availability conditions have not changed
-4. Use the confirmed execution combinations for [task orchestration](#53-model-and-task-orchestration)
-   If the selected combination cannot be invoked, use a confirmed alternative
-   If no alternative has been confirmed, report the change and ask the developer to confirm a new combination
-   Record the actual selection, fallback, and reasons in the report
+1. **Scan available Agent environments and models**
+   - Scan the current AI Agent environment and other AI Agent environments already available on this machine
+   - Record the Agent tool types and actual model identifiers in each environment and compare them with the main agent
+   - Use existing tool entry points, configuration, and model lists to verify invocation methods and availability
+   - Installation or configuration alone does not prove that an environment can be invoked, and information that cannot be verified is marked as unknown
+2. **Propose execution combinations**
+   - Prefer callable flagship models and assess flagship status using information that can currently be verified
+   - Prefer combinations whose Agent environment and model both differ from those of the main agent, without prescribing a brand, model, or order of attempts
+   - If no other suitable and callable candidate is available, propose using the current model
+3. **Confirm execution combinations**
+   - Show each candidate's Agent, model, availability, invocation method, and differences from the main agent
+   - Explain the recommendation and available alternative combinations, and ask the developer to confirm before running the review
+   - Reuse the existing confirmation if the confirmed selection and availability conditions have not changed
+4. **Handle execution fallback**
+   - Use the confirmed execution combinations for [Model and Task Orchestration](#53-model-and-task-orchestration)
+   - If the selected combination cannot be invoked, use a confirmed alternative, or report the change and ask the developer to confirm a new combination if no alternative has been confirmed
+   - Record the actual selection, fallback, and reasons in the report
 
 ## 4 Read Source Material and Run Checks
 
 ```mermaid
 flowchart TD
-    Kind["Determine review type · §4.1"] -- Design review --> Design["Design review · §4.2"]
-    Kind -- Implementation review --> Implementation["Implementation review · §4.3"]
+    Kind["Determine review type · §4.1"] -- Design review --> Design["Design review preparation and mechanical checks · §4.2"]
+    Kind -- Implementation review --> Implementation["Implementation review source preparation · §4.3"]
     Design --> Results["Handle check results · §4.4"]
-    Implementation --> Results
+    Implementation --> Next(["Proceed to independent review orchestration · §5"])
+    Results --> Next
 ```
 
 ### 4.1 Determine Review Type
 
-1. If the developer has specified the review type, follow that specification first
-   Otherwise, use the review type already specified by the caller
-2. If the review type is unclear, determine it from the subject under review and the actual changes
-   - Design docs: run a design review
-   - Code, tests, or runtime configuration: run an implementation review
-   - Both design and implementation: run both review types separately
-3. If the review type is still unclear, ask the developer to specify it
+1. **Determine the review type for this run**
+   - Developer has specified the review type: follow that specification first
+   - Developer has not specified it: use the review type already specified by the caller
+   - Review type is not specified: determine it from the subject under review and the actual changes (run a design review for design docs, run an implementation review for code, tests, or runtime configuration, and run both review types separately when both are involved)
+   - Review type still cannot be determined: ask the developer to specify it
 
-Run both check branches when both review types are selected
+Run both branches when both review types are selected
 
 ### 4.2 Design Review
 
-1. Read the document set, Doc Design, and Patterns actually used for the current scope
-   Extract their applicable checklist items as the basis for item-by-item verification
-2. Determine target paths for mechanical checks based on the current review scope
-   Prose checks cover all docs under review, including project-level records within the review scope
-   For the doc graph check, select a doc tree that includes the docs under review and has a README entry
-   Mechanical checks for Context verify structure and formatting, while content is verified against the corresponding Doc Design checklist
-3. Run or reuse mechanical checks
-   Existing mechanical check results from this session can be reused if they cover the same scope and the relevant files, check rules, and tools have not changed
-   When reusing results, state the original check results and the reuse conditions met in this review in the report
-   If the reuse conditions are not met, replace the placeholder paths in the following commands with the actual paths determined in step 2 and run them
+1. **Extract applicable checklist items**
+   - Read the document set, Doc Design, and Patterns actually used for the current scope
+   - Extract their applicable checklist items as the basis for item-by-item verification
+2. **Determine target paths for mechanical checks**
+   - Prose checks cover all docs under review, including project-level records within the review scope
+   - For the doc graph check, select a doc tree that includes the docs under review and has a README entry
+   - Mechanical checks for Context verify structure and formatting, while content is verified against the corresponding Doc Design checklist
+3. **Run or reuse mechanical checks**
+   - Existing mechanical check results from this session can be reused if they cover the same scope and the relevant files, check rules, and tools have not changed, stating the original results and reuse conditions in the report
+   - If the reuse conditions are not met, replace the placeholder paths in the following commands with the actual paths determined in step 2 and run them
 
    ```bash
    bash ~/.cursor/skills/aca/bin/aca-doc-graph-check <doc directory>
@@ -179,22 +176,19 @@ Run both check branches when both review types are selected
 
 ### 4.3 Implementation Review
 
-1. Read the confirmed design, test design, and repository implementation conventions for the current scope
-2. Read the current diff and changed files against the established comparison baseline
-   Read affected callers and dependency code
-   Read the functions, classes, and related call chains containing the changes to understand their execution context
-3. Map the implementation and tests to the design conventions and test scenarios respectively
-4. Based on the impact scope of the current changes, run or reuse the tests, builds, and static checks required by the design and repository conventions
-   Verify behavior that the design requires checking through actual execution by running the corresponding test cases
-   Existing verification results can be reused if they cover the same content under review and the test cases, fixtures, configuration, and dependency environment have not changed
-   When reusing results, state the original verification results and the reuse conditions met in this review in the report
-   Run the corresponding checks if verification evidence is insufficient or reuse conditions are not met
-   Use an isolated verification environment as specified by the test design
-   Do not modify commit history during verification
+1. **Read design and implementation conventions**
+   - Read the confirmed design, test design, and repository implementation conventions for the current scope
+2. **Read code and tests under review**
+   - Read the current diff and changed files against the established comparison baseline
+   - Read affected callers and dependency code
+   - Read the functions, classes, test files, and related call chains containing the changes to understand their execution context
+3. **Map design to implementation**
+   - Map the production code implementation and test code implementation to the design conventions and test scenarios respectively for item-by-item static review in Chapter 5
+   - Implementation review does not run code, tests, or builds directly, and runtime verification is executed by `/aca-test` after the review passes
 
 ### 4.4 Handle Check Results
 
-Handle tool checks for both review types as specified in this section
+Handle mechanical checks for design reviews as specified in this section
 
 | Check status | Action |
 | --- | --- |
@@ -226,62 +220,67 @@ Handle tool checks for both review types as specified in this section
 
 ### 5.2 Implementation Review Dimensions
 
-Check the following items individually against the confirmed design docs
+Statically check the following items individually against the confirmed design docs
 
 1. **Structural setup**
    Check whether the division of modules and files, responsibility assignments, interface definitions, and dependencies conform to the design
 2. **Detailed logic implementation**
    Check whether inputs, outputs, and processing flows conform to the design
    Check whether data and state changes, error handling, and boundary behavior conform to the design
-   Check whether fixtures, scenarios, and expected results in black-box and white-box tests conform to the corresponding test design
+   Check whether fixtures, scenarios, and assertions in black-box and white-box test code completely cover the corresponding test design
    Check whether test assertions can detect deviations between actual behavior and expected results
 3. **Overall structural implementation**
    Check whether module assembly, call chains, and collaboration methods conform to the overall architecture design
-   Check whether integrated behavior conforms to the cross-module flows and acceptance criteria in the design
+   Check whether cross-module wiring conforms to the flows and contract boundaries in the design
 
 ### 5.3 Model and Task Orchestration
 
-1. Create independent review tasks for the selected review type
-   For design reviews, assign an independent sub-agent to each perspective
-   For implementation reviews, assign independent sub-agents to structural setup, detailed logic implementation, and overall structural implementation
-   Each sub-agent forms conclusions independently without reading other sub-agents' review results beforehand
-2. Arrange execution using the combinations confirmed in [Agent and Model Selection](#32-agent-and-model-selection)
-   Keep review tasks independent even when using the current model
-3. Provide task context to each sub-agent
+1. **Create independent review tasks**
+   - For design reviews, assign an independent sub-agent to each perspective
+   - For implementation reviews, assign independent sub-agents to structural setup, detailed logic implementation, and overall structural implementation
+   - Each sub-agent forms conclusions independently without reading other sub-agents' review results beforehand
+2. **Arrange execution models**
+   - Arrange execution using the combinations confirmed in [Agent and Model Selection](#32-agent-and-model-selection)
+   - Keep review tasks independent even when using the current model
+3. **Provide task context**
    - Assigned review items and applicable checklist items
    - Review subject, scope, and comparison baseline, including commits under review and uncommitted changes included in the review
    - Locations of the content under review and the corresponding design source material
-   - Existing check results and evidence from chapter 4, with the basis for execution or reuse
-   - The diff, changed files, affected callers and dependency code, and repository implementation conventions needed for the implementation review
+   - Existing mechanical check results and evidence from Chapter 4
+   - The diff, changed files, test files, affected callers and dependency code, and repository implementation conventions needed for the implementation review
 
 ### 5.4 Run the Review
 
-1. Each sub-agent verifies its assigned checklist items individually
-   If a checklist item does not apply to the current scope, record it as not applicable and state the basis
-2. For each check, record the verification result, corresponding file location, and basis for judgment
-3. For each issue, record the location, problem, impact, and recommended changes using the issue format in [Review Report](#81-review-report)
-4. Return the complete check records, issue list, and incomplete items to the main agent
+1. **Verify checklist items individually**
+   - Each sub-agent verifies its assigned checklist items individually
+   - If a checklist item does not apply to the current scope, record it as not applicable and state the basis
+2. **Record verification results and issues**
+   - For each check, record the verification result, corresponding file location, and basis for judgment
+   - For each issue, record the location, problem, impact, and recommended changes using the issue format in [Review Report](#81-review-report)
+3. **Return summary to the main agent**
+   - Return the complete check records, issue list, and incomplete items to the main agent
 
 ## 6 Recheck and Summarize
 
-1. The main agent reads each sub-agent's check records
-   Check whether tool checks and verification evidence correspond to the current content under review
-2. Check the files and evidence for each issue and include it in the report only after confirming it
-   Exclude disproven issues
-   Mark issues with insufficient evidence as incomplete verification
-   The main agent can add issues it finds independently after applying the same evidence verification
-   Merge duplicate issues while retaining their locations, evidence, and impact
-3. Summarize the check records for all review items and check each checklist item's applicability and verification result
-   If a sub-agent did not cover its assigned scope, omitted checks, or lacked verification evidence, assign the corresponding supplementary checks
-   The main agent rechecks the supplementary results
-   Mark review items or checks that still cannot be completed as incomplete and state the reasons
-4. Summarize confirmed issues and check completion status as the basis for the verdict
+1. **Read sub-agent check records**
+   - The main agent reads each sub-agent's check records and checks whether the check evidence corresponds to the current content under review
+2. **Recheck and merge issues**
+   - Check the files and evidence for each issue and include it in the report only after confirming it
+   - Exclude disproven issues and mark issues with insufficient evidence as incomplete verification
+   - The main agent can add issues it finds independently after applying the same evidence verification
+   - Merge duplicate issues while retaining their locations, evidence, and impact
+3. **Check review coverage**
+   - Summarize the check records for all review items and check each checklist item's applicability and verification result
+   - If a sub-agent did not cover its assigned scope, omitted checks, or lacked verification evidence, assign the corresponding supplementary checks and recheck the results
+   - Mark review items or checks that still cannot be completed as incomplete and state the reasons
+4. **Form the basis for the verdict**
+   - Summarize confirmed issues and check completion status as the basis for the verdict
 
 ## 7 Verdict
 
 | Verdict | Criteria |
 | --- | --- |
-| Pass | All selected review tasks are complete, all applicable checklist items have passed verification, all applicable tool checks have passed, and there are no must-fix items |
+| Pass | All selected review tasks are complete, all applicable checklist items have passed verification, all applicable mechanical checks have passed, and there are no must-fix items |
 | Needs changes | Confirmed must-fix items exist |
 | Incomplete | Pass criteria are not met and there are no confirmed must-fix items |
 
@@ -305,7 +304,7 @@ Output the review results in the current conversation using the following templa
 | Baseline | <comparison baseline, commits under review, and uncommitted changes> |
 | Verdict basis | <how pass criteria are met, or issues and incomplete checks preventing a pass> |
 | Must fix | <issue count and main impact / none> |
-| Tool checks | <pass, failure, and incomplete status of tests, builds, or mechanical checks> |
+| Tool checks | <pass, failure, and incomplete status of design review mechanical checks / not applicable for implementation review> |
 | Incomplete | <incomplete review tasks and checks within the current scope, and reasons / none> |
 | Next step | <one immediately actionable step> |
 
@@ -324,7 +323,7 @@ Output the review results in the current conversation using the following templa
 
 - Read: <files actually read in this review>
 - Checklist: <criteria and sources, item-by-item verification results, basis for non-applicability, and reasons for incomplete checks>
-- Tools: <commands actually run and their results, or original results reused and basis for reuse>
+- Tools: <mechanical check commands actually run and their results, or original results reused and basis for reuse / not applicable for implementation review>
 
 | Review item | Agent environment | Model | Completion status | Notes |
 | --- | --- | --- | --- | --- |
@@ -340,12 +339,12 @@ Select the next step based on the review verdict and progress in the current rou
 
 | Verdict | Situation | Next step |
 | --- | --- | --- |
-| Incomplete | Inputs, verification environment, or verification conditions are missing | Report the conditions for resuming and continue this review through `/aca-review` once they are met |
-| Needs changes | Implementation issues | Fix and verify through `/aca-implement` |
-| Needs changes | The design solution still needs reasoning or decisions | Extend or revise the solution through `/aca-specify` |
-| Needs changes | The solution is clear and only design docs need revision | Revise the docs through `/aca-design` |
-| Pass | Only the design review has passed and implementation is needed in this round | `/aca-implement` |
-| Pass | The implementation review has passed and implementation tasks remain in this round | Continue implementation through `/aca-implement` |
-| Pass | All work in this round is complete and all required reviews have passed | Proceed to `/aca-release` according to the confirmed version progression plan |
+| Incomplete | Inputs or verification conditions are missing | Report the conditions for resuming and continue this review through `/aca-review` once they are met |
+| Needs changes | The design solution still needs reasoning or decisions | `/aca-specify` Extend or revise the solution |
+| Needs changes | The solution is clear and only design docs need revision | `/aca-design` Revise the docs |
+| Needs changes | Code or test implementation issues | `/aca-implement` Fix the implementation |
+| Pass | Design review passed and code implementation is needed in this round | `/aca-implement` |
+| Pass | Design review passed and only design docs are changed in this round | Proceed to `/aca-release` according to the confirmed version progression plan |
+| Pass | Implementation review passed | `/aca-test` Run test verification for the current scope |
 
 After design or implementation corrections, review the affected scope again through `/aca-review`

package/dist/cursor/aca-test/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: aca-test
+description: Select and run minimal tests based on the current implementation or change blast radius, testing only without modifying files
+disable-model-invocation: true
+---
+<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
+<!-- Regenerate: bash scripts/build-skills.sh --host cursor -->
+
+# aca-test
+
+Select and run the corresponding minimal tests based on the current implementation scope or the design boundary crossed by changes
+Run tests and verification only, without modifying design docs, production code, or test code
+
+## 1 Principles
+
+1. **Blast-Radius Scoping**
+   Determine the minimal test scope from the contract boundaries and dependencies of the current implementation or changes
+2. **Test Only, No Edits**
+   Run tests and verify results only, without modifying design docs, production code, or test code
+3. **Evidence Binding**
+   Bind test results to the commit under test, test scope, and commands actually executed for direct reuse by downstream stages
+
+## 2 Workflow
+
+```mermaid
+flowchart TD
+    Start([Receive test request]) --> Scope["Determine test scope · §3"]
+    Scope --> Reuse{"Result reuse conditions met? · §3"}
+    Reuse -- Yes --> Report(["Output and next step · §5"])
+    Reuse -- No --> Ready{"Test environment and prerequisites ready? · §3"}
+    Ready -- No --> Report
+    Ready -- Yes --> Run["Run tests and recheck anomalies · §4"]
+    Run --> Report
+```
+
+## 3 Determine Test Scope
+
+1. **Identify the subject under test and scope of changes**
+   - Developer or upstream caller has specified the scope to test: use that scope directly
+   - Scope not specified: read current workspace changes and recent commits, and locate the modules, commands, or events to which the changes belong against the design docs
+   - Record the commit under test and any uncommitted changes included in verification
+2. **Select the minimal test set by the design boundary crossed by changes**
+   - Only internal implementation of a module, command, or event is added or modified, and the module `interface`, command routing, and event dispatch contracts are unchanged: select only the unit's own white-box and black-box tests
+   - Module `interface`, command routing, event dispatch, or cross-unit collaboration is modified: select this unit's tests, tests of modules or commands and events that call this contract, and black-box tests in project-level `testcase` whose design basis links to this unit
+   - Shared foundation across modules such as common infrastructure, global configuration, data migration, build, or deployment is modified: select all affected tests and the corresponding environment verification
+   - When the repository `release` doc specifies additional verification for the current scope, include it as well
+3. **Check reuse conditions and execution environment**
+   - Existing test results cover the selected scope and the content under test, test code, fixtures, configuration, and dependency environment have not changed: reuse the results directly, record the basis, and proceed to [Output and Next Step](#5-output-and-next-step)
+   - Test execution required: check the readiness of the required environment, fixtures, and real dependencies or test doubles according to the test design
+   - Environment or dependencies not ready: record the missing conditions and report incomplete according to [Output and Next Step](#5-output-and-next-step)
+
+## 4 Run and Recheck
+
+1. **Control concurrency and resource isolation**
+   - Set up fixtures and an isolated environment according to the test design
+   - When shared or heavy resources such as containers, databases, real platforms, or model evaluations are involved, limit concurrency and isolate resources to prevent timeouts caused by parallel contention
+2. **Run the selected tests**
+   - Run the test cases selected in [Determine Test Scope](#3-determine-test-scope) along with required builds or static checks
+   - After execution completes, clean up test data and temporary resources created in this run according to the fixture rules
+   - Do not modify design docs, production code, test code, or commit history during verification
+3. **Recheck failures and distinguish causes**
+   - All pass: record the executed commands, number of passing test cases, and elapsed time
+   - Failures occur: check the failure logs and diagnostics
+   - Suspected timeout caused by high host load or resource contention: rerun the failed items individually under low-concurrency isolated conditions to verify
+   - Individual rerun passes consistently and is confirmed to be caused by environment load: record the initial anomaly, rerun command, and passing result
+   - Failure confirmed to be caused by code or test implementation issues: record the failing test cases, error diagnostics, and corresponding locations
+   - Environment failure or diagnostics cannot be verified: mark the corresponding verification as incomplete and record the reason
+
+## 5 Output and Next Step
+
+### 5.1 Verdict
+
+| Verdict | Criteria |
+| --- | --- |
+| Pass | All tests and required checks in the selected scope pass (including reused results or timeout rechecks), with no failing or incomplete items |
+| Fail | Confirmed code or test failures exist |
+| Incomplete | Environment is missing, execution is impossible, or diagnostics cannot be verified, and no confirmed failures exist |
+
+When both confirmed failures and incomplete items exist, the verdict is fail, and the incomplete items must be listed
+
+### 5.2 Test Report
+
+Output the test results in the current conversation using the following template
+
+```markdown
+# 🧪 Test: <pass / fail / incomplete>
+
+| Item | Result |
+| --- | --- |
+| Scope | <unit or change scope under test> |
+| Baseline | <commit under test and uncommitted changes included in verification> |
+| Selection basis | <upstream scope / intra-unit tests with unchanged contract / dependency-chain tests for contract change / full tests for global foundation> |
+| Commands | <actual test and check commands run, or basis for reuse> |
+| Result | <pass count, fail count, and elapsed time> |
+| Anomaly recheck | <individual rerun verification result for timeouts / none> |
+| Failures | <failing test cases, causes, and corresponding locations / none> |
+| Incomplete | <unexecuted verification, reasons, and conditions for resuming / none> |
+| Next step | <one immediately actionable step> |
+```
+
+### 5.3 Follow-Up Actions
+
+Select the next step based on the test verdict and progress in the current round
+
+| Verdict | Situation | Next step |
+| --- | --- | --- |
+| Incomplete | Test environment, fixtures, or external dependencies are missing | Supply the environment conditions and verify again through `/aca-test` |
+| Fail | Code or test implementation issues | Fix through `/aca-implement`, review through `/aca-review`, then run `/aca-test` |
+| Fail | Missing design or contract conflict | Revise the design through `/aca-specify` or `/aca-design` |
+| Pass | Subsequent implementation tasks remain in this round | Continue implementing the next scope through `/aca-implement` |
+| Pass | All implementation scopes in this round have passed verification | Proceed to `/aca-release` according to the version progression plan or conclude the current task |

package/dist/cursor/aca-walkthrough/SKILL.md

@@ -34,7 +34,7 @@ Confirm design decisions unit by unit and correct identified issues on the spot
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.cursor/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/grok/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/grok/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](~/.grok/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