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
...

Candidate designation (R15/R16)

When two or more proposals survive triage (R7) and have not been merged via composition (R9), the session owner SHALL designate exactly one surviving proposal or composition as the current candidate before any vote comment can count toward the governance threshold (R3/R10). The designation is a top-level comment matching exactly the form [CANDIDATE] Proposal: <title> — mirroring the bracket-prefix convention already established by [TRIAGE-REJECTED] (R7) and [COMPOSITION] (R9) — where <title> names a proposal or composition already present in the session. A [CANDIDATE] comment naming a title absent from the session is invalid and designates nothing.

Required vs. implicit. A [CANDIDATE] comment is mandatory once two or more surviving, non-composed proposals exist after triage. When exactly one proposal survives triage and no [CANDIDATE] comment has ever been posted in the session, that lone survivor is the implicit candidate from the moment it alone survives — no [CANDIDATE] comment is required for its votes to count.

Re-designation rule. Posting a new valid [CANDIDATE] comment voids every vote comment posted before it. Eligible voters must recast their vote against the newly designated candidate for it to count toward the governance threshold.

Example candidate designation comment:

[CANDIDATE] Proposal: <title>

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.

A vote comment binds to the proposal or composition named by the most recently posted valid [CANDIDATE] comment at the time the vote was cast — or to the implicit candidate (R16) when exactly one proposal survives triage and no [CANDIDATE] comment has been posted. See Candidate designation (R15/R16) above. The Threshold calculation below counts only vote comments posted after the current candidate's designation timestamp; re-designation voids and requires eligible voters to recast their votes.

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:

Content truncated.