Self-review, create PR, and handle the feedback loop. Takes implemented code through review, PR creation, evidence gathering, and responding to every piece of feedback. Works standalone or as part of /ks-feature or /ks-ticket workflow.
How this skill is triggered — by the user, by Claude, or both
Slash command
/keller-solutions-core:present [PR number or 'current'][PR number or 'current']The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Present your work through self-review, PR creation, and the feedback loop.
Present your work through self-review, PR creation, and the feedback loop.
Never ignore feedback. Every comment gets a response.
If you agree with feedback, make the change and reply with the commit link. If you disagree, reply with clear rationale. This ensures every piece of feedback is acknowledged and addressed.
Before creating a PR, examine every change:
# View all changes from develop
git diff develop...HEAD
# List all modified files
git diff --name-only develop...HEAD
# View commit history
git log develop..HEAD --oneline
For each changed file, verify:
console.log, binding.pry, puts)Final verification before PR:
# All tests
bin/rails test
# All linters
bin/lint
# Security scan
bin/brakeman
All must pass before creating PR.
Before creating a PR, ensure CHANGELOG reflects the changes.
# Check if CHANGELOG was modified in this branch (use develop or main as base)
git diff develop...HEAD --name-only | grep -i changelog
# If not modified, check if CI validates CHANGELOG
grep -ri "changelog" .github/workflows/ 2>/dev/null | grep -v "#"
If CI validates CHANGELOG (like Version Bump Required checks):
The PR will fail if CHANGELOG isn't updated. Add an entry now:
# View what to document
git log develop..HEAD --oneline
# Edit CHANGELOG.md with [Unreleased] or new version section
Warning signs to check:
git diff shows code changes but CHANGELOG unchanged.github/workflows/ with changelog validationIf CHANGELOG needs updating, do it before creating the PR to avoid CI failures.
Before gathering evidence, complete every step of the story yourself using only the tools an average user has—a browser, not the Rails console. Each acceptance criterion should be reachable that way, with preconditions created through the application itself (per the plan skill's Deliver Without Seeding principle).
If a step can't be completed without seeding, check the story's Developer Notes: anticipated seeding should be called out there. If it isn't, flag it before asking a reviewer to accept—either the delivery order needs fixing or the note is missing.
Use /compound-engineering:feature-video to record a demonstration:
Capture before/after screenshots for UI changes, using browser tools or Playwright.
Capture a test summary for the PR body: bin/rails test 2>&1 | tail -20
# Feature branches → develop
# Hotfix branches → main
TARGET_BRANCH="develop"
gh pr create \
--base develop \
--title "feat(scope): brief description" \
--body "$(cat <<'EOF'
## Summary
[Brief description of what this PR does and why]
## Changes
- [Change 1]
- [Change 2]
- [Change 3]
## Test Plan
- [ ] Unit tests added/updated
- [ ] Manual testing performed
- [ ] Verified acceptance criteria
## Screenshots
[Include if UI changes]
## Checklist
- [ ] Tests pass
- [ ] Linters pass
- [ ] Self-review complete
Refs #[TICKET_NUMBER]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
PR_NUMBER=$(gh pr view --json number -q '.number')
PR_URL=$(gh pr view --json url -q '.url')
echo "PR created: $PR_URL"
Link the PR to your project management tool. See managing-tickets for tool-specific commands.
GitHub Issues: Use Refs #[NUMBER] in PR body (automatic linking).
Jira/ClickUp/Linear: Add PR link as comment and update status to "In Review":
# Example for ClickUp - see managing-tickets for full setup
curl -X POST "https://api.clickup.com/api/v2/task/[TASK_ID]/comment" \
-H "Authorization: ${CLICKUP_API_TOKEN}" \
-H "Content-Type: application/json" \
-d "{\"comment_text\": \"PR created: ${PR_URL}\"}"
curl -X PUT "https://api.clickup.com/api/v2/task/[TASK_ID]" \
-H "Authorization: ${CLICKUP_API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"status": "in review"}'
If the project has preview deployments:
# Wait for deployment
gh pr checks $PR_NUMBER
# Get preview URL (project-specific)
If applicable, run Playwright tests:
/compound-engineering:playwright-test
Monitor for automated review:
# Check for reviews
gh pr view $PR_NUMBER --json reviews -q '.reviews[] | select(.author.login == "copilot")'
# Get PR comments
gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/comments \
--jq '.[] | {id: .id, path: .path, line: .line, body: .body, user: .user.login}'
# Get review comments
gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/reviews \
--jq '.[] | {id: .id, body: .body, user: .user.login, state: .state}'
For each piece of feedback, determine the appropriate response.
Make the change
Commit with descriptive message
git add .
git commit -m "$(cat <<'EOF'
fix(scope): address review feedback
[Description of what changed]
Refs #[TICKET_NUMBER]
Co-Authored-By: Claude Opus 4.5 <[email protected]>
EOF
)"
Push the commit
git push
Get the commit SHA
COMMIT_SHA=$(git rev-parse --short HEAD)
Reply to the comment
gh api -X POST repos/{owner}/{repo}/pulls/$PR_NUMBER/comments/{comment_id}/replies \
-f body="Addressed with the help of Claude Code in $COMMIT_SHA. [1-2 sentence summary]."
Identify the relevant guideline or pattern
Reply with clear rationale
gh api -X POST repos/{owner}/{repo}/pulls/$PR_NUMBER/comments/{comment_id}/replies \
-f body="This follows [specific guideline/pattern]. [Clear explanation]. See [reference if applicable]."
For accepted feedback:
Addressed with the help of Claude Code in [commit-sha]. [Summary of change].
Examples:
For declined feedback:
This [pattern/approach] follows [guideline/convention]. [Explanation]. [Reference if applicable].
Examples:
app/services/. Changing would create inconsistency."# Check for unresolved comments
gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/comments \
--jq '[.[] | select(.in_reply_to_id == null)] | length'
If unresolved comments remain, repeat the evaluation.
After making changes:
bin/rails test
bin/lint
gh pr checks $PR_NUMBER
PR_URL=$(gh pr view --json url -q '.url')
PR_TITLE=$(gh pr view --json title -q '.title')
PR_BRANCH=$(gh pr view --json headRefName -q '.headRefName')
Claude does not merge PRs. Output notification for user:
---
## PR Ready for Final Review
**PR**: [PR_URL]
**Title**: [PR_TITLE]
**Branch**: [PR_BRANCH] → develop
### Summary
[Brief description of what was built and why]
### Completed Checklist
- [x] Story created following story-writing-guide
- [x] Feature branch from develop
- [x] TDD approach (tests written first)
- [x] All acceptance criteria implemented
- [x] Tests pass
- [x] Linting passes
- [x] Copilot review feedback addressed
- [x] All PR comments responded to
### Files Changed
- [List of key files modified]
### Ready for Your Review
Please review the PR and merge when satisfied.
**To merge:** `gh pr merge [PR_NUMBER] --squash --delete-branch`
---
When invoked directly (/ks-present):
When invoked as part of /ks-feature or /ks-ticket:
Specific code suggestions - usually accept and implement.
Architectural or design feedback - evaluate against guidelines.
Style preferences - accept unless conflicts with project style guide.
Clarification requests - reply with explanation (no code change needed).
Reply to a review comment:
gh api -X POST repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
-f body="Your reply here"
Get comment IDs:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
--jq '.[] | "\(.id) \(.path):\(.line)"'
Resolve a review thread:
gh api graphql -f query='
mutation {
resolveReviewThread(input: {threadId: "THREAD_ID"}) {
thread { isResolved }
}
}
'
This skill integrates with compound-engineering commands:
/compound-engineering:feature-video - Record video walkthrough/compound-engineering:playwright-test - Run browser tests/compound-engineering:resolve_todo_parallel - Address multiple findings/compound-engineering:resolve_pr_parallel - Parallel PR comment resolutionGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub keller-solutions/kslabs-marketplace --plugin keller-solutions-core