From buyoung-skills
Reviews completed Linear sub-issues: cross-validates done criteria, code changes, and worker comments to approve, request changes, or seek clarification. For QA on done issues.
npx claudepluginhub buyoung/skills --plugin backend-skillsThis skill uses the workspace's default tool permissions.
Review sub-issues completed by `linear-issue-worker` and decide whether to approve, request changes, or ask for clarification.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Review sub-issues completed by linear-issue-worker and decide whether to approve, request changes, or ask for clarification.
| Stage | Skill | Role |
|---|---|---|
| 1 | linear-issue-creator | Creates main issue + sub-issues with structured templates |
| 2 | linear-issue-worker | Picks up sub-issues, performs code work, transitions to Done |
| 3 | linear-issue-reviewer | Validates Done sub-issues, approves or rejects |
The creator writes Done Criteria and Acceptance Criteria that serve as the contract for this entire pipeline. The worker fulfills that contract; the reviewer verifies it was fulfilled.
Each skill uses a distinct comment prefix so comments can be attributed to the correct stage:
| Skill | Comment Identifiers |
|---|---|
linear-issue-worker | ## ๐ Work Started, ## โ
Work Complete |
linear-issue-reviewer | ## ๋ฆฌ๋ทฐ ๊ฒฐ๊ณผ: |
The user provides a main issue identifier (e.g., PRI-42).
Linear:get_issue with includeRelations: true to fetch the main issueLinear:list_issues with parentId set to the main issue IDLinear:get_issue with includeRelations: true to get full details and commentsFilter sub-issues to find those needing review.
Review target conditions:
Done## โ
Work Complete comment exists (worker's completion report)## ๋ฆฌ๋ทฐ ๊ฒฐ๊ณผ: comment exists yet (not reviewed)Re-review detection:
## ๋ฆฌ๋ทฐ ๊ฒฐ๊ณผ: ๐ Changes Requested comment exists AND a newer ## โ
Work Complete comment follows it โ the worker has re-done the work โ this is a re-review targetStatus-based handling:
| Sub-Issue Status | Completion Comment | Review Comment | Decision |
|---|---|---|---|
| Done | Present | Absent | Review target |
| Done | Present | Approved | Already reviewed, skip |
| In Progress | Present | Changes Requested | Worker fixing, skip |
| Done | Present | Changes Requested โ then new Work Complete | Re-review target |
| Done | Absent | Absent | Exception (see Step 3 exceptions) |
| Todo / In Progress | โ | โ | Skip |
Present the review plan and wait for user confirmation:
Review Targets (PRI-42):
1. PRI-43 โ [project] Sub-issue title (first review)
2. PRI-45 โ [project] Sub-issue title (re-review)
Skipped:
- PRI-44 โ Already Approved
- PRI-46 โ Still In Progress
Proceed?
For each review target, execute the following verification cycle.
Gather the three sources needed for cross-validation:
| Source | Origin | How to Collect |
|---|---|---|
| Done Criteria | Creator wrote in sub-issue description | Parse ## Done Criteria section from description |
| Completion Comment | Worker's change summary | Find comment containing ## โ
Work Complete |
| Actual Code | Changed files | Extract file paths from the Changes section of completion comment โ read files |
Also collect:
## Target Location section from sub-issue description## Technical Details section from sub-issue descriptionCheck each Done Criteria item against both the completion comment and actual code:
| Evidence in Comment | Confirmed in Code | Verdict |
|---|---|---|
| Yes | Yes | Fulfilled |
| Yes | No | Not fulfilled (comment-code mismatch) |
| No | Yes | Fulfilled (flag: comment should be updated) |
| No | No | Not fulfilled |
Cross-check against the Technical Details section:
Review for general code quality regardless of what the issue specifies:
console.log, debugger, commented-out code, etc.)Based on steps 3bโ3e, choose one of three verdicts:
| Verdict | Condition | Status Change |
|---|---|---|
| Approved | All Done Criteria fulfilled, no critical quality issues | Keep Done |
| Changes Requested | Any Done Criteria not fulfilled, or critical quality issues found | Done โ In Progress ("started") |
| Clarification Needed | Implementation choices need explanation, judgment reserved | Keep Done |
Write a review comment based on the verdict. Use the templates from references/comment-templates.md.
Review Comment Quality Guide (Content Skill Principles):
Apply these principles when writing review comments to improve quality. Target audience: Fullstack developers | Language: Korean | Tone: Professional
notifications.service.ts:42 queries notifications without userId validation. Other users' notifications could be exposed."{ error: 'NOT_FOUND', message: '...' } format."For Changes Requested, also transition the status:
Linear:save_issue
id: "<sub-issue-id>"
state: "started"
Proceed to the next review target and repeat from 3a.
Execute this only when all sub-issues have been Approved.
## ๋ฆฌ๋ทฐ ๊ฒฐ๊ณผ: โ
Approved comment๐ Changes Requested or โ Clarification Needed as its latest review, do NOT proceed with final verification โ inform the user which sub-issues are pendingPost the final review comment on the main issue using the templates from references/comment-templates.md (Final Review sections).
Apply the same Review Comment Quality Guide above to the final review comment as well.
For exception handling (missing comments, scope creep, conflicts, ambiguous criteria, re-review), see references/exceptions.md.
For Linear API details (state values, description parsing, comment identification, tool calls, retry policy), see references/linear-api.md.