| name | ingest |
| description | Unified entry point for new AND resumed work. Research → classify → scope → execute for new tasks; manifest validate → divergence check → bounded context compile → resume for kernel.handoff/v1 / kernel.checkpoint/v1 manifests. Triggers: start, begin, do, implement, build, fix, create, resume, continue. |
| user-invocable | true |
| allowed-tools | Read, Bash, Grep, Glob, Task, WebSearch, WebFetch |
| kernel | {"kind":"workflow","version":1,"side_effects":"writes_repo","confirmation":"none","consumes":["kernel.handoff/v1","kernel.checkpoint/v1"]} |
Unified entry for new and resumed work.
New task: READ → CLASSIFY → RESEARCH → SCOPE → TESTS → EXECUTE → LEARN (human confirms each phase).
Resume: DISCOVER → VALIDATE → DIVERGENCE → COMPILE (bounded context + receipt) → RESUME AT PHASE.
For autonomous loop: /kernel:forge
Authority order (highest wins) — a manifest is a map, not the territory:
- live verified repository state
- explicit current user instruction
- handoff or checkpoint manifest
- chronicle
- inferred conversation history
<skill_load>
always: skills/debug/SKILL.md
on_classify:
bug: skills/debug/SKILL.md
feature: skills/build/SKILL.md, skills/architecture/SKILL.md
refactor: skills/architecture/SKILL.md
review: skills/review/SKILL.md
on_domain:
frontend: skills/frontend/SKILL.md
app: skills/app-dev/SKILL.md
on_tier:
2+: skills/orchestration/SKILL.md
reference: skills/build/reference/build-research.md
</skill_load>
<on_start>
agentdb read-start
ls _meta/research/
Load /kernel:quality, /kernel:testing, /kernel:git immediately.
After classify: load task-specific skills above. Do NOT proceed without loading them.
After scope: if tier 2+, load /kernel:orchestration.
If any domain detected (API, auth, frontend, backend): load domain skills.
</on_start>
task: what user wants (one sentence)
type: bug|feature|refactor|question|verify|resume|review
familiar: yes|no
Search before asking: Glob, Grep, common paths.
<ask_user>
Use AskUserQuestion when: classification is ambiguous (could be bug or feature, refactor or rewrite)
Ask: "This looks like {type_A} but could be {type_B}. Which framing fits your intent?"
Options: type_A, type_B, or clarify
</ask_user>
After classify: load matching workflow from workflows/{type}.md if it exists.
Workflow steps guide the phase sequence. Human confirms at each step (ingest mode).
IF type == resume (or a manifest path was supplied) → go to MANIFEST RESUME (below)
IF familiar AND tier_likely_1 → skip to step 3 (scope), mark research="skipped (familiar)"
IF unfamiliar OR complex → proceed to step 2 (research)
ALWAYS: check _meta/research/ cache regardless (cache != full research)
Resume from a kernel.handoff/v1 or kernel.checkpoint/v1 manifest. The runtime CLI:
`KM="${CLAUDE_PLUGIN_ROOT:-.}/orchestration/manifest/kernel-manifest"`
-
Discover: explicit path if the user gave one, else:
"$KM" latest
Legacy markdown handoffs (_meta/handoffs/*.md) remain readable this release:
parse goal/decisions/next-steps from prose, note "legacy handoff (deprecated,
no validation/divergence/budget)" and suggest regenerating as JSON. Removal
path: docs/MIGRATION-8.md.
-
Validate — a manifest that does not validate is not resumed:
"$KM" validate <manifest>
-
Divergence — live state wins over manifest claims:
"$KM" divergence <manifest> --json
Typed divergence events apply workflow.invalidation_rules[].when and return
recalculated phase statuses. Never trust an inherited phase whose inputs changed.
-
Preflight: run "$KM" preflight <manifest>. Canonical state permits only typed
current-branch, path-exists, and allowlisted argv checks; raw shell is invalid.
-
Compile bounded context — read the bundle, not the raw tree:
"$KM" compile <manifest> --bundle-out /tmp/resume-bundle.md --receipt-out _meta/reports/receipt-{date}.json
The receipt (kernel.context-receipt/v1) reports estimated tokens per layer and
status: within_budget → proceed · target_exceeded → drop optional selectors,
proceed with a note · maximum_exceeded (exit 3) → STOP, report the receipt,
ask before loading anything.
-
Activate the policy (arms the guard-context hook for sealed/bounded):
"$KM" activate <manifest>
sealed: forbidden globs are hook-BLOCKED; do not fight the hook — amend the
manifest if access is genuinely needed. bounded: extra loads are allowed but
ledgered; justify each in the receipt's loads_beyond_manifest.
-
Optional advisory (never auto-loads):
bash agentdb graph-suggest {task_type}
Output: "Resuming {manifest}: {goal}. Entry: {entry_phase}. Receipt: {total_estimated_tokens} tokens ({status})."
**RULE: Research without verification is theory fiction.** Every research finding must be verified
with a minimal test, prototype, or proof before it drives implementation. 8 research agents and
6 docs mean nothing if nobody built a test to prove the approach works. (LRN-F11)
1. Check existing: ls _meta/research/, agentdb query
2. anti_patterns FIRST: "{tech} not working", "{tech} gotchas"
3. Solutions: official docs, GitHub issues, Stack Overflow
4. Built-in check: framework > stdlib > npm package
5. **Verify**: build minimal proof (test screen, script, unit test) before committing to approach
6. Write to: _meta/research/{topic}.md (include verification result)
# {Topic} Research
## Anti-Patterns
1. {pattern}: {why} → {fix}
## Proven Solution
- package: {name}@{version}
## Sources
- {urls}
tier 2+: spawn kernel:researcher
<ask_user>
Use AskUserQuestion when: research reveals multiple viable approaches or unknown risks
Ask: "Research found {N} approaches. Proceed with {recommended}, or explore alternatives?"
Options: proceed, explore alternatives, skip research
</ask_user>
files:
1: {path} - {what changes}
count: N
tier: 1|2|3
1: reversible + loud if wrong → execute inline
2: persistent or moderately quiet → plan, execute inline; delegate a surgeon only for heavy file-disjoint work; verify
3: hard to undo, quiet if wrong, or wide blast radius → contract + surgeon + adversary
ambiguous: assume higher. File count is only a weak hint, never the trigger.
<ask_user>
Use AskUserQuestion when: tier classification is borderline (e.g., 2-3 files but complex coupling)
Ask: "Scoped to {N} files — tier {X}. Confirm tier, or should I treat as tier {X+1}?"
Options: confirm tier {X}, bump to tier {X+1}
When the request itself is underspecified (any GOAL/CONSTRAINTS/INPUTS/OUTPUTS/DONE-WHEN
field unknowable), run the structured interview from skills/build/SKILL.md "The
interview" BEFORE scoping: batched AskUserQuestion rounds over intent, implementation
forks, veto-risk UX, edge behavior, and tradeoffs. Bounded choices only; open-ended
direction stays prose. Answers are quoted into the spec/commission so each decision
carries its authority.
</ask_user>
IF scope reveals unknowns not covered by research → loop to step 2 with narrowed query
IF scope is clear → proceed to step 4
Define success before coding. Tests first.
skill_ref: skills/testing/SKILL.md
done_when:
- observable outcome 1
- edge case handled
evals:
code_grader: PASS/FAIL command
regression: existing tests pass
mock_boundaries_only: external APIs, DBs
edge_cases_first: null, empty, boundary, timeout
strong_assertions: specific values
Spec framing > contract framing. Execution-ready, not goal-shaped.
Specification prompts with exact code achieve 100% success across all scopes (modelmind H002/H003,
0.95 confidence). Contract framing ("achieve X under constraint Y") leaves interpretation gaps
that agents fill incorrectly.
Before handing to surgeon (tier 2+) or starting execution (tier 1), the spec must answer:
- Exact file paths: every file that will change, by absolute path
- Exact symbols: every function/class/type to add/modify/remove, by name
- Exact code snippets for non-trivial logic (not pseudocode, not "implement X")
- Exact configs/SQL/schemas: if the change touches them, paste the literal block
- Exact verification commands: how a fresh agent confirms success without asking
Litmus test: could a fresh agent in a new session execute this spec with zero follow-up
questions? If no, the spec is incomplete. Return to step 3 (scope) or step 4 (tests) and fill
the gap before proceeding.
Anti-pattern: shipping a contract that says "the surgeon will figure out X." The surgeon will
figure out X by guessing, and the guess will be wrong.
<ask_user>
Use AskUserQuestion when: the spec has a known gap and you need the user to decide which
exact path to take (rather than letting the surgeon guess).
Ask: "Spec gap at {location}: option A = {exact}, option B = {exact}. Which?"
Options: option A, option B, other
</ask_user>
1. Reference research doc
2. Write failing tests (edge cases!)
3. Implement proven pattern
4. Check Big 5: skills/quality/SKILL.md
5. Run evals → /kernel:validate before commit
6. Commit when done_when satisfied
<tier_2_plus>
rule: you do NOT write code
- /kernel:tearitapart — review plan before implementation
- agentdb contract '{"goal":"X","files":["Y"],"tier":N}'
2b. If non-local profile: _gh_create_issue with contract goal + tier label
- git checkout -b {type}/{name}
- Spawn surgeon
- Wait for checkpoint
- (tier 3) spawn adversary
- /kernel:validate → verify evals
- /kernel:review — self-review before PR
</tier_2_plus>
IF adversary rejects (tier 3) → return to execute with adversary feedback, max 3 retries
IF tests fail → /kernel:diagnose, fix, re-execute
IF blocked → checkpoint and STOP, ask human
Every task teaches. Capture or lose.
agentdb learn pattern "{what worked}" "{evidence}"
agentdb learn failure "{what broke}" "{evidence}"
Update _meta/research/ if new findings.
Suggest /kernel:retrospective if 5+ learnings accumulated since last synthesis.
Long task still running? Emit /kernel:checkpoint at natural boundaries instead of letting context accumulate (EXP-L21).
agentdb write-end '{"task":"X","tier":N,"learned":["Z"]}'
MUST run before session ends.
<output_format>
task: one sentence | type: bug|feature|refactor | tier: 1|2|3 | status: researching|scoping|testing|executing|complete
</output_format>
<hard_stops>
ask_file_location→search | code_without_research→step2 | code_without_tests→step4 | code_tier2+→surgeon | skip_agentdb→go_back
</hard_stops>