Install
openclaw skills install adr-decision-extractionUse when you need to mine a conversation, session transcript, or design discussion for architectural decisions before writing ADRs. Identifies problem-solution pairs, trade-off debates, technology choices, and explicit "[ADR]" tags. Triggers on "what decisions did we make", "extract decisions from this chat", "find the choices in our discussion", or "summarize architectural decisions". Also useful after long planning sessions to capture decisions that were made implicitly. Does NOT write ADR documents — use adr-writing or write-adr for that.
openclaw skills install adr-decision-extractionExtract architectural decisions from conversation context for ADR generation.
| Signal Type | Examples |
|---|---|
| Explicit markers | [ADR], "decided:", "the decision is" |
| Choice patterns | "let's go with X", "we'll use Y", "choosing Z" |
| Trade-off discussions | "X vs Y", "pros/cons", "considering alternatives" |
| Problem-solution pairs | "the problem is... so we'll..." |
Text marked with [ADR] is always extracted:
[ADR] Using PostgreSQL for user data storage due to ACID requirements
These receive confidence: "high" automatically.
Patterns detected without explicit tags require confidence assessment:
| Confidence | Criteria |
|---|---|
| high | Clear statement of choice with rationale |
| medium | Implied decision from action taken |
| low | Contextual inference, may need verification |
{
"decisions": [
{
"title": "Use PostgreSQL for user data",
"problem": "Need ACID transactions for financial records",
"chosen_option": "PostgreSQL",
"alternatives_discussed": ["MongoDB", "SQLite"],
"drivers": ["ACID compliance", "team familiarity"],
"confidence": "high",
"source_context": "Discussion about database selection in planning phase"
}
]
}
| Field | Required | Description |
|---|---|---|
title | Yes | Concise decision summary |
problem | Yes | Problem or context driving the decision |
chosen_option | Yes | The selected solution or approach |
alternatives_discussed | No | Other options mentioned (empty array if none) |
drivers | No | Factors influencing the decision |
confidence | Yes | high, medium, or low |
source_context | No | Brief description of where decision appeared |
[ADR] tagged contentRun these in order after the workflow above and before returning output. Each step has an objective pass condition.
[ADR] inventory — Capture every [ADR] segment from the full source (verbatim in working notes). Pass: a second pass over the same source adds no new [ADR] blocks.[ADR] decision (see Merge Related Decisions). Pass: at most one row per distinct decision.decisions[] item has non-empty title, problem, chosen_option; confidence ∈ {high,medium,low}; alternatives_discussed is an array (use [] if none); other optional fields per table.confidence: "low", source_context states what was missing, weak, or contradictory. Pass: a reader can see why the rating is not higher."We decided to use Redis for caching because of its sub-millisecond latency
and native TTL support. Memcached was considered but lacks persistence."
Extracts:
"Let's go with TypeScript for the frontend since we're already using it
in the backend."
Extracts:
"The API seems to be working well with REST endpoints."
Extracts:
Always capture sufficient context for the ADR writer:
If multiple statements relate to the same decision, consolidate them:
When decisions are unclear or contradictory:
source_contextlow