Skip to main content
Spec 1.0: This example uses the current stable portable core release.
Use this when adding net-new behavior to an existing project.

​
Goal

Define the feature boundary clearly enough that implementation stays inside it.
  1. Write or update the subject spec before coding.
  2. Define the feature in requirements, not just prose.
  3. Add scenarios for the important cases and boundaries.
  4. Point verification at the tests or commands that should prove it.
  5. Implement only what the spec calls for.
  6. Update docs in the same change when the feature is user-facing.
  7. Run the local verification and strict check commands before merge.

​
Prompt you can give an agent

Work on one new feature slice only.

Write or update the subject spec first.
State the feature in requirements, add scenarios for the important boundaries, and point at the proof that should verify it.
Implement only what the current-truth spec calls for.
Do not widen the feature without changing the spec.

​
Why this matters

New feature work is where scope drift often starts. That gets worse when agents can generate extra behavior quickly. The spec gives the team a simple question to ask: Does this change implement the intended effect, or is it inventing more than we asked for?

​
What to keep explicit

  • what the feature is
  • what the feature is not
  • what counts as done
  • what evidence should prove it
One good first example is a single user-visible workflow step, not the whole feature family.

​
Avoid

  • vague requirements like “support the new workflow”
  • mixing feature delivery with unrelated cleanup
  • adding extra behavior just because the implementation made it easy
  • leaving docs and verification behind the code

​
Good outcome

The feature pass is strong when:
  • the new behavior is explicit in the spec
  • the tests and docs line up with that behavior
  • the verification loop passes
  • reviewers can see the intended boundary without reconstructing it from code alone