From f2dd13c34f7d6d003f3b34e47696eaddf901b906 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 25 Jul 2026 00:52:11 +0000 Subject: [PATCH] refactor(prompts): apply Claude 5 context-engineering rules to commands Anthropic's "new rules of context engineering" post reports removing 80% of Claude Code's system prompt with no performance loss: current-generation models follow intent better than procedure. Rework the command sources accordingly. - Move trigger conditions into each `description`. It is the only text a model sees before deciding to load a skill, so it now says when to reach for the command, and disambiguates the three overlapping reviewers (code-review vs. code-refinement vs. review-pr). - Drop body lines that restate the description in review-pr, commitmsg, and efficient-orchestration, and the "When to Use This Skill" section in dependency-review, now redundant with its description. - Replace code-review's step-by-step diff recipe with the two gotchas it actually encodes (cite the + side; an empty diff with staged files means re-run without --unified=0). Hunk-header parsing is not something a current model needs spelled out. - Trim date arithmetic and a semver primer from dependency-review, keeping the non-obvious signal: breaking changes in a minor/patch release. - Document the house style in README so new commands follow it. Hard constraints the review loops depend on are deliberately untouched, as are the rubrics and output templates the blog classes as references rather than rules. --- .antigravity/skills/code-refinement/SKILL.md | 2 +- .antigravity/skills/code-review/SKILL.md | 20 +++++----------- .antigravity/skills/commitmsg/SKILL.md | 4 +--- .../skills/dependency-review/SKILL.md | 11 +++------ .../skills/efficient-orchestration/SKILL.md | 4 ++-- .antigravity/skills/review-pr/SKILL.md | 4 +--- .claude/commands/code-refinement.md | 2 +- .claude/commands/code-review.md | 20 +++++----------- .claude/commands/commitmsg.md | 4 +--- .claude/commands/dependency-review.md | 11 +++------ .claude/commands/efficient-orchestration.md | 4 ++-- .claude/commands/review-pr.md | 4 +--- .codex/skills/code-refinement/SKILL.md | 2 +- .codex/skills/code-review/SKILL.md | 20 +++++----------- .codex/skills/commitmsg/SKILL.md | 4 +--- .codex/skills/dependency-review/SKILL.md | 11 +++------ .../skills/efficient-orchestration/SKILL.md | 4 ++-- .codex/skills/review-pr/SKILL.md | 4 +--- .copilot/skills/code-refinement/SKILL.md | 2 +- .copilot/skills/code-review/SKILL.md | 20 +++++----------- .copilot/skills/commitmsg/SKILL.md | 4 +--- .copilot/skills/dependency-review/SKILL.md | 11 +++------ .../skills/efficient-orchestration/SKILL.md | 4 ++-- .copilot/skills/review-pr/SKILL.md | 4 +--- .kimi-code/skills/code-refinement/SKILL.md | 2 +- .kimi-code/skills/code-review/SKILL.md | 20 +++++----------- .kimi-code/skills/commitmsg/SKILL.md | 4 +--- .kimi-code/skills/dependency-review/SKILL.md | 11 +++------ .../skills/efficient-orchestration/SKILL.md | 4 ++-- .kimi-code/skills/review-pr/SKILL.md | 4 +--- README.md | 24 +++++++++++++++++++ prompts/code-review.md | 18 ++++---------- 32 files changed, 99 insertions(+), 168 deletions(-) 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