Claude Skill

goga-brainstorm-plan-assembly

Assembly of the architecture plan document

LLM Mart · 0 points · 12 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download qarium-goga-goga_assets_skills_goga-brainstorm-plan-assembly-b2d5a7f.zip · 1 KB
qarium/goga 31 0 forks BSD-3-Clause Updated 6d ago
Part of qarium/goga — 72 skills

Install

skills CLI npx skills add https://github.com/qarium/goga/tree/1.2.x/goga/assets/skills/goga-brainstorm-plan-assembly
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install qarium-goga@llmmart
Git 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-assembly

Identity

You are responsible for assembling the architecture plan — a structured document describing CODEMANIFEST and .usages/ files for each cell — and writing it to disk.

Context

Use these reports for its specific purpose:

  • [CELL_ASSEMBLY_REPORT] — use it for the assembled per-cell CODEMANIFESTs and .usages/ files, the dependency diagram, and the artifact list — the material to write into the plan.
  • [PRIMARY_ANALYSIS_REPORT] — use its Topic as the plan's short name, its Existing Cells & Schema for the project structure (file names and paths), and its Artifact Resolution to mark each cell as modified vs created anew.

Workflow

Phase 1. Determine the topic

Resolve the topic directory — the path printed by goga history path (the current topic in the history tree). Keep the Topic section of the [PRIMARY_ANALYSIS_REPORT] as the plan's short name.

Phase 2. Assemble the plan structure

Build the plan with the following sections.

Implementation order

Cells ordered from leaves to root (cells without dependencies first, then dependent ones). For each cell, specify the reason for the order (e.g., "has no Imports", "depends on cell X").

Artifacts for each cell

For each cell in implementation order:

  • CODEMANIFEST — complete file contents in DSL format
  • .usages/ files — for each file: path, name, complete contents

Dependency map

ASCII diagram or list of connections between cells via Imports.

Verification checklist

What to check after implementing each artifact.

Phase 3. Apply plan generation rules

  • Each CODEMANIFEST in the plan must be syntactically correct per the DSL specification
  • File names and paths must correspond to the project structure from the Existing Cells & Schema section of the [PRIMARY_ANALYSIS_REPORT]
  • For modification of existing CODEMANIFESTs — specify a diff: what to add, change, delete
  • Explicitly mark which cells are modified vs created anew (per the Artifact Resolution in the [PRIMARY_ANALYSIS_REPORT])
  • The plan contains ONLY CODEMANIFEST and .usages/ file artifacts — no implementation code in any language

Phase 4. Save the plan

Save the plan to the path printed by goga history path -f arch.md (run goga history ensure first if the topic directory does not exist).

WAIT

Present the plan to the user and obtain confirmation.

Output Format

Fill every section. No empty sections.

# [ARCHITECTURE_PLAN]

## Topic
[Short name and the path printed by `goga history path -f arch.md`]

## Implementation Order
[Ordered list of cells, leaves to root, with rationale per cell]

## Artifacts
[For each cell: CODEMANIFEST (full DSL) + .usages/ files (full content). For existing cells: diff.]

## Dependency Map
[ASCII diagram or list of inter-cell Imports connections]

## Verification Checklist
[What to check after implementing each artifact]

STOP if:

  • plan incomplete (missing section, missing cell, placeholder content)
Files (goga)
  • SKILL.md 3.1 KB
    ---
    name: goga-brainstorm-plan-assembly
    description: Assembly of the architecture plan document
    ---
    
    # goga-brainstorm-plan-assembly
    
    ## Identity
    
    You are responsible for assembling the architecture plan — a structured document describing CODEMANIFEST and `.usages/`
    files for each cell — and writing it to disk.
    
    ## Context
    
    Use these reports for its specific purpose:
    
    - **`[CELL_ASSEMBLY_REPORT]`** — use it for the assembled per-cell **CODEMANIFESTs and `.usages/` files**, the
      **dependency diagram**, and the **artifact list** — the material to write into the plan.
    - **`[PRIMARY_ANALYSIS_REPORT]`** — use its **Topic** as the plan's short name, its **Existing Cells & Schema** for the
      project structure (file names and paths), and its **Artifact Resolution** to mark each cell as modified vs created
      anew.
    
    ## Workflow
    
    ### Phase 1. Determine the topic
    
    Resolve the topic directory — the path printed by `goga history path` (the current topic in the history tree).
    Keep the **Topic** section of the `[PRIMARY_ANALYSIS_REPORT]` as the plan's short name.
    
    ### Phase 2. Assemble the plan structure
    
    Build the plan with the following sections.
    
    #### Implementation order
    
    Cells ordered from leaves to root (cells without dependencies first, then dependent ones). For each cell, specify the
    reason for the order (e.g., "has no Imports", "depends on cell X").
    
    #### Artifacts for each cell
    
    For each cell in implementation order:
    
    - **CODEMANIFEST** — complete file contents in DSL format
    - **.usages/ files** — for each file: path, name, complete contents
    
    #### Dependency map
    
    ASCII diagram or list of connections between cells via Imports.
    
    #### Verification checklist
    
    What to check after implementing each artifact.
    
    ### Phase 3. Apply plan generation rules
    
    - Each CODEMANIFEST in the plan must be syntactically correct per the DSL specification
    - File names and paths must correspond to the project structure from the Existing Cells & Schema section of the
      `[PRIMARY_ANALYSIS_REPORT]`
    - For modification of existing CODEMANIFESTs — specify a diff: what to add, change, delete
    - Explicitly mark which cells are modified vs created anew (per the Artifact Resolution in the
      `[PRIMARY_ANALYSIS_REPORT]`)
    - The plan contains ONLY CODEMANIFEST and `.usages/` file artifacts — no implementation code in any language
    
    ### Phase 4. Save the plan
    
    Save the plan to the path printed by `goga history path -f arch.md`
    (run `goga history ensure` first if the topic directory does not exist).
    
    ## WAIT
    
    Present the plan to the user and obtain confirmation.
    
    ## Output Format
    
    Fill every section. No empty sections.
    
    ```md
    # [ARCHITECTURE_PLAN]
    
    ## Topic
    [Short name and the path printed by `goga history path -f arch.md`]
    
    ## Implementation Order
    [Ordered list of cells, leaves to root, with rationale per cell]
    
    ## Artifacts
    [For each cell: CODEMANIFEST (full DSL) + .usages/ files (full content). For existing cells: diff.]
    
    ## Dependency Map
    [ASCII diagram or list of inter-cell Imports connections]
    
    ## Verification Checklist
    [What to check after implementing each artifact]
    ```
    
    ## STOP if:
    - plan incomplete (missing section, missing cell, placeholder content)
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related