Reviews a cell across three dimensions and proposes concrete remediation actions for each detected issue. Each action requires explicit user confirmation before execution.
\nYou identify issues, propose solutions, and execute user-approved actions (invoking other skills, editing files).
\nIdentify the exact problem before proposing a solution. The three review dimensions target distinct root causes and require different remediation strategies. Do not conflate them — classify each finding into exactly one of the three categories before proposing any action.
\nAlways provide answer options. When requesting user confirmation, decisions, or clarifications, always offer 2–4 concrete options to choose from. Never pose open-ended questions without selectable choices.
\ngoga-lang-disp via the Skill tool to load the target language skill.\nThe language skill defines implementation conventions: cell structure, facade, signature rules, naming.\nExamples in other skills may follow naming conventions of one language (e.g., snake_case), while the target language\nrequires different conventions (e.g., PascalCase). The language skill contains authoritative rules for the target language.goga-cell via the Skill tool to understand CODEMANIFEST DSL syntax, structural rules, and semantics\n(cell structure, Imports, Usages, Annotations directives, types, signatures, mutations, embeddings, constraints)goga-cookbook via the Skill tool to understand cell and CODEMANIFEST working principles\n(when to use Entity vs Routine, when to apply mutations and embeddings, usage file authoring principles, cell granularity)CODEMANIFEST file.usages/, build artifacts, tests, and other non-contract files)location values.usages/*.md files if the .usages/ directory existsgoga lint\nIf the linter reports errors, record each as a DSL syntax issue. Fix all DSL syntax errors before proceeding with analysis.
\ngoga schema\nExtract the cell's position in the project hierarchy for contextual reference.
\nQuestion: Does the code implement what CODEMANIFEST requires?
\nFor each entity declared in CODEMANIFEST, verify that the implementation satisfies the contract.
\nFor each entity:
\n\"()\" (constructor signature) between CODEMANIFEST and source code\"methods\" dictionary — identify missing, extra, or mismatched method signatures\"properties\" dictionary — identify missing, extra, or mismatched property typesFor each function (routine):
\nAdditional checks:
\n<cell-path>/<location>?Imports actually referenced in source code?When issues are detected, present each finding with:
\nFormulate a task describing the discrepancy between code and contract.
\nPropose: invoke /goga:design in brainstorm mode, passing the task as context. This produces an implementation redesign that satisfies the contract.
Request user confirmation before execution.
\nQuestions: Do CODEMANIFEST requirements match the actual code and usages? Is CODEMANIFEST well-authored?
\nThe contract may be incomplete, incorrect, outdated, or poorly written compared to what the code actually implements and what usages describe.
\nFor each entity and function (routine) in CODEMANIFEST, verify that annotations satisfy the following authoring quality criteria. Even a technically correct contract degrades overall quality when annotations are poorly written.
\nContent guidelines:
\n`parameter_name`: description syntaxAlgorithm: section with numbered steps tracing the execution flowRequirements: section with explicit descriptionsQuality guidelines:
\n`name`) must resolve to entities in the current CODEMANIFEST context — types from Imports, practices from Usages, or parameters from the signatureWhen issues are detected, present each finding with:
\nAlgorithm: section\", \"describe parameter path\", \"restructure annotation with Algorithm: and Requirements: sections\")Edit CODEMANIFEST to correct inaccuracies and improve authoring quality, then invoke /goga:design in changes mode to update the design document based on the corrected contract.
Request user confirmation before execution.
\nQuestion: Do usage files exist and are they adequate for the cell implementation?
\nUsages entry with a file path — does the file exist? (project-level in .goga/usages/, cell-level in .usages/ directory)Imports → Usages — does {from_path}/.usages/{usage_name}.md exist?.usages/*.md file describe cell API usage? Is the content accurate and sufficiently detailed for consumers?.usages/ functional categories clearly defined and non-overlapping? Should inline usages be extracted into category files?When issues are detected, present each finding with:
\nCreate or update .usages/*.md files directly. This does not require invoking another command — usage files are practice documentation editable directly.
Request user confirmation before execution.
\nFor each user-approved action across all three analyses:
\n/goga:design and select brainstorm modegoga lint/goga:design and select changes mode.usages/*.md filesAfter executing all approved actions (6a, 6b, 6c):
\ngoga lint/goga:design brainstorm/goga:design changes.usages/*.md filesBefore completion, verify:
\ngoga-cell and goga-cookbook skills before analysis?.usages/ files analyzed?goga lint executed?goga schema executed?goga lint executed after all actions and did it pass without errors?If any answer is \"no\" — complete the outstanding work before returning.
\n