# Goga Discover > Interview the user relentlessly about a decision until every branch of the design tree is resolved, then record the result as a short ADR. - Skill: `qarium/goga-discover` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add qarium/goga-discover` - Raw SKILL.md: https://api.skillmd.com/api/skills/qarium/goga-discover/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: qarium (https://skillmd.com/u/qarium) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/qarium/goga-discover --- # Goga discover Interview the user relentlessly until you reach a shared understanding on a decision worth recording. Map this as a **design tree**: every decision branches into the decisions that hang off it. Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round. Each question should be formatted like so: ``` ❓ **Q1** - ****: ➡️ ``` Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one. Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The _decisions_ are the user's — put each to them and wait. The interview is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not write the ADR until the user confirms you have reached a shared understanding. Once confirmed, write the ADR to the path printed by `goga history path -f adr.md` (run `goga history ensure` first if the topic directory does not exist), following `adr-template.md` from the current skill directory. ## Research ### Initialization Load these skills via the **Skill tool** before starting the interview. - **`goga-cell`** — DSL specification: cell and CODEMANIFEST structure, directives, and syntax. - **`goga-lang-disp`** — language implementation rules: naming, signatures, and location for the target language (routes to the per-language skill). These skills are loaded **read-only**: use them solely to understand and discuss the existing project architecture — to read `goga schema` output and existing CODEMANIFEST and usage files. They do not license you to produce contracts, signatures, or cell layouts. ### Project structure To understand the architectural diagram of the project, use: ```bash goga schema ``` For the JSON structure of the diagram, see `goga schema --help`. ## Context structure Keep a working context in your context window — do not write it to disk. The structure: ```yaml terms: # glossary: term -> definition, captured during the interview : "" decided: # what has been settled in this session, not to be re-litigated - "" ``` Append to it as the interview progresses — never overwrite, only add. After each round, update `terms` with new or sharpened definitions, and `decided` with anything the user has confirmed. ### Active term work Challenge terms as you go. Specifically: - **Fuzzy term surfaced?** Don't let it pass. Pin it down with a concrete definition before moving on — propose one and put it to the user. - **Overloaded word?** If one term is doing two or three jobs across questions, name the conflict explicitly, propose split definitions, and ask the user to choose. - **User uses a term informally?** Capture the formal version in `terms` and use it consistently from then on. - **Term already in `terms`?** Use that exact definition in subsequent questions — don't re-coin, don't paraphrase, don't drift. ### Why The ADR's "why" only makes sense if the vocabulary it uses is sharp. ## Constraints - To understand the project, read only the architectural diagram, CODEMANIFEST and usage files. - Never design cells or CODEMANIFEST contracts — even when the user's constraints sound architectural. That is outside this skill's scope. - Do not propose or discuss: type signatures, method/property lists, `location` values, Entities vs Routines, cell boundaries, Imports/Usages wiring, or CODEMANIFEST structure. If a question drifts there, do not answer it — record the open point in the ADR as an unresolved question and move on. - Interview outputs are decision records about the problem, its terms, and its constraints — not contracts.