Add acceptance criteria verification skill and unify AI tool configs#9
Conversation
- Add ac-check skill that verifies code changes against GitHub issue acceptance criteria, with status reporting per AC item - Symlink CLAUDE.md → AGENTS.md so all AI tools read one source of truth - Add Codex and Cursor symlinks to shared skill directory
alireza-sharifpour
requested review from
RamRamez,
ae2079,
geleeroyale and
mmahdigh
WalkthroughNew skill configuration files are added to enable an "ac-check" acceptance criteria verification agent. The primary skill definition is established in Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~8 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.claude/skills/ac-check/SKILL.md (2)
98-98: Base branch assumption may need flexibility in edge cases.Line 98 hardcodes
stagingas the base branch in the output template. While this aligns with the typical workflow described in the PR objectives, there are edge cases where this assumption might not hold:
- Developer runs
/ac-checkwhile already onstagingbranch- Feature branch was forked from a different base (e.g.,
main,develop)- Hotfix branches that target production branches directly
Since the skill doesn't provide guidance for these scenarios, the AI agent might produce misleading output if the base isn't actually
staging.💡 Suggested enhancement
Consider adding a brief note in Step 3 or Step 1 that instructs the agent to:
- Detect the actual base branch (e.g., via
git merge-baseor branch tracking info)- Default to
stagingif detection fails or the branch is unambiguous- Use the detected base in the report rather than hardcoding
stagingAlternatively, document the assumption explicitly: "This skill assumes feature branches are based on
staging. If your branch has a different base, specify it when running the command."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/skills/ac-check/SKILL.md at line 98, Update the SKILL.md to avoid hardcoding the base branch: modify the text around Step 1/Step 3 (where `staging` is currently used) to either (A) instruct the agent to detect the actual base branch (e.g., via git merge-base or branch tracking info) and use that detected base in the report, defaulting to `staging` only when detection fails or is ambiguous, or (B) explicitly document the assumption by adding a short note that the skill assumes feature branches are based on `staging` and instruct users to specify a different base when applicable; reference the Step 1/Step 3 wording that currently outputs `staging` and replace it with the chosen detection/defaulting or explicit-assumption text.
56-62: Consider adding brief technical guidance for gathering all change types.Step 3 correctly emphasizes that the verification must include "committed changes, staged changes, unstaged modifications, and brand-new untracked files" (line 58), which is important for thorough AC coverage. However, gathering these different change types involves distinct git operations that may not be obvious from a simple branch comparison:
- Committed changes:
git diff staging...HEADorgit log staging..HEAD- Staged changes:
git diff --cached- Unstaged modifications:
git diff- Untracked files:
git status --porcelain(filtering untracked entries)Since Claude will need to orchestrate these separately, a brief note or example command sequence in this step could reduce ambiguity and ensure consistent behavior across invocations.
📋 Optional addition to Step 3
## Step 3 — Understand the Code Changes -Gather **all** changes on this branch compared to `staging` — this must include committed changes, staged changes, unstaged modifications, **and** brand-new untracked files. Make sure nothing is missed; new features often live in files that haven't been `git add`-ed yet. +Gather **all** changes on this branch compared to `staging` — this must include committed changes, staged changes, unstaged modifications, **and** brand-new untracked files. Make sure nothing is missed; new features often live in files that haven't been `git add`-ed yet. + +To capture everything, you'll need to combine multiple git operations: +- Committed changes: `git diff staging...HEAD` or `git log -p staging..HEAD` +- Staged changes: `git diff --cached` +- Unstaged modifications: `git diff` +- Untracked files: `git status --porcelain` (look for `??` entries) Read the changes carefully. For each changed file, understand what was added, modified, or removed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/skills/ac-check/SKILL.md around lines 56 - 62, Update Step 3 in SKILL.md to include concise, actionable git guidance showing how to gather each change type referenced (committed changes, staged changes, unstaged modifications, and untracked files): state which git operations to run for comparing the branch to staging, for inspecting the index (staged), for unstaged workspace diffs, and for listing untracked files (porcelain-friendly output). Mention these four categories by name in the paragraph and add one short example command for each category so callers know exactly which git commands to run when following Step 3.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.claude/skills/ac-check/SKILL.md:
- Line 98: Update the SKILL.md to avoid hardcoding the base branch: modify the
text around Step 1/Step 3 (where `staging` is currently used) to either (A)
instruct the agent to detect the actual base branch (e.g., via git merge-base or
branch tracking info) and use that detected base in the report, defaulting to
`staging` only when detection fails or is ambiguous, or (B) explicitly document
the assumption by adding a short note that the skill assumes feature branches
are based on `staging` and instruct users to specify a different base when
applicable; reference the Step 1/Step 3 wording that currently outputs `staging`
and replace it with the chosen detection/defaulting or explicit-assumption text.
- Around line 56-62: Update Step 3 in SKILL.md to include concise, actionable
git guidance showing how to gather each change type referenced (committed
changes, staged changes, unstaged modifications, and untracked files): state
which git operations to run for comparing the branch to staging, for inspecting
the index (staged), for unstaged workspace diffs, and for listing untracked
files (porcelain-friendly output). Mention these four categories by name in the
paragraph and add one short example command for each category so callers know
exactly which git commands to run when following Step 3.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 38d09832-1fe3-4702-a49c-24887f46a0e1
📒 Files selected for processing (4)
.claude/skills/ac-check/SKILL.md.codex/skills/ac-check.cursor/skills/ac-checkCLAUDE.md
1 participant
Summary
.claude/skills/ac-check/SKILL.md): A reusable skill that verifies whether current branch code changes satisfy all Acceptance Criteria from a linked GitHub issue. It resolves the issue (from user input, branch name, or by asking), diffs againststaging, reads committed + staged + unstaged + untracked files, then reports per-AC status (Implemented / Partial / Not Addressed / Needs Manual Verification) withfile:lineevidence. Also flags genuinely relevant uncovered edge cases.CLAUDE.mdis now a symlink toAGENTS.mdso all AI-assisted tools (Claude Code, Codex, Cursor) read one source of truth instead of maintaining separate files..codex/skills/ac-checkand.cursor/skills/ac-checksymlink to the shared.claude/skills/ac-checkdirectory, so the skill is available across all three tools without duplication.Why
Developers currently have to manually cross-reference issue acceptance criteria against their code changes before opening PRs. This skill automates that verification step, catching missed or partially implemented requirements early. The symlink setup ensures all AI coding tools in the team share the same configs and skills.
What it does NOT do
How to use
From any feature branch, run
/ac-check(or/ac-check 123with an issue number). The skill fetches the issue, parses AC items, reads all code changes, and produces a verification report table.Test plan
/ac-checkon a branch with a linked issue and verify the report is generated correctly/ac-check 123with an explicit issue numberCLAUDE.mdsymlink points toAGENTS.mdSummary by CodeRabbit