tk-drive

Drive execution

The user /tk-drive, $tk-drive, or only starts when the host skill picker containing the source is explicitly selected. If invoked again without a source, resume only when the current source, ledger, Git, and repository evidence in the same conversation unambiguously point to a single approved or pending run. Ordinary requests, artifacts, and new sessions do not start or resume Drive.

Authority and invariants

With one approved plan, preparation, direct or delegated unit execution, required verification, one verified current-branch commit per approved unit, up to three revision rounds, comprehensive verification, and finalization may be performed. This does not include push, PR, merge, tag, release, publishing, or history rewriting.

Drive is the controller. In the delegated strategy, without directly writing product, test, or configuration changes, it sends bounded units to a new worker. In the direct strategy, the current context temporarily steps down from the controller role and becomes the executor of the single approved unit, modifying only the frozen owned paths. This is not an alternative path for the controller. Because this skill is user-invoked, an explicit /tk-drive or $tk-drive invocation itself satisfies the host's user-requested AgentTool condition. Mechanical Git bookkeeping may be handled by the controller only after the final candidate has passed. If the host cannot dispatch an available worker via the delegated strategy, stop with Blocked . The direct strategy begins changes after the approved plan is recorded, and is not an implicit fallback path when a worker is unavailable. The executor does not orchestrate or invoke other user-owned TigerKit workflows.

Lifecycle

Prepare -> Execute -> Close gaps -> Finalize

Drive owns this lifecycle. Child receipts are internal material and do not require continue, /clear, model switching, or a second invocation. After crossing a host/process boundary, derive the next action from new evidence, not from a cursor or lifecycle claim.

Source precedence

Explicit user requirements in the current conversation and decisions finalized in the same conversation are the most recent authoritative source. Precedence is as follows.

현재 대화의 명시적 요구
> 같은 대화의 확정 결정
> 승인된 활성 run
> 현재 source와 일치하는 Ready 작업 문서
> 과거 terminal 문서와 durable prior-art

Past Status: Pass ledger or completion documents cannot override the current request. If the current conversation is a complete source and the goal, scope, R/AC, and verification obligations can be derived, then even if past documents are stale or have a different lineage, record the supersedes evidence and issue three current work documents under a new lineage. Only when the current source is incomplete, contradictory, risky, or requires a user decision, Blocked. Blocked다.

Deliver to the worker a self-contained work document that reflects the current source, not the conversation itself. Therefore, do not omit current requirements merely because past documents were read, and do not skip the completeness check of the work document merely because the current source is in the conversation.

Prepare

1. Read the complete source and applicable repository instructions. First, in the current target checkout, git rev-parse --show-toplevelto confirm the repository root, and replace that result with <repository-root>to derive the following four absolute paths and read them all: <repository-root>/.tigerkit/drive.md, <repository-root>/.tigerkit/spec.md, <repository-root>/.tigerkit/tickets.md, <repository-root>/.tigerkit/implement.md. Optional <repository-root>/.tigerkit/session.mdIf present, read it as a model routing source, but do not treat its absence itself as a reason to block the work document. drive.md owns only progress, approvals, and receipts. Detailed requirements and instructions go only in the three work documents. First, fix the identifiers and explicit instructions of the current conversation source, and classify past closed documents as prior evidence. Document rules과 Worker source rulesIf the current source is complete according to , issue missing documents and stale/lineage-mismatched closed documents as new Pending work documents and record supersedes. When the user approves the displayed plan, update that document to Ready. Only when the current source is incomplete, contradictory, or risky, or when a document is Pending but not approved, set it to the exact status Blockedand do not assign a worker or modify the product. Record the branch, baseline HEAD, work tree, pre-existing changed paths, and up to seven related persistent prior evidence items.
2. Resolve ambiguities that can be reverted with evidence and safe defaults. Record all important controller choices, evidence, and alternatives that change behavior. Call tk-grill-me only when a user-owned decision blocks a safe execution plan. While the question is pending, output 🙋 drive > grill-me · 응답 필요 and do not dispatch a worker. Use tk-prototype only when the decision can be closed with a bounded comparison.
3. Write Ready requirements and acceptance criteria, including the current source identifiers and replacement lineage, scope, exclusions, frozen user-displayed literals, and verification obligations.
4. Derive independently verifiable 1..N units, a dependency graph, and waves. Serialize coupled or uncertain units. Parallelize only units whose independence is proven when the host already provides isolated checkouts/work trees. Do not create a scheduler or let workers concurrently share a mutable work tree.
5. Classify tests/inspections. browser-visible If it is an AC, plan the exact scenario, target, non-sensitive authentication mode, prerequisites, and limitations, and tk-browser-verify에 handoffthe verification. If that AC requires a development server, also pass the exact command/cwd/target URL/auth mode/readiness conditions. Drive/controller/worker/direct executordoes not directly start, wait for, or stop browser tools or development servers. Server PID/port/log/readinessand the summary tk-browser-verifyis owned by, verifier before the result commitdoes not. Other than that, not-required is recorded as. Required headless authcannot be used or verifier handoffis absent, mutation before Unverifiable it is.
6. worker-dispatch.mdselects each unit's execution strategy and minimum model according to. If the ticket already has a confirmed model/effort, consume it as plan metadata and do not silently overwrite it. For a bounded known-pattern without isolation, recommend strategy=directfirst, which keeps the session model, and for new context, isolation, reviewer handoff, design-centered reasoning, recommend delegatedand the rationale. Delegatedis verified and used as the canonical sectionof the .tigerkit/session.md routing을 skills/tk-drive/references/worker-dispatch.md#session-model-routingthat has the current host schema. If there is no file or current host sectionand all three classcontrol values are confirmed, draft the exact nested blockyourself in .tigerkit/session.mdand leave it as Status: Pending. For existing incomplete or conflicting block, do not overwrite but propose a correction. Record routing_state=review-required, and before the user reviews and approves the draft, do not change anything outside the file: worker, product, Git, remote. Only after approval, change it to Status: Readyand verify reread . Approval of an executable delegated unit requires that all model class, selector, effort, routing sources be visible, and if any are missing, use Blocked다. general-purpose implementerand a new task reviewer as a pair, and the returned label is not used for tier determination. Model class/selector/effort selection is delegated-only. In direct approval and the ledger, do not attach the cheapest | standard | strongest tier with any label, and record model_class=n/a, requested_selector=n/a, the session realized_model exposed by the host, or unavailable, reasoning_effort=inherited. According to
7. ledger.md, atomically replace the current progress state of .tigerkit/drive.mdand read it again, then present one concise approval surface. In the Ledger, keep only the current source identifier, supersedes target, repository state, the four work documents and optional session path and state, document status/lineage check, approval snapshot, and unit/dispatch/verification receipt. Goal, scope, frozen literals, R/AC, and implementation guidance are owned by the three work documents, and unknown is left as unavailable . 👍 Recommendation: includes strategy, model class, selector, effort, and routing source, and the user's approval of this plan is the explicit approval of the direct strategy. Do not ask for a separate direct confirmation. This is approval evidence, not a separate lifecycle output.

The approval question is the work surface. Show 🙋 drive · 응답 필요 and exactly one 👍 Recommendation: . Approval applies only to the displayed snapshot. If there is drift in important sources, scope, branch/head, remote state, verifier prerequisite, or an irreversible decision, approval becomes invalid and returns to Prepare. If the plan has not changed, do not seek a routine second approval.

Execute

Apply the frozen strategy for each dependency wave. The Delegated unit is handled by a new general-purpose implementer, and the direct unit is handled by the current context as a single bounded executor. To the Executor, pass the ID/goal, exact R/AC, source/ticket scope, scope/exclusion, related paths, and the <repository-root>/.tigerkit/ resolved from the current target checkout — the following four absolute paths, verification obligation, branch/head/diff ownership. Direct units do not spawn a subagent but, after a focused test and self-review, return the candidate to the controller. Delegated units verify the host worker capability and the approved session selector before dispatch and make them explicit in native model control. Give the implementer the task brief/report paths, and after questions, implementation, focused test, self-review, and commit, receive a short report. Then a new general-purpose give the diff package to the reviewer, and Spec compliance와 Task quality before receiving two verdicts, do not treat the delegated unit as complete. After each delegated worker, record the requested selector and the realized model receipt exposed by the host; for values not exposed, leave as unavailable. general-purpose returning itself is not a failure. Observe the following invariants.

candidate -> required tests/checks/browser verifier -> Close gaps
          -> bounded fresh correction when needed -> one verified unit commit

Run the required verifier against the final candidate before commit. Stage only the verified owned paths and pre-existing preserve user changes. For direct units, the current executor closes isolated gaps within the same frozen unit and owned paths, and for delegated units, dispatch a new corrective worker and re-run the affected obligations. Prefer up to three rounds. Replenish missing context without a model upgrade. Only when there is a proven reasoning failure, use a new worker one step stronger once. If failures repeat, unchanging, cannot isolate the cause, conflict, or expand scope, stop the mutation.

An integration conflict means the independence was wrong. Serialize the affected units or Prepare them again. Workers must not arbitrarily create semantic merges. Isolation, integration order, stale-base/conflict detection, and cleanup are owned by Drive.

Close gaps

For each approved R/AC, evidence observed is classified as one of satisfied, missing, partial, unverifiable . Check only the scope/exclusion related to Acceptance, unit, verifier, externally visible behavior, commit/ancestry, dirty path ownership, and evidence freshness. Omit findings unrelated to that acceptance fact.

When you cannot make a judgment with confidence from the evidence alone, dispatch at most once a stronger new non-mutating reviewer using the same narrow R/AC brief. Only when user/repository policy requires independent review, use an available built-in or third-party reviewer. If required review is unavailable, Unverifiable . All corrections are still sent to a new corrective worker.

Finalize

Only when there is at least one Delegated unit or the approved plan requires independent final review, a new general-purpose Dispatch one overall branch reviewer to check the Spec/AC and quality of the entire diff. All direct executions use only aggregate checks and self-review. If the delegated review finds issues, perform only one new corrective worker and one scoped re-review, and leave load-bearing residual as Blocked. After every verified unit commit, recheck aggregate R/AC traceability, repository check, ancestry, exclusion, and freshness. Update .tigerkit/drive.md to include the unit commit, verifier/gap rationale, correction rounds, aggregate results, and recovery facts. If not successful, freeze the mutation and non-success-finalization.md.

If successful, output a concise behavioral result, useful unit commits, one to four aggregate verifications, and exactly Status: Pass . The terminal response of an active execution outputs only Drive. Omit child receipts, raw logs, dispatch models, and progress markers.