plugins/developer-kit-core/skills/pr-review-comments/SKILL.md
Posts review findings from a JSON file as inline comments on a GitHub Pull Request, attaching each comment to its file and line. Use when you have a list/JSON of review findings (each with a file path, line number, and a message such as summary/failure_scenario) and want them published on a PR as inline review comments. Triggers include "post these review comments on the PR", "associate comments to files in the PR", "publish review findings to PR
npx skillsauth add giuseppe-trisciuoglio/developer-kit pr-review-commentsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Publish a JSON array of review findings as inline comments on a GitHub Pull Request,
each anchored to its file and line. Uses the GitHub API through the authenticated
gh CLI, so no token handling is needed.
gh CLI installed and authenticated (gh auth status). The script auto-detects the
repo with gh repo view; pass --repo OWNER/REPO to override.file, line.
Message comes from summary and/or failure_scenario (combined into the body), or an
explicit body. See references/json-schema.md for the full
schema and a sample.GitHub only accepts an inline comment if the target line is part of the PR's diff.
line is the line number in the new file (use side: "LEFT" for removed lines).
The script fetches the PR diff, validates every finding against the actual hunks, and
skips any whose line is outside the diff — reporting them at the end so nothing is
lost silently. There is no way to attach a line comment to an unchanged, undiffed line.
gh repo view.scripts/post_pr_comments.py --pr <N> --json <path> --dry-run
# Grouped (default): one PR review bundling all comments
scripts/post_pr_comments.py --pr <N> --json <path> --event COMMENT
# Individual: one separate inline comment per finding
scripts/post_pr_comments.py --pr <N> --json <path> --mode individual
| Mode | Endpoint | Use when |
|------|----------|----------|
| grouped (default) | POST /pulls/{n}/reviews | Publishing a set of findings as one review. One notification; can set --event APPROVE \| REQUEST_CHANGES \| COMMENT. |
| individual | POST /pulls/{n}/comments | Adding standalone comments incrementally, or when each finding should be its own thread/notification. |
Default to grouped with --event COMMENT unless the user wants a verdict or separate threads.
--pr N PR number (required)
--json PATH JSON array of findings (required)
--repo OWNER/REPO Override auto-detected repo
--mode grouped|individual Default: grouped
--event COMMENT|APPROVE|REQUEST_CHANGES Grouped-mode verdict (default COMMENT)
--review-body TEXT Top-level summary body for the grouped review
--commit SHA Commit to anchor to (default: PR head SHA)
--dry-run Validate and print payloads without posting
start_line (and optional start_side) in the JSON
object alongside line; the script passes them through.--dry-run before a real post on an unfamiliar PR — stale line numbers are the
most common failure and the dry-run surfaces them as "skipped" without side effects.gh api calls for this — it handles
diff validation, repo/commit detection, and body assembly consistently.development
Explore codebase before committing to a change. Phase executor skill for specs.explore command.
development
Executes real end-to-end verification against a running application after specification implementation. Detects the application type, starts the local runtime (Docker, Node, Spring Boot, etc.), runs real tests (curl for REST APIs, Playwright for web SPAs, computer-use for desktop apps), verifies acceptance criteria from the functional specification, generates a markdown report, and tears down the environment. Use when: user asks to verify a completed spec with real tests, run e2e checks after implementation, validate acceptance criteria in a live environment, or test the feature for real after task completion.
development
Initialize Spec-Driven Development context — detects tech stack, conventions, architecture patterns, and bootstraps persistence backends. Triggers on 'sdd-init', 'init sdd', 'setup sdd', 'initialize sdd', 'setup project', 'initialize project context'. Creates/updates docs/specs/architecture.md & ontology.md (Constitution), and populates knowledge-graph.json.
development
Optimizes raw idea descriptions into structured prompts ready for the brainstorming workflow. TRIGGER when: user says "optimize for brainstorm", "prepare idea for brainstorm", "enhance this idea", "make this ready for brainstorming", "imposta per brainstorm", or wants to improve a feature idea before using /specs.brainstorm. DO NOT TRIGGER for code optimization, refactoring, or general prompt engineering tasks.