--- 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.