Skill
Content
Skill
/address-pr-comments
Standard workflow to address pull request review comments in Cecil. Use when responding to review feedback, fixing requested changes, or preparing a clear reviewer reply with reproduction, fix, tests, and response.
Install
$ npx -y skills add Cecilapp/Cecil --skill address-pr-comments --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/address-pr-comments
Context preview
The summary Claude sees to decide when to auto-load this skill.
Standard workflow to address pull request review comments in Cecil. Use when responding to review feedback, fixing requested changes, or preparing a clear reviewer reply with reproduction, fix, tests, and response.
SKILL.md
address-pr-comments.SKILL.mdname: address-pr-comments
description: Standard workflow to address pull request review comments in Cecil. Use when responding to review feedback, fixing requested changes, or preparing a clear reviewer reply with reproduction, fix, tests, and response.
Address PR Comments
Use this workflow to process review feedback consistently.
Scope
- Applies to PR comments and requested changes.
- Goal: produce a correct fix and a reviewer-ready response.
Required Sequence
0. Fetch comments
- General comments and reviews: `gh pr view <number> --comments`
- Inline comments (with file and line): `gh api repos/{owner}/{repo}/pulls/<number>/comments`
- If no PR number is given, use the PR of the current branch (`gh pr view --json number`).
1. Reproduction
- Identify the exact issue described by the reviewer.
- Reproduce with the smallest possible scenario.
- Confirm expected vs. actual behavior.
2. Fix
- Implement the minimal safe change.
- Preserve existing public behavior unless the review explicitly requests a behavior change.
- Follow project conventions in `AGENTS.md`.
3. Tests and checks
- Run the smallest relevant checks first.
- Use project commands as needed: `composer code:style`, `composer code:analyse`, `composer test`, `composer test:cli`.
- If a check is skipped, state it explicitly with reason.
4. Reviewer response
- Explain what was changed and why.
- Reference files and key lines.
- Summarize validation performed and outcomes.
- Call out risks, assumptions, and follow-ups if any.
- Keep details concise but sufficient for asynchronous review (what changed, why, and proof of validation).
- Show the response to the user and post it only after confirmation:
- general reply: `gh pr comment <number> --body-file <file>`
- inline reply: `gh api repos/{owner}/{repo}/pulls/<number>/comments/<comment_id>/replies -F body=@<file>`
Output Template
Use this structure in your final PR comment response:
- Issue reproduced: yes/no + short evidence
- Fix applied: concise summary + impacted files/components
- Validation: commands run + result (passed/failed/skipped)
- Notes: assumptions, limitations, risks, or next steps
Guardrails
- Do not include unrelated refactors.
- Do not revert user changes outside the scope.
- Keep diffs focused and reviewable.
Read more
name: address-pr-comments description: Standard workflow to address pull request review comments in Cecil. Use when responding to review feedback, fixing requested changes, or preparing a clear reviewer reply with reproduction, fix, tests, and response.
Address PR Comments
Use this workflow to process review feedback consistently.
Scope
- Applies to PR comments and requested changes.
- Goal: produce a correct fix and a reviewer-ready response.
Required Sequence
0. Fetch comments
- General comments and reviews: `gh pr view <number> --comments`
- Inline comments (with file and line): `gh api repos/{owner}/{repo}/pulls/<number>/comments`
- If no PR number is given, use the PR of the current branch (`gh pr view --json number`).
1. Reproduction
- Identify the exact issue described by the reviewer.
- Reproduce with the smallest possible scenario.
- Confirm expected vs. actual behavior.
2. Fix
- Implement the minimal safe change.
- Preserve existing public behavior unless the review explicitly requests a behavior change.
- Follow project conventions in `AGENTS.md`.
3. Tests and checks
- Run the smallest relevant checks first.
- Use project commands as needed: `composer code:style`, `composer code:analyse`, `composer test`, `composer test:cli`.
- If a check is skipped, state it explicitly with reason.
4. Reviewer response
- Explain what was changed and why.
- Reference files and key lines.
- Summarize validation performed and outcomes.
- Call out risks, assumptions, and follow-ups if any.
- Keep details concise but sufficient for asynchronous review (what changed, why, and proof of validation).
- Show the response to the user and post it only after confirmation:
- general reply: `gh pr comment <number> --body-file <file>`
- inline reply: `gh api repos/{owner}/{repo}/pulls/<number>/comments/<comment_id>/replies -F body=@<file>`
Output Template
Use this structure in your final PR comment response:
- Issue reproduced: yes/no + short evidence
- Fix applied: concise summary + impacted files/components
- Validation: commands run + result (passed/failed/skipped)
- Notes: assumptions, limitations, risks, or next steps
Guardrails
- Do not include unrelated refactors.
- Do not revert user changes outside the scope.
- Keep diffs focused and reviewable.
Stats
299
Stars
32
Forks
Active
Maintenance
PHP
Language
EUPL-1.2
License
6h ago
Last commit
13y ago
Created
5d ago
Added