Agent Init: Situation-to-Skill Routing Table

Run this at the start of any substantive work session, or when you're unsure which skill handles a situation. This is the index — not a replacement for reading the actual skill files. Every row below names a skill that ships with this harness; if you've added your own skills, tell the agent about them and add a row here so future sessions find them too.

---

Phase 0: Before You Do Anything

Situation	Invoke	Why
Starting any task, need context	Search first, then act. If institutional memory search is set up (see /alignment-harness:harness-setup), run it before your first Glob/Grep. Otherwise: search this repo's docs and notes, git log, and your past Claude Code sessions (~/.claude/projects/*/*.jsonl, grep for the topic), and say plainly when nothing turned up.	You should never guess when a search would tell you.
Starting a new task or feature	/governer	Scores how much could go wrong and how far a mistake would travel — sets how carefully everything downstream gets done.
Not sure what the person actually means	/ask	Gates on leverage × uncertainty; tells you when to just decide instead of asking.
Asked "what should I work on"	/next-priority-tasks	Aggregates whatever priority signals you have (proposals, logs, notes) into one ranked queue.

---

Phase 1: Understanding & Research

Situation	Invoke	Why
Need to find an existing helper/utility before writing a new one	/agentic-tooling-registry	Registry pattern for agent-discoverable tools. Search before building anything new.
Need to know the intended UX before coding	/intent-db → find "<topic>"	Source of truth for what the person wants users to experience, once they've started filling it in.
Deciding whether an idea is worth building	/leverage-predictor or /ix-sila-leverage-scoring	Structured scoring instead of a gut call.

---

Phase 2: Building

Situation	Invoke	Why
Writing or reviewing code, general standards	/code-principles-how-to-code	The harness's own coding discipline (defensive coding, no silent failures, read-before-change).
Naming a variable, function, file or skill	/how-to-name-things	Ambiguous names cause hallucination; this is the naming contract.
Creating or updating a skill file	/how-to-create-or-update-skill-files	Frontmatter format, naming rules, validation.
Building a workflow with several stages	/workflow-design or /workflow-factory	Structured multi-stage workflow authoring.

---

Phase 3: Measurement & Experiments

Situation	Invoke	Why
Building a major feature, need a plan	/feature-measurement-workflow	End-to-end: ideation → implementation → measurement, so shipping isn't the finish line.
Feature shipped, need to know if it worked	/feature-completion-ux-test	End-to-end: intended UX → conditions → execute → inspect → verify.

If you have your own experimentation platform (Statsig, PostHog, etc.) wired up, use its own skill or MCP tools for creating and reading experiments — this harness doesn't ship one.

---

Phase 4: Testing & Verification

Situation	Invoke	Why
Tests are failing, need to fix	/how-to-fix-failing-tests	Discovers the true intended UX, determines if the failure is a real bug or a stale test — not in your batch, but ships if selected.
Need to validate UX in a real browser	/devtools-site-testing	Chrome DevTools MCP workflow for real site testing.
Need Playwright-based validation with screenshot evidence	/playwright-validator	Automated browser validation.
Need to capture UX screenshots as evidence	/agent-ux-verification	Captures screenshots without silently marking verification as done.
Reasoning through what could break before you build it	/ux-pre-execution-reflection, /ux-criticality-measurement	Think through failure modes before, not after.

---

Phase 5: Wrapping Up

Situation	Invoke	Why
Ready to commit	/commit	Structured messages, staged file control, verification checklists.
Checking if session work is complete	/workload-status-check or /work-complete-audit	Validates the UX gap, confirmations, and file audit before handoff.
Summarizing what you finished	/communicate-what-you-finished	"When X, then the person sees Y because Z" format with verification evidence.
Summarizing what's left incomplete	/whats-left	Plain-language status for the person, no technical jargon, no silent gaps.
Logging a durable learning from this session	If agent-swarm memory (or your own memory store) is set up, /log-new-mems-in-swarm. Otherwise, write it to the folder alignment-harness records notes prints and say where you put it.	A learning that isn't written down doesn't survive to the next session.
Proposing changes for human review	/how-to-submit-and-track-proposals	Formal proposal with linked intents and a stated confidence.

---

Phase 6: Documentation & Registry

Situation	Invoke	Why
Writing a new intent for the Intent DB	/intent-db (write mode)	UX-centric format; state your certainty, don't assert a guess as settled.
Writing a meta-analysis / deep audit doc	/how-to-write-meta-analysis-docs	Storage and formatting for investigation reports.
Naming or renaming a tool, file, or skill	/how-to-name-things	Same naming contract as Phase 2 — the contract applies everywhere, not just to code.

---

Specialized Workflows

Situation	Invoke	Why
Contributing to an upstream/open-source repo	/contribute	Atomic commits, respectful credit, minimal token budget.
Isolating work on a feature branch	/worktree-pr-workflow	Work done in a worktree, needs a PR.
Fixing an assumption cascade or multi-agent misalignment	/agentic-alignment-optimization	Diagnoses and fixes compounding hallucination between agents.

---

Optional Integrations (only if you have them)

These require ToolSearch before use, and only apply if you've connected the underlying service — none of them are required for the harness to work:

Tool	When to use
mcp__agent-swarm__agent_find	Institutional-memory search, if you've set up the agent-swarm MCP server.
mcp__agent-swarm__add_memory / retrieve_memories	Save or recall a learning, if agent-swarm memory is configured.
mcp__chrome-devtools__*	Browser automation for UX testing.
mcp__statsig__*, mcp__canny__*	Experiment/feature-flag management and feature-request boards, if you use those products.

If a tool listed here isn't connected, skip that row rather than guessing at a call that will fail — say plainly that the integration isn't set up.

---

Standing Rules (Always Active)

These aren't skills — they're the harness's own constraints, general enough to apply to any codebase:

1. Score first, then build — /governer before non-trivial work; the coding gate waits for a score.
2. State your understanding before acting — the coherence check at the top of every reply.
3. Read the real code before changing it — never assume what a function does from its name or a note.
4. Search before you guess — institutional memory if it's set up, otherwise git log, docs, and past sessions.
5. Prove it before calling it done — the evidence gate: run the check, show the output.
6. Keep files a manageable size — split a file that's grown past what one person can hold in their head; the plugin's own scripts split large modules once they cross a few hundred lines.
7. Commit only what the person's own rules allow — see /governer's commit table.