to-spec

A preserved method from https://github.com/mattpocock/skills at 3cca18b368ae, path skills/engineering/to-spec, MIT. 24 of 80 source lines differ (30%), every difference claimed by an entry of the ledger with its reason. Entries: baseline-copies-2026-09-11, pull-2026-09-11, fold-2026-09-11, series-s7-roster-2026-09-11.

  • dependency 1
  • harness 2
  • lifecycle 2
  • method 1
  • scope 1

Files

Every difference, as it stands

SKILL.md

---
---
harnesschangedbaseline-copies-2026-09-11

greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag

name: to-spec
name: "to-spec"
description: "Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed."
description: "Turn the current conversation into a spec and publish it to the initiative's spec.md under .greenline/work/: no interview, just synthesis of what you've already discussed."
disable-model-invocation: true
---
---
 
 
scopechangedfold-2026-09-11

The opening paragraph in the skill's own voice: to-spec fires when shaping is done, reads decisions.md and the research and prototype records, never shapes (a consequential gap returns to grill-with-docs, research or prototype), never slices (to-tickets does), and a settled compact change goes to implement without a spec.

to-spec fires when an initiative's shaping is done and its rulings need one synthesized document: it reads the initiative's `decisions.md` and the research and prototype records the discussion relied on, and writes the initiative's `spec.md`. It never shapes: a consequential gap in the decisions returns to grill-with-docs, or to research or prototype for the fact or the feel it needs, rather than being invented here. It never slices: to-tickets reads the finished spec. A settled compact change needs no spec and goes to implement as one ticket.
 
This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.
This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.
 
 
dependencychangedfold-2026-09-11

Upstream's tracker-and-label sentence points at a setup skill no consumer install carries (ADR 0022 retired that rename); in its place the sentence names the spec's inputs under the initiative's directory, decisions.md and the research and prototype records, with the rule to pin each consumed revision and to name a settled conversation as the source when no decisions artifact exists.

The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.
The spec's inputs are already standing in the initiative's directory under `.greenline/work/`: its `decisions.md`, and any `research/RSRCH-NNN.md` or `prototypes/PROTO-NNN.md` the discussion relied on. Read them and pin the revision of each one the spec consumes. A settled conversation can supply the intent where no decisions artifact was written; the spec then names that source and its limits.
 
 
## Process
## Process
 
 
1 unchanged lines
1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.
1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.
 
 
2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
 
 
methodchangedseries-s7-roster-2026-09-11

upstream's step 2 checks the seams with the user; greenline lets settled seams in the accepted task, the existing interfaces or a standing grant satisfy that check and asks only about a consequential unresolved seam choice, which changes when the method stops to ask Confirmed by the operator on 2026-09-11 (method-rulings.md).

Check with the user that these seams match their expectations.
Settled seams in the accepted task, the existing interfaces or a standing grant satisfy this check; ask the user only about a consequential unresolved seam choice.
 
 
lifecyclechangedfold-2026-09-11

Upstream's publish-to-tracker-and-label step becomes writing the initiative's spec.md with its frontmatter and consumes pins, status draft then complete when the inputs support it, the initiative advancing to specified, Testing Decisions recorded for tdd to inherit, lasting choices promoted to the decisions book, and WORK.md's revision rule for a meaning-changing edit; the Handoff section restates the chain to to-tickets.

3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.
3. Write the spec using the template below into the initiative's `spec.md` (frontmatter `id: INIT-NNN/SPEC`, `type: spec`, `status: draft`, and `consumes` pinning the decisions, research and prototype revisions it rests on), then set `status: complete` once those inputs support every section and advance the initiative to specified; the status is the whole triage. Its Testing Decisions are what tdd inherits when the tickets are implemented, so record them here rather than leaving them to be reopened. A choice settled here that outlives the initiative goes into the decisions book, `.greenline/DECISIONS.md`, with a reference back. A later edit that changes the spec's meaning increments its revision and reopens the tickets that consume it; an annotation alone does not.
 
 
<spec-template>
<spec-template>
 
 
50 unchanged lines
## Problem Statement
## Problem Statement
 
 
The problem that the user is facing, from the user's perspective.
The problem that the user is facing, from the user's perspective.
 
 
## Solution
## Solution
 
 
The solution to the problem, from the user's perspective.
The solution to the problem, from the user's perspective.
 
 
## User Stories
## User Stories
 
 
A LONG, numbered list of user stories. Each user story should be in the format of:
A LONG, numbered list of user stories. Each user story should be in the format of:
 
 
1. As an <actor>, I want a <feature>, so that <benefit>
1. As an <actor>, I want a <feature>, so that <benefit>
 
 
<user-story-example>
<user-story-example>
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
</user-story-example>
</user-story-example>
 
 
This list of user stories should be extremely extensive and cover all aspects of the feature.
This list of user stories should be extremely extensive and cover all aspects of the feature.
 
 
## Implementation Decisions
## Implementation Decisions
 
 
A list of implementation decisions that were made. This can include:
A list of implementation decisions that were made. This can include:
 
 
- The modules that will be built/modified
- The modules that will be built/modified
- The interfaces of those modules that will be modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Technical clarifications from the developer
- Architectural decisions
- Architectural decisions
- Schema changes
- Schema changes
- API contracts
- API contracts
- Specific interactions
- Specific interactions
 
 
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
 
 
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
 
 
## Testing Decisions
## Testing Decisions
 
 
A list of testing decisions that were made. Include:
A list of testing decisions that were made. Include:
 
 
- A description of what makes a good test (only test external behavior, not implementation details)
- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)
- Prior art for the tests (i.e. similar types of tests in the codebase)
 
 
## Out of Scope
## Out of Scope
 
 
A description of the things that are out of scope for this spec.
A description of the things that are out of scope for this spec.
 
 
## Further Notes
## Further Notes
 
 
Any further notes about the feature.
Any further notes about the feature.
 
 
</spec-template>
</spec-template>
lifecyclechangedfold-2026-09-11

Upstream's publish-to-tracker-and-label step becomes writing the initiative's spec.md with its frontmatter and consumes pins, status draft then complete when the inputs support it, the initiative advancing to specified, Testing Decisions recorded for tdd to inherit, lasting choices promoted to the decisions book, and WORK.md's revision rule for a meaning-changing edit; the Handoff section restates the chain to to-tickets.

 
## Handoff
 
Consumes: decisions.md (INIT-NNN/DEC, pinned revision); the research/RSRCH-NNN.md and prototypes/PROTO-NNN.md records it relies on (pinned revisions)
Produces: the initiative's spec.md (INIT-NNN/SPEC) with consumes pins, status draft then complete when its inputs support it; the initiative advances to specified
Next: to-tickets reads spec.md

agents/openai.yaml

harnessremoved filebaseline-copies-2026-09-11

the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected

interface:
display_name: "To Spec"
short_description: "Turn a conversation into a spec"
policy:
allow_implicit_invocation: false

The timeline

Each entry that touched this method, with the differences it claimed as they stood at its commit, read from the repository's history.

2026-09-11 baseline-copies-2026-09-11

the cutover to an edited copy (ADR 0039): the composed output written as the copy, every difference from upstream claimed with the reason of the overlay that produced it

SKILL.md

harnesschangedbaseline-copies-2026-09-11

greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag

name: to-spec
name: "to-spec"
description: "Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed."
description: "Turn the current conversation into a spec and publish it to the initiative's spec.md under .greenline/work/: no interview, just synthesis of what you've already discussed."
disable-model-invocation: true
lifecyclechangedbaseline-copies-2026-09-11

greenline prelude, to fold: read .greenline/WORK.md and pin consumed revisions; settled seams satisfy the confirmation step; tracker publication and triage labels are replaced by writing the initiative's spec.md

**greenline prelude: consume the decisions.** Read `.greenline/WORK.md`, the current intent, and any decisions or research the spec relies on. Pin each artifact revision actually consumed. A settled conversation can supply intent when no separate decisions artifact is needed; name that source and its limits in the spec. Resolve consequential uncertainty through the appropriate shaping or evidence method instead of inventing a decision. **Integration of steps 2 and 3:** settled seams in the accepted task, existing
interfaces or standing grant satisfy the body's confirmation step; ask only
about a consequential unresolved seam choice. The body's tracker publication
and triage-label steps are replaced by writing the initiative's `spec.md`
under WORK.md with `status: complete` when supported. This method does not
publish an issue or apply an external label.
 
dependencychangedbaseline-copies-2026-09-11

ADR 0022 retired the workspace-setup rename, so the body's tracker nudge would surface a raw upstream skill name no consumer install carries; the tracker is .greenline/work/ and the prelude already says so.

The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.
The tracker is the initiative's own directory under `.greenline/work/`, already standing; no tracker configuration precedes this step.
lifecyclechangedbaseline-copies-2026-09-11

greenline completion, to fold: write the spec under the work contract with consumes; meaning-changing revisions reopen consumers; advance the initiative to specified

 
 
## greenline completion: spec.md
 
Write the initiative's spec under the shared work contract, with its actual inputs in `consumes`, and link this planning contribution's execution account. Use the publication mapping in the prelude; the spec artifact is the durable output. Record the testing decisions reached in the method so implementation can inherit them without reopening settled choices.
 
A meaning-changing revision reopens affected consumers: reassess and repin those still valid, or mark their needed rework explicitly. An annotation alone does not change meaning. Use the decisions book defined in `.greenline/WORK.md` for lasting choices and link them. When the spec satisfies the authorized scope, advance the initiative to specified and return to the request owner for its next needed stage; preserve any explicit operator stop boundary.

agents/openai.yaml

harnessremoved filebaseline-copies-2026-09-11

the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected

interface:
display_name: "To Spec"
short_description: "Turn a conversation into a spec"
policy:
allow_implicit_invocation: false

2026-09-11 pull-2026-09-11

pin advance to 3cca18b: upstream moved with no change under the vendored paths

2026-09-11 fold-2026-09-11

The fold: the prelude and completion bookends dissolve into the body, which now opens with the skill's scope, names its inputs where upstream pointed at a setup skill, writes the spec as the initiative's spec.md at its publication step, and closes with the handoff to to-tickets.

SKILL.md

scopechangedfold-2026-09-11

The opening paragraph in the skill's own voice: to-spec fires when shaping is done, reads decisions.md and the research and prototype records, never shapes (a consequential gap returns to grill-with-docs, research or prototype), never slices (to-tickets does), and a settled compact change goes to implement without a spec.

to-spec fires when an initiative's shaping is done and its rulings need one synthesized document: it reads the initiative's `decisions.md` and the research and prototype records the discussion relied on, and writes the initiative's `spec.md`. It never shapes: a consequential gap in the decisions returns to grill-with-docs, or to research or prototype for the fact or the feel it needs, rather than being invented here. It never slices: to-tickets reads the finished spec. A settled compact change needs no spec and goes to implement as one ticket.
 
dependencychangedfold-2026-09-11

Upstream's tracker-and-label sentence points at a setup skill no consumer install carries (ADR 0022 retired that rename); in its place the sentence names the spec's inputs under the initiative's directory, decisions.md and the research and prototype records, with the rule to pin each consumed revision and to name a settled conversation as the source when no decisions artifact exists.

The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.
The spec's inputs are already standing in the initiative's directory under `.greenline/work/`: its `decisions.md`, and any `research/RSRCH-NNN.md` or `prototypes/PROTO-NNN.md` the discussion relied on. Read them and pin the revision of each one the spec consumes. A settled conversation can supply the intent where no decisions artifact was written; the spec then names that source and its limits.
methodchangedfold-2026-09-11

upstream's step 2 checks the seams with the user; greenline lets settled seams in the accepted task, the existing interfaces or a standing grant satisfy that check and asks only about a consequential unresolved seam choice, which changes when the method stops to ask

Check with the user that these seams match their expectations.
Settled seams in the accepted task, the existing interfaces or a standing grant satisfy this check; ask the user only about a consequential unresolved seam choice.
lifecyclechangedfold-2026-09-11

Upstream's publish-to-tracker-and-label step becomes writing the initiative's spec.md with its frontmatter and consumes pins, status draft then complete when the inputs support it, the initiative advancing to specified, Testing Decisions recorded for tdd to inherit, lasting choices promoted to the decisions book, and WORK.md's revision rule for a meaning-changing edit; the Handoff section restates the chain to to-tickets.

3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.
3. Write the spec using the template below into the initiative's `spec.md` (frontmatter `id: INIT-NNN/SPEC`, `type: spec`, `status: draft`, and `consumes` pinning the decisions, research and prototype revisions it rests on), then set `status: complete` once those inputs support every section and advance the initiative to specified; the status is the whole triage. Its Testing Decisions are what tdd inherits when the tickets are implemented, so record them here rather than leaving them to be reopened. A choice settled here that outlives the initiative goes into the decisions book, `.greenline/DECISIONS.md`, with a reference back. A later edit that changes the spec's meaning increments its revision and reopens the tickets that consume it; an annotation alone does not.
lifecyclechangedfold-2026-09-11

Upstream's publish-to-tracker-and-label step becomes writing the initiative's spec.md with its frontmatter and consumes pins, status draft then complete when the inputs support it, the initiative advancing to specified, Testing Decisions recorded for tdd to inherit, lasting choices promoted to the decisions book, and WORK.md's revision rule for a meaning-changing edit; the Handoff section restates the chain to to-tickets.

 
## Handoff
 
Consumes: decisions.md (INIT-NNN/DEC, pinned revision); the research/RSRCH-NNN.md and prototypes/PROTO-NNN.md records it relies on (pinned revisions)
Produces: the initiative's spec.md (INIT-NNN/SPEC) with consumes pins, status draft then complete when its inputs support it; the initiative advances to specified
Next: to-tickets reads spec.md

2026-09-11 series-s7-roster-2026-09-11

The operator's ruling on the method-class edits put to them by the S3 fold: the edit is kept and re-recorded with the ruling as its authority.

SKILL.md

methodchangedseries-s7-roster-2026-09-11

upstream's step 2 checks the seams with the user; greenline lets settled seams in the accepted task, the existing interfaces or a standing grant satisfy that check and asks only about a consequential unresolved seam choice, which changes when the method stops to ask Confirmed by the operator on 2026-09-11 (method-rulings.md).

Check with the user that these seams match their expectations.
Settled seams in the accepted task, the existing interfaces or a standing grant satisfy this check; ask the user only about a consequential unresolved seam choice.