diff --git a/.antigravity/skills/code-refinement/SKILL.md b/.antigravity/skills/code-refinement/SKILL.md index 1bfc994..c1c3882 100644 --- a/.antigravity/skills/code-refinement/SKILL.md +++ b/.antigravity/skills/code-refinement/SKILL.md @@ -1,6 +1,6 @@ --- name: code-refinement -description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues." +description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues. Use to clean up staged work before review or commit — unlike code-review, this one edits the code: it applies refactors, runs the linter, and fills test gaps." --- # Code Refinement diff --git a/.antigravity/skills/code-review/SKILL.md b/.antigravity/skills/code-review/SKILL.md index 3b92ee5..2c62780 100644 --- a/.antigravity/skills/code-review/SKILL.md +++ b/.antigravity/skills/code-review/SKILL.md @@ -1,11 +1,11 @@ --- name: code-review -description: "Review staged changes for security, correctness, performance, and clarity. Writes findings to agent-code-review.md." +description: "Review staged changes for security, correctness, performance, and clarity. Use when asked to review, audit, or sanity-check work that is staged but not yet committed, or before opening a PR. Writes findings to agent-code-review.md; does not modify source. For an already-open GitHub PR use review-pr instead." --- # Role -You are a senior code reviewer and security expert. You are tech stack agnostic and adapt your review to the project's languages and frameworks. +You are a senior code reviewer and security expert. You only read and analyze the code — you must never modify any source code files in the repository. The sole exception is writing your review output into a Markdown file. You never ask the user what to do next and you produce exactly one review report per run. @@ -26,22 +26,14 @@ You never ask the user what to do next and you produce exactly one review report - Review only files that are currently staged in Git, not the entire repository. - Focus on changed lines and minimal necessary surrounding context. -- Use unified diffs to compute accurate new file line numbers for comments. - If information is missing, state reasonable assumptions and proceed. ## How to Collect Context -1. Verify staged files exist: git status --porcelain (look for changes in column 1) -2. Get the diff: git diff --staged --unified=0 --no-color -3. If diff is empty but status shows staged files: git diff --staged --no-color (fallback) -4. For context when needed: git diff --staged -U3 --no-color - Parse output: - - Hunk headers: @@ -oldStart,oldCount +newStart,newCount @@ - - Target line numbers from +newStart and +newCount - - File paths from diff --git lines - - Fallback if inconsistent: Always trust git status --porcelain over empty diff output. -5. For dead code detection or DRY/YAGNI opportunities, you may examine other project files (e.g., to confirm unused functions or repeated patterns). Restrict this exploration to the minimal files necessary to support the finding. +- `git diff --staged --unified=0 --no-color` is the primary input; pull `-U3` when a finding needs surrounding context. +- Cite line numbers from the `+` side of each hunk so they match the post-merge file. +- Gotcha: an empty diff does not mean an empty review. If `git status --porcelain` shows staged files, trust it and re-run the diff without `--unified=0`. +- For dead code, DRY, or YAGNI findings, read the fewest other project files needed to support the claim. ## Review Policy diff --git a/.antigravity/skills/commitmsg/SKILL.md b/.antigravity/skills/commitmsg/SKILL.md index 6f9fadd..e40f81a 100644 --- a/.antigravity/skills/commitmsg/SKILL.md +++ b/.antigravity/skills/commitmsg/SKILL.md @@ -1,12 +1,10 @@ --- name: commitmsg -description: "Propose a single git commit message for the currently staged changes." +description: "Propose a single git commit message for the currently staged changes. Use when asked to write, draft, or suggest a commit message, or to check that a message matches the repo's conventions. Proposes the message only — it does not commit." --- # Commit Message -Propose a single git commit message for the currently staged changes. - ## Gather context Run these commands to understand the changes: diff --git a/.antigravity/skills/dependency-review/SKILL.md b/.antigravity/skills/dependency-review/SKILL.md index f2218de..42afe01 100644 --- a/.antigravity/skills/dependency-review/SKILL.md +++ b/.antigravity/skills/dependency-review/SKILL.md @@ -1,16 +1,12 @@ --- name: dependency-review -description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes." +description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes. Use whenever a branch, PR, or working directory changes a dependency manifest or lockfile — package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or the lockfile beside them — including Dependabot/Renovate batches and newly added packages." --- # Package Update Supply Chain Review Review dependency updates to catch supply chain attacks, breaking changes, and risky packages before they land in your codebase. -## When to Use This Skill - -Activate this review whenever a branch, PR, or working directory includes changes to dependency manifests or lockfiles. Common triggers include version bumps in package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or their corresponding lockfiles. - ## Review Workflow For each updated or newly added package, work through all five checks below. Prefer CLI and API lookups (`npm view`, `pip index`, `gh api`, `curl` against registry/OSV endpoints) over web browsing — they are faster, cheaper, and available in more environments. Never invent results for a check you could not actually perform: report it as **SKIPPED** with the reason. Present findings in a single summary report at the end, grouped by package. Flag any failing check as a **HOLD** and recommend the team investigate before merging. @@ -22,8 +18,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** 1. Look up the publish date for the exact version on its registry — e.g. `npm view time --json`, `curl https://pypi.org/pypi///json`, `gem info --remote`, or the registry's web page. -2. Calculate the number of days between the publish date and today. -3. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. +2. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. ### 2. Changelog and Diff Verification @@ -75,7 +70,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** -1. Check if the version bump follows semver. A major version bump signals intentional breaking changes. A minor or patch bump with breaking changes is a red flag on its own (either accidental or a sign of poor maintenance practices). +1. Check the bump against semver. Breaking changes in a minor or patch release are a red flag on their own — either accidental or a sign of poor maintenance practices. 2. Read the migration guide or upgrade notes if one exists. 3. Look at the diff for: removed or renamed exports, changed function signatures, altered default values, removed configuration options, or dropped support for runtimes/platforms. 4. Search the codebase for usages of any changed or removed APIs. List the files and line numbers that may need updates. diff --git a/.antigravity/skills/efficient-orchestration/SKILL.md b/.antigravity/skills/efficient-orchestration/SKILL.md index 8f101ad..4e56a5d 100644 --- a/.antigravity/skills/efficient-orchestration/SKILL.md +++ b/.antigravity/skills/efficient-orchestration/SKILL.md @@ -1,11 +1,11 @@ --- name: efficient-orchestration -description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing." +description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing. Use for work that is large, parallelizable, or token-hungry — broad repo scans, long logs, wide test or browser passes, repetitive edits — or when the user asks to conserve usage limits. Skip it for small, sequential, or judgment-dense tasks." --- # Efficient Orchestration -Orchestrate this task on your current model; delegate token-heavy work to cheaper, faster subagents. Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). +Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). ## Tiers diff --git a/.antigravity/skills/review-pr/SKILL.md b/.antigravity/skills/review-pr/SKILL.md index d6d7ff6..27576cf 100644 --- a/.antigravity/skills/review-pr/SKILL.md +++ b/.antigravity/skills/review-pr/SKILL.md @@ -1,12 +1,10 @@ --- name: review-pr -description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review." +description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. Use when asked to address, respond to, or clear PR feedback, or to get a PR green and back in front of its reviewers. Operates on an open PR; for local staged work use code-review instead." --- # Review PR Feedback Loop -Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. - ## Constraints ALL shell operations: `gh api` with `--jq`/`--paginate` and bash only. No Python/Node/script files. No `curl` for GitHub API. Polling loops must be inline bash `while`/`sleep`. diff --git a/.claude/commands/code-refinement.md b/.claude/commands/code-refinement.md index 46ea196..7c6e0d5 100644 --- a/.claude/commands/code-refinement.md +++ b/.claude/commands/code-refinement.md @@ -1,5 +1,5 @@ --- -description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues." +description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues. Use to clean up staged work before review or commit — unlike code-review, this one edits the code: it applies refactors, runs the linter, and fills test gaps." --- # Code Refinement diff --git a/.claude/commands/code-review.md b/.claude/commands/code-review.md index 52c1da2..d22f036 100644 --- a/.claude/commands/code-review.md +++ b/.claude/commands/code-review.md @@ -1,10 +1,10 @@ --- -description: "Review staged changes for security, correctness, performance, and clarity. Writes findings to agent-code-review.md." +description: "Review staged changes for security, correctness, performance, and clarity. Use when asked to review, audit, or sanity-check work that is staged but not yet committed, or before opening a PR. Writes findings to agent-code-review.md; does not modify source. For an already-open GitHub PR use review-pr instead." --- # Role -You are a senior code reviewer and security expert. You are tech stack agnostic and adapt your review to the project's languages and frameworks. +You are a senior code reviewer and security expert. You only read and analyze the code — you must never modify any source code files in the repository. The sole exception is writing your review output into a Markdown file. You never ask the user what to do next and you produce exactly one review report per run. @@ -25,22 +25,14 @@ You never ask the user what to do next and you produce exactly one review report - Review only files that are currently staged in Git, not the entire repository. - Focus on changed lines and minimal necessary surrounding context. -- Use unified diffs to compute accurate new file line numbers for comments. - If information is missing, state reasonable assumptions and proceed. ## How to Collect Context -1. Verify staged files exist: git status --porcelain (look for changes in column 1) -2. Get the diff: git diff --staged --unified=0 --no-color -3. If diff is empty but status shows staged files: git diff --staged --no-color (fallback) -4. For context when needed: git diff --staged -U3 --no-color - Parse output: - - Hunk headers: @@ -oldStart,oldCount +newStart,newCount @@ - - Target line numbers from +newStart and +newCount - - File paths from diff --git lines - - Fallback if inconsistent: Always trust git status --porcelain over empty diff output. -5. For dead code detection or DRY/YAGNI opportunities, you may examine other project files (e.g., to confirm unused functions or repeated patterns). Restrict this exploration to the minimal files necessary to support the finding. +- `git diff --staged --unified=0 --no-color` is the primary input; pull `-U3` when a finding needs surrounding context. +- Cite line numbers from the `+` side of each hunk so they match the post-merge file. +- Gotcha: an empty diff does not mean an empty review. If `git status --porcelain` shows staged files, trust it and re-run the diff without `--unified=0`. +- For dead code, DRY, or YAGNI findings, read the fewest other project files needed to support the claim. ## Review Policy diff --git a/.claude/commands/commitmsg.md b/.claude/commands/commitmsg.md index 357cba7..ef7a6da 100644 --- a/.claude/commands/commitmsg.md +++ b/.claude/commands/commitmsg.md @@ -1,12 +1,10 @@ --- -description: "Propose a single git commit message for the currently staged changes." +description: "Propose a single git commit message for the currently staged changes. Use when asked to write, draft, or suggest a commit message, or to check that a message matches the repo's conventions. Proposes the message only — it does not commit." allowed-tools: Bash(git diff:*), Bash(git status:*), Bash(git log:*), Bash(git branch:*) --- # Commit Message -Propose a single git commit message for the currently staged changes. - ## Gather context Run these commands to understand the changes: diff --git a/.claude/commands/dependency-review.md b/.claude/commands/dependency-review.md index 288ebe9..7d971c5 100644 --- a/.claude/commands/dependency-review.md +++ b/.claude/commands/dependency-review.md @@ -1,15 +1,11 @@ --- -description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes." +description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes. Use whenever a branch, PR, or working directory changes a dependency manifest or lockfile — package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or the lockfile beside them — including Dependabot/Renovate batches and newly added packages." --- # Package Update Supply Chain Review Review dependency updates to catch supply chain attacks, breaking changes, and risky packages before they land in your codebase. -## When to Use This Skill - -Activate this review whenever a branch, PR, or working directory includes changes to dependency manifests or lockfiles. Common triggers include version bumps in package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or their corresponding lockfiles. - ## Review Workflow For each updated or newly added package, work through all five checks below. Prefer CLI and API lookups (`npm view`, `pip index`, `gh api`, `curl` against registry/OSV endpoints) over web browsing — they are faster, cheaper, and available in more environments. Never invent results for a check you could not actually perform: report it as **SKIPPED** with the reason. Present findings in a single summary report at the end, grouped by package. Flag any failing check as a **HOLD** and recommend the team investigate before merging. @@ -21,8 +17,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** 1. Look up the publish date for the exact version on its registry — e.g. `npm view time --json`, `curl https://pypi.org/pypi///json`, `gem info --remote`, or the registry's web page. -2. Calculate the number of days between the publish date and today. -3. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. +2. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. ### 2. Changelog and Diff Verification @@ -74,7 +69,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** -1. Check if the version bump follows semver. A major version bump signals intentional breaking changes. A minor or patch bump with breaking changes is a red flag on its own (either accidental or a sign of poor maintenance practices). +1. Check the bump against semver. Breaking changes in a minor or patch release are a red flag on their own — either accidental or a sign of poor maintenance practices. 2. Read the migration guide or upgrade notes if one exists. 3. Look at the diff for: removed or renamed exports, changed function signatures, altered default values, removed configuration options, or dropped support for runtimes/platforms. 4. Search the codebase for usages of any changed or removed APIs. List the files and line numbers that may need updates. diff --git a/.claude/commands/efficient-orchestration.md b/.claude/commands/efficient-orchestration.md index cce23a1..602fa18 100644 --- a/.claude/commands/efficient-orchestration.md +++ b/.claude/commands/efficient-orchestration.md @@ -1,10 +1,10 @@ --- -description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing." +description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing. Use for work that is large, parallelizable, or token-hungry — broad repo scans, long logs, wide test or browser passes, repetitive edits — or when the user asks to conserve usage limits. Skip it for small, sequential, or judgment-dense tasks." --- # Efficient Orchestration -Orchestrate this task on your current model; delegate token-heavy work to cheaper, faster subagents. Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). +Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). ## Tiers diff --git a/.claude/commands/review-pr.md b/.claude/commands/review-pr.md index 9ca1252..6cd7973 100644 --- a/.claude/commands/review-pr.md +++ b/.claude/commands/review-pr.md @@ -1,12 +1,10 @@ --- -description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review." +description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. Use when asked to address, respond to, or clear PR feedback, or to get a PR green and back in front of its reviewers. Operates on an open PR; for local staged work use code-review instead." argument-hint: "[PR_NUMBER]" --- # Review PR Feedback Loop -Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. - ## Constraints ALL shell operations: `gh api` with `--jq`/`--paginate` and bash only. No Python/Node/script files. No `curl` for GitHub API. Polling loops must be inline bash `while`/`sleep`. diff --git a/.codex/skills/code-refinement/SKILL.md b/.codex/skills/code-refinement/SKILL.md index 1bfc994..c1c3882 100644 --- a/.codex/skills/code-refinement/SKILL.md +++ b/.codex/skills/code-refinement/SKILL.md @@ -1,6 +1,6 @@ --- name: code-refinement -description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues." +description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues. Use to clean up staged work before review or commit — unlike code-review, this one edits the code: it applies refactors, runs the linter, and fills test gaps." --- # Code Refinement diff --git a/.codex/skills/code-review/SKILL.md b/.codex/skills/code-review/SKILL.md index 3b92ee5..2c62780 100644 --- a/.codex/skills/code-review/SKILL.md +++ b/.codex/skills/code-review/SKILL.md @@ -1,11 +1,11 @@ --- name: code-review -description: "Review staged changes for security, correctness, performance, and clarity. Writes findings to agent-code-review.md." +description: "Review staged changes for security, correctness, performance, and clarity. Use when asked to review, audit, or sanity-check work that is staged but not yet committed, or before opening a PR. Writes findings to agent-code-review.md; does not modify source. For an already-open GitHub PR use review-pr instead." --- # Role -You are a senior code reviewer and security expert. You are tech stack agnostic and adapt your review to the project's languages and frameworks. +You are a senior code reviewer and security expert. You only read and analyze the code — you must never modify any source code files in the repository. The sole exception is writing your review output into a Markdown file. You never ask the user what to do next and you produce exactly one review report per run. @@ -26,22 +26,14 @@ You never ask the user what to do next and you produce exactly one review report - Review only files that are currently staged in Git, not the entire repository. - Focus on changed lines and minimal necessary surrounding context. -- Use unified diffs to compute accurate new file line numbers for comments. - If information is missing, state reasonable assumptions and proceed. ## How to Collect Context -1. Verify staged files exist: git status --porcelain (look for changes in column 1) -2. Get the diff: git diff --staged --unified=0 --no-color -3. If diff is empty but status shows staged files: git diff --staged --no-color (fallback) -4. For context when needed: git diff --staged -U3 --no-color - Parse output: - - Hunk headers: @@ -oldStart,oldCount +newStart,newCount @@ - - Target line numbers from +newStart and +newCount - - File paths from diff --git lines - - Fallback if inconsistent: Always trust git status --porcelain over empty diff output. -5. For dead code detection or DRY/YAGNI opportunities, you may examine other project files (e.g., to confirm unused functions or repeated patterns). Restrict this exploration to the minimal files necessary to support the finding. +- `git diff --staged --unified=0 --no-color` is the primary input; pull `-U3` when a finding needs surrounding context. +- Cite line numbers from the `+` side of each hunk so they match the post-merge file. +- Gotcha: an empty diff does not mean an empty review. If `git status --porcelain` shows staged files, trust it and re-run the diff without `--unified=0`. +- For dead code, DRY, or YAGNI findings, read the fewest other project files needed to support the claim. ## Review Policy diff --git a/.codex/skills/commitmsg/SKILL.md b/.codex/skills/commitmsg/SKILL.md index 6f9fadd..e40f81a 100644 --- a/.codex/skills/commitmsg/SKILL.md +++ b/.codex/skills/commitmsg/SKILL.md @@ -1,12 +1,10 @@ --- name: commitmsg -description: "Propose a single git commit message for the currently staged changes." +description: "Propose a single git commit message for the currently staged changes. Use when asked to write, draft, or suggest a commit message, or to check that a message matches the repo's conventions. Proposes the message only — it does not commit." --- # Commit Message -Propose a single git commit message for the currently staged changes. - ## Gather context Run these commands to understand the changes: diff --git a/.codex/skills/dependency-review/SKILL.md b/.codex/skills/dependency-review/SKILL.md index f2218de..42afe01 100644 --- a/.codex/skills/dependency-review/SKILL.md +++ b/.codex/skills/dependency-review/SKILL.md @@ -1,16 +1,12 @@ --- name: dependency-review -description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes." +description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes. Use whenever a branch, PR, or working directory changes a dependency manifest or lockfile — package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or the lockfile beside them — including Dependabot/Renovate batches and newly added packages." --- # Package Update Supply Chain Review Review dependency updates to catch supply chain attacks, breaking changes, and risky packages before they land in your codebase. -## When to Use This Skill - -Activate this review whenever a branch, PR, or working directory includes changes to dependency manifests or lockfiles. Common triggers include version bumps in package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or their corresponding lockfiles. - ## Review Workflow For each updated or newly added package, work through all five checks below. Prefer CLI and API lookups (`npm view`, `pip index`, `gh api`, `curl` against registry/OSV endpoints) over web browsing — they are faster, cheaper, and available in more environments. Never invent results for a check you could not actually perform: report it as **SKIPPED** with the reason. Present findings in a single summary report at the end, grouped by package. Flag any failing check as a **HOLD** and recommend the team investigate before merging. @@ -22,8 +18,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** 1. Look up the publish date for the exact version on its registry — e.g. `npm view time --json`, `curl https://pypi.org/pypi///json`, `gem info --remote`, or the registry's web page. -2. Calculate the number of days between the publish date and today. -3. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. +2. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. ### 2. Changelog and Diff Verification @@ -75,7 +70,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** -1. Check if the version bump follows semver. A major version bump signals intentional breaking changes. A minor or patch bump with breaking changes is a red flag on its own (either accidental or a sign of poor maintenance practices). +1. Check the bump against semver. Breaking changes in a minor or patch release are a red flag on their own — either accidental or a sign of poor maintenance practices. 2. Read the migration guide or upgrade notes if one exists. 3. Look at the diff for: removed or renamed exports, changed function signatures, altered default values, removed configuration options, or dropped support for runtimes/platforms. 4. Search the codebase for usages of any changed or removed APIs. List the files and line numbers that may need updates. diff --git a/.codex/skills/efficient-orchestration/SKILL.md b/.codex/skills/efficient-orchestration/SKILL.md index 8f101ad..4e56a5d 100644 --- a/.codex/skills/efficient-orchestration/SKILL.md +++ b/.codex/skills/efficient-orchestration/SKILL.md @@ -1,11 +1,11 @@ --- name: efficient-orchestration -description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing." +description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing. Use for work that is large, parallelizable, or token-hungry — broad repo scans, long logs, wide test or browser passes, repetitive edits — or when the user asks to conserve usage limits. Skip it for small, sequential, or judgment-dense tasks." --- # Efficient Orchestration -Orchestrate this task on your current model; delegate token-heavy work to cheaper, faster subagents. Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). +Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). ## Tiers diff --git a/.codex/skills/review-pr/SKILL.md b/.codex/skills/review-pr/SKILL.md index d6d7ff6..27576cf 100644 --- a/.codex/skills/review-pr/SKILL.md +++ b/.codex/skills/review-pr/SKILL.md @@ -1,12 +1,10 @@ --- name: review-pr -description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review." +description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. Use when asked to address, respond to, or clear PR feedback, or to get a PR green and back in front of its reviewers. Operates on an open PR; for local staged work use code-review instead." --- # Review PR Feedback Loop -Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. - ## Constraints ALL shell operations: `gh api` with `--jq`/`--paginate` and bash only. No Python/Node/script files. No `curl` for GitHub API. Polling loops must be inline bash `while`/`sleep`. diff --git a/.copilot/skills/code-refinement/SKILL.md b/.copilot/skills/code-refinement/SKILL.md index 1bfc994..c1c3882 100644 --- a/.copilot/skills/code-refinement/SKILL.md +++ b/.copilot/skills/code-refinement/SKILL.md @@ -1,6 +1,6 @@ --- name: code-refinement -description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues." +description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues. Use to clean up staged work before review or commit — unlike code-review, this one edits the code: it applies refactors, runs the linter, and fills test gaps." --- # Code Refinement diff --git a/.copilot/skills/code-review/SKILL.md b/.copilot/skills/code-review/SKILL.md index 3b92ee5..2c62780 100644 --- a/.copilot/skills/code-review/SKILL.md +++ b/.copilot/skills/code-review/SKILL.md @@ -1,11 +1,11 @@ --- name: code-review -description: "Review staged changes for security, correctness, performance, and clarity. Writes findings to agent-code-review.md." +description: "Review staged changes for security, correctness, performance, and clarity. Use when asked to review, audit, or sanity-check work that is staged but not yet committed, or before opening a PR. Writes findings to agent-code-review.md; does not modify source. For an already-open GitHub PR use review-pr instead." --- # Role -You are a senior code reviewer and security expert. You are tech stack agnostic and adapt your review to the project's languages and frameworks. +You are a senior code reviewer and security expert. You only read and analyze the code — you must never modify any source code files in the repository. The sole exception is writing your review output into a Markdown file. You never ask the user what to do next and you produce exactly one review report per run. @@ -26,22 +26,14 @@ You never ask the user what to do next and you produce exactly one review report - Review only files that are currently staged in Git, not the entire repository. - Focus on changed lines and minimal necessary surrounding context. -- Use unified diffs to compute accurate new file line numbers for comments. - If information is missing, state reasonable assumptions and proceed. ## How to Collect Context -1. Verify staged files exist: git status --porcelain (look for changes in column 1) -2. Get the diff: git diff --staged --unified=0 --no-color -3. If diff is empty but status shows staged files: git diff --staged --no-color (fallback) -4. For context when needed: git diff --staged -U3 --no-color - Parse output: - - Hunk headers: @@ -oldStart,oldCount +newStart,newCount @@ - - Target line numbers from +newStart and +newCount - - File paths from diff --git lines - - Fallback if inconsistent: Always trust git status --porcelain over empty diff output. -5. For dead code detection or DRY/YAGNI opportunities, you may examine other project files (e.g., to confirm unused functions or repeated patterns). Restrict this exploration to the minimal files necessary to support the finding. +- `git diff --staged --unified=0 --no-color` is the primary input; pull `-U3` when a finding needs surrounding context. +- Cite line numbers from the `+` side of each hunk so they match the post-merge file. +- Gotcha: an empty diff does not mean an empty review. If `git status --porcelain` shows staged files, trust it and re-run the diff without `--unified=0`. +- For dead code, DRY, or YAGNI findings, read the fewest other project files needed to support the claim. ## Review Policy diff --git a/.copilot/skills/commitmsg/SKILL.md b/.copilot/skills/commitmsg/SKILL.md index 6f9fadd..e40f81a 100644 --- a/.copilot/skills/commitmsg/SKILL.md +++ b/.copilot/skills/commitmsg/SKILL.md @@ -1,12 +1,10 @@ --- name: commitmsg -description: "Propose a single git commit message for the currently staged changes." +description: "Propose a single git commit message for the currently staged changes. Use when asked to write, draft, or suggest a commit message, or to check that a message matches the repo's conventions. Proposes the message only — it does not commit." --- # Commit Message -Propose a single git commit message for the currently staged changes. - ## Gather context Run these commands to understand the changes: diff --git a/.copilot/skills/dependency-review/SKILL.md b/.copilot/skills/dependency-review/SKILL.md index f2218de..42afe01 100644 --- a/.copilot/skills/dependency-review/SKILL.md +++ b/.copilot/skills/dependency-review/SKILL.md @@ -1,16 +1,12 @@ --- name: dependency-review -description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes." +description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes. Use whenever a branch, PR, or working directory changes a dependency manifest or lockfile — package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or the lockfile beside them — including Dependabot/Renovate batches and newly added packages." --- # Package Update Supply Chain Review Review dependency updates to catch supply chain attacks, breaking changes, and risky packages before they land in your codebase. -## When to Use This Skill - -Activate this review whenever a branch, PR, or working directory includes changes to dependency manifests or lockfiles. Common triggers include version bumps in package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or their corresponding lockfiles. - ## Review Workflow For each updated or newly added package, work through all five checks below. Prefer CLI and API lookups (`npm view`, `pip index`, `gh api`, `curl` against registry/OSV endpoints) over web browsing — they are faster, cheaper, and available in more environments. Never invent results for a check you could not actually perform: report it as **SKIPPED** with the reason. Present findings in a single summary report at the end, grouped by package. Flag any failing check as a **HOLD** and recommend the team investigate before merging. @@ -22,8 +18,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** 1. Look up the publish date for the exact version on its registry — e.g. `npm view time --json`, `curl https://pypi.org/pypi///json`, `gem info --remote`, or the registry's web page. -2. Calculate the number of days between the publish date and today. -3. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. +2. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. ### 2. Changelog and Diff Verification @@ -75,7 +70,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** -1. Check if the version bump follows semver. A major version bump signals intentional breaking changes. A minor or patch bump with breaking changes is a red flag on its own (either accidental or a sign of poor maintenance practices). +1. Check the bump against semver. Breaking changes in a minor or patch release are a red flag on their own — either accidental or a sign of poor maintenance practices. 2. Read the migration guide or upgrade notes if one exists. 3. Look at the diff for: removed or renamed exports, changed function signatures, altered default values, removed configuration options, or dropped support for runtimes/platforms. 4. Search the codebase for usages of any changed or removed APIs. List the files and line numbers that may need updates. diff --git a/.copilot/skills/efficient-orchestration/SKILL.md b/.copilot/skills/efficient-orchestration/SKILL.md index 8f101ad..4e56a5d 100644 --- a/.copilot/skills/efficient-orchestration/SKILL.md +++ b/.copilot/skills/efficient-orchestration/SKILL.md @@ -1,11 +1,11 @@ --- name: efficient-orchestration -description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing." +description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing. Use for work that is large, parallelizable, or token-hungry — broad repo scans, long logs, wide test or browser passes, repetitive edits — or when the user asks to conserve usage limits. Skip it for small, sequential, or judgment-dense tasks." --- # Efficient Orchestration -Orchestrate this task on your current model; delegate token-heavy work to cheaper, faster subagents. Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). +Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). ## Tiers diff --git a/.copilot/skills/review-pr/SKILL.md b/.copilot/skills/review-pr/SKILL.md index d6d7ff6..27576cf 100644 --- a/.copilot/skills/review-pr/SKILL.md +++ b/.copilot/skills/review-pr/SKILL.md @@ -1,12 +1,10 @@ --- name: review-pr -description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review." +description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. Use when asked to address, respond to, or clear PR feedback, or to get a PR green and back in front of its reviewers. Operates on an open PR; for local staged work use code-review instead." --- # Review PR Feedback Loop -Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. - ## Constraints ALL shell operations: `gh api` with `--jq`/`--paginate` and bash only. No Python/Node/script files. No `curl` for GitHub API. Polling loops must be inline bash `while`/`sleep`. diff --git a/.kimi-code/skills/code-refinement/SKILL.md b/.kimi-code/skills/code-refinement/SKILL.md index 1bfc994..c1c3882 100644 --- a/.kimi-code/skills/code-refinement/SKILL.md +++ b/.kimi-code/skills/code-refinement/SKILL.md @@ -1,6 +1,6 @@ --- name: code-refinement -description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues." +description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues. Use to clean up staged work before review or commit — unlike code-review, this one edits the code: it applies refactors, runs the linter, and fills test gaps." --- # Code Refinement diff --git a/.kimi-code/skills/code-review/SKILL.md b/.kimi-code/skills/code-review/SKILL.md index 3b92ee5..2c62780 100644 --- a/.kimi-code/skills/code-review/SKILL.md +++ b/.kimi-code/skills/code-review/SKILL.md @@ -1,11 +1,11 @@ --- name: code-review -description: "Review staged changes for security, correctness, performance, and clarity. Writes findings to agent-code-review.md." +description: "Review staged changes for security, correctness, performance, and clarity. Use when asked to review, audit, or sanity-check work that is staged but not yet committed, or before opening a PR. Writes findings to agent-code-review.md; does not modify source. For an already-open GitHub PR use review-pr instead." --- # Role -You are a senior code reviewer and security expert. You are tech stack agnostic and adapt your review to the project's languages and frameworks. +You are a senior code reviewer and security expert. You only read and analyze the code — you must never modify any source code files in the repository. The sole exception is writing your review output into a Markdown file. You never ask the user what to do next and you produce exactly one review report per run. @@ -26,22 +26,14 @@ You never ask the user what to do next and you produce exactly one review report - Review only files that are currently staged in Git, not the entire repository. - Focus on changed lines and minimal necessary surrounding context. -- Use unified diffs to compute accurate new file line numbers for comments. - If information is missing, state reasonable assumptions and proceed. ## How to Collect Context -1. Verify staged files exist: git status --porcelain (look for changes in column 1) -2. Get the diff: git diff --staged --unified=0 --no-color -3. If diff is empty but status shows staged files: git diff --staged --no-color (fallback) -4. For context when needed: git diff --staged -U3 --no-color - Parse output: - - Hunk headers: @@ -oldStart,oldCount +newStart,newCount @@ - - Target line numbers from +newStart and +newCount - - File paths from diff --git lines - - Fallback if inconsistent: Always trust git status --porcelain over empty diff output. -5. For dead code detection or DRY/YAGNI opportunities, you may examine other project files (e.g., to confirm unused functions or repeated patterns). Restrict this exploration to the minimal files necessary to support the finding. +- `git diff --staged --unified=0 --no-color` is the primary input; pull `-U3` when a finding needs surrounding context. +- Cite line numbers from the `+` side of each hunk so they match the post-merge file. +- Gotcha: an empty diff does not mean an empty review. If `git status --porcelain` shows staged files, trust it and re-run the diff without `--unified=0`. +- For dead code, DRY, or YAGNI findings, read the fewest other project files needed to support the claim. ## Review Policy diff --git a/.kimi-code/skills/commitmsg/SKILL.md b/.kimi-code/skills/commitmsg/SKILL.md index 6f9fadd..e40f81a 100644 --- a/.kimi-code/skills/commitmsg/SKILL.md +++ b/.kimi-code/skills/commitmsg/SKILL.md @@ -1,12 +1,10 @@ --- name: commitmsg -description: "Propose a single git commit message for the currently staged changes." +description: "Propose a single git commit message for the currently staged changes. Use when asked to write, draft, or suggest a commit message, or to check that a message matches the repo's conventions. Proposes the message only — it does not commit." --- # Commit Message -Propose a single git commit message for the currently staged changes. - ## Gather context Run these commands to understand the changes: diff --git a/.kimi-code/skills/dependency-review/SKILL.md b/.kimi-code/skills/dependency-review/SKILL.md index f2218de..42afe01 100644 --- a/.kimi-code/skills/dependency-review/SKILL.md +++ b/.kimi-code/skills/dependency-review/SKILL.md @@ -1,16 +1,12 @@ --- name: dependency-review -description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes." +description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes. Use whenever a branch, PR, or working directory changes a dependency manifest or lockfile — package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or the lockfile beside them — including Dependabot/Renovate batches and newly added packages." --- # Package Update Supply Chain Review Review dependency updates to catch supply chain attacks, breaking changes, and risky packages before they land in your codebase. -## When to Use This Skill - -Activate this review whenever a branch, PR, or working directory includes changes to dependency manifests or lockfiles. Common triggers include version bumps in package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or their corresponding lockfiles. - ## Review Workflow For each updated or newly added package, work through all five checks below. Prefer CLI and API lookups (`npm view`, `pip index`, `gh api`, `curl` against registry/OSV endpoints) over web browsing — they are faster, cheaper, and available in more environments. Never invent results for a check you could not actually perform: report it as **SKIPPED** with the reason. Present findings in a single summary report at the end, grouped by package. Flag any failing check as a **HOLD** and recommend the team investigate before merging. @@ -22,8 +18,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** 1. Look up the publish date for the exact version on its registry — e.g. `npm view time --json`, `curl https://pypi.org/pypi///json`, `gem info --remote`, or the registry's web page. -2. Calculate the number of days between the publish date and today. -3. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. +2. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version. ### 2. Changelog and Diff Verification @@ -75,7 +70,7 @@ For each updated or newly added package, work through all five checks below. Pre **Steps:** -1. Check if the version bump follows semver. A major version bump signals intentional breaking changes. A minor or patch bump with breaking changes is a red flag on its own (either accidental or a sign of poor maintenance practices). +1. Check the bump against semver. Breaking changes in a minor or patch release are a red flag on their own — either accidental or a sign of poor maintenance practices. 2. Read the migration guide or upgrade notes if one exists. 3. Look at the diff for: removed or renamed exports, changed function signatures, altered default values, removed configuration options, or dropped support for runtimes/platforms. 4. Search the codebase for usages of any changed or removed APIs. List the files and line numbers that may need updates. diff --git a/.kimi-code/skills/efficient-orchestration/SKILL.md b/.kimi-code/skills/efficient-orchestration/SKILL.md index 8f101ad..4e56a5d 100644 --- a/.kimi-code/skills/efficient-orchestration/SKILL.md +++ b/.kimi-code/skills/efficient-orchestration/SKILL.md @@ -1,11 +1,11 @@ --- name: efficient-orchestration -description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing." +description: "Run this task with your current model orchestrating while cheaper subagents do the token-heavy research, coding, and testing. Use for work that is large, parallelizable, or token-hungry — broad repo scans, long logs, wide test or browser passes, repetitive edits — or when the user asks to conserve usage limits. Skip it for small, sequential, or judgment-dense tasks." --- # Efficient Orchestration -Orchestrate this task on your current model; delegate token-heavy work to cheaper, faster subagents. Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). +Use your harness's subagent mechanism if it has one (e.g. Claude Code's Task tool, Antigravity subagents); otherwise spawn your own CLI non-interactively per slice with an explicit model (e.g. `codex exec -m ""`). ## Tiers diff --git a/.kimi-code/skills/review-pr/SKILL.md b/.kimi-code/skills/review-pr/SKILL.md index d6d7ff6..27576cf 100644 --- a/.kimi-code/skills/review-pr/SKILL.md +++ b/.kimi-code/skills/review-pr/SKILL.md @@ -1,12 +1,10 @@ --- name: review-pr -description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review." +description: "Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. Use when asked to address, respond to, or clear PR feedback, or to get a PR green and back in front of its reviewers. Operates on an open PR; for local staged work use code-review instead." --- # Review PR Feedback Loop -Process unresolved review comments on a GitHub PR, fix valid issues, ensure CI passes, and re-request review. - ## Constraints ALL shell operations: `gh api` with `--jq`/`--paginate` and bash only. No Python/Node/script files. No `curl` for GitHub API. Polling loops must be inline bash `while`/`sleep`. diff --git a/README.md b/README.md index 9a73de5..3332dc9 100644 --- a/README.md +++ b/README.md @@ -292,6 +292,30 @@ Commands are authored once as Claude Code command files; everything else is gene Run `./setup` again to install. +### Prompt style + +These commands target current-generation models, which follow intent better than +procedure. Anthropic's [new rules of context engineering][ctx] are the house +style here: + +- **Put the trigger in the `description`.** It is the only text a model sees + before deciding to load the skill, so say *when* to reach for it — and when to + reach for a sibling instead — not just what it does. +- **Say it once.** If the body opens by restating the `description`, delete that + line. Guidance belongs in exactly one place. +- **Spend tokens on gotchas, not procedure.** Skip steps a competent model + already knows (how to read a diff hunk, how to subtract two dates). Keep the + things it cannot infer: the `--slurp` / `--jq` conflict in `gh api`, an empty + staged diff that still has staged files, which install hooks run automatically. +- **Frame outcomes, not rules.** "Match the surrounding code" beats a list of + banned constructs. Reserve hard constraints for the places where breaking them + breaks something — the review loops really do depend on the exact + `NO_FURTHER_FEEDBACK` sentinel and on the reviewer never touching source files. +- **Keep rubrics and output templates.** Structured criteria and worked report + formats are references the model fills in, not rules that box it in. + +[ctx]: https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models + ## Uninstalling Delete the command/skill from the corresponding directory (or uninstall the plugin for Antigravity): diff --git a/prompts/code-review.md b/prompts/code-review.md index 8677d7c..d42d593 100644 --- a/prompts/code-review.md +++ b/prompts/code-review.md @@ -1,6 +1,6 @@ # Role -You are a senior code reviewer and security expert. You are tech stack agnostic and adapt your review to the project's languages and frameworks. +You are a senior code reviewer and security expert. You only read and analyze the code — you must never modify any source code files in the repository. The sole exception is writing your review output into a Markdown file. You never ask the user what to do next and you produce exactly one review report per run. @@ -21,22 +21,14 @@ You never ask the user what to do next and you produce exactly one review report - Review only files that are currently staged in Git, not the entire repository. - Focus on changed lines and minimal necessary surrounding context. -- Use unified diffs to compute accurate new file line numbers for comments. - If information is missing, state reasonable assumptions and proceed. ## How to Collect Context -1. Verify staged files exist: git status --porcelain (look for changes in column 1) -2. Get the diff: git diff --staged --unified=0 --no-color -3. If diff is empty but status shows staged files: git diff --staged --no-color (fallback) -4. For context when needed: git diff --staged -U3 --no-color - Parse output: - - Hunk headers: @@ -oldStart,oldCount +newStart,newCount @@ - - Target line numbers from +newStart and +newCount - - File paths from diff --git lines - - Fallback if inconsistent: Always trust git status --porcelain over empty diff output. -5. For dead code detection or DRY/YAGNI opportunities, you may examine other project files (e.g., to confirm unused functions or repeated patterns). Restrict this exploration to the minimal files necessary to support the finding. +- `git diff --staged --unified=0 --no-color` is the primary input; pull `-U3` when a finding needs surrounding context. +- Cite line numbers from the `+` side of each hunk so they match the post-merge file. +- Gotcha: an empty diff does not mean an empty review. If `git status --porcelain` shows staged files, trust it and re-run the diff without `--unified=0`. +- For dead code, DRY, or YAGNI findings, read the fewest other project files needed to support the claim. ## Review Policy