Ingest

<skill id="ingest">

<purpose>
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:

1. live verified repository state
2. explicit current user instruction
3. handoff or checkpoint manifest
4. chronicle
5. inferred conversation history

   </purpose>

<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/  # check prior work

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>

<step id="1_classify">
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). </step>

<branch after="classify">
  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)
</branch>

<step id="1b_manifest_resume" trigger="classify.type == resume">
  Resume from a kernel.handoff/v1 or kernel.checkpoint/v1 manifest. The runtime CLI:
  `KM="${CLAUDE_PLUGIN_ROOT:-.}/orchestration/manifest/kernel-manifest"`

1. Discover: explicit path if the user gave one, else:

   "$KM" latest        # newest across _meta/checkpoints/ + _meta/handoffs/

   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.

2. Validate — a manifest that does not validate is not resumed:

   "$KM" validate <manifest>     # exit 2 (no parser) on a sealed manifest = STOP

3. 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.

4. Preflight: run "$KM" preflight <manifest>. Canonical state permits only typed current-branch, path-exists, and allowlisted argv checks; raw shell is invalid.

5. 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.

6. 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.

7. Resume at the declared position:

   "$KM" resume <manifest>    # entry_phase / entrypoint / next_operation

   Skip inherited phases (already verified by divergence), execute required ones. Honor execution.stop_conditions and emit checkpoints at execution.checkpoints.

8. Complete: when outputs.required are verified,

   "$KM" deactivate --receipt _meta/reports/receipt-{date}.json

   Deactivate projects the receipt into AgentDB's observational context graph (shadow telemetry). Then outputs.completion (usually agentdb write-end), which records session outcome on that graph row when did/blocked are present.

Optional advisory (never auto-loads): bash agentdb graph-suggest {task_type}

Output: "Resuming {manifest}: {goal}. Entry: {entry_phase}. Receipt: {total_estimated_tokens} tokens ({status})." </step>

<step id="2_research" mandatory="true">
**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)

<substeps>
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)
</substeps>

<format>
# {Topic} Research
## Anti-Patterns
1. {pattern}: {why} → {fix}
## Proven Solution
- package: {name}@{version}
## Sources
- {urls}
</format>

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> </step>

<step id="3_scope">
files:
  1: {path} - {what changes}
count: N
tier: 1|2|3

<tiers>
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.
</tiers>

<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}