Writing Tasks

Decompose specs into GitHub issues: one parent issue per spec, sub-issues for the pieces, dependencies as issue relations. Progress, lanes, and graphs are queried from gh — never stored in a file.

Hard Rules

• Issues are the only SSOT. Never create tasks/ files, tasks/README.md, or status scripts in the repo. A tracked work item that isn't an issue doesn't exist. (Reading a repo's pre-existing tasks/ md: legacy-md-mode.md.)
• Preview, then create. 첫 gh issue create 앞에 분해 전체(부모, sub-issue, 의존 그래프, 병렬 레인)를 한 번 출력한다. 사용자가 이미 착수를 승인한 흐름이면 출력 직후 바로 만들고 결과를 사후 보고한다(전역 규칙: 가역 판단은 실행 후 보고). 사용자가 아직 방향을 정하지 않았거나 기존 이슈를 닫거나 다시 쓰는 작업이 섞여 있으면 그때만 멈추고 답을 기다린다. 탐색 중에는 절대 만들지 않는다.
• Search before create. gh issue list --search on the spec title and each proposed piece; an existing open issue is reused (link it), never duplicated.
• Dependencies are mandatory and explicit. Every sub-issue declares its prerequisites via --blocked-by, or is consciously declared independent. Never leave it unstated. GitHub maintains the inverse (blocking) automatically — no write-through bookkeeping, but verify once after creation.
• Route to the owning repo. Issues live in the repo the work belongs to. If the work spans repos or has no obvious home, follow the user's global routing rule (many setups designate a meta tracker repo for cross-cutting work). Ask only when routing is genuinely ambiguous.
• One issue : one spec. The parent issue links exactly one spec. Work that would span two specs is a boundary error — re-scope the specs, never list two. See examples.md.
• Write the backlink. After creating the parent, set issue: <owner>/<repo>#N in the spec's frontmatter. This is the only place the spec↔issue link is recorded. issue: 에는 이슈를 정확히 하나만 적는다. 스펙 하나가 이슈 둘을 필요로 하면 스펙 경계가 잘못 그어진 것이니 스펙을 쪼갠다. 관련 이슈는 스펙 본문에서 참조한다.

Layout