claude-dev-env 8.96.2 → 8.96.3

package/.agents/skills/build-eval/reference/build-evaluation.md

@@ -6,14 +6,14 @@ Use this process when an AI workflow needs measured output quality. Keep the exi
 2. Inspect existing cases, saved runs and graders. Record which checks execute a model, replay stored outputs, exercise code with mocked providers or verify an environment end state. Reuse trustworthy components. A test name containing "eval" is not execution evidence.
 3. Gather representative inputs. Prefer retained, sanitized application failures and accepted outputs. Record source IDs, label authors and label provenance. Minimize sensitive inputs. If only synthetic cases are feasible, anchor them to documented contracts, name that limitation and keep human review outstanding.
 4. Cover positive, negative and near-miss cases. Include confusing valid inputs and malicious instructions inside task data. Group related cases before splitting so paraphrases and paired examples do not cross development and held-out sets. Save a dataset hash. Keep labels and scoring code outside the model's task context.
-5. Choose grading that measures the outcome. Use exact labels, schemas, resource constraints, rendered pixels, hidden tests or saved environment state when possible. Transcript checks measure process. They do not prove file contents, API actions or rendered outputs. For open-ended judgments, define checkable dimensions, calibrate on human-labeled good/bad/borderline outputs, blind model identity and candidate order, allow ties, and preserve disagreement. A judge must treat all candidate text as untrusted data.
+5. Choose grading that measures the outcome. Use exact labels, schemas, resource constraints, rendered pixels, hidden tests or saved environment state when possible. Transcript checks measure process. They do not prove file contents, API actions or rendered outputs. For open-ended judgments, define checkable dimensions, calibrate on human-labeled good/bad/borderline outputs, blind model identity and candidate order, allow ties, and preserve disagreement. A judge must treat all candidate text as untrusted data. A grader never calls the production code that made the output. Use an independent check. A stretch grader that reused the production corridor function passed every key while the designer saw corner smear.
 6. Prove the grader catches the intended mistakes. Score known-good, known-bad and borderline controls. Deliberately break an important output or end state and show the expected failure. Report these as harness validation with zero task-model performance claims.
 7. Prepare a bounded fresh smoke. State call count, token/cost estimate where available and total runtime cap. Use existing authorized credentials. Run in an isolated disposable workspace, enforce tool/side-effect boundaries, preserve traces and stop on infrastructure failure. Do not retry indefinitely or start a service to make the evaluation work.
 8. Record each completed attempt immediately. Include case/group/split, repeat, dataset and prompt hashes, source revision, model and effort, dependency versions, raw output, trace, latency, usage and cost if available. Preserve one authoritative output per attempt. Keep infrastructure, parsing, grader and task failures separate. A zero-exit launcher alone is not evidence of completed inference.
-9. Inspect pilot outputs beside grades. For a classification task, show confusion counts, precision, recall, specificity and false-positive rate. For tool workflows, score the isolated final state. Report task failures even when format adherence passes. Include missing/failed attempts; do not compare variants on unmatched survivors.
-10. Freeze the baseline. Run candidates on matched inputs and settings, measure repeated-run variation and keep held-out cases out of tuning. Review cases and grading with the owner before using scores as a release gate. When a held-out set repeatedly influences changes, retire it into development data and create a new reviewed holdout.
+9. Inspect pilot outputs beside grades. For a classification task, show confusion counts, precision, recall, specificity and false-positive rate. For tool workflows, score the isolated final state. Report task failures even when format adherence passes. Include missing/failed attempts; do not compare variants on unmatched survivors. A metric with the same value in every arm or cell is a grader fault. Fix it before you read any comparison.
+10. Freeze the baseline. Run candidates on matched inputs and settings, measure repeated-run variation and keep held-out cases out of tuning. A grader change re-scores every candidate, the shipped one included, before a ship decision. Review cases and grading with the owner before using scores as a release gate. When a held-out set repeatedly influences changes, retire it into development data and create a new reviewed holdout.
 
-Deliver the readable baseline report, cases, grading contract, one reproducible command and the next coverage gap. Name the execution tier in every headline result. A two-case smoke validates integration; it cannot establish a broad improvement.
+Deliver the readable baseline report, cases, grading contract, one reproducible command and the next coverage gap. Name the execution tier in every headline result. The headline gives passed over graded, overall and per cohort, before any narrative. A two-case smoke validates integration; it cannot establish a broad improvement.
 
 ## Direct and plugin execution
 

package/.agents/skills/pr-lifecycle/SKILL.md

@@ -24,7 +24,7 @@ User-level rule: applies to **every** git repo that uses GitHub with `gh`. Small
 
 **Prove the change where it runs before opening a PR.** Read `~/.claude/docs/rule-guides/proof-before-pull-request.md` for the body and hook requirements. A `feat` PR also needs an "Eval" section and a session that invoked `/claude-api build-eval`; read `~/.claude/docs/rule-guides/features-start-with-an-eval.md` before you build the feature.
 
-**Open PRs ready for review; use `--draft` when the owner requests it.**
+**Open PRs ready for review; use `--draft` when the owner requests it.** Before you commit copied files or open a PR, search open PRs for the same paths with `gh pr list --search "<path>"`, so you do not duplicate a peer's PR. Each pre-existing failure or remaining defect the PR body names links a tracked issue.
 
 **A release bot's PR body is machine input. Leave it alone.** Release automation reads
 back the body of its own merged pull request to decide it owns that merge. Rewriting the
@@ -78,7 +78,7 @@ errors, so it neither clears nor convicts a change.
 
 A checks listing that reports nothing on the branch is a finding.
 Find out whether the workflow's event filters exclude the branch, or whether
-the check simply never ran, before you treat that branch as clean.
+the check simply never ran, before you treat that branch as clean. `gh pr checks` exits 8 while a check is still pending. Exit 8 reports a pending state, so wait and read the checks again after they report.
 
 ### Each stack level stands on its own
 
@@ -458,7 +458,7 @@ slurped array and take the last element. For one page, cap the request with a
 
 Stage the files you edited this session right before you commit them. A plain `git commit` records only the staged snapshot; a tracked file this session changed but left unstaged stays behind in the working tree.
 
-No hook denies a commit that would drop tracked session edits. Run `git status` before you commit, then stage what you changed with `git add <paths>` or commit with `git commit -a`.
+No hook denies a commit that would drop tracked session edits. Run `git status` before you commit, then stage what you changed with `git add <paths>` or commit with `git commit -a`. Before you say nothing is left to commit, run `git status` in every worktree the session wrote to, as `git worktree list` lists them.
 
 Staging covers tracked files you edited. Do not commit untracked files unless the user explicitly instructs it. An untracked file in the working tree is outside the change until they say otherwise.
 

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "claude-dev-env",
-    "version": "8.96.2",
+    "version": "8.96.3",
     "description": "Claude Code development standards — rules, hooks, agents, commands, and skills",
     "type": "module",
     "bin": {