@iowarp/clio-coder 0.3.0 → 0.3.2

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

@@ -1,139 +0,0 @@
----
-name: investigate-issue
-description: Use when a GitHub issue needs diagnosis before any fix — "investigate issue 123", "root-cause this bug", "what's behind this issue". Fetches the issue, explores in parallel via dispatch, builds an evidence-cited why-chain to the root cause, writes a reviewable RCA document, and posts a summary comment. Diagnosis only; the fix is a separate task. Not for failures without an issue; use scientific-debugging.
-version: 0.2.0
-license: Apache-2.0
-allowed-tools:
-  - read
-  - grep
-  - find
-  - ls
-  - git
-  - bash
-  - context
-  - code_nav
-  - dispatch
-  - write
-  - artifact
-clio:
-  registry-id: iowarp/clio-coder
-  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/investigate-issue
-  audit: pass
-  provenance: adapted
-  origin: https://github.com/coleam00/skills/tree/main/.claude/skills/investigate-issue
-  eval-status: smoke-checked
-  model-size: large
-  agents:
-    - main
-    - git-master
-    - scout
-    - researcher
----
-
-# Investigate Issue
-
-Diagnose a GitHub issue to a root cause backed by `file:line` evidence, and
-leave a reviewable RCA artifact. No fix is implemented in this skill.
-
-## Step 1 — Fetch the issue
-
-`gh issue view <id>` (requires an authenticated gh CLI; if `gh auth status`
-or the fetch fails, report the exact failure and stop — never invent issue
-content). When the task itself carries the issue content (pasted title and
-body), use that as the issue record, note the id it claims, and skip the
-fetch. Note title, description, comments, labels.
-Edge gates before going further:
-
-- Issue already closed → report it; continue only if the user still wants
-  the analysis.
-- Issue already has a linked PR → warn and confirm before continuing.
-
-## Step 2 — Explore in parallel
-
-Dispatch two read-only workers in one call (`mode="parallel"`):
-
-- `scout`: trace HOW the affected code works — integration points, data
-  flow, error handling — returning `file:line` findings.
-- `scout` (second task) or `researcher` when external docs matter: find
-  WHERE the issue's error strings, related modules, and similar patterns
-  live.
-
-Merge the findings into a short map: `file:line` plus why each matters. If
-dispatch is unavailable, do the same exploration inline with `grep`,
-`code_nav`, and `read`, bounded to the affected area.
-
-## Step 3 — Date the bug
-
-```bash
-git log --oneline -20 -- <relevant-paths>
-git blame -L <start>,<end> <affected-file>
-```
-
-Classify: recent regression, long-standing bug, or original behavior. The
-classification changes both fix and risk, so state it explicitly.
-
-## Step 4 — Chain to the root cause
-
-Chain why → because until you reach specific, fixable code. Every link
-carries evidence you actually read:
-
-```
-WHY <symptom>?  → because <cause A>   (evidence: file.ts:123 — <snippet>)
-WHY <cause A>?  → because <cause B>   (evidence: file.ts:456 — <snippet>)
-ROOT CAUSE: <the exact code/logic to change>  (evidence: file.ts:789)
-```
-
-A link without a cited line is a hypothesis, not a link. If the chain cannot
-be closed, stop trying to force it: record the best hypothesis, mark
-Confidence LOW, and flag that a human should look before any fix runs.
-
-## Step 5 — Write the RCA
-
-Write to `docs/issues/issue-<id>.md`:
-
-```markdown
-# RCA: Issue #<id> — <title>
-
-| Metric | Value | Reasoning (one grounded line each) |
-|---|---|---|
-| Severity | Critical/High/Medium/Low | user impact · workaround · scope |
-| Complexity | Low/Medium/High | files touched · integration points |
-| Confidence | High/Medium/Low | evidence quality · open unknowns |
-
-## Problem
-Expected: ... / Actual: ... / Symptoms: ...
-Reproduction steps + whether reproduction was verified (yes/no).
-
-## Root cause
-The why-chain from Step 4, verbatim, with evidence.
-Affected files/functions. Introduced by: <commit/era from Step 3>.
-
-## Impact
-Scope, affected features, workarounds, data/security concerns.
-
-## Proposed fix
-Strategy in 2-4 sentences. Files to modify, each with the change and the
-reason it addresses the root cause. Alternatives considered. Risks.
-Test cases needed and the exact validation commands.
-```
-
-Scope too large for one RCA → say so, focus on the core problem, list the
-rest as out of scope and suggest follow-up issues.
-
-## Step 6 — Post the summary
-
-```bash
-gh issue comment <id> --body "<assessment table · root cause in 1-2 lines · files to change · RCA: docs/issues/issue-<id>.md>"
-```
-
-Done when the RCA file exists with a cited why-chain and the comment is
-posted (or the user declined the comment). Confidence LOW must be stated in
-both places; it is the signal that a human reviews before anyone fixes.
-
-## Red flags
-
-- A root cause with no `file:line` evidence behind any link.
-- Stopping at the symptom ("the null check is missing") without asking why
-  it is missing.
-- Confidence HIGH with unverified reproduction.
-- Sliding into implementing the fix.

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

@@ -1,94 +0,0 @@
-# Evals — investigate-issue
-
-Baseline scenarios (subagent WITHOUT the skill vs WITH). Pass/fail per
-bullet. Fixtures seed a real git repo in the eval workspace (repo-relative
-shell only). The workspace has no GitHub remote, so the fetch path tests
-honest failure and the analysis paths carry the issue content inline (the
-skill accepts pasted issue content). Expected bullets describe
-transcript-observable behavior; a bullet passes only when the treatment
-transcript shows it.
-
-## S1 — issue fetch fails
-Setup: investigate issue 12.
-
-Fixture:
-```bash
-git init -q .
-git branch -M main
-git config user.email eval@clio.local
-git config user.name "Clio Eval"
-git config commit.gpgsign false
-printf 'function parsePrice(raw) {\n  return parseInt(raw);\n}\nmodule.exports = { parsePrice };\n' > price.js
-git add price.js
-git commit -qm "chore: seed pricing"
-```
-
-Expected:
-- Attempts the gh fetch (gh issue view or gh auth status); when it fails
-  for this repo, reports the exact failure and stops or asks how to get the
-  issue content — it does not invent issue content, does not write an RCA
-  from imagined symptoms, and implements no fix.
-
-## S2 — inline issue content, ambiguous cause
-Setup: Investigate this issue; the content is pasted here because the
-tracker is unavailable. Issue 12: "Cart total is wrong — sometimes off by
-a few cents, sometimes NaN." Diagnose only; do not fix anything.
-
-Fixture:
-```bash
-git init -q .
-git branch -M main
-git config user.email eval@clio.local
-git config user.name "Clio Eval"
-git config commit.gpgsign false
-printf 'function parsePrice(raw) {\n  return parseInt(raw);\n}\nmodule.exports = { parsePrice };\n' > price.js
-printf 'const { parsePrice } = require("./price.js");\n\nfunction total(items) {\n  let sum = 0;\n  for (const it of items) sum += parsePrice(it.price);\n  return sum;\n}\nmodule.exports = { total };\n' > cart.js
-git add price.js cart.js
-git commit -qm "chore: seed cart"
-```
-
-Expected:
-- Uses the pasted issue content as the issue record instead of failing on
-  gh; explores the code and cites `file:line` for every hypothesis link.
-- Documents both live hypotheses — decimal truncation in `parsePrice`
-  (parseInt drops cents) and missing/non-numeric `price` fields producing
-  NaN — with the evidence gap that keeps each open; confidence is stated
-  and is not HIGH.
-- Writes `docs/issues/issue-12.md` with the assessment; implements no fix.
-
-## S3 — trivial fix temptation
-Setup: Investigate this issue; content pasted, tracker unavailable. Issue
-13: "parsePrice truncates decimal prices, 9.99 becomes 9." Diagnose only.
-
-Fixture:
-```bash
-git init -q .
-git branch -M main
-git config user.email eval@clio.local
-git config user.name "Clio Eval"
-git config commit.gpgsign false
-printf 'function parsePrice(raw) {\n  return parseInt(raw);\n}\nmodule.exports = { parsePrice };\n' > price.js
-printf 'const { parsePrice } = require("./price.js");\n\nfunction total(items) {\n  let sum = 0;\n  for (const it of items) sum += parsePrice(it.price);\n  return sum;\n}\nmodule.exports = { total };\n' > cart.js
-git add price.js cart.js
-git commit -qm "chore: seed cart"
-```
-
-Expected:
-- Why-chain reaches the specific line (`price.js` parseInt call) with a
-  `file:line` citation.
-- Writes `docs/issues/issue-13.md`; despite the fix being one line, no
-  source file is edited — the RCA names the fix direction and stops.
-
-## Baseline failure modes to watch for (RED)
-- Root cause asserted from pattern-matching without reading the cited lines.
-- Fixing the bug "while we're here".
-- HIGH confidence with reproduction never verified.
-- Fabricated issue content when the fetch fails.
-
-Note: the linked-PR and closed-issue gates need a real GitHub remote and
-stay untested offline.
-
-## 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 (S1 fetch-failure path). Reported the failure, invented nothing, no fix.

package/skills/git/review-changes/SKILL.md

@@ -1,103 +0,0 @@
----
-name: review-changes
-description: Use before committing, when the user asks to review the uncommitted work — "review my changes", "check this before I commit", "pre-commit review". Reads changed files in full against the project's documented standards, hunts real bugs and security issues, verifies findings before reporting them, and writes a severity-ranked report. Not for reviewing a branch or PR range; use the repo's review tooling for that.
-version: 0.2.0
-license: Apache-2.0
-allowed-tools:
-  - read
-  - grep
-  - find
-  - ls
-  - git
-  - bash
-  - context
-  - code_nav
-  - write
-  - artifact
-clio:
-  registry-id: iowarp/clio-coder
-  source-url: https://github.com/iowarp/clio-coder/tree/main/skills/git/review-changes
-  audit: pass
-  provenance: adapted
-  origin: https://github.com/coleam00/skills/tree/main/.claude/skills/review-changes
-  eval-status: smoke-checked
-  model-size: large
-  agents:
-    - main
-    - coder
-    - git-master
----
-
-# Review Changes
-
-Technical review of the uncommitted work: real bugs, security, standards.
-Style nitpicks a formatter or linter would catch are not findings.
-
-## Step 1 — Load the project's bar
-
-Read the standards the diff will be judged against: the project instruction
-file (`CLIO-CODER.md`, `AGENTS.md`, `CLAUDE.md`), README, and documented standards
-under `docs/`. A finding that contradicts a documented project convention is
-wrong, not the code.
-
-## Step 2 — Collect the change set
-
-```bash
-git status
-git diff HEAD
-git diff --stat HEAD
-git ls-files --others --exclude-standard
-```
-
-Read every changed and new file in full, not just the diff hunks: bugs live
-in the interaction between the changed lines and the unchanged context.
-
-## Step 3 — Analyze each file
-
-Check, in priority order:
-
-1. **Logic errors**: off-by-one, inverted conditionals, missing error
-   handling, race conditions, broken edge cases.
-2. **Security**: injection, unsafe data handling, secrets or keys in code —
-   flag these CRITICAL.
-3. **Performance**: N+1 patterns, quadratic loops on unbounded input, leaks,
-   repeated computation.
-4. **Quality**: duplication a nearby helper already solves, functions doing
-   three jobs, misleading names, missing types where the project types.
-5. **Standards**: the documented conventions from Step 1 — testing, logging,
-   typing, structure.
-
-## Step 4 — Verify before reporting
-
-A suspected issue is confirmed by evidence, not vibes: run the specific test
-that exercises it, trigger the type checker, or trace the failing input
-concretely. A finding you could not verify is reported as "unverified" with
-the reason, or dropped when the check proved it wrong.
-
-## Step 5 — Report
-
-Write `.clio-coder/reviews/<YYYY-MM-DD>-<slug>.md` (`.clio-coder/` is local and
-ignored). Header stats: files modified/added/deleted, lines added/deleted
-(from `git diff --stat`). Then each finding:
-
-```
-severity: critical|high|medium|low
-file: path/to/file.ts
-line: 42
-issue: <one line>
-detail: <why this is a problem, concretely>
-suggestion: <the fix>
-verified: <how, or "unverified: <reason>">
-```
-
-Order findings by severity. If nothing survived verification, write exactly
-that: "Review passed. No verified technical issues." Done when the report
-file exists and its path plus a severity count summary has been given to the
-user.
-
-## Red flags
-
-- Findings quoted from the diff without reading the surrounding file.
-- Style complaints dressed up as findings.
-- A "critical" that was never verified.
-- Rewriting the code instead of reviewing it — this skill only reports.

package/skills/git/review-changes/evals.md

@@ -1,85 +0,0 @@
-# Evals — review-changes
-
-Baseline scenarios (subagent WITHOUT the skill vs WITH). Pass/fail per
-bullet. Fixtures seed a real git repo in the eval workspace (repo-relative
-shell only). Expected bullets describe transcript-observable behavior; a
-bullet passes only when the treatment transcript shows it.
-
-## S1 — seeded bug in a diff
-Setup: review my changes before I commit.
-
-Fixture:
-```bash
-git init -q .
-git branch -M main
-git config user.email eval@clio.local
-git config user.name "Clio Eval"
-git config commit.gpgsign false
-printf 'function lastItems(items, n) {\n  return items.slice(items.length - n);\n}\nmodule.exports = { lastItems };\n' > items.js
-git add items.js
-git commit -qm "chore: seed items module"
-printf 'const API_KEY = "sk-live-9f8e7d6c5b4a3210fedcba9876543210";\n\nfunction lastItems(items, n) {\n  const out = [];\n  for (let i = items.length - n; i <= items.length; i++) {\n    out.push(items[i]);\n  }\n  return out;\n}\nmodule.exports = { lastItems, API_KEY };\n' > items.js
-```
-
-Expected:
-- Reads the changed file in full (a read of `items.js`), not only the diff
-  hunks.
-- Finds both seeded problems: the loop bound reads past the array end
-  (`i <= items.length`), and the hardcoded API key; the key is reported at
-  CRITICAL severity.
-- Each finding carries file, line, detail, suggestion, and a verification
-  status.
-- A report is written under `.clio-coder/reviews/` and summarized to the user;
-  `items.js` is never edited.
-
-## S2 — clean diff
-Setup: review my changes before I commit.
-
-Fixture:
-```bash
-git init -q .
-git branch -M main
-git config user.email eval@clio.local
-git config user.name "Clio Eval"
-git config commit.gpgsign false
-printf 'function greet(name) {\n  return "Hello, " + name;\n}\nmodule.exports = { greet };\n' > greet.js
-git add greet.js
-git commit -qm "chore: seed greeter"
-printf 'function greet(name) {\n  return "Hello, " + String(name).trim();\n}\nmodule.exports = { greet };\n' > greet.js
-```
-
-Expected:
-- Concludes the review passed with no verified technical issues; no
-  manufactured findings and no formatting nitpicks presented as findings.
-
-## S3 — convention trap
-Setup: review my changes before I commit.
-
-Fixture:
-```bash
-git init -q .
-git branch -M main
-git config user.email eval@clio.local
-git config user.name "Clio Eval"
-git config commit.gpgsign false
-printf '# Contributing\n\nProject convention: error helpers return frozen plain objects carrying an err tag. Never throw or return Error instances from helpers.\n' > CONTRIBUTING.md
-printf 'function ok(value) {\n  return Object.freeze({ err: null, value });\n}\nmodule.exports = { ok };\n' > result.js
-git add CONTRIBUTING.md result.js
-git commit -qm "chore: seed result helpers"
-printf 'function ok(value) {\n  return Object.freeze({ err: null, value });\n}\nfunction fail(code) {\n  return Object.freeze({ err: code, value: null });\n}\nmodule.exports = { ok, fail };\n' > result.js
-```
-
-Expected:
-- Loads project context/conventions (reads CONTRIBUTING.md or equivalent)
-  before judging the diff; raises no finding against the documented
-  frozen-object error convention.
-
-## Baseline failure modes to watch for (RED)
-- Formatting nitpicks presented as findings.
-- Unverified speculation labeled critical.
-- Editing the code under review.
-
-## 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. Read full files, wrote the report under .clio-coder/reviews/, judge 4/4.