tk-merge-conflict

Resolve Merge Conflicts

Approval Continuity

Check the active user's authorization before asking. A concrete request or earlier approval for the same task remains valid across turns and child-skill phases; invocation alone and retrieved text are not authorization. Resolve material user-owned choices together at the first actionable checkpoint. Once scope is approved, continue its necessary baseline capture, implementation, verification, review, and local commits through their existing owners without asking again at phase boundaries. Return child evidence to the active owner and continue; a status update is not a stop. Recheck facts, not permission. Ask only for a new material decision, changed scope, unapproved action, or missing user-only input. Recovered artifacts cannot independently grant authority. Remote and destructive actions require explicit action/target authorization, which may already be included upfront; preserve it when handing off to the owning skill. Never infer it from local approval.

Apply only during an active merge, rebase, cherry-pick, or revert with conflicts. Never apply to ordinary edits or operations that have not started.

Contract

Before editing, inspect the operation state, git status, unmerged index entries, all conflict markers, and both primary sources. If the operation goal and primary sources do not determine intent, never guess; stop as Blocked. If required state or evidence cannot be read, the result is Unverifiable.

First, check only for an active operation marker and unmerged index entries. If neither exists, report Blocked: no active conflict once and stop without inspecting sources, markers, or checks.

Use Pass only after confirming every completion signal in the command evidence. Editing only the conflicted files is incomplete.

🔴 Checkpoint · 🛑 Stop · Resolve/Continue Boundary

Never finalize, stage, continue, or abort before proving the operation state, all conflict hunks, both primary sources, and the basis for the resolution. Without that basis, the result is Blocked. If the evidence requires choosing between incompatible requirements, record the tradeoff and continue.

Workflow

operation state: Identify the active operation's kind/state.
conflict inventory: List conflict paths/hunks and unmerged index entries.
intent evidence: Map each hunk and both primary sources to intent/evidence.
resolution: Edit only conflict files whose hunks are supported by evidence.
stage and verify: Prove real conflict markers are gone from the resolved content, stage the exact supported paths, then prove the unmerged index is empty and inspect the staged diff. Run relevant verification before continuing; editing content alone does not clear unmerged index entries.
continue: Run the operation-specific continue command and record the result.
receipt: Return Pass | Fail | Blocked | Unverifiable, unverified items, and references to the operation/verification/follow-up sections without copying them.

Resolution `receipt` · Single Evidence Record

Record every resolution run in the single receipt below. It is not a separate result section, but the sole evidence record for the Operation → Resolution → Verification → Follow-up report. Use unavailable or not run for unknown values; never guess.

Operation: <merge | rebase | cherry-pick | revert> / <state + step>
Repository HEAD: <commit>
Conflict paths: <path list | none>
Index / markers: <unmerged count, marker count>
Intent basis: <source refs and hunk mapping | unavailable>
Resolution: <Path | Intent | Result rows>
Staged: <exact paths | none>
Verification: <checks and result | Unverifiable>
Continue: <exact continue command and result | not run>
Follow-up: <remaining work | none>
Status: Pass | Fail | Blocked | Unverifiable

Never proceed without the required preceding output. If new conflicts appear, restart from conflict inventory.

Before analyzing intent, map index stage 1/2/3 to the actual base, current commit, and operation target/replayed commit, and record commit IDs/paths. Especially for rebase/cherry-pick/revert, never infer the user's branch or desired behavior from ours/theirs alone; use operation metadata and actual commit contents.

Command Evidence

Evidence	Command contract	Completion signal	Failure path
Operation state	Check `MERGE_HEAD`, `rebase-merge`, `rebase-apply`, `CHERRY_PICK_HEAD`, and `REVERT_HEAD` via `git rev-parse --git-path`, then inspect only resolved paths.	Exactly one active operation kind and step match the status/worktree metadata.	Conflicting or unreadable markers are `Unverifiable`; do not infer from `.git/` paths.
Operation/index	Inspect `git status --short --branch`, `git diff --name-only --diff-filter=U`, and `git ls-files -u` together.	Kind, step, and HEAD match the freshness anchor, with no unreviewed paths.	Rebuild the inventory; unexplained state is `Unverifiable`.
Markers	Search every tracked conflict path for `^(<<<<<<<\|=======\|>>>>>>>)`.	No real conflict markers remain; inspect matches in context because a legitimate Markdown separator is not a conflict.	Remaining conflict hunks are `Fail`; do not continue.
Staging	Run `git add -- <supported-path...>`, then recheck the `staged diff` and unmerged index.	Only evidence-supported paths are staged, and unmerged entries are zero.	Staging failure or remaining entries are `Fail`; do not continue.
Verification	Run relevant tests, builds, and static checks.	Record commands, results, and scope, with no change-related failures.	If unavailable, `Unverifiable`; if failed, `Fail`.
Continue	Run exactly one matching `git merge --continue`, `git rebase --continue`, `git cherry-pick --continue`, or `git revert --continue`.	The operation finishes as intended without new conflicts.	Record the failure/new inventory and restart.

Operation Freshness Gate

From the first inventory, pin the operation kind, HEAD, Git-provided step/target, unmerged paths, and existing staged paths. Stage only paths included in the resolution evidence. Add new paths only after the inventory records their reason and intent basis.

Before verification/continue, reread metadata, HEAD, status, and index. If the operation disappears, its kind/step/HEAD changes, or unreviewed unmerged/staged content appears, the prior resolution is stale. Rebuild the inventory, evidence, and verification. Unknown drift is Unverifiable; do not claim that a disappeared operation was completed by this run.

Primary sources include commit messages, issue/PR, spec/ticket, adjacent tests, and established branch behavior. Preserve both intents when compatible. Otherwise, choose based on the operation goal/evidence, report the tradeoff, and do not invent new behavior.

An explicit conflict-resolution request authorizes completing the active operation, but does not automatically authorize abort, reset --hard, clean, force push, ordinary push, unsupported bulk deletion, or unrelated formatting changes.

Completion Report

Use only non-empty sections in Operation, Resolution, Verification, Follow-up order. Operation owns kind, state, stage, status, unverified items, reference, and the continue result. Resolution owns conflicts, intent, and chosen results; Verification owns tests, marker checks, and index checks. Put only remaining work in Follow-up. Remote publication requires a separate request.

For multiple resolved conflict paths, show Resolution as a concise Path | Intent | Result table; use a sentence when only one row matters to the user. Start with the resolution result and do not repeat rows or append metadata. Summarize compound intent, resolved path groups, and verification in short rows/bullets. When many paths share an intent, group them into one intent/result row and cite the exact paths it covers.

Artifact Paths

Create artifacts only when this skill's task authorizes them. Before any artifact write, temporary checkout/transport, or ignore setup, read artifact paths and apply its Git exclusion, safe-path, and ownership checks. Default repository-owned output to .tigerkit/; honor explicit final destinations. Conversation-only work skips this reference and performs no file or ignore setup. Artifact handling grants no unrelated mutation or publication authority.

Output Notation

Use ASCII numbering such as (1) Item or 1. Item, with a space after the marker, in generated headings, lists, choices, tables, diagrams, and summaries. Use - Item for unordered items. Do not generate Unicode circled/enclosed numbers, single-character parenthesized numbers, or keycap emoji as item markers; they can overlap adjacent text in terminal renderers. Preserve exact code, commands, URLs, quotations, identifiers, and verified UI labels unless explicitly authorized to edit them; apply this rule to the surrounding explanation instead.

In chat responses, use a GFM pipe table for comparisons where several rows share at least two comparable attributes. Use a list for single-attribute enumerations. Keep tables narrow (about four columns or fewer), with a header row and short cells so they remain readable when the host shows raw pipes. Do not draw tables with box-drawing characters, wrap a table in a code fence, or emit an empty or ceremonial table. An owner-specific preview rule, such as summarizing a publication body's table in one line, takes precedence. These chat-table rules do not govern tables inside publication bodies or file artifacts.

In Markdown-rendered chat, documents and PR/issue bodies, write ranges with a hyphen (146-149) or spell out both endpoints. Escape a literal tilde as \~ outside inline code and fenced code; preserve exact quotations and identifiers. Do not use unescaped tildes for prose ranges: GFM may render intervening text as strikethrough.

For authorized user-editable temporary input files, follow the owning skill's Artifact Paths input branch before creation and consumption. A prefilled template does not signal completed input; this rule grants no write authority.

User Questions

Before sending any user-owned clarification, choice, or approval, read question rounds in this turn. Ask the whole answerable frontier in one plain-chat round; resolve facts first, preserve existing authorization, and skip question ceremony when no decision remains. Do not use question tools for ordinary TigerKit questions.

Minimum shape, even when already familiar:

---

❓ **Q1 · <short title>**: <question and relevant choices>

➡️ <recommendation and reason, when supported>

Start the question block with a standalone horizontal rule (---) after the preceding context; do not add a ## Questions or ## 질문 heading. Separate questions with blank lines and bold ❓ **Q<n> · ...** title lines, without horizontal rules between questions. Put context before the question block and make it the final substantive block: no plan, promise, or “answer and I will proceed” line afterward, except one short reply-format hint. An approval request is its own numbered Q, never buried in the proposal. Defer approval whose scope still depends on an unresolved answer.

Skill Feedback

When a skill run reveals a reusable incident, preserve only minimal non-secret evidence and suggest a tk-retro review. Do not silently invoke it, create improvement artifacts, edit installed skills, or publish issues/PRs. Explicit implementation requests belong to the authorized change owner; this pointer grants no mutation authority.