@iowarp/clio-coder 0.4.6 → 0.4.8

package/skills/git/branch-closeout/SKILL.md

@@ -1,132 +0,0 @@
----
-name: branch-closeout
-description: Proves merged work on the canonical base, inspects and removes associated worktrees through Git, deletes local branches safely, and audits surviving repository refs. Not for creating worktrees; use worktree-create. Not for integrating branches; use worktree-merge.
-triggers:
-  - close out this branch
-  - clean up merged branch
-  - remove merged worktree
-  - closeout branch
-  - branch-closeout
-version: 0.1.0
-license: Apache-2.0
-compatibility: git >=2.30.0, gh CLI >=2.0.0 (optional for remote PR verification), POSIX-compatible shell
-allowed-tools:
-  - read
-  - grep
-  - ls
-  - git
-  - bash
-  - tasks
-  - ask_user
-clio-coder:
-  registry-id: iowarp/clio-coder
-  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/branch-closeout
-  audit: pass
-  provenance: designed
-  eval-status: scenarios-recorded
-  model-size: any
-  agents:
-    - main
-    - git-master
----
-
-# Branch Closeout
-
-Safely tear down local scaffolding after work has merged. Closeout proves landing evidence before removing any ref or worktree, distinguishes canonical and fork remotes, protects dirty or ignored worktree state, and audits surviving repository references.
-
-See [the closeout checklist](references/closeout-checklist.md) for detailed commands and edge cases.
-
-## Arguments
-
-Arguments are passed in the user invocation message. Interpret them structurally from the prompt:
-
-```text
-/skill:branch-closeout [--canonical remote] [--base branch] [--delete-fork-branch] <branch...>
-```
-
-### Examples
-- `/skill:branch-closeout feat/worker-profiles`
-- `/skill:branch-closeout --base main --canonical upstream fix/session-leak`
-- `/skill:branch-closeout --delete-fork-branch feat/issue-99`
-
-### Positional Arguments
-- `<branch...>`: One or more local branch names to close out.
-  - Required. If missing, prompt the user for the branch name; never guess.
-  - Must be valid ref names (`git check-ref-format --branch <branch>`).
-
-### Options
-- `--canonical <remote>`: Remote name of the canonical upstream repository.
-  - Default: detected canonical remote from repository URLs or `upstream` / `origin`.
-- `--base <branch>`: Base branch on which the changes landed.
-  - Default: detected canonical default branch (e.g. `main` or `master`).
-- `--delete-fork-branch`: Delete the corresponding branch on the contributor's fork remote after local closeout.
-  - Default: `false`.
-  - Refusal Guard: If the fork remote resolves to the canonical repository, this option is strictly refused.
-
-### Unknown Arguments and Validation
-- Unknown flags must be rejected with an error; do not pass unknown options to git or gh.
-- Ref names and paths must be validated before execution. Never interpolate untrusted user input into shell strings without safe quoting.
-
-## Step 1 — Detect Remotes and Policy
-
-1. Identify `<canonical>` remote: inspect `git remote -v` and `gh repo view`.
-2. Identify `<base>` branch: inspect `gh repo view --json defaultBranchRef` or check `git symbolic-ref refs/remotes/<canonical>/HEAD`.
-3. Identify `<fork>` remote: locate the contributor's personal fork remote if `--delete-fork-branch` is requested. If `<canonical>` is the only remote, fork deletion is not applicable.
-
-## Step 2 — Prove Integration
-
-Never delete a branch based on similar commit subjects or author names alone.
-For each `<branch>`:
-1. `git fetch --prune <canonical>`
-2. **Direct ancestry**: Check if the branch is fully merged:
-   ```bash
-   git merge-base --is-ancestor <branch> <canonical>/<base>
-   ```
-3. **Squash or Cherry-Pick**: If ancestry fails, verify if a squash merge landed via PR:
-   ```bash
-   gh pr view <branch> --repo <canonical> --json state,mergedAt,mergeCommit
-   ```
-   Confirm that the reported `mergeCommit.oid` is present on `<canonical>/<base>`.
-4. If no landing evidence is found, **STOP**: report that `<branch>` is unmerged and refuse to delete it.
-
-## Step 3 — Inspect Worktree State
-
-1. Query registered worktrees via `git worktree list --porcelain`.
-2. If a worktree is registered for `<branch>`:
-   - Check for uncommitted tracked modifications: `git -C <path> status --porcelain`
-   - Check for untracked and ignored artifacts: `git -C <path> status --ignored --porcelain`
-   - If dirty changes or non-rebuildable artifacts exist, prompt the user via `ask_user` before removal.
-3. Remove the registered worktree with `git worktree remove <path>`.
-   - Never use `rm -rf`.
-   - Use `--force` only if the user explicitly approved discarding remaining uncommitted/untracked artifacts.
-
-## Step 4 — Delete Branches Safely
-
-1. Delete the local branch:
-   ```bash
-   git branch -d <branch>
-   ```
-2. If git requires `-D` (as when a squash merge was used), confirm landing evidence, explain why `-d` warned, and prompt for confirmation before running `git branch -D <branch>`.
-3. If `--delete-fork-branch` is set and authorized:
-   - Verify `<fork>` is not `<canonical>`.
-   - Run `git push --delete <fork> refs/heads/<branch>`.
-   - Never delete branches from `<canonical>`, and never delete `<base>`.
-
-## Step 5 — Report Surviving State
-
-Audit and output the complete survivor inventory:
-- Remaining worktrees (`git worktree list`)
-- Remaining local branches (`git branch`)
-- Remaining stashes (`git stash list`)
-- Local-only tags (`git tag -l` vs remote tags)
-- Canonical remote heads (`git ls-remote --heads <canonical>`)
-
-In a canonical-main-only repository, the expected canonical head set is strictly `refs/heads/<base>`. Report any extra heads as anomalies.
-
-## Red Flags
-
-- Deleting a branch without verifying ancestry or squash PR evidence on the canonical base.
-- Deleting or attempting to delete canonical `main` or canonical remote branches.
-- Using `rm -rf` instead of `git worktree remove`.
-- Force-removing a dirty worktree without explicit user approval.
-- Implicitly dropping stashes, local tags, or unrelated branches during cleanup.

package/skills/git/file-ticket/SKILL.md

@@ -1,126 +0,0 @@
----
-name: file-ticket
-description: "Turns something noticed mid-session into a tracker issue: captures evidence, dedups against existing issues, composes a labeled issue with acceptance criteria, confirms, and creates it via gh. Not for batch ticket creation from a PRD; use backlog. Not for diagnosing an existing issue; use fix-issue."
-triggers:
-  - file a ticket
-  - open an issue for this
-  - log this bug
-  - ticket this behavior
-  - create a tracker issue
-version: 0.3.0
-license: Apache-2.0
-compatibility: git >=2.30.0, gh CLI >=2.0.0 (authenticated for issue operations), POSIX-compatible shell
-allowed-tools:
-  - read
-  - grep
-  - ls
-  - git
-  - bash
-  - tasks
-  - ask_user
-clio-coder:
-  registry-id: iowarp/clio-coder
-  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/file-ticket
-  audit: pass
-  provenance: designed
-  eval-status: scenarios-recorded
-  model-size: any
-  agents:
-    - main
----
-
-# File Ticket
-
-Turn one observed behavior into one well-formed tracker issue, then stop. The ticket is the deliverable; the fix belongs to a later skill in the pipeline (`fix-issue` picks it up from here).
-
-See [issue discovery](references/issue-discovery.md) for template, label, and milestone discovery details, and [issue template](assets/issue-template.md) for the default body layout.
-
-## Arguments
-
-Arguments are passed in the user invocation message. Interpret them structurally from the prompt:
-
-```text
-/skill:file-ticket [--repo owner/repo] [--type type] [--milestone name] <observation>
-```
-
-### Examples
-- `/skill:file-ticket settings overlay crashes when terminal is narrower than 40 columns`
-- `/skill:file-ticket --type bug --milestone v1.2 "memory leak in worker pool"`
-- `/skill:file-ticket --repo owner/custom-repo --type enhancement add dark mode support`
-
-### Positional Arguments
-- `<observation>`: Free-text description of the observed defect, symptom, or enhancement.
-  - Required if not already established in recent session conversation.
-  - If omitted, prompt the user for the observed behavior.
-
-### Options
-- `--repo <owner/repo>`: Target GitHub repository.
-  - 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_.-]+$`.
-- `--type <type>`: Issue category.
-  - Allowed: `bug`, `enhancement`, `documentation`, `question` (or repository-defined issue types).
-  - Default: inferred from `<observation>` or confirmed with user via `ask_user`.
-- `--milestone <name>`: Open milestone to attach to the ticket.
-  - Default: none (or repository triage default).
-  - Validation: Must match an open milestone returned by the GitHub API.
-
-### Unknown Arguments and Safe Quoting
-- Unknown options must be rejected with an error; do not pass unknown flags to `gh`.
-- Never interpolate raw user strings into double-quoted shell command strings. Write the issue body to a temporary file and pass `--body-file "$tmpfile"` to prevent command substitution or backtick evaluation.
-
-## Step 1 — Capture
-
-From the session that surfaced the behavior, record before anything scrolls away:
-- **Type**: bug, enhancement, documentation, or question. Uncertain -> ask via `ask_user`; never guess between bug and enhancement.
-- **Observed vs expected**: what actually happened, in the reporter's words, and what should have happened.
-- **Reproduction**: the exact commands, slash commands, or session steps that showed the behavior. Only steps actually performed; a repro you did not run is written as "unverified".
-- **Evidence**: when the code location is already known or findable in one short grep pass, cite it as `file:line`. Stop after at most a few minutes of searching.
-
-Complete when every bullet above is either filled or explicitly marked unknown.
-
-## Step 2 — Resolve Repository and Dedup
-
-1. Determine `--repo <owner/repo>` (provided flag or detected via `gh repo view`).
-2. Search for existing issues:
-   ```bash
-   gh issue list --repo <owner/repo> --search "<key terms>" --state all --limit 20
-   ```
-   Requires an authenticated `gh` CLI; if the command fails, report the exact failure and stop rather than filing blind.
-3. **Open duplicate found**:
-   - Do NOT file a new issue.
-   - Compose a comment with the new evidence and repro details.
-   - **Mandatory confirmation**: Present the target issue URL and the exact comment text to the user via `ask_user`. Execute `gh issue comment <id> --repo <owner/repo> --body-file "$tmpfile"` ONLY after the user confirms.
-   - Report that issue's URL as the outcome and end.
-4. **Closed duplicate found**:
-   - Continue to file a new issue and link the closed issue in the body's Links section.
-
-## Step 3 — Discover Taxonomy and Compose
-
-1. Discover repository issue templates, labels, and open milestones per [issue discovery](references/issue-discovery.md).
-2. Format the ticket:
-   - **Title**: conventional tag plus a specific imperative summary (`fix: ...`, `feat: ...`, `docs: ...`). Never a bare noun.
-   - **Body**: Problem (observed vs expected), Reproduce, Evidence (`file:line` pointers and session excerpts), Acceptance criteria as a verifiable checklist, and Links. Use [the standard template](assets/issue-template.md) when no repository template matches.
-   - **Labels**: one type label (`bug`, `enhancement`, etc.) plus applicable discovered area/component labels (`area:*`). Propose new labels to the user rather than creating them silently.
-   - **Milestone**: apply `--milestone` if specified and valid; otherwise leave unassigned.
-
-## Step 4 — Confirm Every Outward Action
-
-Show the full title, repository, labels, milestone, and complete body.
-Obtain explicit approval via `ask_user`. Issue creation is an outward-facing change; nothing is created before the user explicitly confirms.
-
-## Step 5 — Create and Hand Off
-
-Write the body to a file and execute:
-```bash
-gh issue create --repo <owner/repo> --title "..." --body-file "$tmpfile" --label "..." [--milestone "..."]
-```
-Run creation exactly once, verify with `gh issue view`, report the issue number and URL, and name the next pipeline step: `fix-issue`.
-
-## Red Flags
-
-- Filing without the Step 2 dedup search.
-- Posting a comment on an existing duplicate without explicit user confirmation.
-- Sliding into fixing the bug instead of filing it.
-- Passing raw user text in `gh issue create --body "..."` instead of using `--body-file`.
-- Creating repository labels or milestones nobody approved.
-- Batch-filing multiple tickets; that is `backlog`'s job.

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

@@ -1,136 +0,0 @@
----
-name: fix-issue
-description: "Resolves a tracker issue end to end: fetches it, diagnoses only when the issue does not name the code, fixes test-first, and self-reviews against the acceptance criteria, leaving a verified uncommitted change. Not for filing; use file-ticket. Not for committing or PRs; use ship."
-triggers:
-  - fix issue 123
-  - take this ticket
-  - resolve the bug in issue
-  - implement this tracker issue
-  - fix a GitHub issue end to end
-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
-  - find
-  - ls
-  - git
-  - bash
-  - context
-  - code_nav
-  - dispatch
-  - tasks
-  - write
-  - edit
-clio-coder:
-  registry-id: iowarp/clio-coder
-  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/fix-issue
-  audit: pass
-  provenance: designed
-  eval-status: smoke-checked
-  model-size: any
-  agents:
-    - main
-    - 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 completion report; committing, pushing, and PRs belong to `ship`.
-
-See [diagnosis and RCA](references/diagnosis-and-rca.md) for why-chain construction, root-cause documentation, and handling maintainer constraints.
-
-## Arguments
-
-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>
-```
-
-### 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
-
-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
-
-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
-
-Handoff: Inform the user that the change is verified and uncommitted, ready for `ship`.
-
-## Red Flags
-
-- 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/resolve-merge-conflicts/SKILL.md

@@ -1,151 +0,0 @@
----
-name: resolve-merge-conflicts
-description: Resolves a merge, rebase, or cherry-pick stopped on conflicts by reconstructing both sides' intent, validating with the project's own checks, and completing the operation. Not for integrating many branches; use worktree-merge.
-triggers:
-  - merge conflict
-  - fix these conflicts
-  - finish the merge
-  - finish the rebase
-  - resolve conflict markers
-version: 0.4.0
-license: Apache-2.0
-compatibility: git >=2.30.0, POSIX-compatible shell
-allowed-tools:
-  - read
-  - grep
-  - ls
-  - git
-  - bash
-  - edit
-  - write
-  - verify
-  - tasks
-  - ask_user
-clio-coder:
-  registry-id: iowarp/clio-coder
-  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/resolve-merge-conflicts
-  audit: pass
-  provenance: adapted
-  origin: https://github.com/mattpocock/skills/tree/main/skills/engineering/resolve-merge-conflicts
-  eval-status: smoke-checked
-  model-size: any
-  agents:
-    - main
-    - coder
-    - git-master
----
-
-# Resolve Merge Conflicts
-
-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.
-
-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).
-
-## Arguments
-
-Arguments are passed in the user invocation message. Interpret them structurally from the prompt:
-
-```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 diff --name-only --diff-filter=U
-```
-
-## 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>`.
-
-## Step 4 — Validate
-
-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 5 — Complete Operation or Multi-Stop Loop
-
-If `--no-continue` was specified:
-- Report that all conflicts are resolved and files are staged; stop here.
-
-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.
-
-## Step 6 — Report
-
-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
-
-- 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,85 +0,0 @@
-# Evals — resolve-merge-conflicts
-
-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.
-
-Fixture:
-```bash
-git init -q .
-git branch -M main
-git config user.email eval@clio-coder.local
-git config user.name "Clio Coder Eval"
-git config commit.gpgsign false
-printf 'function getUser(id) {\n  return db.find(id);\n}\n\nmodule.exports = { getUser };\n' > util.js
-git add util.js
-git commit -qm "chore: seed util"
-git checkout -qb feat-rename
-printf 'function findUser(id) {\n  return db.find(id);\n}\n\nmodule.exports = { findUser };\n' > util.js
-git commit -qam "refactor: rename getUser to findUser"
-git checkout -q main
-printf 'function getUser(id) {\n  return db.find(id);\n}\n\nfunction getUserName(id) {\n  return getUser(id).name;\n}\n\nmodule.exports = { getUser, getUserName };\n' > util.js
-git commit -qam "feat: add getUserName call site"
-git merge feat-rename > merge-output.txt 2>&1 || true
-```
-
-Expected:
-- 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
-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:
-- 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.
-
-Expected:
-- 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)
-- 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.