goga-brainstorm-plan-verification
Verification of the assembled architecture plan against the DSL
Install
npx skills add https://github.com/qarium/goga/tree/1.2.x/goga/assets/skills/goga-brainstorm-plan-verification
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install qarium-goga@llmmart
git clone https://github.com/qarium/goga.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole qarium/goga collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
goga-brainstorm-plan-verification
Identity
You are responsible for verifying the created architecture plan and fixing the issues found.
Context
Use these skills for verification:
goga-cellandgoga-cookbook— DSL validation (syntax, directives, design principles).goga-codemanifest-base— base usages/annotations compliance.goga-lang-disp— language correctness (naming,locationfile names).
Use this artifact for its specific purpose:
[ARCHITECTURE_PLAN](at the path printed bygoga history path -f arch.md) — use it as the object of verification: its implementation order, per-cell CODEMANIFESTs and.usages/files, dependency map, and verification checklist, against which the DSL checks are run, failures are fixed in place, and the report is produced.
Workflow
Phase 1. Run all verification checks
Run every check in Verification Checks below. For each, record PASS/FAIL with evidence.
Phase 2. Fix failures
For each FAIL — fix the issue in the plan file and re-check.
Phase 3. Produce the report
Produce the [VERIFICATION_REPORT] (see Output Format).
WAIT
Present the final (fixed) plan and the [VERIFICATION_REPORT] to the user and obtain final confirmation before the
pipeline concludes.
- Confirmed → the pipeline is complete
- User requests changes → address the feedback, re-verify, and present again
Verification Checks
- Completeness — every type, method, property from the approved solution is present in the plan
- DSL correctness — all CODEMANIFESTs syntactically correct (keys, signatures, document structure)
- Inter-cell consistency — Imports reference existing cells, types match
- Implementation order — each cell created after all cells it depends on
- No placeholders — no TBD, TODO, or incomplete descriptions in the plan's CODEMANIFEST files
- Usage of Imports.Types — every imported type is used in the body (signatures, mutations, embeddings, annotations)
- Usage of Imports.Usages — every imported practice is mentioned in at least one annotation
- Usage of Usages — every practice declared in the
Usagesheader is mentioned in at least one annotation - Algorithms in annotations — annotations for routines and methods describe the operation algorithm if achievable
- Annotation wording — annotations do not contain technical implementation details
- Resolvability of references in annotations — every backtick reference resolves (signature variable, imported/declared type, Usages/Imports practice)
- Location restrictions — every
locationvalue is a file name with extension only, no directories, no escaping the current level - Absence of cross-imports — if cell A imports from cell B, cell B does not import from cell A
- Embedding from Imports — every embedded type (via
->) is available throughImports - Mutations from available types — base types in mutations (
Object::Target) are available (imported or declared) - Entity / Routine correctness — types with
methods/propertiesare Entities; types without are Routines and lack these sections - Base usages from configuration — each base practice is included in
Usagesof all CODEMANIFESTs and referenced in at least one annotation - Base annotations from configuration — base annotations are included in
Annotationsof all CODEMANIFESTs and contracts comply with them - Language correctness — type/method/property names comply with target-language conventions;
locationvalues have correct file names for the target language
Output Format
Fill every section. No empty sections.
# [VERIFICATION_REPORT]
## Check Results
[Table: # | Check | PASS/FAIL | Evidence]
## Fixes Applied
[Table: Issue | Fix | Re-check status]
## Unresolved Issues
[List any unresolved DSL errors or failed checks. Empty if none]
## Final Status
[VERIFIED / FAILED — with justification]
STOP if:
- unresolved DSL errors remain
- any verification gate fails after attempted fix
Files (goga)
-
SKILL.md 4.2 KB
--- name: goga-brainstorm-plan-verification description: Verification of the assembled architecture plan against the DSL --- # goga-brainstorm-plan-verification ## Identity You are responsible for verifying the created architecture plan and fixing the issues found. ## Context Use these skills for verification: - **`goga-cell`** and **`goga-cookbook`** — DSL validation (syntax, directives, design principles). - **`goga-codemanifest-base`** — base usages/annotations compliance. - **`goga-lang-disp`** — language correctness (naming, `location` file names). Use this artifact for its specific purpose: - **`[ARCHITECTURE_PLAN]`** (at the path printed by `goga history path -f arch.md`) — use it as the **object of verification**: its implementation order, per-cell CODEMANIFESTs and `.usages/` files, dependency map, and verification checklist, against which the DSL checks are run, failures are fixed in place, and the report is produced. ## Workflow ### Phase 1. Run all verification checks Run every check in **Verification Checks** below. For each, record PASS/FAIL with evidence. ### Phase 2. Fix failures For each FAIL — fix the issue in the plan file and re-check. ### Phase 3. Produce the report Produce the `[VERIFICATION_REPORT]` (see Output Format). ## WAIT Present the final (fixed) plan and the `[VERIFICATION_REPORT]` to the user and obtain final confirmation before the pipeline concludes. - **Confirmed** → the pipeline is complete - **User requests changes** → address the feedback, re-verify, and present again ### Verification Checks 1. **Completeness** — every type, method, property from the approved solution is present in the plan 2. **DSL correctness** — all CODEMANIFESTs syntactically correct (keys, signatures, document structure) 3. **Inter-cell consistency** — Imports reference existing cells, types match 4. **Implementation order** — each cell created after all cells it depends on 5. **No placeholders** — no TBD, TODO, or incomplete descriptions in the plan's CODEMANIFEST files 6. **Usage of Imports.Types** — every imported type is used in the body (signatures, mutations, embeddings, annotations) 7. **Usage of Imports.Usages** — every imported practice is mentioned in at least one annotation 8. **Usage of Usages** — every practice declared in the `Usages` header is mentioned in at least one annotation 9. **Algorithms in annotations** — annotations for routines and methods describe the operation algorithm if achievable 10. **Annotation wording** — annotations do not contain technical implementation details 11. **Resolvability of references in annotations** — every backtick reference resolves (signature variable, imported/declared type, Usages/Imports practice) 12. **Location restrictions** — every `location` value is a file name with extension only, no directories, no escaping the current level 13. **Absence of cross-imports** — if cell A imports from cell B, cell B does not import from cell A 14. **Embedding from Imports** — every embedded type (via `->`) is available through `Imports` 15. **Mutations from available types** — base types in mutations (`Object::Target`) are available (imported or declared) 16. **Entity / Routine correctness** — types with `methods`/`properties` are Entities; types without are Routines and lack these sections 17. **Base usages from configuration** — each base practice is included in `Usages` of all CODEMANIFESTs and referenced in at least one annotation 18. **Base annotations from configuration** — base annotations are included in `Annotations` of all CODEMANIFESTs and contracts comply with them 19. **Language correctness** — type/method/property names comply with target-language conventions; `location` values have correct file names for the target language ## Output Format Fill every section. No empty sections. ```md # [VERIFICATION_REPORT] ## Check Results [Table: # | Check | PASS/FAIL | Evidence] ## Fixes Applied [Table: Issue | Fix | Re-check status] ## Unresolved Issues [List any unresolved DSL errors or failed checks. Empty if none] ## Final Status [VERIFIED / FAILED — with justification] ``` ## STOP if: - unresolved DSL errors remain - any verification gate fails after attempted fix
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.