ワンクリックでManusで任意のスキルを実行

doncheli-pr-review

スター56

フォーク10

更新日2026年3月28日 16:28

Perform a structured code review of a pull request aligned with SDD principles. Activate when user mentions "PR review", "pull request", "review PR", "code review", "review this diff".

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

doncheli

doncheli/don-cheli-sdd

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Don Cheli: PR Review

Instructions

Accept a PR number, URL, or diff as input
Fetch the diff using gh pr diff <number> or read the provided diff
Review in this sequence:
- Spec alignment: does the code implement what the spec says? Flag any drift
- Tests: are new behaviors covered? Is coverage maintained above 85%?
- Code quality: complexity, duplication, naming, error handling
- Security: OWASP Top 10 surface, secrets in code, input validation
- Breaking changes: API contract changes, schema migrations, deprecations
Categorize each finding: [blocker | warning | suggestion | nitpick]
Blockers must be resolved before merge — list them prominently
Never approve a PR with unresolved blockers
Generate a structured review comment ready to post with gh pr review
If spec docs are missing for a non-trivial feature, flag as a warning

Output Format

## PR Review — #142 "feat: add voice mode integration"

### Spec Alignment ✅
All scenarios in specs/voice.feature are covered by the implementation.

### Blockers 🔴
1. src/voice/transcriber.ts:34 — API key hardcoded. Must use env var VOICE_API_KEY.

### Warnings 🟡
1. src/voice/transcriber.ts — coverage 72%, below 85% threshold.
2. No migration doc for the new voice_sessions table.

### Suggestions 🟢
1. Consider extracting the cleanup logic at line 88 into a private method.

### Nitpicks
1. Line 12: typo "recieve" → "receive"

### Verdict: CHANGES REQUESTED
Resolve 1 blocker before merging.

このリポジトリの他の Skills

同じリポジトリ

doncheli-prd

doncheli/don-cheli-sdd

Generate professional Product Requirement Documents (PRD) from multiple sources — Figma designs, briefs, user research, existing code. Includes risk analysis, RICE prioritization, Gherkin stories and launch plan. Activate when user mentions "PRD", "product requirements", "requirement document", "product spec", "figma to PRD", "generate PRD".

2026-04-0756

doncheli-audit-trail

doncheli/don-cheli-sdd

Record and query the decision log for a project. Activate when user mentions "audit", "trail", "log decisions", "decision history", "why was this decided", "ADR", "architecture decision".

2026-04-0156

doncheli-data-policy

doncheli/don-cheli-sdd

Audit and document what personal or sensitive data the project collects, processes, and stores. Activate when user mentions "privacy", "data policy", "what data", "GDPR", "personal data", "data retention", "PII".

2026-04-0156

doncheli-drift

doncheli/don-cheli-sdd

Detect and reconcile divergence between specs and implementation. Activate when user mentions "drift", "sync", "spec divergence", "out of sync", "spec doesn't match", "implementation differs".

2026-04-0156

doncheli-estimate

doncheli/don-cheli-sdd

Estimate effort, duration and cost using 4 complementary models (Function Points, Planning Poker AI, COCOMO, Historical). Activate when user mentions "estimate", "estimation", "effort", "how long", "cost", "story points", "sizing".

2026-04-0156

doncheli-spec-score

doncheli/don-cheli-sdd

Evaluate the quality of a spec and return a structured score with improvement recommendations. Activate when user mentions "spec quality", "score spec", "how good is my spec", "spec review", "validate spec quality".

2026-04-0156

name	doncheli-pr-review
description	Perform a structured code review of a pull request aligned with SDD principles. Activate when user mentions "PR review", "pull request", "review PR", "code review", "review this diff".

Don Cheli: PR Review

Instructions

Accept a PR number, URL, or diff as input
Fetch the diff using gh pr diff <number> or read the provided diff
Review in this sequence:
- Spec alignment: does the code implement what the spec says? Flag any drift
- Tests: are new behaviors covered? Is coverage maintained above 85%?
- Code quality: complexity, duplication, naming, error handling
- Security: OWASP Top 10 surface, secrets in code, input validation
- Breaking changes: API contract changes, schema migrations, deprecations
Categorize each finding: [blocker | warning | suggestion | nitpick]
Blockers must be resolved before merge — list them prominently
Never approve a PR with unresolved blockers
Generate a structured review comment ready to post with gh pr review
If spec docs are missing for a non-trivial feature, flag as a warning

Output Format

## PR Review — #142 "feat: add voice mode integration"

### Spec Alignment ✅
All scenarios in specs/voice.feature are covered by the implementation.

### Blockers 🔴
1. src/voice/transcriber.ts:34 — API key hardcoded. Must use env var VOICE_API_KEY.

### Warnings 🟡
1. src/voice/transcriber.ts — coverage 72%, below 85% threshold.
2. No migration doc for the new voice_sessions table.

### Suggestions 🟢
1. Consider extracting the cleanup logic at line 88 into a private method.

### Nitpicks
1. Line 12: typo "recieve" → "receive"

### Verdict: CHANGES REQUESTED
Resolve 1 blocker before merging.