Help us improve
Share bugs, ideas, or general feedback.
From epic
Routes context signals to matching skills (tdd, debug, secure, etc.) for automation. Always active; runs confusion protocol on ambiguity.
npx claudepluginhub epicsagas/epic-harness --plugin epic-harnessHow this skill is triggered — by the user, by Claude, or both
Slash command
/epic:_dispatchThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**CRITICAL**: When accessing harness data, run `HARNESS_DIR=$(epic path)` first. NEVER use `.harness/` in the project directory.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
CRITICAL: When accessing harness data, run HARNESS_DIR=$(epic path) first. NEVER use .harness/ in the project directory.
You have access to the following skills. Invoke the matching skill BEFORE responding or taking action. Even a 1% chance of relevance means you should invoke it.
| Context Signal | Invoke Skill |
|---|---|
| New feature implementation starting | tdd |
| Test failure, error, or unexpected behavior | debug |
| Auth, DB, API, infra, or secrets code touched | secure |
| Loops, queries, rendering, or data processing code | perf |
| File > 200 lines or high cyclomatic complexity | simplify |
| Public API/function added or changed | document |
| Before completing /go or /ship | verify |
| User wants to commit changes | commit |
| Context window > 70% used | context |
| User request is vague, unfocused, or presents a solution without a clear problem | discover |
| User shares code for review, mentions code smells, or asks to refactor/analyze | episteme → analyze_code + suggest_refactorings → feed results into go:plan mode |
User invokes /reflect, asks about AI usage quality, "am I using AI well", "thought amplifier", or requests AI usage self-assessment | reflect |
| Session start (project has psychographic node in memory) | Run epic mem list --type psychographic → apply 5-dimension profile to all subsequent skill dispatch |
Orchestration run active ($HARNESS_DIR/orchestrator/run.json exists with status "running") | orchestrate |
| Agent tool output received with inter-agent message | orchestrate |
User runs /intervene | orchestrate |
| 요구사항 정의 필요, 스펙 없음 | spec |
| 빌드/구현 시작, 스펙 승인됨 | go |
| 리뷰/감사/테스트 필요 | audit |
| PR 생성 / CI / 배포 준비 | ship |
Users can still type legacy command names. Map them:
/spec → invoke skill spec directly/go → invoke skill go directly/audit → invoke skill audit directly/check → invoke skill audit directly (legacy alias)/ship → invoke skill ship directly/discover → invoke skill discover directly/intervene → invoke skill orchestrate (intervene mode)/status → invoke skill orchestrate (status mode)When a phase completes, prompt the user toward the next step. Do NOT auto-proceed — surface the transition explicitly.
| Phase completed | Condition | Prompt to user |
|---|---|---|
/discover problem framed | status: framed written | "Problem defined. Run /spec to turn this into a buildable specification." |
/spec saved | status: approved written | "Spec saved. Run /go to start building." |
/go report done | All tasks complete, tests green | "Build complete. Run /audit to verify before shipping." |
/audit report done | All PASS + all AC verified | "Audit passed. Run /ship to create a PR." |
/audit report done | Any FAIL or AC missing | "Fix blockers with /go, then re-run /audit." |
/ship report done | PR created, CI green | "Shipped. Loop complete." |
/orbit phase done | Pipeline status: running | "(orbit) Phase complete. Continuing to next phase..." |
/orbit audit FAIL × 3 | audit_fail_count >= max_retries | "(orbit) 3 audit failures reached. Pausing for your input." |
/orbit complete | PR created, CI green | "(orbit) Pipeline complete. See consolidated report above." |
/intervene executed | Control directive written | "Intervention recorded. Use /status to monitor." |
These transitions are informational nudges only. The user controls when each phase runs.
When /orbit is active (detected by: $HARNESS_DIR/orbit/PIPELINE-*.json exists with status: running):
/go", "Run /audit", "Run /ship", etc.) — orbit handles its own phase transitions internallysuggest_refactorings output is present in context before /orbit starts, pass it directly to go:plan as spec material — auto-detect direct modestatus: complete or status: aborted) — resume normal dispatch behaviorOrbit Recovery on Session Resume: When a session resumes (after context compaction or crash) and an active pipeline is detected:
"(orbit) Recovering pipeline {id}. Phase: {phase}. Branch: {branch}."mode fieldspec_file fieldphase as documented in the pipeline statephase is auto_detect with no mode set, run auto-detection logic (PRD present → council, clear request → direct, vague → council) and proceed without askingThe orbit command is a self-contained pipeline. Interjecting normal transition nudges during orbit would confuse the user.
When you encounter high-risk ambiguity, you MUST stop and present options instead of guessing.
High-risk ambiguity triggers:
Protocol:
Example:
AMBIGUITY: You asked to "fix the auth flow" but this could mean: A) Fix the token refresh bug in the existing JWT flow (surgical, 30 min) B) Migrate from JWT to session-based auth (architectural, 2 days) C) Add MFA to the existing flow (additive, 1 day) Which approach do you want?
NEVER guess the scope of an ambiguous request. 2 minutes of clarification saves 2 hours of rework.
If a user says "skip tests", respect that. Skills guide, users decide.
Every skill invocation must be logged for evolution analysis. After selecting skills to invoke, record the dispatch event:
$HARNESS_DIR/dispatch/dispatch_YYYYMMDD.jsonl if it doesn't exist{ "timestamp": "<ISO>", "trigger_signal": "<signal>", "selected_skills": ["<skill1>", ...], "context_hint": "<why>" }This enables Ring 3 to analyze which skills fire most often, which are effective, and tune dispatch rules accordingly.
Before invoking any skill, proactively recall relevant knowledge from the memory graph:
epic mem recall "TASK_HINT" with a hint describing the current task (e.g., "auth refactor", "CI pipeline fix"). This returns relevance-ranked memories combining FTS match, importance, recency, access frequency, and graph connectivity.epic mem recall "ERROR_CATEGORY" with the error category/message as hint. Past resolutions and patterns for similar errors surface automatically.epic mem recall "DOMAIN_AREA" with the domain area. Past decision nodes (importance=0.9) rank highest and prevent contradictory choices.epic mem add --title "TITLE" --type resolution --body "BODY" (auto-importance=0.8) or --type decision (auto-importance=0.9). These high-importance nodes persist across sessions and resist decay.mem recall is unavailable, use epic mem search "KEYWORD" (keyword FTS) or epic mem context --project PROJ (project-scoped smart recall).Memory scoring: recency(25%) + importance(35%) + access_freq(15%) + FTS_match(25%). Frequently accessed and important memories naturally float to the top; unused noise decays over time.
This enables cross-session learning: the agent remembers past mistakes, decisions, and solutions — and retrieves the most relevant ones for the current context.
Check $HARNESS_DIR/evolved/ for project-specific auto-evolved skills. These are generated by the Ring 3 evolution loop based on actual failure patterns.
$HARNESS_DIR/evolved/ — each is a skillSKILL.md file's YAML frontmatter description fieldevo-{pattern_type} — from failure pattern detection (e.g., evo-fix_then_break, evo-repeated_same_error)evo-{tool}-discipline — from weak tool category (e.g., evo-bash-discipline)evo-{ext}-care — from weak file type (e.g., evo-ts-care)evo-fix-{error} — from high-frequency error (e.g., evo-fix-build-fail)When user preference data is available via epic mem list --type psychographic, adapt dispatch behavior:
| Dimension | Values | Effect on dispatch |
|---|---|---|
scope_appetite | conservative / moderate / ambitious | conservative: smaller, safer changes. ambitious: larger refactors allowed |
risk_tolerance | cautious / balanced / bold | cautious: more verification steps. bold: fewer checkpoints |
detail_preference | brief / standard / thorough | brief: minimal output. thorough: detailed explanations |
autonomy | guided / collaborative / independent | guided: ask before each step. independent: execute autonomously |
architecture_care | pragmatic / balanced / principled | pragmatic: working > elegant. principled: patterns > shortcuts |
epic mem list --type psychographic to load profilescope_appetite=conservative: Prefer simplify skill. Flag changes touching >3 files.
risk_tolerance=cautious: Run verify after every skill. Add extra test runs.
detail_preference=brief: Skip explanatory output. Show only results and blockers.
autonomy=guided: Present plan before execution. Ask at each decision point.
architecture_care=principled: Trigger council skill for architectural decisions. Enforce pattern compliance.
Store profiles using epic mem add with:
$HARNESS_DIR/dispatch/dispatch_YYYYMMDD.jsonl$HARNESS_DIR/evolved/ for project-specific skills that supplement static skills| Excuse | Rebuttal | What to do instead |
|---|---|---|
| "I'll invoke skills after responding" | Skills must run BEFORE action to prevent mistakes | Always dispatch first, respond second |
| "The skill isn't relevant enough" | Even 1% relevance means invoke it | Err on the side of invoking; skills are cheap |
| "I can skip the confusion protocol" | Wrong guesses cause hours of rework | Stop and present options on ambiguity |
| "Evolved skills override static ones" | Static skills are authoritative | Static > evolved; evolved only supplements |
$HARNESS_DIR/dispatch/dispatch_YYYYMMDD.jsonl