@clipboard-health/ai-rules 2.15.9 → 2.16.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clipboard-health/ai-rules",
-  "version": "2.15.9",
+  "version": "2.16.0",
   "description": "Pre-built AI agent rules for consistent coding standards.",
   "keywords": [
     "ai",

package/skills/babysit-pr/scripts/parseNitpicks.sh

@@ -59,7 +59,12 @@ for my $section (@sections) {
     my $raw_file_name = trim($1);
     my $file_content = $2;
 
-    while ($file_content =~ /`(\d+(?:-\d+)?)`:\s*(?:_[^_]+_\s*\|\s*_[^_]+_\s*)?\*\*([^*]+)\*\*\s*([\s\S]*?)(?=---|\n`\d|<\/blockquote>|$)/g) {
+    # Category prefix is optional. CodeRabbit emits 0–N `_…_` tags
+    # separated by `|` (e.g. `_⚠️ Potential issue_ | _🟠 Major_ | _⚡ Quick win_`
+    # or just `_💤 Low value_` on lower-confidence findings). The previous
+    # regex required exactly two tags and silently dropped one-tag and
+    # three-tag variants.
+    while ($file_content =~ /`(\d+(?:-\d+)?)`:\s*(?:_[^_]+_(?:\s*\|\s*_[^_]+_)*\s*)?\*\*([^*]+)\*\*\s*([\s\S]*?)(?=---|\n`\d|<\/blockquote>|$)/g) {
       my $line_range = $1;
       my $title = trim($2);
       my $clean_body = clean_comment_body(trim($3));

package/skills/commit-push-pr/SKILL.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Bash(git checkout --branch:*), Bash(git add:*), Bash(git status:*), Bash(git push:*), Bash(git commit:*), Bash(gh pr view:*), Bash(gh pr create:*), Bash(git diff:*), Bash(git merge-base:*)
+allowed-tools: Bash(git checkout --branch:*), Bash(git add:*), Bash(git status:*), Bash(git push:*), Bash(git commit:*), Bash(gh pr view:*), Bash(gh pr create:*), Bash(gh pr edit:*), Bash(git diff:*), Bash(git merge-base:*), Bash(bash scripts/find-session-id.sh:*)
 description: Commit, push, and open a PR. Use when the user wants to ship changes, create a pull request, or says things like 'commit and push', 'open a PR', 'ship it', 'send it', 'create a PR for this', or 'push this up'.
 ---
 
@@ -14,20 +14,14 @@ description: Commit, push, and open a PR. Use when the user wants to ship change
 
 ## Your task
 
-**First, decide from the context above. If `Commits ahead of default branch` is `(unknown)`, skip this decision and use the full flow below.**
+If `Commits ahead of default branch` is `(unknown)`, `origin/HEAD` couldn't be resolved — stop and tell the user to run `git remote set-head origin -a` (or otherwise set the default branch) before retrying, since the simplify step also depends on it. Otherwise, if `Git status`, `Commits ahead of default branch`, and `Existing PR` are all empty/none, stop and reply `nothing to ship.`. Otherwise:
 
-- If `Git status` is empty AND `Commits ahead of default branch` is empty AND `Existing PR` is `none`: stop. Reply with `nothing to ship.` and do nothing else.
-- If `Git status` is empty but there are `Commits ahead of default branch` or an `Existing PR`: still run step 1 and step 2. Then re-check `git status --short`; skip step 3 only if it remains empty. Then continue with step 4 and step 5.
-- Otherwise: proceed with all steps below.
-
-Based on the above changes:
-
-1. Create a new branch if on main (e.g., `feat/add-user-validation`, `fix/null-check-in-parser`)
-2. Run the `simplify` skill on the files included in the PR before committing, pushing, or opening the PR. If the working tree is clean, run `simplify` against `git diff $(git merge-base HEAD origin/HEAD)..HEAD`. If the working tree has changes, run it against `git diff HEAD`; when local commits also exist, include `git diff $(git merge-base HEAD origin/HEAD)..HEAD` as additional PR context. Invoke the skill by name using this agent's normal skill invocation mechanism. Wait for the skill to finish, then include any resulting fixes in the commit step below.
-3. Re-check `git status --short`. If there are changes, create a single conventional commit message.
-4. Push the branch to origin
-5. Check for an existing PR with `gh pr view`.
-   - No PR exists: Create with `gh pr create`. Title = commit subject line. Description = brief explanation of **why**, not what. Append `<!-- commit-push-pr:created v1 -->` on its own line at the end of the PR description so skill-created PRs can be identified later.
-   - PR exists: Report the URL and move on.
-6. You have the capability to call multiple tools in a single response. After the `simplify` skill completes, do the remaining git and PR operations in a single message. Do not use any other tools or do anything else.
-7. After tool calls complete, send one short final text response with the branch name and the full PR URL (e.g., `https://github.com/clipboardhealth/core-utils/pull/123`). Never use shorthand like `repo#123` — always output the complete URL so it is clickable.
+1. Create a new branch if on main (e.g., `feat/add-user-validation`, `fix/null-check-in-parser`).
+2. Run the `simplify` skill on the full PR diff — `git diff $(git merge-base HEAD origin/HEAD)..HEAD` plus any uncommitted changes. When it returns, continue to step 3 in the same turn; do not stop.
+3. If `git status --short` shows changes, create a single conventional commit.
+4. Push the branch to origin.
+5. Look up the current agent session ID with `bash scripts/find-session-id.sh '<phrase>'`. Pass a distinctive verbatim chunk (≥10 words) from the most recent user message; see the script header for quoting constraints. On success the script prints `<agent> <id>`; otherwise nothing — if empty, omit the session ID line below.
+6. Check for an existing PR with `gh pr view`.
+   - No PR: create with `gh pr create`. Title = commit subject. Description = brief explanation of **why**, not what. Append `Agent session ID: <output of step 5>` (omit if step 5 produced no output) and `<!-- commit-push-pr:created v1 -->` on their own lines at the end.
+   - PR exists: refresh the body via `gh pr edit --body` so (a) the new commit's changes are reflected in the prose and (b) `Agent session ID: <output of step 5>` appears in the body — append if missing, never remove or rewrite existing session ID lines so each contributing session is preserved. Then report the URL.
+7. End with one short text response: branch name and the full PR URL (e.g., `https://github.com/clipboardhealth/core-utils/pull/123`). Never use shorthand like `repo#123` — always output the complete URL.

package/skills/commit-push-pr/scripts/find-session-id.sh

@@ -0,0 +1,39 @@
+#!/usr/bin/env bash
+# find-session-id.sh — print the current agent session ID, or nothing.
+# Output format on success: "<agent> <id>" (e.g. "codex 0193..." or "claude-code c8fb7000-...").
+# Exits 0 either way; callers should treat empty output as "unknown, skip the line".
+#
+# Codex: reads $CODEX_THREAD_ID directly.
+# Claude Code: greps the project's JSONL transcripts for a phrase the caller
+#   passes as $1. The phrase MUST come from a recent user message in the
+#   current session and MUST avoid: " ' \ tab newline (those are JSON-escaped
+#   on disk or break shell quoting). Non-ASCII is fine — Claude Code stores
+#   user messages verbatim, not as \uXXXX escapes.
+#
+# Usage: find-session-id.sh "<distinctive phrase>"
+
+set -euo pipefail
+
+if [ -n "${CODEX_THREAD_ID:-}" ]; then
+  echo "codex $CODEX_THREAD_ID"
+  exit 0
+fi
+
+phrase="${1:-}"
+[ -n "$phrase" ] || exit 0
+
+# Claude Code encodes both / and . as - in the project-dir name
+# (e.g. /Users/x/.claude → -Users-x--claude).
+project_dir="$HOME/.claude/projects/$(pwd | sed -e 's|/|-|g' -e 's|\.|-|g')"
+[ -d "$project_dir" ] || exit 0
+
+# -- guards against a phrase that starts with -. -m 1 stops scanning each
+# transcript at the first hit (transcripts can be hundreds of MB).
+matches=$(grep -lFm 1 -- "$phrase" "$project_dir"/*.jsonl 2>/dev/null || true)
+[ -n "$matches" ] || exit 0
+
+# Require exactly one match. Falling back to recency under multi-match would
+# risk a wrong ID when concurrent sessions exist in the same project.
+[ "$(printf '%s\n' "$matches" | wc -l)" -eq 1 ] || exit 0
+
+echo "claude-code $(basename "$matches" .jsonl)"

package/skills/go/SKILL.md

@@ -4,59 +4,43 @@ description: Implement a plan file or direct request end-to-end, then hand off t
 
 # Go: Execute Work and Ship It
 
-Given a plan file or direct implementation request, implement the requested work, then invoke the `commit-push-pr` skill to commit, push, and open a PR.
+Given a plan file or direct implementation request, implement the requested work, then invoke the `commit-push-pr` skill to create a PR.
 
 This skill is the bridge between intent and shipping. It does not re-plan or re-design unless the user asked for that. If the request is wrong or cannot be implemented safely, surface that; do not silently improvise.
 
-## Phase 1: Understand the Input
+## Phase 1: Resolve the Input
 
-The user may invoke this skill with either a plan file path/identifier or a direct implementation request such as "add a button to the homepage to log in." Resolve the input in this order:
+The user invokes this skill with either a plan file path/identifier or a direct request like "add a login button."
 
-1. **Absolute path** (starts with `/`): read it directly only when it is inside the current workspace/repo root or the host's plans directory. If it is outside those roots, ask the user to confirm before reading it; if they do not confirm, stop and ask for an approved path.
-2. **Relative path** (contains `/` or starts with `./`): resolve from the current working directory.
-3. **Bare name** (no path separators, e.g. `my-plan` or `my-plan.md`): if the host exposes a plans directory, look there first. Use whatever directory the current host stores plan files in — do not hard-code a host-specific path. If no plan is found and the input is ambiguous, ask whether it is a plan identifier or an implementation request.
-4. **Natural-language request** (for example, contains spaces or reads like an implementation task): treat it as the implementation request. There may be no separate plan file.
-5. **No argument given**: ask the user to provide either the plan file path or the implementation request. Do not guess.
+- **Path-like input** (absolute, relative, or bare name): try to read it. For bare names, check the host's plans directory first. Resolve the path first; if it lies outside the workspace/repo or the host's plans directory, ask the user to confirm before reading it (applies to both absolute and relative inputs — `..` escapes count). If the input doesn't resolve to a readable file, stop and tell the user — do not reinterpret a missing path as a direct request.
+- **Natural-language request**: treat as the implementation task. There may be no plan file.
+- **No argument**: ask for either a plan path or the implementation request.
 
-If a path-like input does not exist or cannot be read, stop and tell the user. Do not reinterpret a missing path as a direct request.
+When using a plan, read it fully before starting. Note **Critical files**, **Approach**, and **Verification** sections (or equivalents).
 
-When using a plan, read the entire plan before starting. Note the **Critical files**, **Approach**, and **Verification** sections (or their equivalents).
+## Phase 2: Implement
 
-## Phase 2: Implement the Request
+The plan or request is the source of truth for scope:
 
-Treat the plan or direct request as the source of truth for scope:
-
-- Make exactly the changes requested — no more, no less. Do not add extra refactors, tests, or cleanup the request did not ask for.
-- If a plan references files, functions, or utilities that no longer exist, stop and surface the discrepancy before guessing.
-- If you discover the request is wrong (the codebase has moved, an assumption is invalid, a constraint was missed), stop and report. Do not silently rewrite the approach.
-- For direct implementation requests, inspect the relevant code before editing and use the repo's existing patterns.
-- Do **not** modify the plan file itself when working from a plan.
+- Make exactly the changes requested — no extra refactors, tests, or cleanup.
+- If the plan references files or utilities that no longer exist, stop and report.
+- If an assumption is invalid or a constraint was missed, stop and report. Do not silently rewrite the approach.
+- Do not modify the plan file itself.
 
 ## Phase 3: Validate
 
-Validation should follow the repo's instructions and the cost profile of the repo. Some repos intentionally leave slow checks to CI; do not run broad or slow suites unless the repo instructions explicitly require them.
-
-Run validation in this order:
-
-1. **Repo instructions.** Look up the repo's standard validation guidance. Common signals, in priority order:
-   - An explicit instruction in the repo's agent or contributor instructions, such as `AGENTS.md`, `CLAUDE.md`, `CONTRIBUTING.md`, or an equivalent host-specific instruction file (e.g. "MUST run before opening PRs"). This wins over everything else.
-   - A relevant `package.json` script when the repo instructions point to it, such as `affected`, `precommit`, `validate`, `check`, `verify`, `test`, `lint`, `typecheck`, or repo-equivalent.
-   - A repo-specific equivalent in the rare case the project does not use `package.json`.
-
-   If the repo primarily relies on git pre-commit or pre-push hooks and does not mandate a manual validation command, do not invent one. Let the hooks run during the `commit-push-pr` handoff.
-
-2. **Request-specific verification.** If the plan or user request names specific checks, run them when they are practical and consistent with the repo instructions. If a requested check is clearly a slow CI-only suite, ask before running it.
-
-If any check you run fails, fix the failures and re-run the same check. Do not hand off to `commit-push-pr` with known failing checks unless the user explicitly accepts a pre-existing or unrelated failure.
+- Read `AGENTS.md`, `CLAUDE.md`, `CONTRIBUTING.md`, or equivalent contributor instructions for the mandated pre-PR command (e.g. `npm run affected`). That wins over everything.
+- If the repo relies on pre-commit/pre-push hooks and mandates no manual command, don't invent one — let the hooks run during the `commit-push-pr` handoff.
+- If the plan names specific checks, run them when practical. Ask before running anything that's clearly a slow CI-only suite.
 
-## Phase 4: Hand Off to commit-push-pr
+Fix any failures before handing off. Do not hand off with known failing checks unless the user explicitly accepts a pre-existing or unrelated failure.
 
-Once implementation is complete and Phase 3 validation is satisfied, invoke the `commit-push-pr` skill by name using this agent's normal skill invocation mechanism.
+## Phase 4: Hand Off
 
-Do **not** commit, push, or open the PR yourself in this skill. Let `commit-push-pr` own the shipping flow.
+Invoke the `commit-push-pr` skill. Do not commit, push, or open the PR yourself.
 
-If `commit-push-pr` reports `nothing to ship.` (the work resulted in no actual file changes), surface that to the user — it usually means the request was already implemented or was a no-op.
+If `commit-push-pr` reports `nothing to ship.`, surface that.
 
 ## Phase 5: Final Output
 
-After `commit-push-pr` returns, ensure the user sees one short final response with the branch name and the full PR URL it produced. If the current host already surfaced that response, do not duplicate it. If `commit-push-pr` reported nothing to ship, say so plainly.
+Ensure the user sees the branch name and full PR URL.