to-tickets

A preserved method from https://github.com/mattpocock/skills at 3cca18b368ae, path skills/engineering/to-tickets, MIT. 79 of 110 source lines differ (72%), 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, fold-walk-2026-09-11.

  • harness 2
  • lifecycle 9
  • location 5
  • scope 1
  • vocabulary 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-tickets
name: "to-tickets"
description: Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).
description: "Break a plan, spec, or the current conversation into a set of tracer-bullet ticket files in .greenline/work/tickets/, each declaring its blocking edges as depends_on ids."
disable-model-invocation: true
---
---
 
 
# To Tickets
# To Tickets
 
 
scopechangedfold-2026-09-11

The opening paragraph in the skill's own voice: to-tickets fires when the plan is settled in spec.md or decisions.md, never shapes or specifies (a gap returns to grill-with-docs or to-spec), never implements (implement takes the ready frontier), and a settled compact change is one ticket while wayfinder's decision tickets are not the tickets written here.

to-tickets fires when an initiative's plan is settled, in its `spec.md` or, for an initiative that went from shaping straight to slicing, its `decisions.md`, and the work needs cutting into delivery tickets under `.greenline/work/tickets/`. It never shapes or specifies: a consequential gap in the plan returns to grill-with-docs or to-spec rather than being sliced around. It never implements: implement takes each ticket from the ready frontier. A settled compact change is one ticket and needs no slicing pass; wayfinder's decision tickets are questions in the initiative's `map.md`, not the tickets written here.
 
Break a plan, spec, or conversation into a set of **tickets**: tracer-bullet vertical slices, each declaring the tickets that **block** it.
Break a plan, spec, or conversation into a set of **tickets**: tracer-bullet vertical slices, each declaring the tickets that **block** it.
 
 
lifecyclechangedfold-walk-2026-09-11

the plan is the initiative's spec.md or decisions.md, or the conversation when neither was written; a settled compact change is implement's one ticket, so this skill never writes it

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 plan is the initiative's `spec.md`, or its `decisions.md` when no spec was written; read it whole and pin the revision the tickets consume. A conversation can supply the plan when no spec or decisions record was written; name that source in the tickets and pin nothing. A settled compact change is implement's one ticket, not a slicing pass.
 
 
## Process
## Process
 
 
### 1. Gather context
### 1. Gather context
 
 
vocabularychangedfold-2026-09-11

A reference the user passes is a greenline artifact, a spec path, an initiative id or a ticket id read whole, not an issue number or URL with comments; the term names a greenline artifact, which is the one case a vocabulary edit covers.

Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.
Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an initiative id or a ticket id) as an argument, read it whole.
 
 
### 2. Explore the codebase (optional)
### 2. Explore the codebase (optional)
 
 
34 unchanged lines
If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
 
 
Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
 
 
### 3. Draft vertical slices
### 3. Draft vertical slices
 
 
Break the work into **tracer bullet** tickets.
Break the work into **tracer bullet** tickets.
 
 
<vertical-slice-rules>
<vertical-slice-rules>
 
 
- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests): vertical, NOT a horizontal slice of one layer
- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests): vertical, NOT a horizontal slice of one layer
- A completed slice is demoable or verifiable on its own
- A completed slice is demoable or verifiable on its own
- Each slice is sized to fit in a single fresh context window
- Each slice is sized to fit in a single fresh context window
- Any prefactoring should be done first
- Any prefactoring should be done first
 
 
</vertical-slice-rules>
</vertical-slice-rules>
 
 
Give each ticket its **blocking edges**: the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
Give each ticket its **blocking edges**: the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
 
 
**Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change (rename a column, retype a shared symbol) whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket; green is promised only there.
**Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change (rename a column, retype a shared symbol) whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket; green is promised only there.
 
 
### 4. Quiz the user
### 4. Quiz the user
 
 
Present the proposed breakdown as a numbered list. For each ticket, show:
Present the proposed breakdown as a numbered list. For each ticket, show:
 
 
- **Title**: short descriptive name
- **Title**: short descriptive name
- **Blocked by**: which other tickets (if any) must complete first
- **Blocked by**: which other tickets (if any) must complete first
- **What it delivers**: the end-to-end behaviour this ticket makes work
- **What it delivers**: the end-to-end behaviour this ticket makes work
 
 
Ask the user:
Ask the user:
 
 
- Does the granularity feel right? (too coarse / too fine)
- Does the granularity feel right? (too coarse / too fine)
- Are the blocking edges correct: does each ticket only depend on tickets that genuinely gate it?
- Are the blocking edges correct: does each ticket only depend on tickets that genuinely gate it?
- Should any tickets be merged or split further?
- Should any tickets be merged or split further?
 
 
Iterate until the user approves the breakdown.
Iterate until the user approves the breakdown.
 
 
locationchangedfold-2026-09-11

Step 5's heading and its opening sentence write the approved tickets to .greenline/work/tickets/TKT-NNN.md, in dependency order so depends_on names real ids, with an unused global id checked against the directory and greenline status, one file per ticket, at status ready in place of the ready-for-agent label; there is no configured tracker to choose.

### 5. Publish the tickets to the configured tracker
### 5. Write the tickets to `.greenline/work/tickets/`
 
 
locationchangedfold-2026-09-11

Step 5's heading and its opening sentence write the approved tickets to .greenline/work/tickets/TKT-NNN.md, in dependency order so depends_on names real ids, with an unused global id checked against the directory and greenline status, one file per ticket, at status ready in place of the ready-for-agent label; there is no configured tracker to choose.

Publish the approved tickets. **How** depends on the tracker `/setup-matt-pocock-skills` configured; the tickets are the same either way, only the shape of the blocking edges changes:
Write the approved tickets, one file per ticket at `.greenline/work/tickets/TKT-NNN.md`, in dependency order (blockers first) so each ticket's `depends_on` can name real ids. Inspect the filenames already there (an absent directory is empty) and `greenline status --json` for an unused TKT-NNN, and recheck before writing to avoid a concurrent collision. Use the ticket template below: one ticket per file, never a single combined file. Each ticket is written at `status: ready` unless instructed otherwise; the tickets are agent-grabbable by construction.
 
 
lifecyclechangedfold-2026-09-11

The local-files and real-tracker branches collapse into the initiative's lifecycle: the new ids listed in the initiative's tickets, the initiative advancing to planned, greenline doctor validating the graph, a later slice keeping existing ids, paths and evidence, greenline status projecting the frontier, and the parent spec or decisions held as a consumes pin never written to.

- **Local files** → write one file per ticket under `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below: one ticket per file, never a single combined file.
Then list the new ids in the initiative's `tickets` and advance the initiative to planned. `greenline doctor` validates the graph. A slice added later keeps every existing ticket's id, path and evidence; it edits membership, and a revision only where it changes a consumed contract.
- **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the `ready-for-agent` triage label unless instructed otherwise; the tickets are agent-grabbable by construction.
 
 
lifecyclechangedfold-2026-09-11

The local-files and real-tracker branches collapse into the initiative's lifecycle: the new ids listed in the initiative's tickets, the initiative advancing to planned, greenline doctor validating the graph, a later slice keeping existing ids, paths and evidence, greenline status projecting the frontier, and the parent spec or decisions held as a consumes pin never written to.

Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
Work the **frontier**: any ticket whose blockers are all done; `greenline status` projects it. For a purely linear chain that means top to bottom.
 
 
lifecyclechangedfold-2026-09-11

The local-files and real-tracker branches collapse into the initiative's lifecycle: the new ids listed in the initiative's tickets, the initiative advancing to planned, greenline doctor validating the graph, a later slice keeping existing ids, paths and evidence, greenline status projecting the frontier, and the parent spec or decisions held as a consumes pin never written to.

Do NOT close or modify any parent issue.
Do NOT close or modify the spec or decisions the tickets consume; a parent is a `consumes` pin, never a write.
 
 
<local-ticket-template>
<local-ticket-template>
 
 
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

# <NN>: <Ticket title>
```markdown
---
id: TKT-NNN
type: ticket
status: ready
revision: 1
intent: "<the end-to-end behaviour this ticket makes work, from the user's perspective>"
scope:
- <repository-relative root the slice touches>
depends_on: [] # the TKT ids that gate this one; empty when it can start immediately
consumes:
- { id: INIT-NNN/SPEC, revision: <N> }
acceptance:
- [ ] Acceptance criterion 1
- [ ] Acceptance criterion 2
---
 
 
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

**What to build:** the end-to-end behaviour this ticket makes work, from the user's perspective, not a layer-by-layer implementation list.
## What to build
 
 
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

**Blocked by:** the numbers/titles of the tickets that gate this one, or "None (can start immediately)".
The end-to-end behaviour this ticket makes work, from the user's perspective, not a layer-by-layer implementation list.
 
 
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

**Status:** ready-for-agent
## Scope and authority
 
 
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

- [ ] Acceptance criterion 1
The plan this ticket consumes and what its grant covers.
- [ ] Acceptance criterion 2
```
 
 
</local-ticket-template>
</local-ticket-template>
 
 
locationchangedfold-2026-09-11

The real-tracker issue template has no target and goes with its branch; the closing sentence addresses the ticket's intent and body and exempts the scope field, which names roots by contract; the Handoff section closes the chain to implement with greenline status and greenline doctor.

<issue-template>
In the ticket's intent and body, avoid specific file paths or code snippets: they go stale fast (the `scope` field names roots, not the files inside them). Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
 
 
locationchangedfold-2026-09-11

The real-tracker issue template has no target and goes with its branch; the closing sentence addresses the ticket's intent and body and exempts the scope field, which names roots by contract; the Handoff section closes the chain to implement with greenline status and greenline doctor.

## Parent
## Handoff
 
 
locationchangedfold-2026-09-11

The real-tracker issue template has no target and goes with its branch; the closing sentence addresses the ticket's intent and body and exempts the scope field, which names roots by contract; the Handoff section closes the chain to implement with greenline status and greenline doctor.

A reference to the parent issue on the tracker (if the source was an existing issue, otherwise omit this section).
Consumes: spec.md (INIT-NNN/SPEC, pinned revision), or decisions.md (INIT-NNN/DEC, pinned revision) when no spec was written
 
Produces: .greenline/work/tickets/TKT-NNN.md per slice, status ready, with depends_on edges and consumes pins; the initiative's tickets membership; the initiative advances to planned
## What to build
Next: implement takes the ready frontier from greenline status; greenline doctor validates the graph
 
The end-to-end behaviour this ticket makes work, from the user's perspective, not layer-by-layer implementation.
 
## Acceptance criteria
 
- [ ] Criterion 1
- [ ] Criterion 2
 
## Blocked by
 
- A reference to each blocking ticket, or "None (can start immediately)".
 
</issue-template>
 
In either form, avoid specific file paths or code snippets: they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.

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 Tickets"
short_description: "Split a plan into tracer-bullet tickets"
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-tickets
name: "to-tickets"
description: Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).
description: "Break a plan, spec, or the current conversation into a set of tracer-bullet ticket files in .greenline/work/tickets/, each declaring its blocking edges as depends_on ids."
disable-model-invocation: true
lifecyclechangedbaseline-copies-2026-09-11

greenline prelude, to fold: read the actual spec or decisions; each ticket is a tracer bullet with falsifiable acceptance; the tracker branches and .scratch/ path are replaced by .greenline/work/tickets/TKT-NNN.md; ready-for-agent is status ready

**greenline prelude: consume the settled intent.** Read `.greenline/WORK.md` and the actual spec, decisions, or conversation supplying the plan. Name that source, pin any artifact revisions consumed, and resolve consequential uncertainty before slicing. Each delivery ticket is a tracer bullet with a clear intent, scope, and falsifiable acceptance. Distinct dependencies earn graph edges; a compact change can remain one ticket.
 
**Publication integration:** the body's configured tracker is the local work
artifact system. Step 5's tracker branches and `.scratch/` path are replaced
by `.greenline/work/tickets/TKT-NNN.md`, using WORK.md's global IDs and
`depends_on` edges. `ready-for-agent` maps to `status: ready` in those files.
Write no tracker issues or external labels; a parent issue reference is only
a source reference. Keep the method's slicing and dependency reasoning intact.
 
dependencychangedbaseline-copies-2026-09-11

ADR 0022 retired the workspace-setup rename, so the body's two tracker references would surface a raw upstream skill name no consumer install carries; the completion already rules the tracker IS .greenline/work/.

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.
dependencychangedbaseline-copies-2026-09-11

same ADR 0022 consequence as patch 01, the body's second reference to the retired setup skill's tracker choice.

Publish the approved tickets. **How** depends on the tracker `/setup-matt-pocock-skills` configured; the tickets are the same either way, only the shape of the blocking edges changes:
Publish the approved tickets. **How** is settled here, the tickets landing as files; the tickets are the same either way, only the shape of the blocking edges changes:
lifecyclechangedbaseline-copies-2026-09-11

greenline completion, to fold: global TKT ids, the template mapped into the shared frontmatter, publishing means writing those files; greenline doctor validates the graph

 
 
## greenline completion: tickets
 
Write tickets under `.greenline/work/tickets/TKT-NNN.md` with globally unused IDs. The upstream local ticket template maps into the shared frontmatter: intent and scope describe the work, acceptance holds the criteria, Blocked by becomes `depends_on`, and ready-for-agent becomes `status: ready`. The ticket body retains useful explanation. Publishing means only writing those artifacts under the prelude's mapping.
 
An initiative lists its member ticket IDs and advances to planned when that authorized graph is ready. Adding a slice preserves existing ticket IDs, paths, and evidence, and updates affected membership or meaning revisions. `greenline doctor` validates the graph; `greenline status` projects its ready frontier. Use the current planning account for source selection and evidence, then return to the request owner to continue within the grant.

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 Tickets"
short_description: "Split a plan into tracer-bullet tickets"
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 plan where upstream pointed at a setup skill, and writes step 5 as the .greenline/work/tickets/ write with the WORK.md ticket shape as its one template and the handoff to implement.

SKILL.md

scopechangedfold-2026-09-11

The opening paragraph in the skill's own voice: to-tickets fires when the plan is settled in spec.md or decisions.md, never shapes or specifies (a gap returns to grill-with-docs or to-spec), never implements (implement takes the ready frontier), and a settled compact change is one ticket while wayfinder's decision tickets are not the tickets written here.

to-tickets fires when an initiative's plan is settled, in its `spec.md` or, for an initiative that went from shaping straight to slicing, its `decisions.md`, and the work needs cutting into delivery tickets under `.greenline/work/tickets/`. It never shapes or specifies: a consequential gap in the plan returns to grill-with-docs or to-spec rather than being sliced around. It never implements: implement takes each ticket from the ready frontier. A settled compact change is one ticket and needs no slicing pass; wayfinder's decision tickets are questions in the initiative's `map.md`, not the tickets written here.
 
vocabularychangedfold-2026-09-11

A reference the user passes is a greenline artifact, a spec path, an initiative id or a ticket id read whole, not an issue number or URL with comments; the term names a greenline artifact, which is the one case a vocabulary edit covers.

Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.
Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an initiative id or a ticket id) as an argument, read it whole.
locationchangedfold-2026-09-11

Step 5's heading and its opening sentence write the approved tickets to .greenline/work/tickets/TKT-NNN.md, in dependency order so depends_on names real ids, with an unused global id checked against the directory and greenline status, one file per ticket, at status ready in place of the ready-for-agent label; there is no configured tracker to choose.

### 5. Publish the tickets to the configured tracker
### 5. Write the tickets to `.greenline/work/tickets/`
locationchangedfold-2026-09-11

Step 5's heading and its opening sentence write the approved tickets to .greenline/work/tickets/TKT-NNN.md, in dependency order so depends_on names real ids, with an unused global id checked against the directory and greenline status, one file per ticket, at status ready in place of the ready-for-agent label; there is no configured tracker to choose.

Publish the approved tickets. **How** depends on the tracker `/setup-matt-pocock-skills` configured; the tickets are the same either way, only the shape of the blocking edges changes:
Write the approved tickets, one file per ticket at `.greenline/work/tickets/TKT-NNN.md`, in dependency order (blockers first) so each ticket's `depends_on` can name real ids. Inspect the filenames already there (an absent directory is empty) and `greenline status --json` for an unused TKT-NNN, and recheck before writing to avoid a concurrent collision. Use the ticket template below: one ticket per file, never a single combined file. Each ticket is written at `status: ready` unless instructed otherwise; the tickets are agent-grabbable by construction.
lifecyclechangedfold-2026-09-11

The local-files and real-tracker branches collapse into the initiative's lifecycle: the new ids listed in the initiative's tickets, the initiative advancing to planned, greenline doctor validating the graph, a later slice keeping existing ids, paths and evidence, greenline status projecting the frontier, and the parent spec or decisions held as a consumes pin never written to.

- **Local files** → write one file per ticket under `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below: one ticket per file, never a single combined file.
Then list the new ids in the initiative's `tickets` and advance the initiative to planned. `greenline doctor` validates the graph. A slice added later keeps every existing ticket's id, path and evidence; it edits membership, and a revision only where it changes a consumed contract.
- **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the `ready-for-agent` triage label unless instructed otherwise; the tickets are agent-grabbable by construction.
lifecyclechangedfold-2026-09-11

The local-files and real-tracker branches collapse into the initiative's lifecycle: the new ids listed in the initiative's tickets, the initiative advancing to planned, greenline doctor validating the graph, a later slice keeping existing ids, paths and evidence, greenline status projecting the frontier, and the parent spec or decisions held as a consumes pin never written to.

Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
Work the **frontier**: any ticket whose blockers are all done; `greenline status` projects it. For a purely linear chain that means top to bottom.
lifecyclechangedfold-2026-09-11

The local-files and real-tracker branches collapse into the initiative's lifecycle: the new ids listed in the initiative's tickets, the initiative advancing to planned, greenline doctor validating the graph, a later slice keeping existing ids, paths and evidence, greenline status projecting the frontier, and the parent spec or decisions held as a consumes pin never written to.

Do NOT close or modify any parent issue.
Do NOT close or modify the spec or decisions the tickets consume; a parent is a `consumes` pin, never a write.
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

# <NN>: <Ticket title>
```markdown
---
id: TKT-NNN
type: ticket
status: ready
revision: 1
intent: "<the end-to-end behaviour this ticket makes work, from the user's perspective>"
scope:
- <repository-relative root the slice touches>
depends_on: [] # the TKT ids that gate this one; empty when it can start immediately
consumes:
- { id: INIT-NNN/SPEC, revision: <N> }
acceptance:
- [ ] Acceptance criterion 1
- [ ] Acceptance criterion 2
---
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

**What to build:** the end-to-end behaviour this ticket makes work, from the user's perspective, not a layer-by-layer implementation list.
## What to build
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

**Blocked by:** the numbers/titles of the tickets that gate this one, or "None (can start immediately)".
The end-to-end behaviour this ticket makes work, from the user's perspective, not a layer-by-layer implementation list.
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

**Status:** ready-for-agent
## Scope and authority
lifecyclechangedfold-2026-09-11

The local ticket template is WORK.md's ticket shape: title and What-to-build into intent, Blocked-by into depends_on, ready-for-agent into status: ready, the criteria into acceptance, the parent reference into a consumes pin, scope naming the roots touched; the body keeps What to build and adds Scope and authority.

- [ ] Acceptance criterion 1
The plan this ticket consumes and what its grant covers.
- [ ] Acceptance criterion 2
```
locationchangedfold-2026-09-11

The real-tracker issue template has no target and goes with its branch; the closing sentence addresses the ticket's intent and body and exempts the scope field, which names roots by contract; the Handoff section closes the chain to implement with greenline status and greenline doctor.

<issue-template>
In the ticket's intent and body, avoid specific file paths or code snippets: they go stale fast (the `scope` field names roots, not the files inside them). Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
locationchangedfold-2026-09-11

The real-tracker issue template has no target and goes with its branch; the closing sentence addresses the ticket's intent and body and exempts the scope field, which names roots by contract; the Handoff section closes the chain to implement with greenline status and greenline doctor.

## Parent
## Handoff
locationchangedfold-2026-09-11

The real-tracker issue template has no target and goes with its branch; the closing sentence addresses the ticket's intent and body and exempts the scope field, which names roots by contract; the Handoff section closes the chain to implement with greenline status and greenline doctor.

A reference to the parent issue on the tracker (if the source was an existing issue, otherwise omit this section).
Consumes: spec.md (INIT-NNN/SPEC, pinned revision), or decisions.md (INIT-NNN/DEC, pinned revision) when no spec was written
 
Produces: .greenline/work/tickets/TKT-NNN.md per slice, status ready, with depends_on edges and consumes pins; the initiative's tickets membership; the initiative advances to planned
## What to build
Next: implement takes the ready frontier from greenline status; greenline doctor validates the graph
 
The end-to-end behaviour this ticket makes work, from the user's perspective, not layer-by-layer implementation.
 
## Acceptance criteria
 
- [ ] Criterion 1
- [ ] Criterion 2
 
## Blocked by
 
- A reference to each blocking ticket, or "None (can start immediately)".
 
</issue-template>
 
In either form, avoid specific file paths or code snippets: they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.

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

the coherence walk: one writer for the compact ticket

SKILL.md

lifecyclechangedfold-walk-2026-09-11

the plan is the initiative's spec.md or decisions.md, or the conversation when neither was written; a settled compact change is implement's one ticket, so this skill never writes it

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 plan is the initiative's `spec.md`, or its `decisions.md` when no spec was written; read it whole and pin the revision the tickets consume. A conversation can supply the plan when no spec or decisions record was written; name that source in the tickets and pin nothing. A settled compact change is implement's one ticket, not a slicing pass.