oh-my-skills/skills/brainstorming/SKILL.md

---

name: brainstorming

description: "Orchestrates brainstorming, inspection, planning, delegated implementation, and review."

Role

Act only as an orchestrator.

You may inspect files, discuss decisions, and delegate work.

You must not create, modify, or delete any file directly.

Workflow

Follow these phases in order. You must use todos tool to track progress and avoid skipping steps, else you can't work. If you don't have todos, simulate it with this output:

`[X]` *todo 1*  
`[ ]` **todo 2**  
`[ ]` todo 3

Done items in italic, the next pending item in bold, later items plain.

1. Brainstorm

• Load skill coding-standard-rules.
• Understand the objective.
• Ask at most three material questions.
• Do not ask what repository inspection can answer.
• When alternatives exist, show 2–3 options with concise pros and cons.
• Do not finalize the plan yet.

2. Inspect

Read only relevant:

• affected files;
• callers and consumers;
• types, interfaces, configuration, and tests;
• causal call paths.

Identify current behavior, downstream effects, conventions, and available checks.

Ask again only if inspection reveals an unresolved material decision.

3. Decompose

Create stable sequential IDs: MS-001, MS-002, etc.

Each microdevelopment must define exactly one file-local behavior and authorize exactly one file.

If an intended outcome requires changes to multiple files, create one microdevelopment per file and express their ordering through explicit dependencies. A file must belong to exactly one microdevelopment.

Each microdevelopment must include:

• behavior;
• input;
• output;
• measurable success criterion;
• exact authorized file;
• causal call path;
• dependencies or none.

Do not include multiple behaviors, multiple files, unresolved decisions, vague criteria, unspecified files, or unrelated cleanup.

4. Plan

Produce the final plan using the same IDs everywhere.

Include:

• objective;
• current and intended behavior;
• ordered microdevelopments;
• authorized files and call paths;
• invariants and non-goals;
• checks and measurable acceptance criteria.

Never renumber an ID after presenting it.

5. Approve

Show:

ID	Behavior	Decision made	Confirmed?
MS-001	Concise behavior	Relevant decision	Pending

Then show the file map:

path/to/file.ext (1 change)
└─ [MS-001] planned change

Every change must map to exactly one ID. Omit the map when no files change.

Ask exactly one approval question, in bold italic: ***Approval question?***.

Approval must be explicit and case-insensitive, such as positive or negative words in the language of user.

On rejection or requested changes, revise the plan, table, and map, then request approval again.

6. Implement

Delegate every microdevelopment to one subagent gv-dev, granting it authority to modify only the single file authorized by that microdevelopment. Pass the full microdevelopment definition — ID, behavior, input, output, success criterion, authorized file, causal call path, dependencies — directly in the task instruction. Never create or reference an intermediate task file.

implement MS-001: <behavior> on <authorized file>

Spawn one agent per microdevelopment. Parallelize only microdevelopments with no dependencies, shared state or behavior, or unresolved decisions. Dependent microdevelopments must run in dependency order.

Require:

**Implemented IDs:** `MS-001`  
**Changed files:** `path/to/file.ext`  
**Summary:** ...  
**Checks and results:** ...  
**Deviations:** ...  
**Blockers:** ...

Do not apply changes yourself. Deviations require new authorization.

7. Review

Delegate review to subagent gv-reviewer with the approved plan, the microdevelopment definitions, IDs, changed files, and developer summaries.

The reviewer must inspect the diff, verify causal scope, acceptance criteria, invariants, and unauthorized changes.

Classify findings as:

***`REQUIRED`***: blocking fix  
**`CONCERN`**: non-blocking limitation  
`PASS`: satisfied criterion

Verdicts:

• APPROVED: no REQUIRED;
• CHANGES_REQUIRED: fixable REQUIRED remain;
• REJECTED: criteria cannot be met within scope or fixes are exhausted.

Show the verdict as an H3 heading:

### `CHANGES_REQUIRED`

8. Fix

For open REQUIRED findings:

• delegate only affected IDs to subagent gv-dev, forwarding for each ID its full finding record (problem, evidence, file, line, remediation) as returned by gv-reviewer;
• do not fix CONCERN or unrelated issues;
• do not expand files or scope;
• review after every fix, scoping the re-review to: the microdevelopments of files touched by this fix round, the ledger of previous IDs, and the diff since the last review — not the full original plan, unless gv-reviewer explicitly flags a need to re-examine plan-level scope;
• allow at most three fix delegations.

After the third fix, review once more and return REJECTED if any REQUIRED remains.

With zero REQUIRED, report completion.

Test execution

• Tests run only on a direct user instruction, whether from the orchestrator or any delegated role.
• Every test run is subject to a hard timeout of two minutes; on expiry, abort the run and report the check as FAIL with the timeout noted.

Scope changes

When new files, behaviors, or decisions become necessary:

1. stop affected work;
2. revise the plan;
3. update the table and map;
4. obtain approval again.

Output

Emit every template as rendered Markdown, never inside a code fence. Only the ASCII file map stays in a text fence. End a line with two trailing spaces when the next line of the same section must start on a new line.

Planning

**[OBJECTIVE]**  
*One-line outcome.*

**[QUESTIONS]**  
*Maximum three.*

**[OPTIONS]**  
*2–3 concise choices.*

**[MICRODEVELOPMENTS]**  
`[MS-001]` behavior, input, output, criterion, `authorized file`, call path, dependencies.

**[PLAN]**  
*Ordered IDs, invariants, non-goals, checks.*

**[APPROVAL]**  
*Table, ASCII map, and one approval question.*

Final

**[RESULT]**  
Status: ***COMPLETED*** | ***BLOCKED*** | ***REJECTED***  
Fix rounds used: **N / 3**

**[WHAT CHANGED]**
- `[MS-001]` *observable result*

**[FILES]**
- `changed file`

**[VALIDATION]**
- `criterion or command`: **PASS** | ***FAIL*** | ~~NOT RUN~~

**[KNOWN LIMITATIONS]**
- *remaining CONCERN findings or None*

Boundaries

• No implementation before approval.
• No direct code changes.
• No delegation before approval.
• No agent may modify a file other than the single file authorized by its assigned microdevelopment.
• No unspecified files or scope expansion.
• No unrelated cleanup, refactoring, or documentation.
• No CONCERN fixes without authorization.
• No completion while REQUIRED findings remain.
• Maximum three fix delegations.

When to use subagents

• Delegate Code: Use parallel subagent gv-dev on different files, with a clear, imperative plan.
• Request a Review: Use subagent gv-reviewer with a checklist.