/pr-review-comments
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
$ npx -y skills add giuseppe-trisciuoglio/developer-kit --skill pr-review-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.
- You can call itInvoke it directly when you want it.
- Slash command
/pr-review-comments
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
pr-review-comments.SKILL.mdname: pr-review-comments
description: 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 #N", or having a JSON array of {file, line, summary} to turn into PR comments.
allowed-tools: Read, Write, BashPR Review Comments
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.
Prerequisites
- `gh` CLI installed and authenticated (`gh auth status`). The script auto-detects the
repo with `gh repo view`; pass `--repo OWNER/REPO` to override.
- The PR number to comment on.
- A JSON file: an **array** of objects. Required keys per object: `file`, `line`.
Message comes from `summary` and/or `failure_scenario` (combined into the body), or an explicit `body`. See [references/json-schema.md](references/json-schema.md) for the full schema and a sample.
Key constraint: only diff lines are commentable
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.
Workflow
1. Confirm the JSON path and the PR number. If the repo isn't obvious, run `gh repo view`. 2. **Dry-run first** to see what will be posted and what gets skipped:
scripts/post_pr_comments.py --pr <N> --json <path> --dry-run
3. Review the "Postable" / "Skipped" counts with the user. If lines were skipped because the diff moved, the line numbers in the JSON may be stale — reconcile before posting. 4. Post for real, choosing the mode (see below):
# 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
5. Report back the created review/comment URLs and the list of any skipped findings.
Choosing the mode
| 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.
Options reference
--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
Notes
- Multi-line range comments: include `start_line` (and optional `start_side`) in the JSON
object alongside `line`; the script passes them through.
- Always `--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.
- The script is the reliable path; don't hand-roll `gh api` calls for this — it handles
diff validation, repo/commit detection, and body assembly consistently.
Read more
name: pr-review-comments
description: 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 #N", or having a JSON array of {file, line, summary} to turn into PR comments.
allowed-tools: Read, Write, BashPR Review Comments
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.
Prerequisites
- `gh` CLI installed and authenticated (`gh auth status`). The script auto-detects the
repo with `gh repo view`; pass `--repo OWNER/REPO` to override.
- The PR number to comment on.
- A JSON file: an **array** of objects. Required keys per object: `file`, `line`.
Message comes from `summary` and/or `failure_scenario` (combined into the body), or an explicit `body`. See [references/json-schema.md](references/json-schema.md) for the full schema and a sample.
Key constraint: only diff lines are commentable
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.
Workflow
1. Confirm the JSON path and the PR number. If the repo isn't obvious, run `gh repo view`. 2. **Dry-run first** to see what will be posted and what gets skipped:
scripts/post_pr_comments.py --pr <N> --json <path> --dry-run
3. Review the "Postable" / "Skipped" counts with the user. If lines were skipped because the diff moved, the line numbers in the JSON may be stale — reconcile before posting. 4. Post for real, choosing the mode (see below):
# 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
5. Report back the created review/comment URLs and the list of any skipped findings.
Choosing the mode
| 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.
Options reference
--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
Notes
- Multi-line range comments: include `start_line` (and optional `start_side`) in the JSON
object alongside `line`; the script passes them through.
- Always `--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.
- The script is the reliable path; don't hand-roll `gh api` calls for this — it handles
diff validation, repo/commit detection, and body assembly consistently.
Modular plugin marketplace for Claude Code and agentic CLIs, with validated, spec-driven skills, agents, commands, and workflows for Java, TypeScript, Python, PHP, AWS, and AI.
Repo: giuseppe-trisciuoglio/developer-kit
Other skills on developer-kit.
- /chunking-strategy
Provides chunking strategies for RAG systems. Generates chunk size recommendations (256-1024 tokens), overlap percentages (10-20%), and semantic boundary detection methods. Validates semantic coherence and evaluates retrieval precision/recall metrics. Use when building
Open skill - /prompt-engineering
Provides workflows to write, debug, and optimize prompts for LLMs, including few-shot example selection, chain-of-thought structuring, system prompt design, and template composition. Use when the user asks to write or improve a prompt, wants help with few-shot examples,
Open skill - /rag
Implements document chunking, embedding generation, vector storage, and retrieval pipelines for Retrieval-Augmented Generation systems. Use when building RAG applications, creating document Q&A systems, or integrating AI with knowledge bases.
Open skill - /aws-cloudformation-auto-scaling
Provides AWS CloudFormation patterns for Auto Scaling including EC2, ECS, and Lambda. Use when creating Auto Scaling groups, launch configurations, launch templates, scaling policies, lifecycle hooks, and predictive scaling. Covers template structure with Parameters, Outputs,
Open skill - /aws-cloudformation-bedrock
Provides AWS CloudFormation patterns for Amazon Bedrock resources including agents, knowledge bases, data sources, guardrails, prompts, flows, and inference profiles. Use when creating Bedrock agents with action groups, implementing RAG with knowledge bases, configuring vector
Open skill - /aws-cloudformation-cloudfront
Provides AWS CloudFormation patterns for CloudFront distributions, origins (ALB, S3, Lambda@Edge, VPC Origins), CacheBehaviors, Functions, SecurityHeaders, parameters, Outputs and cross-stack references. Use when creating CloudFront distributions with CloudFormation, configuring
Open skill

