git:20260926.b2cb277 to git:20260926.7121c86

---

name: unfold

description: |

work where a hand belongs on the unit's chart in Linear: "이 길로 가는 이유

기록" / "결정 남겨줘" / "log this decision" (decide), "열린 것들 축으로

without being named: when the accumulated context and the utterance show an

intent to write to a repository, the unit's chart is read before the first

write — matched against the catalog of project root issues, that one chart

and nothing beside it. Writes ONLY structure and decisions, never status.

Invoked as /unfold [moment] [project].

---

# Unfold — Writing the unit's chart in Linear

A unit of work has a chart outside the codebase: its project's root issue in

Linear, whose five sections say what is wanted, why, under which constraints,

and what is still open, and whose decision comments say where the direction

Reading the chart on its own is outside this skill; the adopting host carries

that on its always-loaded surface. What is here is the convention for writing

— the shape of a decision line, what the cull drops, the state/structure

## Core rule — pace layering

- **Write only structure and decisions**: new workstream issues, `blockedBy`

edges, runbook documents, one-line decision comments, a regrouped Open

questions section and the relocation of an item that regrouping releases —

into another section of the same root description, or into the issue or

document that item belongs to.

- **Read at need, never cache-and-trust**: issue status and milestone progress

% are system-maintained. Dependency edges are not — they are stored

structure, written by hand under the bullet above. A write reads what it is

about to change, immediately before changing it.

- **Never hand-write state**: do not set issue status, milestone completion,

or live-system facts (deploy/image existence) in Linear. Status flows from

PR events; live facts are read from their source (CI, registry, ArgoCD)

at need. Hand-mirrored state drifts, and stale state read back as "the

whole picture" pollutes downstream judgment. Sole exception: the initial

state of a backfilled issue — one created for work finished before the

issue existed — is set once at creation, because no PR event will ever

fire for it; this is a one-time creation fact, not ongoing mirroring,

## Invocation

`/unfold [moment] [project]` — both arguments optional.

| Moment | Aliases (EN / KO) | Kind |

|---|---|---|

| `decide` | decision, path, 결정, 왜 이 순서 | **write** (one comment) |

| `group` | axes, collapse, regroup, 축 정리, 정렬, 묶기 | **write** (open-set regroup) |

- No moment argument: infer from the utterance. A direction being chosen is

- Korean voice input is expected — match aliases semantically, not literally.

- **Write-intent trigger.** When the accumulated context and the utterance

show an intent to write to a repository — an edit, a branch, a worktree, a

spawn — and no chart is open for that unit yet, the unit's chart is read

before the first write, resolved by catalog match (below). Recognizing that

intent is the work, so the trigger belongs where the intent forms, not where

a write executes: this skill states the trigger and delivers it nowhere, and

a host that wants it to fire unasked binds it on an always-loaded surface of

its own.

## Project resolution

Resolve the target Linear project in this order; never hardcode project IDs:

1. Explicit `[project]` argument (name, ID, or slug).

2. Infer from the working repo: take the git repo directory name (and, if

present, the current worktree/branch's issue identifier like `FD-123`) and

query Linear (`list_projects` with a name query, or `get_issue` on the

identifier and read its project).

3. **Catalog match** (the write-intent path, and the fallback when 1–2 give

nothing): the catalog is the root issues of the user's projects — the

in-progress projects first, plus a root issue the accumulated context and

utterance make plainly relevant even though its project is not in

progress. Match the intent against that catalog; one match opens that

4. Still ambiguous: list the candidates and ask once. The resolved chart is

reused while the write target and the intent stay the same unit; a switch

to another repository or another unit re-runs the match, because a chart

that is open is not thereby the chart this write belongs to.

## Tool loading

Linear MCP tools are deferred in most sessions. Before the first call, load

schemas via ToolSearch, e.g.

`select:mcp__claude_ai_Linear__list_projects,mcp__claude_ai_Linear__list_issues,mcp__claude_ai_Linear__get_issue,mcp__claude_ai_Linear__list_comments,mcp__claude_ai_Linear__list_documents,mcp__claude_ai_Linear__save_comment,mcp__claude_ai_Linear__save_issue,mcp__claude_ai_Linear__save_document`

(load only what the moment needs; exact server prefix may differ — discover

with a keyword search on "linear" first when unsure).

## Moment routing (summary)

Detailed per-moment procedures and write templates live in

`references/moments.md` — consult it when executing a moment. Summary:

| Moment | Reads | Writes | Emit |

|---|---|---|---|

| `decide` | the chart (root issue description + decision comments), then the anchor the decision belongs to | `save_comment` | one-line decision log, at the moment the direction changes (draft → cull → write) |

| `group` | the chart's open items and its decision comments, in order, plus the body of each relocation destination before changing it | `save_issue` (root description) / `save_issue` or `save_document` (a released item's destination) | axes each naming what it absorbed + every non-axis classified as projection or different-object, with its disposition → cull → rewritten Open questions |

## Output discipline

- Every write moment drafts first and culls the draft before anything is

written. Where the adopting host's always-loaded surface grants standing

authorization for that write — an approval given when the work was set up,

or a class of writes the host lets proceed — the session applies the cull,

writes, and reports what was written. Otherwise the draft is shown and

user culls it. In both branches three reasons drop a line: it is derivable by reasoning from what is already recorded, it

is the product of a mechanical fix rather than a choice, or it does not

match the unit's intent. Derivability drops an assertion, never a

representation a moment is required to produce: a `group` axis and the list

of what it absorbed are derivable from the originals by construction, and

that is what they are for. Only the slow layer is written — structure and

decisions — never a state the next read would refresh anyway.

- When the pre-write read reveals stale structure (an edge or runbook

contradicting reality), surface it as a proposed structure fix — do not

silently rewrite.

## Additional Resources