Predict Required Skills v2

The idea

When starting new work, an agent tends to run only the skills it happens to remember, and drops the ones that matter most — confirming intent at the start, packaging output for review at the end. This skill asks "what did sessions like this one actually need?" and turns the answer into a task list, instead of relying on memory in the moment.

The general method, in four steps:

1. Every time a skill is invoked, write one sentence, right then, on why it was the right move — not a generic label, a specific "my sense is because {what in the live conversation made this relevant}."
2. Collect those sentences over time into one growing record.
3. At the start of new work, ask that record: given this scope, which skills, in what order, and why — with citations — and which skills are commonly skipped on this kind of work.
4. Turn the answer into tasks, so a predicted-but-skipped skill leaves a visible open item.

There are two ways to run this, and you should know which one you're on:

Path A: local fallback (works immediately, no setup)

Claude Code already keeps a transcript of every session on disk. Use that as your corpus instead of building anything new:

1. Print the canonical annotation yourself, in chat, every time you invoke a skill (there's no hook forcing this if you haven't built one — see Path B — so it's a discipline you keep on purpose):

   🔥 /{skill-name} skill called, my sense is because {predicted context which made this relevant}
   

   The "my sense is because" phrase matters: it pushes toward a felt-sense articulation of what in the live conversation triggered this skill being the right next move, not a vague context label like "because the person asked me to."

2. When predicting for new work, search your own past sessions for the pattern:

   grep -h "🔥 /" ~/.claude/projects/*/*.jsonl 2>/dev/null | grep -i "<keyword from the new scope>"
   

   (transcripts store messages as JSON, so this is a plain substring match on the printed annotation text — good enough for a keyword search, not a semantic one). Also check any past plans or compactions for skill sequences on similar work.

3. If nothing turns up (a new project, or you haven't been annotating), say so honestly and fall back to a sensible default skeleton rather than presenting an empty search as a real prediction:

   No prior annotated history for this kind of work yet. Using the default skeleton:
   /align (confirm intent) → /governer (score it) → [work] → /consume (package for review) → /commit
   

This costs nothing to set up and degrades honestly — it's the floor, not a placeholder for something better that doesn't exist yet.

Path B: optional — an automatically-growing oracle (see /alignment-harness:harness-setup)

If you want richer synthesis (semantic matching across hundreds of sessions, not just keyword grep) and are willing to set up a NotebookLM notebook, one example setup automates the whole loop so nobody has to remember to feed it:

Agent invokes Skill tool
  ↓
A PostToolUse hook fires and injects: "print 🔥 /skill skill called, my sense is because {context}"
  ↓
Agent prints the canonical 🔥 annotation in chat
  ↓
The transcript captures it (Claude Code logs every assistant message)
  ↓
A SessionEnd hook scrapes 🔥 annotations out of the transcript, writes this session's record,
  and rebuilds ONE merged corpus file from every session's record
  ↓
Uploads the merged corpus as the notebook's single source, verifies it actually landed, deletes
  the prior copy
  ↓
Next session's prediction draws on a corpus that includes last night's work

Two rules matter if you build this yourself, because the alternative silently fails:

• Replace the corpus, never append to it. A notebook holding one source per session will silently stop accepting new ones once it hits its source-count ceiling — the fix is one merged document, rebuilt whole each time, so there's no ceiling to hit and no way for the oracle to answer from a stale partial copy.
• Verify against the notebook's own source listing, never a tool's exit code. Some upload tools report success even when nothing was actually added once a notebook is full. Only trust what a listing command shows is actually there.

If you've set this up, query it:

mcp__notebooklm__query_notebook({
  notebook_id: "<your notebook id>",
  question: "Given this scope: {scope}. Tags: {tags}. Based on historical 🔥 annotations for
    similar scopes, which skills should be invoked, in what order, and why? Cite the verbatim 🔥
    annotations you draw from, and flag which skills are commonly SKIPPED on this kind of work."
})

Ask for the verbatim citations and the commonly-skipped flag explicitly. If it's not set up, skip this and say so — "no skill-history oracle configured (/alignment-harness:harness-setup can build one)" — and use Path A.

Format the prediction as a mandatory sequence (either path)

## Required Skill Sequence — {scope title}

Grounded in {cited 🔥 annotations for similar work | the default skeleton, no history yet}.
These are REQUIREMENTS, not suggestions. Each must be executed and marked done.

1. /align — confirm intent before acting [EARLY]
2. /governer — score complexity and leverage [EARLY]
3. /[skill] — [why, grounded in similar past sessions' 🔥 annotations, or reasoned directly] [MID]
...
N. /consume — build reviewable output [LATE]
N+1. /commit [LATE]

Skipped-skill risk: [skills flagged as commonly missed, if you have history to flag them from]

Reasoning: [1-2 sentences, with citations if you have them]

Then decompose into tasks — one TaskCreate per skill in the list:

TaskCreate({
  subject: "Run /[skill-name] — [one-line description]",
  description: "Required pipeline step for this scope. Why: [reasoning, with a citation if available]"
})

If your history is thin or entirely reconstructed rather than captured live, treat the prediction as a strong suggestion rather than an unconditional requirement until you've built up more of your own track record — say so plainly rather than presenting a thin guess with false confidence.

Building a starting corpus instead of starting from zero

If you have prior Claude Code sessions but haven't been annotating, you can backfill: scan ~/.claude/projects/*/*.jsonl for past Skill tool invocations, read the messages just before each one, and write an inferred "why" sentence for it. Mark these as reconstructed, not live-captured — they're weaker evidence than an annotation written in the moment, and an oracle or search built from them should say so when it cites one.

Verification — how to know this is actually working

Path A: after printing a 🔥 annotation, grep "🔥 /" ~/.claude/projects/*/*.jsonl should find it in the current session's transcript. A prediction on a topic you know you've worked on before should surface that annotation, not come back empty.

Path B, if you built it: after a skill call and a session end, confirm your local per-session record was written, confirm the merged corpus was rebuilt, and confirm the notebook holds exactly one current source (list its sources directly — don't trust an upload tool's success message). A stale corpus answers fluently but cites nothing newer than its last good upload — if a query never cites anything recent, that's the tell.

Why the "why" sentence, specifically

The annotation does two jobs at once: it feeds whichever corpus you're building, and it makes the agent stop and articulate — even in one sentence — why this skill fits right now, which is a small alignment check in its own right, independent of whether anything ever reads it back.