Post Research To Plan

Post Research To Plan

Purpose

Bridge the gap between "we have an idea / paper / architecture direction" and "we know what to build first, what to validate first, and how to stage execution."

This skill is for turning prior technical thinking into an actionable delivery path.

It should answer:

• what is already solid enough to build
• what is still a hypothesis
• what must be de-risked first
• what can be implemented directly
• what needs a spike or POC
• what validation depth is appropriate for each stage

Use when

Use this skill when:

• research or architecture work already exists
• the user wants a concrete plan for implementation
• the main uncertainty is no longer "what is this method?" but "how do we adopt it safely?"
• there is a risk of overbuilding before validating the key assumptions

Typical trigger phrases:

• "сделай план внедрения"
• "переведи это в план реализации"
• "что делать дальше после ресёрча"
• "разложи внедрение по этапам"
• "какие дешёвые проверки нужны сначала"
• "turn this into an implementation plan"
• "what is the rollout path from here"
• "what should we validate before building more"

Do not use when

Do not use this skill for:

• raw literature or method analysis
• architecture option comparison
• broad brainstorming
• direct coding with no planning request
• product roadmap planning
• personal planning

If the question is still "what actually works?", use a research skill first. If the architecture is not yet chosen, use architecture-options-analysis first. If the design is fixed and only a formal spec is missing, use architecture-spec-writer first.

Inputs

Expected inputs:

• prior research findings, method analysis, or architecture decision
• current repository or system context
• implementation target
• constraints that affect delivery

Optional inputs:

• prior experiment results
• unresolved technical risks
• validation constraints
• rollout constraints
• compute, latency, or cost limits
• migration constraints

Outputs

Always produce:

1. a clear separation between proven conclusions and open hypotheses
2. a phased implementation plan
3. explicit spike or POC candidates
4. per-stage validation depth
5. decision points or stop conditions where relevant
6. a written plan document in the repository when the task is substantial
7. the path to that document

Core principles

• Do not treat research conclusions as production truth without checking transferability.
• Do not waste time validating already-settled parts with oversized experiments.
• Do not build infrastructure for hypotheses that have not passed cheap tests.
• Separate "build now" from "validate first".
• Let the uncertainty shape the plan.

Constraints

• Start from real prior conclusions instead of redoing the whole analysis.
• Proven vs hypothesis separation is mandatory.
• Use cheap-first de-risking where uncertainty is still material.
• Validation depth must match the stage question.
• Define stop or pivot criteria for uncertainty-heavy stages.
• Keep the first step as the cheapest meaningful move that either reduces uncertainty or creates durable execution progress.

Procedure

1. Reconstruct the upstream reasoning. First summarize the prior work that this plan depends on:

   • research findings
   • architecture choice
   • assumptions already accepted
   • constraints already identified
   • conclusions already rejected

   The plan must start from real prior conclusions, not restart the whole analysis.

2. Separate what is proven from what is uncertain. Create three buckets:

   • Proven enough to build
   • Plausible but still hypothesis-level
   • Unknown or risky enough to block direct implementation

   Be explicit and strict here. A weak separation will cause either premature implementation or unnecessary over-validation.

3. Identify the cheapest de-risking moves. For each important uncertainty, ask:

   • can this be checked with a minimal experiment?
   • can this be checked with a synthetic or narrow input slice?
   • can this be checked with a tiny prototype?
   • can this be checked with a local benchmark or cheap integration check?

   Prefer cheap clarity over broad effort.

4. Decide where spike or POC is needed. A spike or POC is justified when:

   • a key design assumption is still unverified
   • the integration surface is unclear
   • the performance or compatibility risk is material
   • the architecture might change depending on the result

   Do not add spikes for things that are already known well enough.

5. Decide what can be implemented directly. Some parts are already sufficiently grounded and should move straight to implementation. Mark these explicitly. Good candidates:

   • stable interfaces
   • obvious wrappers or adapters
   • deterministic plumbing around a chosen design
   • well-understood infrastructure changes
   • low-risk scaffolding needed regardless of which hypothesis wins

6. Build phased execution. Break the work into isolated stages. Each stage should be one of:

   • de-risking stage
   • implementation stage
   • integration stage
   • hardening / rollout stage

   Stages should be reasonably balanced and should minimize cross-stage entanglement.

7. For each stage, specify:

   • goal
   • what it assumes
   • what it changes
   • what it deliberately does not yet do
   • what validation depth is required
   • what outcome would let the team continue
   • what outcome would invalidate or redirect the plan

8. Assign the right validation depth. Use one of three validation levels:

   Lightweight checks

   Use when the stage is mostly structural or low-risk:

   • narrow unit tests
   • smoke tests
   • type, schema, or contract checks
   • tiny local benchmark
   • focused integration sanity check

   Spike / POC validation

   Use when the point is to answer one technical uncertainty:

   • minimal prototype
   • narrow experiment
   • synthetic or sampled data
   • toy-scale performance or quality check
   • one integration seam tested end-to-end

   Fuller validation

   Use only when the decision genuinely depends on it:

   • realistic benchmark
   • broad integration test
   • production-like load or latency validation
   • rollout validation on real traffic/data
   • end-to-end behavior confirmation

   Do not escalate validation depth too early.

9. Add stage-level stop conditions. For any stage built around uncertainty, define:

   • what result is good enough to proceed
   • what result means "pivot or stop"
   • what ambiguous result requires one more bounded check

   This prevents infinite exploratory drift.

10. Write the plan document. For substantial work, create or update a repository plan document. Prefer existing repo conventions. Otherwise use:

    • PLANS.md
    • or docs/plans/<short-slug>.md

    The document should include:

    • context
    • proven vs uncertain
    • implementation stages
    • validation depth by stage
    • stage exit criteria
    • open risks / assumptions

11. End with the smallest sensible next step. The first stage should usually be the cheapest meaningful move that reduces uncertainty or creates durable execution progress. Avoid plans whose first step is broad infrastructure work unless that work is necessary regardless of later outcomes.

Decision rules

Proven-vs-hypothesis rule

If a conclusion still depends on untested assumptions in the target setting, treat it as hypothesis-level, not as settled.

Cheap-first rule

Before building large machinery, ask whether one small experiment or narrow integration check could remove the main uncertainty.

Direct-build rule

If a part is already well justified and low-risk, build it directly instead of forcing unnecessary prototyping.

Validation-depth rule

Use the lightest validation that can credibly answer the stage question.

Stage-isolation rule

Each stage should create either:

• a resolved uncertainty
• a usable implementation increment
• a safer rollout position

If a stage does none of these, it is probably poorly designed.

Kill-criteria rule

For uncertainty-heavy stages, define what result would invalidate the current path.

Minimality rule

Do not expand the plan with speculative infrastructure, future-proofing, or broad hardening before the critical assumptions are tested.

Optional subagent use

For larger or ambiguous transitions, explicitly spawn bounded subagents before finalizing the plan:

• one subagent to extract proven findings vs open hypotheses from the research/spec material
• one subagent to identify the cheapest validation surfaces
• one subagent to inspect implementation touchpoints in the current codebase

Wait for the memos, then synthesize the final staged plan. Do not spawn subagents for a small, already-clear transition.

References

Use the supporting references when needed:

• references/proven-vs-hypothesis-checklist.md
• references/validation-depth-matrix.md
• references/staged-adoption-plan-template.md

Definition of done

• Proven enough vs hypothesis-level is explicit.
• The plan distinguishes build-now work from validate-first work.
• Stages are isolated and evidence-aware.
• Validation depth is chosen deliberately per stage.
• Stop or pivot criteria exist for uncertainty-heavy stages.
• The first next step is cheap and meaningful.

Final response format

Return the result in this structure:

• Plan document: <path> (if written)
• Context
• Proven enough to build
• Still hypothesis-level
• Open risks / unknowns
• Stages:
  1. Stage name
     • goal
     • scope
     • validation depth
     • success criteria
     • stop / pivot criteria
  2. ...
• First recommended next step

Positive examples

Use this skill for:

• "переведи ресёрч в план внедрения"
• "после этого анализа нужен план"
• "разложи реализацию с учётом неизвестных"
• "что сначала проверить, а что можно сразу строить"
• "turn this research into an execution plan"
• "what is the staged adoption path from here"

Negative examples

Do not use this skill for:

• "разбери paper"
• "сравни варианты архитектуры"
• "напиши design doc"
• "сделай roadmap"
• "почини баг"