--- name: meta-synthesis version: 3.2.0 description: > Reads /context/skill-sessions.md to detect patterns that repeat across 2+ sessions, proposes new guardrails for /context/meta-patterns.md, and proposes brain updates for confirmed learnings. Run on demand or roughly weekly, not as a background job. Trigger on: "run meta-synthesis", "what patterns are emerging", "detect cross-skill signals", "update guardrails", "compound our learnings", "what should we remember". metadata: author: Stefanos Karakasis context: brain-dependent quality_gate: true last_updated: 2026-08-24 --- # meta-synthesis — Skill ## How This Works Reads the session log every execution skill already writes to, finds patterns that repeat across 2 or more sessions, and turns confirmed patterns into either a guardrail (for `/context/meta-patterns.md`) or a brain update (for `/foundation/brain.md`). This is what makes the rest of the stack compound instead of starting fresh every session. The skill runs in 5 steps: **Step 0** — Load `/context/skill-sessions.md` and `/context/meta-patterns.md`. Block if the session log doesn't exist or has zero rows. **Step 1** — Scan sessions for repeated patterns, both within one skill and across skills. **Step 2** — Rank patterns by confidence (occurrence count) and propose next action for each. **Step 3** — Surface proposed guardrails and brain updates, gated on user approval. **Step 4** — Write approved guardrails to `/context/meta-patterns.md` and approved brain updates to `/foundation/brain.md`. Log the session. --- ## Trigger - **When:** Detecting patterns across 2+ prior sessions logged by other skills, and turning confirmed patterns into guardrails or brain updates. - **Not for:** Real-time feedback during a session — execution skills already check `/context/meta-patterns.md` at their own Step 0. Auditing a single skill's output quality → use `meta-review`. One-off pattern lookups — this skill's value is in running it repeatedly. - **Example prompts:** - "run meta-synthesis" - "what patterns are emerging" - "detect cross-skill signals" - "update guardrails" - "compound our learnings" - "what should we remember" --- ## Inputs - **Args:** Timeframe to analyze — all sessions, or a specific window (e.g. last 30 days). Asked in Step 0 if not specified. - **Defaults:** All sessions in `/context/skill-sessions.md` if no timeframe is given. - **Context keys:** - `/context/skill-sessions.md` — required. The session log every execution skill writes to. - `/context/meta-patterns.md` — optional; loaded if it exists, treated as empty otherwise. - `/foundation/brain.md` — optional; Sections 1-6 loaded silently as baseline context for proposed updates. - **Brain contract:** Reads Sections 1-6. Writes: Section named in an approved brain-update proposal only, after explicit user approval (Step 3). --- ## Pre-flight - Load `/context/skill-sessions.md` — see Step 0. - **Hard block:** if `/context/skill-sessions.md` is missing, or contains zero `type: execution` entries, stop and tell the user there's nothing to synthesize yet. - Load `/context/meta-patterns.md` and `/foundation/brain.md` if they exist — see Step 0. --- ## Steps ### Step 0 — Pre-Flight Load: - `/context/skill-sessions.md` — required. If missing, or contains zero `type: execution` entries, stop and tell the user there's nothing to synthesize yet. - `/context/meta-patterns.md` — load if it exists; if missing, treat as empty (this run may create it). - `/foundation/brain.md` — load Sections 1-6 silently, as baseline context for any proposed updates. Ask, if not specified: "Look at all sessions, or a specific timeframe (e.g. last 30 days)?" Default: all sessions in the log. --- ### Step 1 — Scan for Repeated Patterns Read every entry in `/context/skill-sessions.md` for the chosen timeframe where `type: execution`. Skip `type: synthesis` entries — those are this skill's own prior output, not raw material for pattern detection. Group the remaining entries by two lenses: **Within one skill** — the same issue showing up 2+ times in sessions from the same skill (e.g. `retro` logging "champion alignment gap" in two different launches). **Across skills** — the same underlying issue showing up in sessions from 2+ different skills (e.g. `pre-mortem` flags a risk that `retro` later confirms happened). Cross-skill patterns are the ones most worth turning into a guardrail, since they're not visible from inside any single skill. For each candidate pattern, capture: what it is in one sentence, which sessions it appeared in (skill + date), and how many times. --- ### Step 2 — Rank and Recommend Classify each pattern by occurrence count: | Occurrences | Confidence | Recommended action | |---|---|---| | 3+ | High | Propose as a guardrail — ready to surface to execution skills at their own Step 0 | | 2 | Medium | Propose as a guardrail, flagged "watch" rather than "confirmed" | | 1 | Low | Note only — not enough evidence yet, don't propose anything | If a pattern points at something durable about the business rather than a process gap — a buying trigger, a market shift, a proof point that keeps landing — propose it as a brain update instead of a guardrail, naming the exact section (2 ICP, 5 Market Context, 6 Proof Points) it belongs in. --- ### Step 3 — Propose and Gate Surface every High and Medium confidence pattern together, in one message, for approval: ``` 🔁 PATTERNS FROM /context/skill-sessions.md 1. [Pattern name] — HIGH confidence (4 occurrences: 2 retros, 2 pre-mortems, dates [list]) Proposed: add guardrail to /context/meta-patterns.md: "[exact guardrail text]" 2. [Pattern name] — MEDIUM confidence (2 occurrences: [dates]) Proposed: add guardrail (watch status): "[exact guardrail text]" 3. [Pattern name] — durable signal, not a process gap Proposed: brain update, Section [N]: "[exact text]" Approve all / approve some (name which) / reject all? ``` Never write anything without this gate. If the user rejects a pattern, log it as rejected with the reason and move on — don't re-propose it next run unless new occurrences push it to a higher confidence tier. --- ### Step 4 — Write and Log For each approved item: - Guardrail → append to `/context/meta-patterns.md` with the pattern text, occurrence count, and date added. - Brain update → write to the named section of `/foundation/brain.md`, showing the exact before/after, same confirmation standard as every other skill that writes to the brain. Log this session to `/context/skill-sessions.md`: ```yaml type: synthesis skill: meta-synthesis session_date: [YYYY-MM-DD] sessions_analyzed: [count] timeframe: [all / last N days] patterns_found: high_confidence: [count] medium_confidence: [count] guardrails_proposed: [count] guardrails_approved: [count] brain_updates_proposed: [count] brain_updates_approved: [count] ``` Close by telling the user plainly what changed: how many guardrails are now live, what the brain updates were, and what's worth watching next time (the Low-confidence, single-occurrence notes from Step 1). --- ## Outputs - **Files written:** `/context/meta-patterns.md` — approved guardrails appended (Step 4). `/foundation/brain.md` — approved updates written to the named section (Step 4). `/context/skill-sessions.md` — one appended row per session (Step 4). - **Chat output format:** Numbered list of proposed patterns with confidence tier and exact guardrail/brain-update text (Step 3), followed by a plain-language close summarizing what changed (Step 4). - **External side effects:** None beyond the three files above, and only after explicit user approval. --- ## Verification - `/context/skill-sessions.md` has at least one `type: execution` entry before proceeding past Step 0. - Every candidate pattern classified by occurrence count (Step 2). - No guardrail or brain update written without explicit approval shown as exact text first (Step 3). - Rejected patterns logged with reason, not silently dropped (Step 3). - Session logged to `/context/skill-sessions.md` (Step 4). --- ## Operating Rules - **Session log is the only input.** No integrations, no scheduler, no separate memory store — everything this skill needs, every other skill already writes to `/context/skill-sessions.md`. - **2+ occurrences minimum to propose anything.** A single session is an anecdote, not a pattern. - **Cross-skill patterns take priority.** They're invisible from inside any one skill, which is the entire reason this skill exists. - **Every write is gated.** No guardrail or brain update happens without explicit approval, shown as exact text before it's written. - **Rejected patterns aren't silently dropped.** Log the rejection so the same pattern isn't re-proposed next run without new evidence. - **Durable signals go to the brain, not a guardrail.** A pattern about the business itself (buying trigger, market shift, proof point) is a brain update, not a process guardrail. --- ## Quality Gate | Check | Pass = | |---|---| | Session log loaded | `/context/skill-sessions.md` parsed, ≥1 row | | Patterns ranked | Every candidate classified High/Medium/Low by occurrence count | | Cross-skill patterns flagged | Patterns spanning 2+ skills marked as priority | | Proposals gated | All guardrails and brain updates shown for approval before writing | | Session logged | Metadata appended to `/context/skill-sessions.md` | --- ## Do Not Use For - **Real-time feedback during a session** — execution skills already check `/context/meta-patterns.md` at their own Step 0 - **Auditing a single skill's output quality** — use `meta-review` - **One-off pattern lookups** — this skill's value is in running it repeatedly, not as a single query tool