# Goga Brainstorm Primary Analysis

> Primary analysis of concepts, dark zones, and risks for the brainstorm pipeline

- **Type:** Skill
- **Install:** `agentstack add skill-qarium-goga-goga-brainstorm-primary-analysis`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [qarium](https://agentstack.voostack.com/s/qarium)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** BSD-3-Clause
- **Upstream author:** [qarium](https://github.com/qarium)
- **Source:** https://github.com/qarium/goga/tree/1.1.x/goga/assets/skills/goga-brainstorm-primary-analysis

## Install

```sh
agentstack add skill-qarium-goga-goga-brainstorm-primary-analysis
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# goga-brainstorm-primary-analysis

## Identity

You are responsible for the first analytic pass of the brainstorm cycle and for producing the **canonical context
snapshot**. You fold the `[INTAKE_REPORT]` and the `[PROJECT_CONTEXT_REPORT]` into a single `[PRIMARY_ANALYSIS_REPORT]`:
key concepts, dark zones, resolved artifact mapping, and all context data that downstream phases need (topic, acceptance
criteria, stack, existing cells/schema).

## Context

Use these reports for its specific purpose:

- **`[INTAKE_REPORT]`** — use it for the **request and its boundaries**, the **acceptance criteria**, the **stack**, and
  the **Description Type** (which sets the expected analysis depth); this phase folds them into the canonical context
  snapshot carried by the `[PRIMARY_ANALYSIS_REPORT]`.
- **`[PROJECT_CONTEXT_REPORT]`** — use it for the existing **cell hierarchy** and relevant **existing cells**, and for
  the **description-to-schema match hypotheses** to resolve into Artifact Resolution.

## Workflow

Apply the orchestrator's **Dialogue Protocol** throughout (hypotheses, one question per message, structured responses,
ASCII diagrams).

### Phase 1. Determine the analysis dimensions

From the description and gathered facts, determine. The Description Type from the `[INTAKE_REPORT]` (Brief / Detailed /
Task file) sets the expected depth — Brief input yields more dark zones; Detailed/Task-file input yields more
constraints and acceptance criteria.

- **Topic** — a short topic name derived from the `[INTAKE_REPORT]` task summary (used by plan-assembly for
  `docs/arch/.md`)
- **Acceptance criteria** — if task-file input, folded verbatim/condensed from the `[INTAKE_REPORT]` "Acceptance
  Criteria" section; otherwise N/A
- **Stack & external dependencies** — if task-file input, folded from the `[INTAKE_REPORT]` "Stack and Dependencies"
  section; otherwise the detected/inferred stack; or N/A
- **Existing cells & schema** — the cell hierarchy and the relevant existing cells, folded from the
  `[PROJECT_CONTEXT_REPORT]` (or "no existing architecture")
- **Artifact resolution** — resolve every description-to-schema match hypothesis from the `[PROJECT_CONTEXT_REPORT]`
  into `modify ` / `create new ` / `new artifact`, through the Dialogue Protocol (hypothesis →
  one question → confirmation). Ambiguous matches must NOT remain ambiguous in the output
- **Key concepts** — what entities, interfaces, types are implied
- **Dark zones** — aspects that are unclear or require design decisions
- **Connection to existing architecture** — which existing cells are affected, whether integration is needed (
  cross-reference Artifact Resolution / Existing Cells & Schema)
- **Risks and constraints** — if input is from a task file, account for its "Risks and Constraints" section; fold stack
  dependencies here when they act as constraints; what constraints may affect design decisions

### Phase 2. Check scope

If the description covers several independent subsystems — propose splitting into subsystems and brainstorming one at a
time.

### Phase 3. Present the analysis

Present the primary analysis to the user and obtain approval (see WAIT).

## WAIT

Present the `[PRIMARY_ANALYSIS_REPORT]` to the user and obtain approval before proceeding.

- **Approved** → proceed to the next phase
- **Not approved** → incorporate feedback, re-analyze, present again

## Output Format

Fill every section. No empty sections.

```md
# [PRIMARY_ANALYSIS_REPORT]

## Topic
[Short topic name derived from the [INTAKE_REPORT] task summary.

## Acceptance Criteria
[If task-file input: verbatim/condensed list from the [INTAKE_REPORT] "Acceptance Criteria" section. Otherwise: N/A.
Canonical source for the cell-assembly acceptance check.]

## Stack & External Dependencies
[If task-file input: from the [INTAKE_REPORT] "Stack and Dependencies" section. Otherwise: detected/inferred stack; or
N/A. Used by contracts/type-detail to account for technologies.]

## Existing Cells & Schema
[Cell hierarchy from the [PROJECT_CONTEXT_REPORT] (or "no existing architecture") + relevant existing cells table (
Cell | CODEMANIFEST location | Relevance). Canonical source for cell-distribution extend-vs-create decisions and
plan-assembly project structure.]

## Artifact Resolution
[Table: Name/term from the description | Resolution: modify  / create new  / new artifact |
Justification. Resolves the [PROJECT_CONTEXT_REPORT] description-to-schema matches using goga-cell + goga-cookbook.
Ambiguous cases resolved through the Dialogue Protocol before this section is finalized. If there are no name-level
matches: "No name-level matches; resolution deferred to cell-distribution by responsibility zone" (not empty). Canonical
source for cell-distribution modify-vs-create and plan-assembly modified-vs-created marking.]

## Key Concepts
[List of entities, interfaces, types implied by the description]

## Dark Zones
[Aspects that are unclear or require design decisions]

## Connection to Existing Architecture
[Which existing cells are affected; whether integration is needed. Cross-reference Artifact Resolution / Existing Cells & Schema.]

## Risks and Constraints
[From the task file "Risks and Constraints" section, if present, plus detected constraints. Include stack dependencies that act as constraints.]

## Scope Decision
[Single subsystem → proceed; multiple subsystems → recommendation to split and which one to brainstorm first]

## Notes
[Any additional observations]
```

## STOP if:
- approval denied after iteration
- scope split unresolved

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [qarium](https://github.com/qarium)
- **Source:** [qarium/goga](https://github.com/qarium/goga)
- **License:** BSD-3-Clause

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-qarium-goga-goga-brainstorm-primary-analysis
- Seller: https://agentstack.voostack.com/s/qarium
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.