Decision Extraction

Purpose / When to Activate

Activate after:

• Discovery produces epics, scope clarifications, or priorities
• Delivery resolves technical trade-offs or architectural constraints
• QA surfaces systemic issues requiring policy decisions
• Product direction materially changes

Do NOT use for trivial steps, implementation details, brainstorming, or reversible micro-choices.

---

Process

0. Decision Consistency Gate (mandatory). Before extracting any new decision:

   • Read

     contexts/memory/index.md

     → scan the Decision Registry by domain to identify relevant existing decisions
   • Load the specific

     decisions/DEC-{ID}.md

     files for decisions in the affected domain(s)
   • Verify the proposed decision does NOT contradict any active decision
   • If contradiction found: either explicitly supersede (set

     superseded_by

     in old file +

     supersedes

     in new file) with rationale, or STOP and escalate to human. <!-- E39S07: Impact list added before escalation to give the human full ripple-effect context at decision time. Prevents escalations that lack scope — the human needs to know what else references the contradicted decision before resolving it. Drift prevention. --> When escalating due to contradiction: before surfacing the escalation, grep

     contexts/

     for all occurrences of

     DEC-{id}

     (where

     {id}

     is the contradicted decision's ID). Collect every file path that references the contradicted DEC — memory files, stories, and architecture docs. Present this impact list alongside the escalation message so the human can assess scope before deciding. If the

     contexts/

     directory scan fails: proceed with the escalation without the impact list — the escalation is more important than the impact details.
   • If unable to determine consistency → STOP and escalate to human
   • Never record a decision silently if it may conflict with an existing one

1. Scan outputs for explicit or implicit decisions: architectural choices, accepted trade-offs, scope boundaries, prioritization shifts, constraints introduced

2. Filter strictly for durable, governance-relevant decisions

3. Deduplication check: Scan the Decision Registry in

   index.md

   for existing entries covering the same topic. If found: (a) if the new decision supersedes the old, update the old

   DEC-{ID}.md

   file's frontmatter (

   status: superseded

   ,

   superseded_by: DEC-{new-id}

   ) and record the supersession in the new entry's

   supersedes

   field; (b) if the new decision confirms the old, skip writing a duplicate. 3b. Cross-reference assignment: For the new decision, populate

   related_to

   with up to 5 DEC IDs that are directly related (same domain cluster, supersession chain, or shared concern). Only include decisions the new entry explicitly builds on, refines, or constrains. If no strong relation exists, leave as

   []

   .

4. Convert each into a structured ADR file (see Output Format below):

   • Context
   • Decision
   • Impact

5. Classify using the 10 canonical domains:

   architecture

   ,

   matching

   ,

   expert-system

   ,

   billing

   ,

   booking

   ,

   infrastructure

   ,

   strategy

   ,

   governance

   ,

   market

   ,

   content

   . And 3 levels:

   strategic

   (WHAT/WHY),

   architectural

   (HOW),

   operational

   (PROCESS).

6. Get next available ID from

   decisions/_log.md

   → write

   decisions/DEC-{N}.md

7. Update

   _log.md

   : increment next available ID, add one-line entry for the new decision

8. MANDATORY GATE — Update

   index.md

   : Add one row per new decision to the Decision Registry table (columns: DEC ID | domain | level | one-line description). Increment the file count in the Shared Categories table. Verify: re-read the updated

   index.md

   and confirm the new DEC-{N} entry is present before completing this skill. This step is a blocking gate — do not output success until confirmed.

9. Summary range check: Read the Summaries section of

   index.md

   . If the new DEC ID exceeds the highest DEC covered by the latest summary file (e.g., summary covers 90–155 but new DEC is 156), append a line to

   decisions/_log.md

   :

   # ⚠️ PENDING: extend summary range to DEC-{new-max-id} — run memory-refresh

   . This signals the next

   memory-refresh

   cycle to extend the summary. Do NOT create a new summary mid-delivery.

---

Output Format

Each decision is an individual ADR file:

decisions/DEC-{N}.md

(sequential numeric ID).

---
id: DEC-{N}
domain: architecture | matching | expert-system | billing | booking | infrastructure | strategy | governance | market | content
level: strategic | architectural | operational
title: "Decision Title"
status: active
created_by: discovery
created_at: YYYY-MM-DD
last_updated_by: discovery
last_updated_at: YYYY-MM-DD
supersedes: null          # or DEC-{old-id} if replacing
superseded_by: null
tags:
  - {relevant tags}
related_to: []            # optional — max 5 DEC IDs
---

# DEC-{N} — Decision Title

## Context
...

## Decision
...

## Impact
...

---

Quality Checks

• All major decisions become explicit memory
• No repeated reasoning across sessions
• Governance trail is traceable
• Memory grows only with high-signal knowledge

---

Non-Goals

This skill must NOT:

• Summarize entire sessions
• Capture raw logs
• Duplicate existing decisions
• Store trivial steps
• Invent interpretation without artefact support

If future agents benefit from knowing it → extract it. If not → do not store it. Memory is leverage — not history.