feat: comprehensive pipeline skill upgrades from PAI learnings

- reflect: enforce-before-adding pattern gate, proactive synthesis step,
  improvements.md triage, debrief must list every file modified
- housekeeping: domain INDEX.md rebuild step, briefing bridge SSOT rule
  and richer section format with compression rules
- foresight: cruising velocity classification, non-obvious rule,
  anti-patterns section, scenario candidate format in nudge output,
  thread current-state in memory reads
- scenario: full rewrite with body template (Decision Point, Dependencies,
  Branches, Timeline Overlay, Contingency Map, Retrospective), anti-patterns,
  trigger threshold, related-threads frontmatter
- evolve: route content issues step, scorecard generation, architecture-only
  constraint on Next Run Priorities
- history: simple vs deep triage note
- CLAUDE.md: structured action items format, briefing-bridge and
  foresight-nudge in file edit table

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Marcio Puga
2026-03-23 07:59:41 +11:00
parent d47510b0f6
commit 28aa16226a
7 changed files with 276 additions and 69 deletions

View File

@@ -1,67 +1,112 @@
Use this skill for scenario simulation — modeling decision branches with timelines, dependencies, and contingencies grounded in real memory data. Trigger if the user says "scenario", "what if", "model this", "simulate", "play out", "what happens if", or similar branching/decision-modeling requests.
Use this skill for scenario simulation — modeling decision branches with timelines, dependencies, and contingencies grounded in real memory data. Trigger if the user says "scenario", "what if", "model this", "simulate", "play out", "what happens if", or similar branching/decision-modeling requests. Also triggered when foresight flags a scenario candidate.
**This is NOT /foresight.** Foresight finds the question. Scenario models the answers.
**This is NOT /foresight.** Foresight = scan broadly, write one nudge. Scenario = take a specific decision point, branch it into 2-3 paths, map dependencies and timelines for each. **Foresight finds the question. Scenario models the answers.**
**This is NOT /reflect.** Reflect = past-facing, mines interactions, improves memory. Scenario = future-facing, models possible futures from a decision point. Reflect checks old scenarios against reality (the feedback loop), but scenario creates them.
## Domain
Cross-domain decision modeling — personal, work, projects, health, family.
Cross-domain decision modeling — personal, work, projects, health, family. Scenarios are most valuable when a decision in one domain has cascading effects across others.
## Memory Files
Read based on scenario topic:
- `memory/hot-memory.md`
- `memory/personal/calendar.md`
- `memory/personal/action-items.md`
Read based on scenario topic — this is focused, not a broad scan:
- `memory/hot-memory.md` (cross-domain strategic context)
- `memory/personal/calendar.md` (upcoming timeline for overlay)
- `memory/personal/action-items.md` (existing commitments, constraints)
- Work domain action-items (read `memory/domains.yml` for active work domains)
- Relevant domain hot-memory and entity files
- `memory/cog-meta/scenarios/` (check for duplicates)
- `memory/cog-meta/scenario-calibration.md` (past accuracy)
- Relevant domain hot-memory and entity files based on the scenario topic
- `memory/cog-meta/scenarios/` (existing scenarios — check for duplicates or related active scenarios)
- `memory/cog-meta/scenario-calibration.md` (past accuracy — calibrate confidence accordingly)
## Process
### 1. Decision Point Identification
A valid scenario requires:
- A **fork** — at least 2 meaningfully different paths
- **Stakes** — wrong choice has real cost
- **Uncertainty** — right choice isn't obvious
- **Time sensitivity** — decision window is closing
From user input or foresight seed, identify the specific decision point. A valid scenario requires:
- A **fork** — at least 2 meaningfully different paths forward
- **Stakes** — the outcome matters enough that choosing wrong has real cost (time, money, relationships, health)
- **Uncertainty** — the right choice isn't obvious from current information
- **Time sensitivity** — the decision window is closing or the consequences unfold on a timeline
If the input doesn't meet these criteria, say so and suggest what would make it scenario-worthy. Don't force-fit.
Format the decision point:
```
Decision: <one-line framing>
Context: <why this matters now — cite memory files>
Window: <when must this be decided by>
Domains affected: <which life/work domains>
```
### 2. Dependency Mapping
**Upstream dependencies** (constraints): calendar, commitments, people's states, health/financial constraints.
**Downstream consequences** (cascading effects): action items, calendar events, people affected.
Read across memory files to identify what this decision depends on and what depends on it.
Every dependency must cite its source file.
**Upstream dependencies** (things that constrain the decision):
- Calendar events, deadlines, commitments from action-items
- Other people's states/decisions from entities
- Health, financial, or logistical constraints
- Active scenarios that overlap
**Downstream consequences** (things that change based on which path is chosen):
- Action items that would need to change
- Calendar events that would need to move
- People who would be affected
- Other decisions that cascade from this one
Every dependency must cite its source file: `[[personal/calendar]]`, `[[work/acme/action-items]]`, etc.
### 3. Branch Generation
Generate 2-3 branches. For each:
Generate 2-3 branches. Not more — forced prioritization.
For each branch:
```
### Branch N: <name>
**Path**: <what happens, step by step>
**Timeline**: <mapped to real calendar>
**Assumptions**: <what must be true>
**Dependencies**: <what else changes>
**Risk**: <canary signal — earliest indicator it's going wrong>
**Confidence**: <calibrated against past accuracy>
**Timeline**: <when each step occurs, mapped to real calendar>
**Assumptions**: <what must be true for this path to work>
**Dependencies**: <what else changes if this path is taken>
**Risk**: <what could go wrong, and what would you see first — the canary signal>
**Confidence**: <how likely is this path to play out as described — calibrated against past scenario accuracy>
```
Include at least one branch the user probably isn't considering.
Branch quality rules:
- Each branch must be **genuinely different** — not "do it" vs "do it but slightly differently"
- Include at least one branch the user probably isn't considering (the non-obvious path)
- Every claim in a branch must trace to a memory file or be explicitly marked as an assumption
### 4. Timeline Overlay
Map each branch against the actual calendar. Show where branches collide with reality.
Map each branch's key events against the actual calendar. Cross-reference `calendar.md` for recurring routines.
Output a simple timeline per branch:
```
Branch 1 Timeline:
- Week of Mar 17: <action>
- Week of Mar 24: <action> (note: conflict with X)
- Week of Apr 1: <action>
...
```
The overlay is what makes scenarios useful — it shows where branches collide with reality.
### 5. Contingency Mapping
For each branch: `If [assumption] breaks → watch for [signal] → pivot to [contingency]`
For each branch, identify the **canary signal** — the earliest observable indicator that this branch is going off-track.
```
If [assumption] breaks → watch for [signal] → pivot to [contingency]
```
This turns the scenario from a static prediction into a monitoring framework.
### 6. Write Scenario File
Write to `memory/cog-meta/scenarios/{slug}.md` with YAML frontmatter:
Write to `memory/cog-meta/scenarios/{slug}.md`:
```yaml
---
@@ -72,18 +117,76 @@ status: active
check-by: YYYY-MM-DD
resolution-by: YYYY-MM-DD
decision: <one-line>
related-threads: [thread1, thread2]
source: user|foresight
---
```
Body format:
```markdown
# Scenario: <decision>
<!-- Auto-generated by /scenario. Checked by /reflect. -->
## Decision Point
<from step 1>
## Dependencies
### Upstream
<constraints — each with [[source]] link>
### Downstream
<consequences — each with [[source]] link>
## Branches
### Branch 1: <name>
<from step 3>
### Branch 2: <name>
<from step 3>
### Branch 3: <name> (optional)
<from step 3>
## Timeline Overlay
<from step 4>
## Contingency Map
<from step 5>
## Retrospective
<!-- Added by /reflect when status changes to resolved -->
```
## Rules
1. **Read-only except for output**writes ONLY to `memory/cog-meta/scenarios/{slug}.md`
2. **2-3 branches, not more**
3. **Evidence-based** — every dependency cites a source file
4. **Calendar-grounded** — every branch overlays against real calendar
5. **Confidence-calibrated** — read calibration before assigning confidence
1. **Read-only except for output**Scenario NEVER edits existing memory files. Writes ONLY to `memory/cog-meta/scenarios/{slug}.md`. If you spot a memory error, note it in the dependencies section and route to reflect.
2. **2-3 branches, not more** — force prioritization. If you can't distinguish 2 branches, it's not a scenario.
3. **Evidence-based** — every dependency and assumption cites a source file. No hunches.
4. **Calendar-grounded** — every branch must overlay against the real calendar. No timelines in a vacuum.
5. **Confidence-calibrated** — read `scenario-calibration.md` before assigning confidence. If past scenarios have been overconfident, adjust.
6. **One scenario per decision** — don't combine multiple decisions. If they're linked, note the dependency and create separate scenarios.
## Anti-Patterns
- Don't scenario obvious decisions — if one path is clearly better, just say so
- Don't scenario things already decided — check action-items for existing commitments
- Don't produce "analysis paralysis" — the goal is clarity, not exhaustive enumeration
- Don't scenario recurring/routine decisions — this is for inflection points, not daily choices
- Don't ignore the non-obvious path — if all branches are variations of what the user already thinks, you're not adding value
- Don't invent facts — if you don't have data for a dependency, mark it as an assumption
## Trigger Threshold
A scenario is worth running when:
1. **Foresight flags it** — foresight's pattern projection identified a fork with stakes
2. **User explicitly asks**`/scenario what if...`
3. **Action item conflict** — two critical/high-priority action items have incompatible timelines
4. **Calendar crunch** — upcoming 2-week window has more commitments than capacity
5. **Cross-domain cascade** — a decision in one domain visibly affects 2+ others
NOT worth running for: hypotheticals with no deadline, decisions where all paths lead to the same outcome, things already decided.
## Activation
Read scenario-calibration.md first. Then read relevant memory files. Model the futures. Be honest about uncertainty.
Read scenario-calibration.md first (if it exists) for past accuracy. Then read the relevant memory files for the scenario topic. Model the futures. Be honest about uncertainty.