Explore Docs

Workflow / 06

Make the work explicit.

Planning translates a request into a bounded set of responsibilities, dependencies, and expected outcomes.

On this page
  1. Begin with the intended outcome
  2. Put dependencies and limits in the plan
  3. Read the rules before authoring
  4. What leaves planning

Begin with the intended outcome

The first job is to preserve the meaning of the request. Investigating a system, explaining a concept, and authoring a specification are different kinds of work. A plan should identify what must be learned or produced without quietly granting extra authority.

The benefit is a reviewable starting point. An evaluator can see what the system intends to do and whether that work addresses the request.

SpecKit 018 · AC-018-005-01 · AC-018-005-03

Put dependencies and limits in the plan

A Merlin plan is a list of tasks. Each task carries a short key, its text and a step kind, and the plan’s routing hints name each task’s dependencies by key. A dependency on a key the plan does not declare is refused by name, before any work starts. Dependencies determine whether downstream work can proceed.

This makes the plan more than a numbered paragraph. Its structure gives the runtime something to enforce. The model can help propose the plan, but a dependent task cannot assume a missing result into existence.

SpecKit 008 · AC-008-002-14 · SpecKit 002 · AC-002-009-08 · SpecKit 009 · AC-009-005-01

Read the rules before authoring

For specification authoring, Merlin’s requirements call for reading the repository’s applicable governance and existing artifacts. Existing implementation is evidence of current behavior, not automatic authority for what the product should do.

This prevents an important category error: documenting a defect as intended behavior merely because it already exists. The desired result is an artifact that respects ownership and exposes unresolved decisions.

SpecKit 018 · AC-018-002-01 · AC-018-002-02 · AC-018-002-04

What leaves planning

A useful handoff identifies the work, its dependencies, and the evidence or artifacts it needs. Analysis receives questions to investigate; authorized authoring receives defined outputs and constraints.

A plan remains a plan. Its presence is not proof of coverage, and its acceptance does not mean the work has happened. Those claims must be earned in the following stages.

SpecKit 008 · AC-008-002-14 · SpecKit 018 · AC-018-004-04

Discuss a workflow or deployment. Contact RLM-Labs.ai →