anyone-can-architect 0.3.0 → 0.4.0

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

@@ -59,10 +59,12 @@ flowchart TD
    - 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
+   - Failures occur: against the confirmed design, check the failure logs, test cases, fixtures, and implementation
    - 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
+   - The implementation deviates from the design: report an implementation issue, and identify the failing test cases and the corresponding implementation locations
+   - Test expectations are outdated or the tests or fixtures are wrong: report a test issue, and identify the corresponding design basis and error locations
+   - The design is missing or contracts conflict: mark the corresponding verification as incomplete, and hand it to `/aca-specify` or `/aca-design`
    - Environment failure or diagnostics cannot be verified: mark the corresponding verification as incomplete and record the reason
 
 ## 5 Output and Next Step
@@ -73,7 +75,7 @@ flowchart TD
 | --- | --- |
 | 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 |
+| Incomplete | The design is missing, contracts conflict, the 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
 
@@ -104,7 +106,7 @@ 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` |
+| Fail | Code or test implementation issues | Fix through `/aca-implement` (verify again directly through `/aca-test` when the code structure is unchanged, or review through `/aca-review` before running `/aca-test` when the code structure changes) |
+| Incomplete | 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/antigravity/aca-walkthrough/SKILL.md

@@ -52,6 +52,8 @@ Confirm design decisions unit by unit and correct identified issues on the spot
 - Remove content that adds no information and does not help understanding
 - Write one sentence per line, with only one fact per sentence
 - State actions directly in operational steps
+- If a specific practice fully expresses a constraint, write the practice directly
+- Keep prohibitions that no specific practice can fully express
 - Write sequential actions as separate items
 - Make the actor, the object of the action, and the referents clear
 - Do not repeat actors, objects of actions, or referents already clear from context
@@ -98,7 +100,7 @@ flowchart TD
    If it still cannot be located, ask the developer to specify the doc location
    Read `~/.gemini/config/skills/aca/doc-design/repo-types/{repo-type}.md`
    Read `CONTEXT.md` and the design docs in the current scope
-   Read the corresponding document set, doc design, and patterns actually used
+   Read the corresponding document set and doc design, and read relevant patterns as needed
 4. Arrange the walkthrough order
    Follow the governance order in the repo-type spec
    Within a document set, follow the order specified by that document set
@@ -152,14 +154,15 @@ flowchart TD
 
 ### 4.2 Discuss and Cross-Check
 
-1. First explain the problems and requirements the current unit must address in business language
-   Then explain how the design meets these requirements
-   When business concepts are involved, link to the corresponding entries in the project's `CONTEXT.md`
-   Explain each concept's meaning and role in the current design
-2. Cross-check the design of the current unit
-   Cross-check each applicable checklist item in the document set, doc design, and patterns actually used
-   When walking through the overall doc structure, discuss chapter and section divisions, content placement, and presentation order against the corresponding Doc Design
-   Identify content that needs to be merged, split, or reordered
+1. **Walk through the current unit in business language**
+   - First explain the problems and requirements the current unit must address, then explain how the design meets these requirements
+   - Business concepts are involved: link to the corresponding entries in the project's `CONTEXT.md`, and explain each concept's meaning and role in the current design
+2. **Cross-check organization and expression**
+   - Walking through the overall doc structure: explain chapter and section divisions, content placement, and presentation order against the corresponding doc design, and propose content to merge, split, or reorder
+   - Walking through a Chapter or Section: against the expression requirements of the corresponding doc design and the applicable scenarios in `~/.gemini/config/skills/aca/doc-design/patterns/`, tell the developer whether the current form of expression fits the content, without keeping existing code, tables, or diagrams by default
+   - The current form of expression does not fit: first propose a replacement, split, or combined form of expression to the developer and read the selected pattern, without patching the original expression locally
+3. **Cross-check each checklist item**
+   - Cross-check each checklist item in the document set, doc design, and selected patterns that applies to the current unit
 
    | Check item | Focus |
    | --- | --- |
@@ -167,14 +170,14 @@ flowchart TD
    | Completeness | Omissions in responsibilities, behavior, boundaries, and exception handling |
    | Ambiguity and implementation uniqueness | Multiple reasonable interpretations, implementations that match the description but behave differently, and unresolved design decisions |
    | Redundancy | Duplicate maintenance and content that adds no information |
-   | Expression | Writing axiom, corresponding doc design, and terminology consistency |
+   | Expression | Choice and fit of the form of expression, writing axiom, corresponding doc design, and terminology consistency |
 
 ### 4.3 Confirm, Revise, and Check
 
-1. Ask the developer to confirm the current unit's design decisions
+1. Ask the developer to confirm the current unit's design decisions and changes to the form of expression
    If the developer does not understand or disagrees, clarify the meaning and rationale
    If not yet confirmed, continue discussing the current unit according to [Discuss and Cross-Check](#42-discuss-and-cross-check)
-2. When changes are confirmed, revise on the spot according to the corresponding doc design
+2. When changes are confirmed, revise on the spot according to the corresponding doc design and selected patterns
    When chapters or sections change, also update affected references and related designs
 3. After revision, rerun affected checklist items and mechanical checks
    Report the corrections and check results
@@ -243,4 +246,5 @@ Choose one immediately executable action based on completion status and progress
 | --- | --- | --- |
 | Incomplete | Units still await a walkthrough or verification conditions are missing | Meet the conditions, then continue this walkthrough through `/aca-walkthrough` |
 | Incomplete | The design solution cannot be determined this round | Use `/aca-specify` to reason through the solution |
-| Complete | The walkthrough of the current scope is complete | Review the design through `/aca-review` according to the confirmed arrangements |
+| Complete | The walkthrough of the current scope is complete, and the design in this round is cross-module | Review the design through `/aca-review` |
+| Complete | The walkthrough of the current scope is complete, and the design in this round is not cross-module | Go directly to the next step (`/aca-implement` when code is needed, `/aca-release` when only design docs change) |

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

@@ -43,7 +43,7 @@ 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, statically review the design or code and test implementation, without modifying the docs or code under review or running code |
+| `/aca-review` | Determine the review subject and scope, statically review the design or the overall code structure, 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 |

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

@@ -41,6 +41,8 @@ Change only documentation, not code
 - Remove content that adds no information and does not help understanding
 - Write one sentence per line, with only one fact per sentence
 - State actions directly in operational steps
+- If a specific practice fully expresses a constraint, write the practice directly
+- Keep prohibitions that no specific practice can fully express
 - Write sequential actions as separate items
 - Make the actor, the object of the action, and the referents clear
 - Do not repeat actors, objects of actions, or referents already clear from context
@@ -167,11 +169,13 @@ If neither the repo-type spec nor the document set specifies an order, arrange w
      Keep plain text in headings, code blocks, Mermaid labels, and product copy
 4. Synchronize affected test designs
    - Identify affected black-box and white-box test designs based on contracts, flows, and internal mechanisms added, revised, or deleted in this round
+   - Against the confirmed design, check the affected existing test code, fixtures, and the behavior they actually verify
    - Update test designs in sequence according to the corresponding doc designs and [test cases](~/.gemini/antigravity-cli/skills/aca/doc-design/patterns/testcase.md)
      1. Update fixtures
      2. Update test scenarios and their references to design rationale
      3. Update test cases based on the scenarios
         Add missing cases, revise changed cases, and delete or replace invalid cases
+   - Leave actual changes to test code and fixtures to `/aca-implement`
    - If only wording is revised and verified behavior has not changed, check that test designs and references remain valid
    - If solution decisions or as-is evidence required for test design are missing, handle them under §3
    - If affected docs are outside the current scope, record their locations and the content that needs synchronization
@@ -256,8 +260,10 @@ Perform the following steps after writing and scope checks are complete for all
    After all applicable checks pass, commit only actual closeout changes, then push to the remote
    If there are no actual changes, do not create an empty commit, and push existing commits from this round
    If committing or pushing is not possible, record completed work, incomplete actions, and the resumption point, and report incomplete under §8
-5. Continue to review
-   After all closeout requirements are complete, the next step is `/aca-review`
+5. Determine whether design review is needed and continue
+   After all closeout requirements are complete, check whether the design in this round is cross-module (involving multiple modules, the project-level architecture, the module division, or cross-module interfaces and collaboration contracts)
+   - Cross-module: the next step is `/aca-review` for a design review
+   - Not cross-module (only changes inside a single module or local design changes): skip design review and go directly to the next step (`/aca-implement` when this round needs code, or `/aca-release` according to the confirmed version progression plan when this round changes only design docs)
 
 ## 8 Output
 
@@ -275,16 +281,16 @@ Perform the following steps after writing and scope checks are complete for all
 
    | Item | Result |
    | --- | --- |
-   | Scope | <current scope and progress in this round> |
+   | Scope | <current scope, progress in this round, and whether it is cross-module> |
    | Inputs | <solution or as-is state and actual sources> |
    | Docs | <files added, revised, moved, or deleted / none> |
    | Checks | <actual results, basis for reuse, and unverified items> |
    | Commits | <commit and push results / not committed> |
    | Pending | <incomplete items, reasons, and resumption point / none> |
-   | Next step | <target skill and pending scope / fill corresponding gaps / none> |
+   | Next step | </aca-review after cross-module closeout, /aca-implement or /aca-release directly after non-cross-module closeout, or fill corresponding gaps> |
    ```
 
 3. Determine the next step
-   After this round is fully closed out, the next step is `/aca-review`
+   After this round is fully closed out, continue to `/aca-review`, `/aca-implement`, or `/aca-release` according to whether the design is cross-module, as in step 5 of 7.2
    If the current scope is complete but another scope remains, determine the next path under 7.1
    If work is incomplete, fill the corresponding gaps, and do not judge Design complete solely because files have been written

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

@@ -54,6 +54,8 @@ Preserve existing changes outside the scope of this implementation
    - 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
+   - Correct or remove outdated or wrong test cases and fixtures according to the confirmed design
+   - When changing test expectations, base the change on the confirmed design or a verified test error
 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`
@@ -141,12 +143,16 @@ Preserve existing changes outside the scope of this implementation
 
 ## 6 Output
 
-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 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
+1. **Update the task status**
+   - All completion criteria for the current scope are satisfied: mark the goal and task status as complete
+   - Completion criteria are not satisfied: report remaining work, reasons for blockers, and actions to resume
+2. **Check for module and code structure changes and determine the next step**
+   - Check whether the changes are cross-module or change a module's overall code structure (module structure, overall code distribution, function construction)
+   - Cross-module or the module's overall code structure changed: use `/aca-review` to run an implementation review on this scope, then go to `/aca-test` after the review passes
+   - Only inside a module, with no change to the module's overall code structure (such as internal module logic, local function implementation, or test details): skip implementation review and go directly to `/aca-test`
+   - Provide the following `/aca-review` or `/aca-test` with the overall goal, corresponding design, implementation scope, orchestrated test scope, and comparison baseline, and identify the commits and uncommitted changes in this run
+3. **Output the implementation report**
+   Use the following format for the final report, filling in the title and results according to the actual status
 
 ```markdown
 # 🛠️ Implement: <complete / incomplete>
@@ -156,9 +162,10 @@ 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 production code and test code changes> |
+| Structural change | <yes (cross-module or module's overall code structure changed) / no (only internal module logic or local 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> |
-| Next step | <one immediately actionable step> |
+| Next step | </aca-review when there is a structural change, /aca-test directly when changes are only inside a module with no structural change> |
 ```

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

@@ -97,14 +97,10 @@ If execution cannot continue in Chapters 4 through 7, report completed facts, th
 1. Run `bash ~/.gemini/antigravity-cli/skills/aca/bin/aca-release-notify-check .` to check the announcement configuration
    Record the check result and the corresponding configuration location
 2. Act on the check result
-
-   | Result | Action |
-   | --- | --- |
-   | `NOTIFY_NONE` | Record that no transport is configured and continue the release |
-   | `NOTIFY_WIRED` | Record the platform and consumer point and continue the release |
-   | `NOTIFY_UNWIRED` | Stop and report that the announcement does not use `aca-tag-notify-extract <tag>` to extract content, then check again after the configuration is corrected |
-   | Unable to complete the check | Stop and report the reason and resume conditions |
-
+   - `NOTIFY_NONE`: record that no transport is configured and continue the release
+   - `NOTIFY_WIRED`: record the platform and consumer point and continue the release
+   - `NOTIFY_UNWIRED`: stop and report that the announcement does not use `aca-tag-notify-extract <tag>` to extract content, then check again after the configuration is corrected
+   - Unable to complete the check: stop and report the reason and resume conditions
 3. Use the configuration check result for the [Announcement Cross-Check](#72-cross-check-the-release-announcement)
    Check again after the configuration is corrected
    The configuration check confirms that the summary is integrated
@@ -305,15 +301,11 @@ Release announcements are generated from the NOTIFY block in the annotated Tag
 1. Locate the delivery results
    Use the [announcement configuration](#33-announcement-configuration) and the repository release workflow to find tasks, logs, or delivery receipts for this Tag
 2. Record the delivery status based on evidence
-
-   | Status | Basis for determination |
-   | --- | --- |
-   | Sent | Evidence of successful delivery for this Tag |
-   | Pending delivery | Confirmed to still be waiting or in progress |
-   | Delivery failed | An explicit failure result |
-   | Unconfirmed | Insufficient evidence to determine the delivery status |
-   | Transport not configured | Configuration checks confirm that no delivery mechanism is configured |
-
+   - Evidence of successful delivery for this Tag exists: mark as sent
+   - The task is confirmed to still be waiting or in progress: mark as pending delivery
+   - An explicit delivery failure result exists: mark as delivery failed
+   - Evidence is insufficient to determine the delivery status: mark as unconfirmed
+   - Configuration checks confirm that no delivery mechanism is configured: mark as transport not configured
 3. Handle follow-up actions
    If delivery fails, recover or resend according to repository conventions
    If the status is unconfirmed, report the missing evidence

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

@@ -53,6 +53,8 @@ Use `/aca-review` when you need to judge whether business goals and design solut
 - Remove content that adds no information and does not help understanding
 - Write one sentence per line, with only one fact per sentence
 - State actions directly in operational steps
+- If a specific practice fully expresses a constraint, write the practice directly
+- Keep prohibitions that no specific practice can fully express
 - Write sequential actions as separate items
 - Make the actor, the object of the action, and the referents clear
 - Do not repeat actors, objects of actions, or referents already clear from context