@clipboard-health/ai-rules 2.15.6 → 2.15.7

package/package.json

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

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:*)
+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:*)
 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'.
 ---
 
@@ -17,16 +17,17 @@ description: Commit, push, and open a PR. Use when the user wants to ship change
 **First, decide from the context above. If `Commits ahead of default branch` is `(unknown)`, skip this decision and use the full flow below.**
 
 - 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`: skip step 2 only (no changes to commit). Still run step 1 — its "if on main" check needs to fire so local commits on main are moved to a new branch rather than pushed directly to main. Then continue with step 3 and step 4.
+- 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. Create a single conventional commit message
-3. Push the branch to origin
-4. 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.
+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.
-5. You have the capability to call multiple tools in a single response. You MUST do all of the above in a single message. Do not use any other tools or do anything else.
-6. 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.
+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.

package/skills/go/SKILL.md

@@ -0,0 +1,62 @@
+---
+description: Implement a plan file or direct request end-to-end, then hand off to commit-push-pr to ship it. Use when the user says 'go', 'execute the plan', 'implement the plan', or gives an implementation request.
+---
+
+# 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.
+
+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
+
+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:
+
+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.
+
+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 the entire plan before starting. Note the **Critical files**, **Approach**, and **Verification** sections (or their equivalents).
+
+## Phase 2: Implement the Request
+
+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.
+
+## 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.
+
+## Phase 4: Hand Off to commit-push-pr
+
+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.
+
+Do **not** commit, push, or open the PR yourself in this skill. Let `commit-push-pr` own the shipping flow.
+
+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.
+
+## 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.

package/skills/simplify/SKILL.md

@@ -12,7 +12,7 @@ Run \`git diff\` (or \`git diff HEAD\` if there are staged changes) to see what
 
 ## Phase 2: Launch Three Review Agents in Parallel
 
-If you can, use the ${AGENT_TOOL_NAME} tool to launch all three agents concurrently in a single message; otherwise, perform the following yourself. Pass each agent the full diff so it has the complete context.
+If the current host supports parallel delegated reviewers, use that mechanism to launch all three reviews concurrently; otherwise, perform the reviews yourself. Pass each reviewer the full diff so it has the complete context.
 
 ### Agent 1: Code Reuse Review