Capability feasibility planning
Use this method to turn a fuzzy capability question into a small, evidence-led set of tests and a decision-ready recommendation. It is for questions where several assumptions must be tested independently, not for a simple research answer or a vendor comparison.
Host operations and boundaries
Read `references/host-operations.md` before using a host's research, agent, artifact, or version-control capability. If a requested operation is not available or authorized, return the proposed dispatch, artifact, or cleanup plan instead. Do not claim a test ran when it was only reasoned about.
Every external factual claim in a spike record or synthesis needs an inline source and a Sources section. Keep observations, assumptions, measurements, and unknowns distinct.
Six-phase workflow
1. **Intake.** Lock the decision to support, audience, scope, constraints, evidence already available, and artifact destination using `references/intake-questions.md`. Ask only for gaps that change the test or decision, then confirm the intake before proposing spikes. 2. **Candidate spikes.** Propose three to five testable plays. For each, state the capability assumption, smallest falsifiable experiment, success signal, explicit resource budget, and the single most important risk. Ask the user to select the plays that should advance to screening unless that selection is already unambiguous in their request. 3. **Risk screen.** Do a lean source check for policy, legal, safety, data, integration, or capability blockers. Mark each play as proceed, reframe, or stop, and explain why. Present the survivors and get confirmation before dispatching a spike. 4. **Dispatch.** Run independent spikes in parallel only when the host supports it and their evidence does not depend on one another. Run dependent spikes in order. Use `references/spike-template.md` and `references/subagent-dispatch.md`; record failures and thin evidence rather than smoothing them over. 5. **Synthesize.** Read every completed spike record and create a ranked synthesis using `references/synthesis-template.md`. Separate what was demonstrated from what remains a hypothesis, and state the next smallest decision or experiment. 6. **Cleanup.** Inventory temporary scaffolding separately from deliverables. Show paths, purpose, and tracked status, then wait for a fresh explicit approval before deletion. Keep deliverables and evidence needed for the decision.
At every phase boundary, summarize what was decided, the next phase, and any cost, delay, or irreversible consequence. Get the user's confirmation before advancing unless they have already supplied an equivalent decision. Tell the user when independent spikes or source collection may take material time; do not invent a duration estimate.
Output
Each spike record includes the question, assumption, smallest experiment, inputs, method, evidence, result, surprises, capability/data-path/channel blockers, reframe-or-stop decision, sources, and created artifacts. The synthesis includes a bottom line, per-spike status, ranked recommendations, prerequisites and kill-or-pivot triggers, deferred items, confidence limits, and the next action.
Quality rules
- Capture the URL for each external fact as research is gathered, cite it beside the claim and in the Sources list, and re-check the URL-to-claim pairing before finalizing a spike record or synthesis. - When a benchmark, KPI, cost, SLA, or conversion assumption informs a recommendation, record its source, date, population, and applicability; do not reuse it as a universal threshold. - Do not invent a threshold, benchmark, policy clearance, or measured result. - A simulated response is not evidence about an untested target system. - Stop or reframe when a blocker invalidates the original play. - Keep analysis separate from deployment, publication, procurement, and other external changes.