idea

Idea

The idea skill opens and manages a structured idea-convergence session — the optional IDEA stage that sits before SPECS in the ADR-0010 lifecycle. Use it when two or more competing, overlapping, or complementary proposals for a problem coexist and must be converged before a spec can be written.

The skill is forge-agnostic: it operates on forge issues (GitHub, GitLab, Gitea) using the host CLI's native commands and does not call any forge-specific API directly.

When to activate

• Explicit user invocation: the user types /idea (or the equivalent CLI activation phrase). Required flags: --mode=solo|unanimity|vote, --issue=<parent-issue-number>. Optional governance parameters vary by mode (see Governance modes below).
• Any situation where multiple independent proposals address the same parent issue and a structured decision record is needed before the SPECS stage begins.

Do not activate on a ticket where a single clear intent already exists — proceed directly to spec-author instead.

Inputs

The skill requires two mandatory parameters at open time:

Additional governance parameters depend on the mode:

All governance parameters are immutable after the session issue is created. No mechanism exists to change the mode, the owner list, the voter set, or the quorum threshold mid-session.

Opening a session

1. Create the session issue on the forge.
   • Title: [IDEA] <brief description> (parent #<N>).
   • Labels: idea-session plus the governance sub-label (idea-solo, idea-unanimity, or idea-vote).
   • Body follows the Session issue template below.
2. Log the session opening on the parent issue as a cross-reference comment.

Session issue template

## IDEA Session — <brief description>

**Parent issue:** #<N>
**Governance mode:** <mode>
**<Mode-specific parameters>**

---

### Proposals

_Proposals are submitted as comments on this issue using the structured
format defined by the `idea` skill. Each accepted proposal is listed here
by the session owner after the triage phase._

### Comparison

_Populated by the session owner after triage._

### Vote tally

_Populated after the governance phase opens._

Proposal format (R6)

Every proposal submitted to an IDEA session SHALL be posted as a comment on the session issue and conform to the following structure:

## Proposal: <title>

**Submitter:** <identity>

### Summary
<One-to-three-sentence description of the proposed approach.>

### Rationale
<Why this approach addresses the parent issue.>

### Trade-offs
<Advantages and disadvantages. Be explicit about costs.>

### Open questions
<Unresolved points that may affect feasibility or design.>

Triage phase (R7)

After the proposal submission window, the session owner evaluates each proposal against three criteria:

1. Relevance — does the proposal address the parent issue?
2. Feasibility — is the proposal realizable within reasonable constraints?
3. Non-duplication — is the proposal substantively distinct from an already- accepted proposal in the same session?

Proposals that fail any criterion are documented in a comment prefixed [TRIAGE-REJECTED] with the criterion and rejection reason stated explicitly. Rejected proposals do not advance to the comparison or governance phase.

Example rejection comment:

[TRIAGE-REJECTED] Proposal: <title>

**Criterion failed:** Non-duplication
**Reason:** This proposal is substantively identical to "Proposal: <existing title>"
submitted by <identity> on <date>. The key mechanism (X) is the same; the
difference in wording does not constitute a distinct approach.

Comparison phase (R8)

Proposals that survive triage are compared across a shared set of dimensions.

Default dimensions:

The session owner MAY declare additional or replacement dimensions at open time by listing them in the session issue body. Declared dimensions apply for the lifetime of the session and cannot be changed mid-session.

The comparison SHALL be documented as a structured comment on the session issue, presenting each surviving proposal against every declared dimension. The comment is authored by the session owner after triage completes.

Composition phase (R9)

When two or more surviving proposals are complementary rather than mutually exclusive, the session owner MAY trigger a composition phase. A composed (hybrid) proposal:

• Is posted as a new comment on the session issue prefixed [COMPOSITION].
• Names the source proposals it synthesizes.
• Conforms to the same Proposal format (R6) as any other proposal.
• Enters the governance phase in the same position as any surviving proposal.

Example composition prefix:

[COMPOSITION] Proposal: <hybrid title>

**Composed from:** "Proposal: <A>" and "Proposal: <B>"
**Submitter:** <session owner identity>

### Summary
...

Consensus protocol (R10)

The official vote mechanism is structured vote comments on the session issue. A valid vote comment matches exactly one of the following forms:

VOTE: APPROVE
VOTE: REJECT
VOTE: ABSTAIN

• Each eligible voter (per the declared governance parameters) casts exactly one vote comment per session.
• Emoji reactions on the session issue MAY serve as informal signals but are not counted toward any governance threshold.
• Only votes posted as top-level comments (not as replies to other comments) count.

Threshold calculation

Success path (R12)

When the declared governance threshold is met:

1. Post a closing comment on the session issue naming:
   • The winning proposal (or composition).
   • The final vote tally.
   • The parent issue reference.
2. Create one or more SPECS issues, each:
   • Pre-populated with the winning proposal's summary as the intent statement.
   • Cross-referencing the IDEA session issue in its body.
3. Close the session issue with the label idea-resolved.

Example closing comment:

## IDEA Session — Resolved

**Winning proposal:** <title>
**Vote tally:** APPROVE: N, REJECT: M, ABSTAIN: K

The session is closed. The following SPECS issue(s) have been created:
- #<specs-issue-number>: <brief description>

**Parent issue:** #<parent-N>
**IDEA session:** this issue (closed `idea-resolved`)

Failure path (R13)

The session owner MAY close an IDEA session at any time without reaching the governance threshold. To do so:

1. Add the label idea-no-consensus to the session issue.
2. Post a mandatory closure comment stating the reason the session is being closed without consensus.
3. Close the session issue.

No SPECS issue is created on this path. The parent issue remains open for a future attempt (which MAY open a new IDEA session).

Example closure comment:

## IDEA Session — Closed Without Consensus

**Reason:** <explicit statement of why no consensus was reached>

No SPECS issue has been created. The parent issue #<N> remains open.
A new IDEA session may be opened against the same parent issue.

Terminal state contract (R14)

Every closed IDEA session issue SHALL carry exactly one of the two terminal labels:

• idea-resolved — the session produced one or more SPECS issues.
• idea-no-consensus — the session closed without consensus and no SPECS issues were created.

No other terminal state is defined. An IDEA session issue that is closed without one of these labels is a protocol violation.

Governance modes (R3)

solo

A single named decision authority. The session closes the moment the owner casts VOTE: APPROVE on the winning proposal.

• One owner only. Multiple owners are not supported in solo mode — use unanimity instead.
• The owner may post VOTE: REJECT to veto without closing the session. The session remains open until the owner approves or manually closes it via the failure path.

unanimity

A declared set of owners. The session closes only when every declared owner has posted VOTE: APPROVE. A single VOTE: REJECT from any owner blocks consensus; the session remains open (it does not auto-close on a veto). Manual closure via the failure path is the only alternative exit.

vote

A named voter set and a quorum threshold (integer percentage, 1–100). The session closes when the percentage of APPROVE votes among all non-ABSTAIN votes reaches or exceeds the declared threshold. VOTE: ABSTAIN is excluded from the denominator (it neither advances nor blocks quorum).

Immutability rule (R4)

The declared governance mode and all its parameters (owner identity, owner list, voter set, quorum threshold) are immutable for the lifetime of the session. They are recorded in the se

Content truncated.