plan-decision

• Triages the decision (record-worthiness; R0 escape hatch), classifies it on four axes (type × domain tags × archetype × conditions), selects a rigor profile (R0–R3 + emergency overlay), and assigns decision rights (DACI) — then plans at a depth scaled by rigor.
• Discovers or confirms the decision record number (e.g. 0007) by scanning existing records in doc/decisions/ for the relevant type (ADR, PDR, TDR, BDR, ODR; defaults to ADR only when type is genuinely unspecified).
• Orients itself in the current repository and high-level documentation under doc/spec/, doc/overview/, doc/changes/, and doc/contracts/.
• Systematically elicits and refines all information needed by /write-decision (context, problem framing, hard requirements (constraints), decision drivers, alternatives, trade-offs, assumptions, verification criteria, etc.), without generating the decision record file itself.
• Applies decision-making discipline (clarify problem → classify → rigor → rights → confirm drivers → explore options → decide) without exposing internal mechanics unless asked.
• Concludes with a compact, machine- and human-friendly planning summary block plus a clear recommendation to invoke /write-decision <number> and, where relevant, to link back to related changes (workItemRef).

This command never writes files or modifies Git state; it operates purely via conversational planning and read-only repository inspection. See doc/guides/decision-making.md for the full decision process.

/plan-decision [] [free-text context]

Examples:

• /plan-decision
  → Auto-discover next number from doc/decisions/ for the relevant type, then ask what decision we are shaping.

• /plan-decision 12
  → Treat 12 as the intended record number (normalized internally to 0012), then start refinement questions.

• /plan-decision 0042 Choose data sharding strategy for multi-tenant billing
  → Use 0042 as the number and seed initial understanding from the idea text.

Notes:

• The command always operates within the current repository only (single codebase per session).
• If multiple decision sessions are active in the same conversation, clearly separate them by record number and avoid mixing context.

All other planning inputs (context, problem framing, drivers, alternatives, trade-offs, verification criteria, etc.) must be elicited interactively from the user and/or derived from existing documentation by summarization. No unstated assumptions may be invented. $ARGUMENTS

<number_resolution>

Primary goal: determine the canonical numeric record number (zero-padded to exactly 4 digits) for this planning session, for the chosen decision type.

Resolution rules:

1. If adrNumberHint is provided:

   • Validate that it is composed of digits only.
   • Normalize to zeroPad4 = numberHint left-padded with zeros to length 4 (e.g. 7 → 0007; 123 → 0123).
   • Treat this as the proposed record number; ask the user to confirm or override.

2. If no numberHint:

   • Discover existing decision records by scanning for files matching: doc/decisions/<TYPE>-*-*.md (where TYPE defaults to ADR only when the decision type is genuinely unspecified).
   • For each match, parse the numeric segment immediately after the type prefix (e.g. ADR-0001-short-title.md → 1, TDR-0042-something.md → 42).
   • If no existing records of this type are found, propose 0001 as the first number.
   • Otherwise, let maxExisting be the highest parsed number; propose candidate = maxExisting + 1.
   • Normalize candidate to zeroPad4 as above.
   • Present the candidate to the user as the default (e.g. "Based on existing ADRs, I propose using number 0007."); allow the user to accept or override with any other integer.