Explore Docs

Workflow / 08

Turn intent into checked work.

Authorized changes and artifacts pass through a controlled execution lifecycle. Creating something and proving what was created are separate responsibilities.

On this page
  1. Start with authority and scope
  2. Produce the intended artifact
  3. Stage and verify workspace changes
  4. Hand over facts about the work

Start with authority and scope

An authoring recipe can describe a procedure. It cannot grant itself permission to change a workspace. The original request, the task’s scope, and the execution controls govern what is allowed.

This matters because the same subject can invite very different actions. “Explain how to write a specification” is not the same request as “write the specification.” Merlin’s contract preserves that distinction.

SpecKit 018 · AC-018-001-02 · AC-018-005-03

Produce the intended artifact

Artifact authoring follows the relevant repository’s rules and structure. For a SpecKit, that means a coherent set of requirements, plan, data model, and tasks, with additional research or contracts where the work calls for them.

The benefit is an output that can be used and reviewed, rather than a conversation that merely describes the intended output. Creating those files still does not mean the implementation they describe has been built.

SpecKit 018 · AC-018-003-01 · AC-018-003-02 · AC-018-003-03 · AC-018-004-04

Stage and verify workspace changes

Workspace writes enter a staged lifecycle with required verification before completion. A failed check is an outcome to handle, not a sentence to edit out of the final response.

Staging creates a boundary around proposed changes. Verification supplies evidence about the result. The scope of each check matters: reading back a document can support a claim about its contents; it cannot establish that an entire application builds.

SpecKit 003 · AC-003-002-01 · AC-003-003-01 · AC-003-005-01 · SpecKit 004 · AC-004-004-02

Hand over facts about the work

The next stage needs to know what was actually produced, which checks ran, and what remains unresolved. A model’s statement that it completed a change is not the same as recorded evidence of that change.

The intended benefit is an accountable handoff: a reviewer can distinguish proposals, completed work, and verification results. This is especially valuable when part of a larger request succeeds and another part remains blocked.

SpecKit 004 · AC-004-004-01 · AC-004-004-02 · AC-004-004-03

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