تشغيل أي مهارة في Manus بنقرة واحدة

$pwd:

review-pr

Name: Review Pr
Author: hmislk

// Investigate and resolve GitHub pull request review comments for HMIS. Use when the user wants Codex to read PR review threads, assess CodeRabbit or Codex feedback, discuss valid fixes, batch and apply changes, reply to each comment, and re-request review.

تشغيل في Manus

$ git log --oneline --stat

stars:٢١٤

forks:١٣٢

updated:٢٤ مايو ٢٠٢٦ في ٠٢:٢٢

مستكشف الملفات

2 ملفات

SKILL.md

readonly

name	review-pr
description	Investigate and resolve GitHub pull request review comments for HMIS. Use when the user wants Codex to read PR review threads, assess CodeRabbit or Codex feedback, discuss valid fixes, batch and apply changes, reply to each comment, and re-request review.

Review PR

Overview

Use this skill when working a PR review loop on HMIS: collect review comments, verify them against the codebase, discuss unclear items with the user, apply confirmed fixes, and close the loop on GitHub.

Workflow

Fetch the branch and inspect the PR comments.
- git fetch origin
- gh pr checkout <pr-number-or-url>
- gh api repos/hmislk/hmis/pulls/<pr-number>/comments
Group comments by file and behavior.
- Read the touched code and nearby context with rg, Get-Content, or git show.
- Separate valid findings from false positives and project conventions.
Discuss before changing anything ambiguous.
- Ask the user when a reviewer suggestion could change behavior, contracts, or workflow.
- Prefer confirmation over guessing when automated review output is uncertain.
Apply confirmed fixes in a tight batch.
- Keep unrelated cleanup out of the review-fix commit.
- Preserve HMIS rules: no constructor signature edits, no mock data, JPQL first, findLongByJpql for count queries.
Check the repository-specific hazards before pushing.
- Verify persistence.xml placeholders remain ${JDBC_DATASOURCE} and ${JDBC_AUDIT_DATASOURCE}.
- For JSF/XHTML fixes, keep standard <!DOCTYPE html> and use h:outputText for static ERP labels.
Push, reply, and re-request review — by the cardinal rules below.

Cardinal Rules for Posting on a PR

Do NOT create new top-level inline comments on the PR. Each one becomes a thread the author must manually resolve. Self-review noise is the most common offender.
Reply only after fixing (or explicitly dismissing). Bots cannot fix anything — describe action taken, not requested.
- Valid + fixed → "Fixed in <commit-sha>: <what was changed>"
- Dismissed → "Dismissed because: <specific reasoning>"
- ⚠️ "Please resolve" wording on a CodeRabbit thread triggers CodeRabbit Chat, which opens a NEW PR attempting the fix against a stale snapshot. These auto-PRs have shipped unsafe diffs in the past (PR #20979). If accidentally triggered: close the PR, delete the coderabbitai/chat/<sha> branch.
Replies go UNDER existing reviewer threads only — use POST /pulls/{pr}/comments/{id}/replies. Never as new top-level comments.
Self-review items go in the commit message (or PR description if deferred). Never as new inline comments. Reference file:line in the commit message so reviewers can find the change in the diff.
ONE re-review request at the end — click "Re-request review" once after all fixes are pushed and all existing threads have replies. Not per item.

Order: discuss → fix → push → reply to existing threads → one re-review request.

Endpoint Cheat Sheet

Want	Endpoint	Use?
Reply under existing reviewer comment	`POST /pulls/{pr}/comments/{id}/replies`	YES
New standalone inline comment	`POST /pulls/{pr}/comments`	NO — creates a fresh thread
Bundled review wrapper	`POST /pulls/{pr}/reviews`	NO
General PR comment	`POST /issues/{n}/comments`	Sparingly, only for actual PR-wide notes

# List existing comments to find a parent ID
gh api "repos/hmislk/hmis/pulls/<PR>/comments" \
  --jq '.[] | "\(.id) \(.user.login) \(.path):\(.line // .original_line)"'

# Post a threaded reply (the only legitimate reply form)
gh api -X POST "repos/hmislk/hmis/pulls/<PR>/comments/<COMMENT_ID>/replies" \
  -f body="Fixed in <commit-sha>: <what was changed>."

Common Review Patterns

CodeRabbit suggestions often need verification against the actual entity or controller method names.
Review comments about null checks, constructor changes, or typos may be false positives in this codebase.
When a reviewer points to session-scoped state, re-check the persisted entity at submit time before mutation.

Reference

developer_docs/git/pr-review-workflow.md
AGENTS.md

related-skills.json

نفس المستودع

review-pr.md

from "hmislk/hmis"

Handle CodeRabbit and Codex review comments on a GitHub PR. Fetches the PR, investigates each comment against the codebase, discusses validity with the user, batches valid fixes, and guides through push and reply steps.

2026-05-24214

jsf-ajax.md

from "hmislk/hmis"

JSF AJAX update rules for the HMIS project. Use when working on AJAX updates, p:commandButton update attributes, PrimeFaces AJAX callbacks, partial page rendering, or debugging AJAX update failures. Also covers JSF navigation patterns: why f:viewAction must not be used on @SessionScoped beans, and how initialization belongs in navigation methods. Critical rules to prevent silent AJAX failures and refresh/back-button state corruption.

Commit code following HMIS project conventions. Use when committing changes with proper issue closing keywords, message format, and co-author attribution.

2026-05-17214

start-issue.md

from "hmislk/hmis"

Full environment setup when starting work on a GitHub issue. Creates a feature branch from origin/development, swaps persistence.xml to local JNDI settings, assigns the issue, and guides project board setup. Use when beginning work on any new issue: "start issue 20408", "/start-issue 20408", or "prepare env for issue 20408".

2026-05-17214

verify-persistence.md

from "hmislk/hmis"

Verify and manage persistence.xml configuration around git push. Use before pushing to ensure environment variable placeholders are in place, and after pushing to restore local JNDI names for continued testing. Prevents QA deployment failures from hardcoded datasource names.

2026-05-17214

package.json

"author": "hmislk"

"repository": "hmislk/hmis"

فتح مستودع GitHub عرض مستودعات المنشئ

$ install --global

$ download --local

تشغيل في Manus

$ useful --forSOC

محللو ضمان جودة البرمجيات والمختبرونمهن الحاسوب والرياضيات15-1253L4

Review PR

Overview

Workflow

Fetch the branch and inspect the PR comments.

git fetch origin
gh pr checkout <pr-number-or-url>
gh api repos/hmislk/hmis/pulls/<pr-number>/comments

Group comments by file and behavior.

Read the touched code and nearby context with rg, Get-Content, or git show.
Separate valid findings from false positives and project conventions.

Discuss before changing anything ambiguous.

Ask the user when a reviewer suggestion could change behavior, contracts, or workflow.
Prefer confirmation over guessing when automated review output is uncertain.

Apply confirmed fixes in a tight batch.

Keep unrelated cleanup out of the review-fix commit.
Preserve HMIS rules: no constructor signature edits, no mock data, JPQL first, findLongByJpql for count queries.

Check the repository-specific hazards before pushing.

Verify persistence.xml placeholders remain ${JDBC_DATASOURCE} and ${JDBC_AUDIT_DATASOURCE}.
For JSF/XHTML fixes, keep standard <!DOCTYPE html> and use h:outputText for static ERP labels.

Push, reply, and re-request review — by the cardinal rules below.

Cardinal Rules for Posting on a PR

Do NOT create new top-level inline comments on the PR. Each one becomes a thread the author must manually resolve. Self-review noise is the most common offender.

Reply only after fixing (or explicitly dismissing). Bots cannot fix anything — describe action taken, not requested.

Valid + fixed → "Fixed in <commit-sha>: <what was changed>"
Dismissed → "Dismissed because: <specific reasoning>"
⚠️ "Please resolve" wording on a CodeRabbit thread triggers CodeRabbit Chat, which opens a NEW PR attempting the fix against a stale snapshot. These auto-PRs have shipped unsafe diffs in the past (PR #20979). If accidentally triggered: close the PR, delete the coderabbitai/chat/<sha> branch.

Replies go UNDER existing reviewer threads only — use POST /pulls/{pr}/comments/{id}/replies. Never as new top-level comments.

Self-review items go in the commit message (or PR description if deferred). Never as new inline comments. Reference file:line in the commit message so reviewers can find the change in the diff.

ONE re-review request at the end — click "Re-request review" once after all fixes are pushed and all existing threads have replies. Not per item.

Order: discuss → fix → push → reply to existing threads → one re-review request.

Endpoint Cheat Sheet

Want

Endpoint

Use?

Reply under existing reviewer comment

POST /pulls/{pr}/comments/{id}/replies

YES

New standalone inline comment

POST /pulls/{pr}/comments

NO — creates a fresh thread

Bundled review wrapper

POST /pulls/{pr}/reviews

General PR comment

POST /issues/{n}/comments

Sparingly, only for actual PR-wide notes

# List existing comments to find a parent ID gh api "repos/hmislk/hmis/pulls/<PR>/comments" \ --jq '.[] | "\(.id) \(.user.login) \(.path):\(.line // .original_line)"' # Post a threaded reply (the only legitimate reply form) gh api -X POST "repos/hmislk/hmis/pulls/<PR>/comments/<COMMENT_ID>/replies" \ -f body="Fixed in <commit-sha>: <what was changed>."

Common Review Patterns

CodeRabbit suggestions often need verification against the actual entity or controller method names.

Review comments about null checks, constructor changes, or typos may be false positives in this codebase.

When a reviewer points to session-scoped state, re-check the persisted entity at submit time before mutation.

Reference

developer_docs/git/pr-review-workflow.md

AGENTS.md

review-pr

Review PR

Overview

Workflow

Cardinal Rules for Posting on a PR

Endpoint Cheat Sheet

Common Review Patterns

Reference

المزيد من هذا المستودع

المزيد من هذا المستودع

Review PR

Overview

Workflow

Cardinal Rules for Posting on a PR

Endpoint Cheat Sheet

Common Review Patterns

Reference