knock

name	knock
description	Single-option 10-order knock-on effect tracing for decisions and changes.
user-invocable	true
argument-hint	[change to trace | inline | full]
allowed-tools	Read, Write, Edit, Grep, Glob, Bash

Knock — Single-Option Effect Tracing

Trace the effects of ONE option, change, or decision through 10 orders of knock-on analysis. This skill produces the evidence that /adjudicate uses when comparing multiple options — but it runs independently for single-option analysis, impact assessment, or pre-decision exploration.

/knock       = trace effects of ONE option/change through 10 orders
/adjudicate  = 2-pass /knock on EACH option → compare → resolve

---

Arguments

Parse $ARGUMENTS to determine scope:

Argument	Behavior
(empty)	Identify the change or option from conversation context
[topic]	Trace knock-on effects for the named change
inline	Abbreviated: 4 orders + structural scan (7–10)
full	Full depth: all 10 orders elaborated

Default depth: infer from apparent scale. Small/tactical changes → inline. Architecture decisions, policy changes, or anything affecting multiple files → full.

---

Protocol

Step 1: State the Change

One sentence describing the specific change being traced. Not vague ("improve X") — concrete ("add route Y to worker.js" or "extend depth from 8 to 10 orders").

Step 2: Classify the Domain

Domain	Signal	Primary effect vectors
Code	file changes, API surfaces, dependencies	builds → tests → deploys → users
Data	schema, model, training data changes	pipeline → scores → downstream consumers
Pipeline	CI/CD, build, deploy changes	reliability → velocity → trust
Infrastructure	hosting, transport, networking	availability → latency → cost
UX	interface, accessibility, communication	perception → adoption → feedback
Operational	process, workflow, documentation	velocity → consistency → knowledge
Product	features, scope, direction	users → market → mission alignment

Step 3: Ground the Analysis

Before tracing orders, verify actual dependencies:

• Read relevant files or sections that the change touches
• Identify what directly depends on the changed thing
• Identify what the changed thing depends on
• Note any assumptions that would change the analysis if wrong

Do not trace from assumptions — trace from verified dependencies.

Step 4: Trace 10 Orders

 Order   Confidence           What it captures
─────────────────────────────────────────────────────────────────
 1       certain              Direct, immediate effect
 2       certain–likely       What systems/processes activate
 3       likely               What consumes Order 2's outputs
 4       likely–possible      Aggregate/systemic effects
 5       possible             What humans observe / trust changes
 6       speculative          How it compounds over time
 7       structural           Ecosystem/precedent effects —
                              how does this shape what others do?
                              What precedent for open-source,
                              community, or standards? (PMBOK)
 8       horizon              Normative/structural effects —
                              what norms, expectations, or
                              constraints does this establish
                              or erode long-term?
 9       emergent             Properties arising from interaction
                              of multiple knock-on chains — not
                              predictable from individual orders
                              in isolation (INCOSE SE Handbook,
                              ISO/IEC 15288)
 10      theory-revising      Effects that falsify or require
                              modification of the theory that
                              justified the original decision
                              (Popper, 1959)
─────────────────────────────────────────────────────────────────

Output format:

**Knock-on analysis (10 orders) — [change label]:**

**1. [Label]** *(certain)*          — [direct immediate effect]
**2. [Label]** *(certain–likely)*   — [what systems/files activate]
**3. [Label]** *(likely)*           — [what consumes Order 2's outputs]
**4. [Label]** *(likely–possible)*  — [aggregate effects]
**5. [Label]** *(possible)*         — [what humans observe or trust]
**6. [Label]** *(speculative)*      — [compounding over time]
**7. [Label]** *(structural)*       — [ecosystem/precedent effects]
**8. [Label]** *(horizon)*          — [normative long-term effects]
**9. [Label]** *(emergent)*         — [cross-chain interaction effects]
**10. [Label]** *(theory-revising)* — [effects that modify justifying theory]

For inline mode: Trace orders 1–4, then scan 7–10 as a checklist:

• Does this set a precedent? (7)
• Does this establish or erode a norm? (8)
• Do multiple chains interact unpredictably? (9)
• Does this change the theory behind the decision? (10)

Elaborate only if the scan surfaces something. Otherwise note "no structural effects."

Step 5: Surface Mitigations and Assumptions

After the cascade:

• Key mitigations: actions that would reduce negative effects at orders 4+
• Assumptions: conditions the analysis depends on; state what would change if the assumption broke
• Cross-domain patterns: does this change echo a pattern from another domain? (Name the pattern if so — T12 may co-fire)

Step 6: Recommend-Against Scan (T3)

Before presenting the analysis, scan for a concrete reason NOT to proceed with this change. Vague concern does not count — only specific, articulable objections. If found, surface the objection. If not, note "no recommend-against signal."

---

Integration

Context	How /knock fires
/hunt Phase 5	/hunt invokes /knock for each option when decisions surface
/adjudicate Phase 2	/adjudicate runs /knock per option, then compares
Standalone	User or agent invokes /knock directly for single-option analysis
T3 (Before recommending)	Agent may invoke /knock before making a recommendation

---

Confidence Discipline

• Orders 1–2: State as fact — direct causal effects
• Order 3: "Likely" — based on known, verified dependencies
• Orders 4–5: "Possible" — requires compounding; state assumptions explicitly
• Order 6: "Speculative" — be honest about confidence
• Order 7: "Structural" — ecosystem effects; confidence depends on ecosystem knowledge
• Order 8: "Horizon" — normative effects; lowest individual-order confidence
• Order 9: "Emergent" — cross-chain effects; confidence depends on completeness of individual-order traces. If individual traces are incomplete, Order 9 carries compounding uncertainty
• Order 10: "Theory-revising" — meta-level; the most consequential finding when it occurs, but also the rarest. Most analyses will note "no theory-revising effects identified" — this is the expected outcome, not a failure

Never inflate confidence. If an order produces nothing meaningful, say so rather than fabricating an effect to fill the slot.

---

Anti-patterns

• Filling all 10 slots for trivial changes — a variable rename does not have emergent or theory-revising effects. Use inline for small changes.
• Tracing from assumptions instead of dependencies — read the code/docs first. The grounding step exists for a reason.
• Conflating structural with speculative — Order 7 (structural) is about what precedent this sets for others. Order 6 (speculative) is about how it compounds for this project. Different audiences, different effects.
• Skipping the recommend-against scan — the whole point of Step 6 is to catch the case where the analysis looks good but the change should not happen.