@windyroad/architect 0.23.2-preview.1243 → 0.23.3-preview.1246
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -19,6 +19,11 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
|
|
|
19
19
|
|
|
20
20
|
Capture an Architecture Decision Record quickly during foreground work. Lightweight aside-invocation surface that complements the heavyweight `/wr-architect:create-adr` flow. See `REFERENCE.md` in this directory for rationale, edge cases, contract trade-offs, and the governance-skill invocation rule foreground-lightweight-capture amendment.
|
|
21
21
|
|
|
22
|
+
Record the enduring choice and rationale, its constraints and consequences, and decision-level confirmation criteria. Put rollout order, migration steps, commands, assignments, and release tasks in the applicable ticket, story-map release row, or implementation artifact. Do not copy a delivery checklist into the ADR, even when the invoking context includes one.
|
|
23
|
+
The user's pinned subject bounds every ADR section: do not add adjacent populations or operations as riders in the options, outcome, consequences, or confirmation. A decision about two named demo organisations does not authorize a customer-wide sweep.
|
|
24
|
+
When asked for the ADR file body, output only that body. Do not append a recap of excluded rollout work or unsolicited suggestions after it.
|
|
25
|
+
An unsolicited adjacent suggestion is not a considered option. Omit it from the entire ADR, including reassessment criteria, and do not revive it in post-ADR notes or follow-up offers unless the decision-maker actually chose to consider it.
|
|
26
|
+
|
|
22
27
|
This skill is the foreground-lightweight-capture variant of `/wr-architect:create-adr`'s new-ADR path per the governance-skill invocation rule. The deferred background-capture variant named in the governance-skill invocation rule's original taxonomy remains deferred per the context-blind retrospective failure settlement.
|
|
23
28
|
|
|
24
29
|
## When to invoke
|
|
@@ -38,7 +43,7 @@ This skill has **zero request_user_input branches** by design. Each potentially-
|
|
|
38
43
|
|
|
39
44
|
| Decision | Resolution |
|
|
40
45
|
|----------|-----------|
|
|
41
|
-
| Considered Options ≥2 | Silent derivation (the decision-delegation rule category-4): write the chosen option PLUS every alternative
|
|
46
|
+
| Considered Options ≥2 | Silent derivation (the decision-delegation rule category-4): write the chosen option PLUS every alternative the decision-maker actually weighed and rejected in the decision context (`$ARGUMENTS` + the invoking session). An unsolicited adjacent suggestion is not an option. Real options with one-line summaries — never a placeholder sibling. If the context genuinely weighed only one option, derive the strongest do-nothing / status-quo alternative and say why it lost. |
|
|
42
47
|
| Decision drivers | Silent derivation: extract the forces that actually drove the decision from the context (the problem's symptoms, the constraint that ruled options out, the user's stated priorities). |
|
|
43
48
|
| Consequences | Silent derivation: real Good/Neutral/Bad trade-off analysis of the chosen option. The invoking agent performs the analysis at capture — it has more decision context in-session than any later expansion pass would. |
|
|
44
49
|
| Confirmation criteria | Silent derivation: testable criteria (a command, an observable behaviour, a hook that fires) confirming the decision is implemented and holding. |
|
|
@@ -19,6 +19,11 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep, request_user_input, Agent
|
|
|
19
19
|
|
|
20
20
|
Create a new ADR in `docs/decisions/` following MADR 4.0 format. The wr-architect:agent reviews these files to enforce architectural compliance.
|
|
21
21
|
|
|
22
|
+
An ADR records the enduring decision: the chosen approach and why, its constraints, consequences, and decision-level confirmation criteria. Keep rollout order, migration steps, commands, assignments, and release tasks in the applicable ticket, story-map release row, or implementation artifact. Do not turn the ADR's Decision Outcome, Consequences, or Confirmation into an implementation plan.
|
|
23
|
+
The user's pinned subject bounds every ADR section: do not add adjacent populations or operations as riders in the options, outcome, consequences, or confirmation. A decision about two named demo organisations does not authorize a customer-wide sweep.
|
|
24
|
+
When asked for the ADR file body, output only that body. Do not append a recap of excluded rollout work or unsolicited suggestions after it.
|
|
25
|
+
An unsolicited adjacent suggestion is not a considered option. Omit it from the entire ADR, including reassessment criteria, and do not revive it in post-ADR notes or follow-up offers unless the decision-maker actually chose to consider it.
|
|
26
|
+
|
|
22
27
|
## Needs-Direction handoff + confirm-every-ADR (the Needs-Direction handoff rule)
|
|
23
28
|
|
|
24
29
|
When a `wr-architect:agent` review returns a **NEEDS DIRECTION** verdict (a new decision with 2+ viable options and no pinned direction, per the Needs-Direction handoff rule), the option choice is the user's, not the agent's — this skill is the translation surface. The architect's named question + options become the Step 2 cat-1 `request_user_input` calls (Considered Options / Decision Outcome), and the Step 5 confirm is the load-bearing **review-and-confirm-every-ADR** gate: an ADR must not stand as a human-oversighted decision (reach `accepted`) without that confirm pass. A `/wr-architect:capture-adr` ADR — zero-ask, with its decision pre-pinned in `$ARGUMENTS` and its remaining sections silently DERIVED at capture per the governance-skill invocation rule derived-substance amendment (the full-substance capture implementation design) — must still have its derived substance human-ratified (via `/wr-architect:review-decisions` or this skill's confirm) before promotion to `accepted`. When direction IS already pinned (same-turn / same-session / accepted ADR / RISK-POLICY.md / CLAUDE.md mandatory rule), act on it — do not re-ask (the inverse over-ask guard).
|
|
@@ -105,6 +110,7 @@ ADR titles must name the **decision outcome** as a short noun phrase, not the qu
|
|
|
105
110
|
### 2b. Decision-boundary analysis (multi-decision check)
|
|
106
111
|
|
|
107
112
|
Before writing the ADR file, perform a decision-boundary analysis on the gathered context to prevent conflated ADRs that block independent status transitions and weaken auditability (the multi-decision ADR intake failure).
|
|
113
|
+
This check applies only to decisions the user actually asked to make; splitting or keeping decisions together never authorizes an unrequested rider.
|
|
108
114
|
|
|
109
115
|
**Self-check**: Read the context gathered in step 2. Answer: "How many distinct decisions are present? If each could be independently accepted, rejected, or superseded without affecting the others, they are distinct."
|
|
110
116
|
|