SOE

The Evaluate-Loop coordinator for soe. Runs the BRAINSTORM → PLAN → EVALUATE_PLAN → EXECUTE → EVALUATE_EXEC → (FIX↺ | COMPLETE) state machine for a track: dispatches leaf agents, dispatches workers into isolated worktrees and applies their validated returns serially, and is the SOLE writer of .soe/tracks/{id}/state.json. Resumes crash-safely from committed state and bounds its fix/plan loops. Use when: 'run the loop', 'orchestrate', 'run the track', 'evaluate-loop', 'drive the track to completion'.

Session-model-led multi-model tiering. Use in ANY conversation (ambient) or in the pipeline to decide which model tier does which slice of work, and to delegate to the right model-pinned agent (strategist/deep-reasoner/fast-worker). The session model you selected IS the orchestrator; it self-selects its topology from its own model identity.

Use when the orchestrator needs to delegate an implementation task to an isolated worker — dispatches each worker as a Task-tool subagent in its own git worktree, awaits its return as the completion signal, and applies results serially as the sole state.json writer behind a validated context firewall

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use at run start to discover what reviewers/analyzers/generators any installed plugin provides and route work by ROLE. Builds a role→provider map via lib/capability-scan.js so the loop prefers the best-matching installed specialist (a Go reviewer, a Flutter reviewer, AgentShield, ...) and falls back to soe-core's generic (soe:code-reviewer, soe:security-reviewer, soe:architect, ...) when none is installed. soe-core is self-sufficient and NEVER hard-depends on packs.

Discover and reuse ANY installed MCP server by CAPABILITY (design §6, for MCP tools). At run start the orchestrator enumerates its available mcp__* tools and calls lib/mcp-discovery.js classifyMcpTools to build a capability map (docs/browser/graph/design/database/search/email/calendar/storage/…). When a needed capability has a discovered MCP, prefer it over doing the work manually — the four named providers (soe:using-graphify / using-codex / using-figma + chrome-devtools) take precedence when present; generic MCP discovery covers everything else. READ/analysis MCP tools auto-use + log; WRITE/irreversible MCP tools follow the confirm rule (soe:soe-modes / lib/escalation.js isIrreversible). Graceful, silent fallback to soe's native tools when no MCP matches. Registered as an optional provider by soe:capability-discovery.

Pattern for progressively refining context retrieval to solve the subagent context problem

Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Provides a comprehensive OWASP security checklist and patterns.

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Optional Figma design-source provider for spec-grounding — detected via a registered Figma MCP (its figma skill / mcp__*figma* tools like use_figma / get_design_context / authenticate). During spec creation for UI/frontend work, when the Figma MCP is available AND authenticated AND the user gave a Figma URL, reads design context (components, layout, spacing/tokens, variants, flows) READ-ONLY from that URL and grounds the design doc's UI section in the ACTUAL design instead of guessing. Three-part guard; silently skipped (no prompt, no offer) when absent OR unauthenticated OR no URL — the agent then derives the UI from intent as usual. NEVER writes to Figma (no generate-design / code-connect). Registered as an optional design-source provider by soe:capability-discovery.

Red-team a design or plan document before it is executed — the runtime critique gate (design §3.4). Hostile, from-scratch review against the quality lens (integrity, simplicity, maintainability, readability, scalability, performance, human-debuggability) + correct pattern usage. Two modes: design mode finds gaps/inconsistencies/missing pieces/pattern misuse; plan mode adds a design↔plan cross-reference (no drift, gaps, or scope creep). Output: numbered findings, then ask discuss all / some / continue. Executed by the soe:devils-advocate agent via /soe:critique, and wired into the orchestrator's EVALUATE_PLAN gate. Use when: 'red-team this', 'critique the plan/design', 'find the holes', 'adversarial review'.

Simulate a 5-lens expert board (architect, product, security, operations, experience) to evaluate a plan, architecture choice, or feature design. Two modes: a cheap collapsed board (default) and a full multi-agent board for high-stakes decisions. Triggers: 'board review', 'board meeting', 'get expert opinions', 'director evaluation', 'consensus review'.

Use when soe repeatedly escalates the same routine judgment call and you want the engine to learn the user's judgment and stop interrupting over time — WITHOUT ever auto-resolving irreversible actions. Defines the capture → instinct → pre-check → log loop: on each escalation-resolution, record {situation, decision, reasoning, principle} as a confidence-scored instinct (via soe:continuous-learning-v2); before escalating, the orchestrator pre-checks instincts via lib/escalation.js resolveViaInstinct and auto-resolves high-confidence REVERSIBLE matches, logging a 'would have escalated' note instead of interrupting. Reference from the orchestrator at the escalation point.

Specialized business logic evaluator for the Evaluate-Loop. Use this for evaluating tracks that implement core product logic — pipelines, dependency resolution, state machines, pricing/tier enforcement, packaging. Checks feature correctness against product rules, edge cases, state transitions, data flow, and user journey completeness. Dispatched by loop-execution-evaluator when track type is 'business-logic', 'generator', or 'core-feature'. Triggered by: 'evaluate logic', 'test business rules', 'verify business rules', 'check feature'.

Specialized code quality evaluator for the Evaluate-Loop. Use this for evaluating code implementation tracks where the deliverable is functional code — features, API routes, state management, utilities. Checks build integrity, type safety, code patterns, error handling, dead code, imports, test coverage, and naming conventions. Dispatched by loop-execution-evaluator when track type is 'feature', 'refactor', or 'infrastructure'. Triggered by: 'evaluate code', 'code review', 'quality check', 'build check'.

Specialized integration evaluator for the Evaluate-Loop. Use this for evaluating tracks that integrate external services — Supabase auth/DB, Stripe payments, Gemini API, third-party APIs. Checks API contracts, auth flows, data persistence, error recovery, environment config, and end-to-end flow integrity. Dispatched by loop-execution-evaluator when track type is 'integration', 'auth', 'payments', or 'api'. Triggered by: 'evaluate integration', 'test auth flow', 'check API', 'verify payments'.

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Extract learned patterns from session - invoked automatically by finishing-a-development-branch or manually anytime

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when reasoning about which pipeline gates may run unattended and which need a human. Classifies every gate as verification (checks reality — always autonomous) or judgment (needs a human call — front-loaded or escalated per soe:soe-modes). Reference from the orchestrator and any skill that decides whether to ask the human or resolve-and-log.

Turn ambiguous or high-impact product and engineering changes into scoped, verifiable acceptance criteria before or alongside implementation. Use when a user asks to clarify a feature, define acceptance criteria, de-risk a security/data/migration/integration change, prepare implementation requirements for another agent, or make a complex request testable. Do not trigger for trivial edits, straightforward fixes, active debugging, code review, or implementation requests whose acceptance conditions are already clear unless the user explicitly invokes this skill.

Minimal, idiomatic, shortest-working-code discipline for implementation. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reuse what's already in the codebase, reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Self-assessed intensity: lite, full (default), ultra. Use on ANY implementation task — writing, adding, refactoring, or fixing code. Do NOT use for review/security/audit/spec work (those stay thorough) or for documentation / human-facing prose (that follows the writing-clearly discipline).

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Scan your Claude Code configuration (.claude/ directory) for security vulnerabilities, misconfigurations, and injection risks using AgentShield. Checks CLAUDE.md, settings.json, MCP servers, hooks, and agent definitions.

Audit all installed skills, commands, agents, and hooks for quality, freshness, and duplication. Use periodically to maintain a clean plugin.

Use when configuring or reasoning about soe's interaction level — how much the engine asks vs. resolves autonomously. Defines the three modes (autonomous-guardrailed, interactive, fully-agentic) stored in .soe/config.json `mode`, and how the orchestrator applies each at judgment gates vs. verification gates. Reference from the orchestrator when deciding whether to ask the human or resolve-and-log.

Use when initializing soe in a project or when asked about the .soe/ layout, config, or the durable-vs-ephemeral commit policy. Explains what /setup scaffolds and how state is committed vs ignored.

Use when you have TWO independently-derived design docs (a human brainstorm + an autonomous codebase-derived spec) for the same goal and need to reconcile them into one canonical design. Presents a 3-way diff (AGREED / AGENT-only / HUMAN-only / CONFLICT) the human resolves, then writes the merged design. Cross-checks catch human omissions and agent hallucinations.

Use when executing implementation plans with independent tasks in the current session

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing any feature or bugfix, before writing implementation code

Register `codex-peer` — an OPTIONAL, EXPERIMENTAL "different-perspective peer" — as a discovered provider used per the soe:model-orchestration methodology for high-stakes PARALLEL SYNTHESIS (run Opus AND Codex on the same problem, merge without cross-contamination). Detected only when BOTH the `codex` CLI is on PATH AND the `openai/codex-plugin-cc` plugin is installed (lib/codex-detect.js isCodexAvailable); invoked via the official Codex plugin (`/codex:rescue --background` style, CLI-backed). ENHANCEMENT-only posture — best-effort, honest scope, SILENTLY SKIPPED when absent, and NEVER takes an irreversible/control action without the soe:soe-modes confirm rule. Registered as an optional peer-synthesis provider by soe:capability-discovery.

Use graphify (a code knowledge-graph) as a first-class OPTIONAL provider when present — detected via graphify-out/graph.json or its registered MCP server. Routes context retrieval through query_graph/get_neighbors/shortest_path instead of grep-and-read (token win), and feeds get_pr_impact/shortest_path into the risk matrix's blast-radius (lib/risk-matrix.js blastRadius). Consume-only, staleness-aware, confidence-labeled; silently falls back to native file/grep tools when graphify is absent or empty. Registered as an optional provider by soe:capability-discovery.

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

Use when you have a spec or requirements for a multi-step task, before touching code

---

A skill that only references existing targets.

A skill that exists so soe:exists resolves correctly.