address-review
- Repo stars 0
- Author repo skills-registry
Address Review
This skill pulls unresolved review comments from the current branch's PR and addresses them. It handles code changes, spec proposal approvals, and pushes fixes.
Process
Step 1: Identify the PR and Feature Folder
- Run
git branch --show-currentto get the current branch. - Derive the feature folder:
- Strip the
feat/prefix from the branch name. - Extract the first path segment (everything before the second
/) — this is the feature slug. - Feature folder =
spec/features/[slug]/ - Example:
feat/0023-payment-retry/eng-123-retry-endpoint→spec/features/0023-payment-retry/ - Example:
feat/0023-payment-retry→spec/features/0023-payment-retry/
- Strip the
- Use
gh pr view --json number,url,headRefNameto find the open PR for this branch. - If no PR is found, fail with a clear message.
Step 2: Pull Unresolved Comments
- Use
gh api repos/{owner}/{repo}/pulls/{number}/commentsto get all review comments. - Filter for unresolved/pending comments (not yet resolved by the author).
- Group comments by category:
Code Comments
General code review feedback — bugs, style, logic issues, suggestions.
Spec Proposal Comments
Comments that reference SPEC-PROPOSAL.md entries. Look for patterns like:
- "SPEC-PROPOSAL: approved" or "SP-001: approved" — reviewer approves the proposal
- "SPEC-PROPOSAL: rejected" or "SP-001: rejected" — reviewer rejects the proposal
- Other comments on SPEC-PROPOSAL.md lines
Step 3: Address Code Comments
For each unresolved code comment:
- Read the referenced file and line range.
- Understand the reviewer's concern.
- Fix the code to address the concern.
- If the fix requires test changes, update tests and ensure they pass.
- If the fix changes behavior covered by
spec://references, verify the references are still correct.
Step 4: Handle Spec Proposals
Read SPEC-PROPOSAL.md from the feature folder (if it exists).
For Approved Proposals
- Read the proposal entry (e.g. SP-001).
- Apply the proposed change to the actual spec file (e.g. update
REQUIREMENTS.md,ADR.md, orDESIGN.mdin the feature folder). - Remove the approved entry from
SPEC-PROPOSAL.md.
For Rejected Proposals
- Read the rejection reason from the review comment.
- Revert any code that was written assuming the proposed spec change.
- Adjust the implementation to work within the existing spec.
- Remove the rejected entry from
SPEC-PROPOSAL.md. - Update tests if the behavior changed.
Cleanup
If all entries in SPEC-PROPOSAL.md are resolved (approved or rejected), delete the file entirely.
Step 5: Run Tests
Run the full test suite (or at minimum, tests related to the changes) to ensure everything passes after the fixes.
Step 6: Commit and Push
- Stage all modified files.
- Commit with message:
fix(NNNN-slug): address review comments for {ISSUE-ID} - Push to the current branch.
Step 7: Report
Present a summary:
- Number of comments addressed
- Code changes made
- Spec proposals approved/rejected and files updated
- Whether SPEC-PROPOSAL.md was cleaned up
- Test results
- Suggest running
/address-reviewagain after the next review cycle - If all comments are resolved and PR is approved, remind the user to merge the PR manually
<!-- tomevault:4.0:skill_md:2026-05-22 -->Source: aqaliarept/sdd — distributed by TomeVault.
- Fluxly category
- Engineering
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 88 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @tomevault-io · no license declared
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Write / modify
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. Process
Run git branch --show-current to get the current branch. Derive the feature folder: Strip the feat/ prefix from the branch name.
Use gh api repos/{owner}/{repo}/pulls/{number}/comments to get all review comments. Filter for unresolved/pending comments (not yet resolved by the author). Group comments by category:
For each unresolved code comment: Read the referenced file and line range. Understand the reviewer's concern.
Read SPEC-PROPOSAL.md from the feature folder (if it exists). For Approved Proposals Read the proposal entry (e.g. SP-001).
Run the full test suite (or at minimum, tests related to the changes) to ensure everything passes after the fixes.
# Address Review
This skill pulls unresolved review comments from the current branch's PR and addresses them. It handles code changes, spec proposal approvals, and pushes fixes.
## Process
### Step 1: Identify the PR and Feature Folder
1. Run `git branch --show-current` to get the current branch.
2. Derive the feature folder:
- Strip the `feat/` prefix from the branch name.
- Extract the first path segment (everything before the second `/`) — this is the feature slug.
- Feature folder = `spec/features/[slug]/`
- Example: `feat/0023-payment-retry/eng-123-retry-endpoint` → `spec/features/0023-payment-retry/`
- Example: `feat/0023-payment-retry` → `spec/features/0023-payment-retry/`
3. Use `gh pr view --json number,url,headRefName` to find the open PR for this branch.
4. If no PR is found, fail with a clear message.
### Step 2: Pull Unresolved Comments
1. Use `gh api repos/{owner}/{repo}/pulls/{number}/comments` to get all review comments.
2. Filter for unresolved/pending comments (not yet resolved by the author).
3. Group comments by category:
#### Code Comments
General code review feedback — bugs, style, logic issues, suggestions.
#### Spec Proposal Comments
Comments that reference SPEC-PROPOSAL.md entries. Look for patterns like:
- "SPEC-PROPOSAL: approved" or "SP-001: approved" — reviewer approves the proposal
- "SPEC-PROPOSAL: rejected" or "SP-001: rejected" — reviewer rejects the proposal
- Other comments on SPEC-PROPOSAL.md lines
### Step 3: Address Code Comments
For each unresolved code comment:
1. Read the referenced file and line range.
2. Understand the reviewer's concern.
3. Fix the code to address the concern.
4. If the fix requires test changes, update tests and ensure they pass.
… Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Process → Step 1: Identify the PR and Feature Folder → Step 2: Pull Unresolved Comments → Step 3: Address Code Comments → Step 4: Handle Spec Proposals → Step 5: Run Tests
terms -> This skill pulls unresolved review comments from the current branch's PR and addresses them. · 1. Run git branch --show-current to get the current branch. · 1. Use gh api repos/{owner}/{repo}/pulls/{number}/comments to get all review comments. · 1. Read the referenced file and line range. · Read SPEC-PROPOSAL.md from the feature folder (if it exists). · 1. Read the proposal entry (e.g. · 1. Read the rejection reason from the review comment. · If all entries in SPEC-PROPOSAL.md are resolved (approved or rejected), delete the file entirely.
files/cmd -> git branch --show-current · feat/ · spec/features/[slug]/ · feat/0023-payment-retry/eng-123-retry-endpoint · spec/features/0023-payment-retry/ · feat/0023-payment-retry · gh pr view --json number,url,headRefName · gh api repos/{owner}/{repo}/pulls/{number}/comments
body sha256 -> 4f4481b2a324
Decide Fit First
Design Intent
How To Use It
Boundaries And Review