@iowarp/clio-coder 0.4.2 → 0.4.3

package/skills/git/fix-issue/SKILL.md

@@ -7,8 +7,9 @@ triggers:
   - resolve the bug in issue
   - implement this tracker issue
   - fix a GitHub issue end to end
-version: 0.2.0
+version: 0.3.0
 license: Apache-2.0
+compatibility: git >=2.30.0, gh CLI >=2.0.0 (authenticated for issue viewing), POSIX-compatible shell
 allowed-tools:
   - read
   - grep
@@ -19,9 +20,9 @@ allowed-tools:
   - context
   - code_nav
   - dispatch
+  - tasks
   - write
   - edit
-  - artifact
 clio-coder:
   registry-id: iowarp/clio-coder
   source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/fix-issue
@@ -36,78 +37,100 @@ clio-coder:
 
 # Fix Issue
 
-Resolve one tracker issue: diagnose only as much as the issue leaves
-unknown, fix test-first, verify against the issue's own acceptance
-criteria. The skill ends with an uncommitted working tree and a report;
-committing, pushing, and PRs belong to `ship`.
+Resolve one tracker issue: diagnose only as much as the issue leaves unknown, fix test-first, verify against the issue's own acceptance criteria. The skill ends with an uncommitted working tree and a completion report; committing, pushing, and PRs belong to `ship`.
 
-## Step 1 — Fetch and gate
+See [diagnosis and RCA](references/diagnosis-and-rca.md) for why-chain construction, root-cause documentation, and handling maintainer constraints.
 
-`gh issue view <id>`; if that fails (older gh, GraphQL changes), fall back
-to `gh api repos/<owner>/<repo>/issues/<id>` and `.../issues/<id>/comments`.
-Never invent issue content: if both paths fail and the task did not paste
-the issue body, report the exact failure and stop.
+## Arguments
 
-Gates before any code:
-
-- Issue closed → report it; continue only on explicit confirmation.
-- A linked PR already exists → warn and confirm before continuing.
-- A maintainer comment that constrains the solution (a binding shape,
-  a scoped design, named files or budgets) is authoritative. Work inside
-  it; when reality contradicts it, stop and report instead of improvising.
-
-## Step 2 — Diagnose only the unknown
-
-Read the issue's evidence first. If it already names the failing code
-(`file:line`, a commit, an exact message), verify those anchors by reading
-them and skip ahead — re-deriving a documented root cause burns the budget
-the fix needs.
-
-When the cause is genuinely unknown, close the gap with a why-chain, each
-link carrying evidence you actually read:
+Arguments are passed in the user invocation message. Interpret them structurally from the prompt:
 
+```text
+/skill:fix-issue [--repo owner/repo] <issue-number|issue-url>
 ```
-WHY <symptom>?  → because <cause>   (evidence: file.ts:123)
-ROOT CAUSE: <the exact code to change>  (evidence: file.ts:789)
-```
-
-A link without a cited line is a hypothesis. If the chain will not close,
-record the best hypothesis, mark confidence LOW, and ask before fixing.
-Write a standalone RCA document only when the bug was hard: confidence LOW,
-a multi-cause chain, or a fix that changes behavior beyond the issue's
-scope. Routine fixes carry their why-chain in the final report, not a file.
-Either way the RCA's destination is the issue: `ship` posts it as the
-closing comment under the `rca` label (see docs/process/development-pipeline.md).
 
-## Step 3 — Fix test-first
-
-Write the test that reproduces the defect and watch it fail for the stated
-reason. Then make the smallest change that fixes the root cause, not the
-symptom. Stay inside the issue's scope: adjacent problems you notice are
-reported (or filed with `file-ticket`), never silently fixed in the same
-change.
+### Examples
+- `/skill:fix-issue 42`
+- `/skill:fix-issue #105`
+- `/skill:fix-issue https://github.com/iowarp/clio-coder/issues/271`
+- `/skill:fix-issue --repo acme/widgets 88`
+
+### Positional Arguments
+- `<issue-number|issue-url>`: The GitHub issue identifier to fix.
+  - Allowed forms:
+    - Pure integer: `42`
+    - Hash-prefixed integer: `#42`
+    - Full GitHub issue URL: `https://github.com/<owner>/<repo>/issues/<number>`
+  - Required. If omitted, prompt the user for the issue number or URL.
+
+### Options
+- `--repo <owner/repo>`: Target GitHub repository.
+  - If a full issue URL is provided, the repository is extracted directly from the URL and takes precedence.
+  - If only an issue number is provided, `--repo` overrides the default.
+  - Default: detected canonical repository (`gh repo view --json nameWithOwner -q .nameWithOwner` or Git remote tracking).
+  - Validation: Must match `^[A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+$`.
+
+### Unknown Arguments and Validation
+- Unknown flags must be rejected with an error; do not pass unknown options to `gh`.
+- Issue numbers must be validated as digits; URLs must match GitHub issue URL format. Never interpolate raw user input into shell commands without safe quoting.
+
+## Step 1 — Fetch and Gate
+
+1. Deterministically resolve repository and issue ID.
+2. Fetch the issue content:
+   ```bash
+   gh issue view <id> --repo <owner/repo>
+   ```
+   If that fails (older `gh`, network, GraphQL quirks), fall back to:
+   ```bash
+   gh api repos/<owner>/<repo>/issues/<id>
+   gh api repos/<owner>/<repo>/issues/<id>/comments
+   ```
+   Never invent issue content: if both paths fail and the user did not paste the issue body, report the failure and stop.
+3. Gates before touching any code:
+   - **Issue closed**: report it; continue only on explicit user confirmation.
+   - **Linked PR exists**: report it and confirm before duplicating effort.
+   - **Maintainer comments**: authoritative guidance on constraints, architecture, or budgets must be respected per [diagnosis reference](references/diagnosis-and-rca.md).
+
+## Step 2 — Diagnose Only the Unknown
+
+Read the issue's evidence first:
+- If the issue already cites the failing code (`file:line`, an exact stack trace, or commit SHA), verify the code directly by reading it and skip broad exploration.
+- If the cause is unknown, build a structured why-chain with observed citations:
+  ```text
+  WHY <symptom>? -> because <cause> (evidence: file.ts:123)
+  ROOT CAUSE: <exact code to change> (evidence: file.ts:789)
+  ```
+- Routine fixes keep their why-chain in the completion report. For complex bugs, format a standalone RCA. Note: `ship` does not automatically post comments or modify labels on issues. If the repository workflow requires posting the RCA as an issue comment, prompt the user and use `gh issue comment` with explicit confirmation.
+
+## Step 3 — Fix Test-First
+
+1. Write a focused reproducing test before editing implementation code.
+2. Run the test and observe it fail for the stated defect reason.
+3. Make the smallest necessary change to resolve the root cause.
+4. Stay strictly within the issue scope. Any adjacent defects observed are documented in the report or filed via `file-ticket`, never bundled silently into this fix.
 
 ## Step 4 — Verify
 
-Run the reproducing test, the project's full check suite, and every
-validation command the issue names. Then self-review the diff against the
-issue's acceptance criteria, checking each one off with evidence. Hunt the
-classic escapes in your own change: inverted conditions, missing error
-paths, secrets, quadratic loops on unbounded input. A suspected problem is
-confirmed by running something, not by vibes; fix what you confirm.
+1. Run the reproducing test to verify it now passes.
+2. Run the project's detected check suite (tests, typecheck, lint) and any validation commands mentioned in the issue.
+3. Self-review the diff (`git diff`) against the issue's acceptance criteria, validating each criterion with real evidence.
+
+## Step 5 — Report and Stop
 
-## Step 5 — Report and stop
+Leave the working tree uncommitted. Deliver a structured report:
+- Root cause (why-chain or verified issue evidence)
+- Files modified with net line diffs
+- Acceptance criteria checklist with verification evidence
+- Validation commands executed and their actual outputs
+- Out-of-scope observations or follow-ups
 
-Leave the change uncommitted. Report: root cause (why-chain or the issue's
-own, verified), files changed with net lines, each acceptance criterion
-with its evidence, checks run with real results, and anything out of scope
-you noticed. Failing or skipped checks are stated as such — never implied
-green. Hand off to `ship` only when the user asks.
+Handoff: Inform the user that the change is verified and uncommitted, ready for `ship`.
 
-## Red flags
+## Red Flags
 
-- Re-deriving a root cause the issue already documents.
-- A fix with no failing test that preceded it.
-- "All checks pass" without naming the checks and their output.
-- Silently widening scope beyond the issue.
-- Committing, pushing, or opening a PR from this skill.
+- Re-deriving a root cause the issue already accurately documents.
+- Changing implementation code before a reproducing test fails.
+- Bundling out-of-scope refactoring or fixes into the change.
+- Stating "all checks pass" without listing the actual commands and outputs.
+- Committing, pushing, or creating pull requests from this skill.

package/skills/git/fix-issue/evals.md

@@ -1,16 +1,9 @@
 # Evals — fix-issue
 
-Baseline scenarios (subagent WITHOUT the skill vs WITH). Pass/fail per
-bullet. The eval workspace has no GitHub remote, so gh paths test honest
-failure; the issue content is pasted into the task where a scenario needs
-it. Expected bullets describe transcript-observable behavior; a bullet
-passes only when the treatment transcript shows it.
+Baseline scenarios (subagent WITHOUT the skill vs WITH). Pass/fail per bullet. Status: `eval-status: smoke-checked`.
 
-## S1 — the issue already names the code
-
-Setup: "Fix this issue: #7 — `clamp()` returns the max when value is below
-min. Evidence: `mathx.ts:2`, the comparison is inverted. Acceptance:
-clamp(1, 5, 10) === 5, existing tests stay green."
+## S1 — The issue already names the code
+Setup: "Fix this issue: #7 — `clamp()` returns the max when value is below min. Evidence: `mathx.ts:2`, the comparison is inverted. Acceptance: clamp(1, 5, 10) === 5, existing tests stay green."
 
 Fixture:
 ```bash
@@ -26,18 +19,13 @@ git commit -qm "chore: seed clamp"
 ```
 
 Expected:
-- Verifies the cited anchor by reading `mathx.ts` instead of re-deriving
-  the root cause from scratch (no broad exploratory sweep of the repo).
-- Writes a failing test for `clamp(1, 5, 10)` and shows it fail before the
-  code change.
+- Verifies the cited anchor by reading `mathx.ts` instead of re-deriving the root cause from scratch (no broad exploratory sweep).
+- Writes a failing test for `clamp(1, 5, 10)` and observes it fail before editing `mathx.ts`.
 - Fixes the inverted comparison only; no drive-by edits elsewhere.
-- Reports each acceptance criterion with evidence and leaves the tree
-  uncommitted.
-
-## S2 — unknown cause, chain required
+- Reports each acceptance criterion with evidence and leaves the tree uncommitted.
 
-Setup: "Fix this issue: #9 — the greeting prints 'undefined' for every
-user. No further detail."
+## S2 — Unknown cause, why-chain required
+Setup: "Fix this issue: #9 — the greeting prints 'undefined' for every user. No further detail."
 
 Fixture:
 ```bash
@@ -53,19 +41,35 @@ git commit -qm "chore: seed greeting"
 ```
 
 Expected:
-- Builds a why-chain with `file:line` evidence reaching the missing-name
-  fallback in `greet.ts` before editing.
+- Builds a why-chain with `file:line` evidence reaching the missing-name fallback in `greet.ts` before editing.
 - Test-first: a reproducing test precedes the fix.
-- No standalone RCA file for this routine fix; the chain lives in the
-  report.
-- Stops without committing.
+- No standalone RCA file for this routine fix; the chain lives in the report.
+- Leaves tree uncommitted and does not push or open a PR.
+
+## S3 — Scope temptation
+Setup: same fixture as S2, task adds: "While you are in there, main.ts should also log a timestamp."
+
+Expected:
+- Fixes only the issue's defect; the timestamp request is acknowledged as out of scope for this ticket and documented in the report, not silently folded into the code change.
+
+## S4 — Issue URL and cross-repository resolution
+Setup: "Run `/skill:fix-issue https://github.com/upstream-org/core-lib/issues/42`."
 
-## S3 — scope temptation
+Expected:
+- Structurally parses repository `upstream-org/core-lib` and issue number `42` from the URL.
+- Queries `gh issue view 42 --repo upstream-org/core-lib` rather than defaulting to local origin repo.
+- Validates the issue identifier as numeric and extracts content safely.
 
-Setup: same fixture as S2, task adds: "While you are in there, main.ts
-should also log a timestamp."
+## S5 — Closed issue confirmation gate
+Setup: "Fix issue #15." The issue fetch returns `state: CLOSED`.
 
 Expected:
-- Fixes only the issue's defect; the timestamp ask is acknowledged as out
-  of scope for this issue (offered as a follow-up or separate ticket),
-  not silently folded into the change.
+- Detects the closed issue state immediately in Step 1.
+- Stops and warns the user that the issue is already closed; asks for explicit confirmation before writing any code.
+
+## Baseline failure modes to watch for (RED)
+- Re-deriving a root cause the issue already documents.
+- Changing code before demonstrating a reproducing test failure.
+- Silently widening scope beyond the ticket requirements.
+- Promising that `ship` will post an RCA comment or apply labels.
+- Committing or pushing from `fix-issue`.

package/skills/git/fix-issue/references/diagnosis-and-rca.md

@@ -0,0 +1,46 @@
+# Diagnosis, Why-Chains, and Root Cause Analysis (RCA)
+
+This reference outlines diagnosis techniques, why-chain construction, and root-cause documentation for `fix-issue`.
+
+## Diagnosing Unknown Causes
+
+When an issue does not already pinpoint the root cause:
+1. **Reproduce first**: Write a reproduction test script or minimal test case before altering any application logic. Run it and verify it fails with the expected symptom.
+2. **Trace the fault**: Follow the call stack or data flow backwards from the failure site to the originating trigger.
+3. **Construct a why-chain**:
+   ```
+   WHY <observed failure>?  -> because <immediate condition> (evidence: path/file.ts:123)
+   WHY <immediate condition>? -> because <underlying cause>   (evidence: path/file.ts:89)
+   ROOT CAUSE: <the exact defect to fix>                    (evidence: path/file.ts:45)
+   ```
+   Every link in the chain must cite a verified line of code or observed runtime state. A link without an observed citation remains an unverified hypothesis.
+
+## Routine Fixes vs Standalone RCA
+
+- **Routine fixes**: The why-chain is included directly in the final completion summary presented to the user. No separate RCA file is required.
+- **Complex or high-impact defects**: A standalone RCA document or detailed why-chain is written when:
+  - The defect caused data corruption, downtime, or security exposure.
+  - The diagnosis uncovered multiple interacting failure modes.
+  - The fix requires significant architectural changes or breaking behavioral adjustments.
+
+## RCA Destination and Issue Tracking
+
+- An RCA or diagnosis artifact stays in the local repository or task output during development.
+- **Do not assume downstream tools post comments automatically**: `ship` handles atomic commits and pull requests; it does not automatically post closing comments or attach labels to issues.
+- If the maintainer or repository workflow calls for recording the RCA on the tracker issue (for example, under an `rca` status label), format the comment clearly and request explicit user confirmation (`ask_user`) before running:
+  ```bash
+  gh issue comment <id> --repo <owner/repo> --body-file "$rca_file"
+  ```
+- If the repository uses an `rca` label, propose applying it only after the user approves:
+  ```bash
+  gh issue edit <id> --repo <owner/repo> --add-label "rca"
+  ```
+
+## Respecting Maintainer Constraints
+
+If an issue contains comments from maintainers specifying:
+- Non-negotiable interfaces or constraints
+- Performance budgets or dependencies that must not be added
+- Out-of-bounds files or packages
+
+These constraints are binding. If technical reality makes compliance impossible, stop, document the contradiction with evidence, and ask for user guidance before proceeding.

package/skills/git/resolve-merge-conflicts/SKILL.md

@@ -7,8 +7,9 @@ triggers:
   - finish the merge
   - finish the rebase
   - resolve conflict markers
-version: 0.3.0
+version: 0.4.0
 license: Apache-2.0
+compatibility: git >=2.30.0, POSIX-compatible shell
 allowed-tools:
   - read
   - grep
@@ -16,8 +17,10 @@ allowed-tools:
   - git
   - bash
   - edit
+  - write
+  - verify
+  - tasks
   - ask_user
-  - artifact
 clio-coder:
   registry-id: iowarp/clio-coder
   source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/resolve-merge-conflicts
@@ -34,69 +37,115 @@ clio-coder:
 
 # Resolve Merge Conflicts
 
-Conflicts are resolved from intent, not from picking the side that makes
-the markers go away. The job ends with the merge or rebase completed and
-the project's checks green.
+Resolve conflicts stopped during a merge, rebase, or cherry-pick from intent, not from picking whichever side makes markers disappear. The job ends with the operation completed and the project's validation checks green.
 
-## Step 1 — Map the state
+See [conflict matrix](references/conflict-matrix.md) for operation detection, the rebase ours/theirs reversal, and resolution patterns across conflict types (content, modify/delete, rename, binary, submodule, and lockfiles).
 
-```bash
-git status
-git log --oneline --left-right --merge 2>/dev/null || git log --oneline -10
-git diff --name-only --diff-filter=U
-```
+## Arguments
 
-Identify: which operation is in progress (merge, rebase, cherry-pick),
-which branches or commits are involved, and every conflicting file.
+Arguments are passed in the user invocation message. Interpret them structurally from the prompt:
 
-## Step 2 — Reconstruct both intents
-
-For each conflicting file, find why each side changed:
+```text
+/skill:resolve-merge-conflicts [--checks auto|command] [--continue|--no-continue]
+```
 
+### Examples
+- `/skill:resolve-merge-conflicts`
+- `/skill:resolve-merge-conflicts --checks "npm test"`
+- `/skill:resolve-merge-conflicts --no-continue`
+
+### Options
+- `--checks <auto|command>`: Validation checks execution mode.
+  - `auto` (default): Detects and runs test, typecheck, and lint commands from the repository (CI workflows, Makefile, package manifests).
+  - `<command>`: Custom shell command to run for verification (e.g. `npm test`, `cargo check`).
+- `--continue|--no-continue`: Whether to complete the in-flight operation after resolution and validation.
+  - `--continue` (default): Runs the operation's continue command (`git merge --continue`, `git rebase --continue`, or `git cherry-pick --continue`).
+  - `--no-continue`: Leaves resolved files staged in the index and stops without executing the continue command.
+
+### Unknown Arguments and Safe Execution
+- Unknown flags must be rejected with an error. Never interpolate untrusted user text into shell execution without proper quoting.
+
+## Step 1 — Map the State and Operation
+
+> [!IMPORTANT]
+> Execute steps directly; do not declare task boards or write artifact files. Run discrete git commands sequentially; never nest commands inside `$(...)` command substitutions or subshells.
+
+Identify the in-flight operation per [conflict matrix](references/conflict-matrix.md):
+- **Merge**: `.git/MERGE_HEAD` exists. `HEAD` is ours (target branch), `MERGE_HEAD` is theirs (incoming branch).
+- **Rebase**: `.git/rebase-merge` or `.git/rebase-apply` exists.
+  > [!WARNING]
+  > In `git rebase`, `--ours` and `--theirs` are **reversed**!
+  > - `HEAD` ("ours") is the upstream branch being rebased onto.
+  > - `REBASE_HEAD` ("theirs") is your branch commit being replayed.
+- **Cherry-pick**: `.git/CHERRY_PICK_HEAD` exists. `HEAD` is target branch, `CHERRY_PICK_HEAD` is commit being cherry-picked.
+
+Query all unmerged paths:
 ```bash
-git log --oneline <ours>..<theirs> -- <file>
-git log --oneline <theirs>..<ours> -- <file>
+git diff --name-only --diff-filter=U
 ```
 
-Read the commit messages; follow PR or issue references when the message
-alone does not explain the change. A hunk resolved without knowing both
-sides' intent is a guess wearing a merge commit.
-
-## Step 3 — Resolve each hunk
+## Step 2 — Reconstruct Both Intents
+
+For each conflicting file, determine why each side modified the code:
+- Check commit logs:
+  ```bash
+  # In merge:
+  git log --oneline HEAD..MERGE_HEAD -- <file>
+  git log --oneline MERGE_HEAD..HEAD -- <file>
+  # In rebase:
+  git log -1 REBASE_HEAD -- <file>
+  ```
+- Read commit messages and linked issue references. A resolution without understanding both intents is an ungrounded guess.
+
+## Step 3 — Resolve Each Conflict by Type
+
+Handle each file according to its conflict class:
+- **Content conflict markers**: Preserve both changes if compatible (e.g. non-overlapping functions or independent parameters). If incompatible, select the change aligned with the operation goal, or prompt the user via `ask_user`. Verify no markers remain:
+  ```bash
+  grep -rn "<<<<<<<\|>>>>>>>" <files>
+  ```
+- **Add / Add**: Merge file contents if same concept, or rename if distinct concepts.
+- **Modify / Delete**: Trace whether deletion was deliberate refactoring or accidental; preserve or remove accordingly.
+- **Rename**: Follow renamed files and integrate changes into the canonical filename.
+- **Binary files**: Check out appropriate version (`git checkout --ours` / `--theirs`) or rebuild asset from source.
+- **Submodules**: Resolve submodule commit pointer via `git diff --submodule` and submodule history.
+- **Lockfiles**: Do not manually resolve JSON/YAML markers in package lockfiles. Re-derive them via the package manager (`npm install --package-lock-only`, `pnpm install --lockfile-only`, `cargo check`, `uv lock`).
+
+Stage resolved files: `git add <files>`.
 
-- Both intents compatible → preserve both.
-- Genuinely incompatible → pick the side matching the merge's stated goal
-  and record the trade-off for the report; when the goal itself does not
-  decide it, ask the user rather than choosing silently.
-- Never invent new behavior in a resolution: the merged code does only
-  what one or both sides already did.
-- Do not `--abort` to escape a hard conflict; abort only if the user
-  decides the operation itself was wrong.
+## Step 4 — Validate
 
-Search for leftover markers before moving on:
-`grep -rn "<<<<<<<\|>>>>>>>" <conflicting files>` must return nothing.
+Run the validation suite determined by `--checks`:
+- If `auto`: execute detected typecheck, tests, and linter.
+- If `<command>`: execute the specified validation command.
+- If any check fails, fix regressions caused by the resolution before proceeding.
 
-## Step 4 — Validate
+## Step 5 — Complete Operation or Multi-Stop Loop
 
-Discover the project's own checks (CI workflow, manifest scripts,
-Makefile) and run them: typecheck, then tests, then lint/format. Fix
-anything the merge broke — the resolution is not done at "markers gone",
-it is done at "checks green".
+If `--no-continue` was specified:
+- Report that all conflicts are resolved and files are staged; stop here.
 
-## Step 5 — Complete the operation
+If `--continue` is active (default):
+- Execute the operation-specific continue command:
+  - **Merge**: `git merge --continue` (or `git commit`)
+  - **Rebase**: `git rebase --continue`
+  - **Cherry-pick**: `git cherry-pick --continue`
+- **Multi-stop rebases**: If git stops on a subsequent commit conflict, loop back to Step 1 and repeat until the rebase completes.
+- **Operation Abort**: If the user decides the operation is invalid or if unresolvable contradictions occur, run the operation-specific abort command (`git merge --abort`, `git rebase --abort`, or `git cherry-pick --abort`) and verify the tree returns to clean pre-operation state.
 
-Stage the resolved files and commit the merge; for a rebase or
-cherry-pick, `git rebase --continue` / `git cherry-pick --continue` and
-repeat from Step 1 for each further stop until the operation reports
-complete.
+## Step 6 — Report
 
-Done when the operation has fully finished, checks are green, and the
-report lists each conflict with which intent(s) survived and any recorded
-trade-offs.
+Summarize:
+- Completed operation type (merge, rebase, cherry-pick)
+- Each conflicting file, conflict type, and how intent was resolved
+- Validation checks run and real outputs
+- Current branch status and clean working tree verification
 
-## Red flags
+## Red Flags
 
-- Taking `--ours`/`--theirs` wholesale without reading either side.
-- A resolution that introduces logic neither side had.
-- Committing with conflict markers still in a file.
-- Declaring done without running the project's checks.
+- Taking `--ours` or `--theirs` wholesale without reading both sides.
+- Inverting intent during a rebase by misunderstanding reversed ours/theirs semantics.
+- Hand-editing conflict markers in binary files or complex lockfiles.
+- Leaving `<<<<<<<` or `>>>>>>>` markers in any committed file.
+- Declaring done without running validation checks.
+- Executing an abort without user instruction.

package/skills/git/resolve-merge-conflicts/evals.md

@@ -1,12 +1,9 @@
 # Evals — resolve-merge-conflicts
 
-Baseline scenarios (subagent WITHOUT the skill vs WITH). Pass/fail per
-bullet. Status: written at port time, not yet executed (`eval-status:
-untested`).
+Baseline scenarios (subagent WITHOUT the skill vs WITH). Pass/fail per bullet. Status: `eval-status: smoke-checked`.
 
-## S1 — compatible two-sided conflict
-Setup: the merge of feat-rename stopped on a conflict in util.js. Resolve
-it and finish the merge.
+## S1 — Compatible two-sided conflict
+Setup: the merge of feat-rename stopped on a conflict in util.js. Resolve it and finish the merge.
 
 Fixture:
 ```bash
@@ -28,31 +25,61 @@ git merge feat-rename > merge-output.txt 2>&1 || true
 ```
 
 Expected:
-- Reads both sides' history (log/show on main and feat-rename) before
-  touching the file.
-- Resolution preserves both intents: the function is named findUser and
-  getUserName calls findUser.
-- The merge is committed and no conflict markers remain in util.js.
+- Reads both sides' history (log/show on main and feat-rename) before editing.
+- Resolution preserves both intents: the function is named `findUser` and `getUserName` calls `findUser`.
+- The merge is committed and no conflict markers remain in `util.js`.
 
-## S2 — incompatible conflict
+## S2 — Incompatible conflict
 Setup: both sides changed the same default to different values.
+
+Expected:
+- Identifies the incompatibility. Picks per the merge's stated goal or prompts the user; trade-off recorded in the report.
+
+## S3 — Mid-rebase, multiple stops
+Setup: a rebase is stopped on its first conflict with more commits still to replay; resolve and finish the whole rebase.
+
 Expected:
-- Picks per the merge's stated goal, or asks when the goal doesn't decide;
-  trade-off recorded in the report.
+- Correctly treats `HEAD` as upstream target and `REBASE_HEAD` as incoming replayed commit (recognizes reversed ours/theirs).
+- Continues the rebase with `git rebase --continue` across multiple stops until complete.
+- Runs validation checks at completion.
+
+## S4 — Binary file conflict
+Setup: merge conflict on a binary asset (e.g. `logo.png`).
+
+Expected:
+- Detects binary conflict (no text conflict markers present).
+- Determines intended version and resolves using `git checkout --ours` or `git checkout --theirs`.
+- Stages binary asset with `git add logo.png`.
+
+## S5 — Modify/delete conflict
+Setup: one branch modified `helper.js`, the other deleted it.
 
-## S3 — mid-rebase, multiple stops
-Setup: a rebase is stopped on its first conflict with more commits still to
-replay; resolve and finish the whole rebase.
 Expected:
-- Continues the rebase after each resolution until complete; validates at
-  the end.
+- Checks git status for `CONFLICT (modify/delete)`.
+- Inspects the commit that deleted the file to determine if deletion was intentional.
+- Resolves by either staging the file (`git add helper.js`) or completing the deletion (`git rm helper.js`).
+
+## S6 — Operation-specific abort behavior
+Setup: user requests aborting an in-flight rebase or merge.
+
+Expected:
+- For merge: invokes `git merge --abort`.
+- For rebase: invokes `git rebase --abort`.
+- Verifies working tree returns to clean pre-operation state.
+
+## S7 — No-continue flag
+Setup: user runs `/skill:resolve-merge-conflicts --no-continue`.
+
+Expected:
+- Resolves all conflict markers and stages resolved files with `git add`.
+- Does not run `git merge --continue` or `git rebase --continue`.
+- Reports files staged and ready for user inspection.
 
 ## Baseline failure modes to watch for (RED)
-- `checkout --theirs` on everything to make it compile.
-- Invented "compromise" behavior neither side had.
-- `--abort` at the first hard hunk.
+- Running `git checkout --theirs` on everything to make markers go away.
+- Inverting intent during a rebase due to ours/theirs reversal.
+- Leaving conflict markers in files.
+- Running generic abort when resolution is achievable.
 
 ## Smoke record (2026-08-13)
-
-One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
-(30B local, llamacpp on mini), full-auto sandbox. PASS. Both sides' history read; both intents preserved; merge committed, no markers.
+One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning (30B local, llamacpp on mini), full-auto sandbox. PASS. Both sides' history read; both intents preserved; merge committed, no markers.