explicitly /tk-to-tickets or $tk-to-tickets execute only when is selected.
First, from the current checkout, git rev-parse --show-toplevelconfirm the repository root with
<repository-root>/.tigerkit/spec.md read . Status: Ready and
consume only the latest specification whose lineage matches the current request. If required specification/evidence is
missing, stop with exactly Status: Unverifiable . If Pending then stop with exactly
Status: Blocked and do not generate downstream tickets. A stale spec or
lineage mismatch also stops with exactly Status: Blocked respectively.
Output contract
Only valid Status: Ready specifications are written as <repository-root>/.tigerkit/tickets.md에
self-contained Markdown, and report by replacing the root with the actual absolute path.
In boundary paths where required input is missing or there is Pending/stale/lineage mismatch/coverage omission,
tickets.mdis not created and only the exact terminal status is reported. Each ticket includes the following fields.
Status, Goal, Coverage(source/R-AC mapping), Scope, Entry points,
Dependencies(none when absent), Acceptance, Verification, model,
effort, rationale, lineage.
Each source/R-AC of Coverage maps to exactly one ticket or explicitly uncovered
write the reason. A ticket is not merely a unit that divides hierarchy but must be an independently observable vertical
piece. model과 effortis proposed as work difficulty metadata, not a provider name,
and the work rationale is written. Later, when assigning SDD workers, use it as the basis for model selection,
but the specific selector is owned by the host routing of the optional .tigerkit/session.md. general-purpose Do not use the return as model selection evidence, and record only the actual
model receipt exposed by the host. If the host does not provide the worker itself, do not invent a mapping,
mark it as a configuration prerequisite, and use tk-wizardfirst.
At the end of the document, place a boundary stating that explicit user approval is required before subsequent consumption.
- Write explanatory sentences and titles in Korean, and keep only exact fields, statuses, IDs, commands, paths, URLs, and literals in the original text.
Do not output implementation, remote issues, global archive/state, or anything other than
.tigerkit/.
Procedure
- Verify the specification's status, freshness, lineage, source/R-AC, and acceptance. If invalid, do not write artifacts and stop at the corresponding boundary state.
- Collect coverage and place each item in exactly one vertical ticket. If there are omissions or conflicts, stop and preserve the original text and reason.
- For each ticket, write from the entry point to observable acceptance and verification.
- Propose model metadata and effort rationale suited to the work difficulty, and specify host worker availability.
self-contained, absolute path, and approval boundary, then save.
Boundary
Do not trigger for general planning, implementation, Pending specifications, or ticket generation by estimation.
ReadyIf it is not , do not pass it to the subsequent step. Missing required input is Status: Unverifiable,
Pending/stale/lineage mismatch/missing coverage each Status: Blockedterminate with
.tigerkit/tickets.mdis not created.