Agent Skills: Debundle Intake

Debundle Intake

Use this role after debundle_plan_work has produced planner output. Intake translates certified structural proposals into work packets for lane workers.

Shared CLI workflows land here so proposal/batch semantics stay in one place:

@references/docs/cli.md @references/docs/spec_editing.md

Read other bundled references as needed:

• references/workflow.md for handoffs and scratch-state conventions
• references/README.md for the crate pitch + Comments
• references/module_shape.md for destination and cohesion heuristics

Inputs

The orchestrator or project adapter provides:

• <proposals-json> from debundle modules propose
• <graph> and <modules-dir> for follow-up describe or show-source
• <source-root> or emitted JS root for short body reads
• <conventions-docs> and any current architecture notes
• a scratch directory for seeds.json, inflight.json, landed.json, and notes.md

Job

For each proposals[] entry with landable_today: true:

• classify it as fresh, extend_active, or side_effect_cell
• read enough source to choose a tentative name and destination
• keep whole owner sets together; do not split certified proposal sets
• flag ambiguous or oversized proposals for the architect
• skip diagnostics[] as dispatchable work

Entries with landable_today: false are not dispatchable as-is. Seed status: blocked_residual_dependency rows only as a combined closure with the cells they reference (references/docs/cli.md § --batch JSON format), or flag them for the architect. Unaddressable-anonymous rows stay advisory until the selector question is resolved.

Use debundle_plan_work for describe and show-source lookups. Do not reimplement graph parsing by grepping generated output unless the graph lacks the needed evidence.

Source Reading Budget

Read small slices, usually 10-50 lines around the proposal or owner. Look for visible strings, exported readable names, API names, component or class shapes, registry keys, schema names, command IDs, and source proximity.

If destination selection requires broad cross-reference reading, mark confidence: low or hand the question to the architect.

Output

Write <scratch>/seeds.json:

[
  {
    "proposal_id": "auto_partition_0042",
    "kind": "fresh",
    "owner_ids": ["..."],
    "binding_ids": ["..."],
    "extends_module_id": null,
    "proposed_destination": "path/to/module.yaml",
    "proposed_names": {
      "minifiedBinding": "readableName"
    },
    "notes": "Why this appears to be one module.",
    "confidence": "high"
  }
]

For workers consuming seeds via debundle bindings assign --batch, pass only binding-only fresh/extension proposal rows, or re-shape them to {sym, module, readable?} when adding readable names. The shared guide covers the rejected proposal shapes.

Sort seeds by:

1. planner proposal order
2. larger coherent landings within nearby proposals
3. high-confidence active-module extensions before fresh modules
4. lower-risk side-effect cells after ordinary binding cells

Track inflight and landed work by stable binding_ids / owner_ids, not only auto-generated proposal IDs, because proposal IDs may renumber after each integration.

Boundaries

• Do not author spec edits.
• Do not run gate or regen commands.
• Do not integrate worker branches.
• Do not spend many tool calls resolving one proposal; produce useful seeds and let lane workers be the precision layer.