jhste-skills 0.6.0 → 0.7.0

package/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 ## Unreleased
 
+## 0.7.0 - 2026-07-23
+
+### Added
+- Added `jhste-pr-review` for explicit, evidence-based pull request reviews that post only high-confidence actionable comments.
+- Added `jhste-review-followup` to validate existing PR feedback, apply only justified fixes, and update the existing PR branch.
+
 ## 0.6.0 - 2026-07-13
 
 ### Added
@@ -35,5 +41,4 @@
 ### Changed
 - Reworked the package into a single personal `jhste-coding` skill.
 - Removed bundled Matt Pocock workflow skills; users can install `mattpocock/skills` separately.
-- Removed jhste workflow/review/guard/setup skills and shared review doctrine from the model-facing package.
 - Simplified docs, package files, and validation around the one-skill structure.

package/README.en.md

@@ -8,23 +8,27 @@ A personal engineering skill set maintained around GPT-5.6's outcome-first, lean
 
 - **`jhste-coding`** — implements features, fixes bugs, and refactors code with a small change and relevant validation.
 - **`jhste-grill`** — sharpens a plan or design through one consequential decision question at a time.
+- **`jhste-pr-review`** — reviews explicitly requested PRs against the actual diff and posts only high-confidence actionable findings.
+- **`jhste-review-followup`** — validates existing PR feedback and pushes only justified fixes to the existing PR branch.
 - **`jhste-to-tickets`** — splits defined work into GitHub parent/sub-issues with native dependencies.
 - **`jhste-domain-modeling`** — clarifies domain terms, boundaries, and relationships, and records them in a glossary or ADR when requested.
 
-The skills do not require or automatically call one another. A request may use more than one when it contains multiple intents. For example, invoke `jhste-grill` with `jhste-domain-modeling` to interview through a design and record the domain terms that become settled.
+The skills do not require or automatically call one another. A request may use more than one when it contains multiple intents. `jhste-pr-review` handles the initial review; `jhste-review-followup` handles feedback already present on a PR, but neither depends on the other.
 
 ## Behavioral boundaries
 
 - `jhste-coding` applies only when repository code must change.
 - `jhste-grill` applies when the user wants an interview or decision stress test; ordinary ambiguity alone must not start a long interview.
+- `jhste-pr-review` applies only to an explicit PR code-review request. That request authorizes high-confidence inline review comments with the `COMMENT` event; approval or change-request decisions still require the exact explicit action.
+- `jhste-review-followup` applies only when the user explicitly asks to handle existing PR review feedback. It validates each item, fixes justified root causes, validates the result, and updates the existing PR branch. It does not merge, reply, resolve threads, change issues, or clean up work artifacts.
 - `jhste-to-tickets` drafts by default. It writes to GitHub only when the user explicitly asks to create, post, or publish the issues.
 - `jhste-domain-modeling` analyzes and proposes by default. It edits repository documentation only when the user asks to record or apply the decisions.
 
-This package intentionally omits TDD, code-review, debugging-process, Wayfinder, and architecture-audit workflows. It favors the model's baseline capabilities and repository CI or guidance, adding another skill only after a repeated real failure justifies it.
+This package intentionally omits TDD, debugging-process, Wayfinder, and architecture-audit workflows. It favors the model's baseline capabilities and repository CI or guidance, adding another skill only after a repeated real failure justifies it.
 
 ## Install user-wide from npm
 
-This package has no CLI. It distributes the four skills and their Codex metadata.
+This package has no CLI. It distributes the six skills and their Codex metadata.
 
 ```sh
 npm install -g jhste-skills
@@ -41,7 +45,7 @@ mkdir -p "$HOME/.agents/skills"
 cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-If another agent expects a different global skills directory, copy the four directories under `skills/` there. This package does not require project-local skill copies.
+If another agent expects a different global skills directory, copy the six directories under `skills/` there. This package does not require project-local skill copies.
 
 ## Development and validation
 

package/README.md

@@ -8,23 +8,27 @@ GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용
 
 - **`jhste-coding`** — 기능 구현, 버그 수정, 리팩터링을 작은 변경과 관련 검증으로 완료합니다.
 - **`jhste-grill`** — 계획이나 설계를 한 번에 하나의 중요한 결정 질문으로 구체화합니다.
+- **`jhste-pr-review`** — 사용자가 명시적으로 요청한 PR을 실제 diff 기준으로 리뷰하고 확신도 높은 actionable finding만 코멘트합니다.
+- **`jhste-review-followup`** — 기존 PR 피드백을 검증하고 타당한 수정만 기존 PR 브랜치에 반영합니다.
 - **`jhste-to-tickets`** — 명확해진 작업을 GitHub 부모/sub-issues와 native dependency로 분할합니다.
 - **`jhste-domain-modeling`** — 도메인 용어, 개념 경계, 관계를 명확히 하고 요청 시 glossary나 ADR에 반영합니다.
 
-스킬은 서로를 강제로 호출하지 않습니다. 하나의 요청이 여러 의도를 포함하면 함께 사용할 수 있습니다. 예를 들어 설계 인터뷰 중 확정된 용어를 기록하려면 `jhste-grill`과 `jhste-domain-modeling`을 함께 지정할 수 있습니다.
+스킬은 서로를 강제로 호출하지 않습니다. 하나의 요청이 여러 의도를 포함하면 함께 사용할 수 있습니다. `jhste-pr-review`는 최초 리뷰를 담당하고, `jhste-review-followup`은 기존 PR에 이미 달린 피드백을 처리하지만 서로를 필수로 요구하지 않습니다.
 
 ## 동작 경계
 
 - `jhste-coding`은 실제 코드 변경 요청에만 사용합니다.
 - `jhste-grill`은 사용자가 인터뷰나 결정 검증을 원할 때 사용하며, 단순한 모호성만으로 긴 인터뷰를 시작하지 않습니다.
+- `jhste-pr-review`는 사용자가 PR 코드 리뷰를 명시적으로 요청한 경우에만 사용합니다. 해당 요청은 확신도 높은 인라인 코멘트를 `COMMENT` event로 게시하는 것까지 승인하며, approve나 request changes는 해당 동작을 정확히 명시해야 합니다.
+- `jhste-review-followup`은 사용자가 기존 PR 리뷰 피드백 처리를 명시적으로 요청한 경우에만 사용합니다. 각 항목의 타당성을 검증하고, 타당한 root cause만 수정·검증한 뒤 기존 PR 브랜치를 업데이트합니다. 병합, 답글, thread resolve, 이슈 변경, 작업 흔적 정리는 수행하지 않습니다.
 - `jhste-to-tickets`는 기본적으로 초안을 만듭니다. 사용자가 GitHub에 생성·게시하라고 명시한 경우에만 외부 쓰기를 수행합니다.
 - `jhste-domain-modeling`은 기본적으로 분석하고 제안합니다. 사용자가 기록·반영을 요청한 경우에만 저장소 문서를 수정합니다.
 
-TDD, 코드 리뷰, 디버깅 절차, Wayfinder, 아키텍처 감사 workflow는 포함하지 않습니다. 모델의 기본 능력과 저장소 자체의 CI·지침을 우선하고, 반복되는 실제 실패가 확인될 때만 새 스킬을 추가합니다.
+TDD, 디버깅 절차, Wayfinder, 아키텍처 감사 workflow는 포함하지 않습니다. 모델의 기본 능력과 저장소 자체의 CI·지침을 우선하고, 반복되는 실제 실패가 확인될 때만 새 스킬을 추가합니다.
 
 ## npm으로 사용자 전역 설치
 
-이 패키지는 CLI를 제공하지 않습니다. npm 패키지는 네 스킬과 Codex 메타데이터를 배포하는 번들입니다.
+이 패키지는 CLI를 제공하지 않습니다. npm 패키지는 여섯 스킬과 Codex 메타데이터를 배포하는 번들입니다.
 
 ```sh
 npm install -g jhste-skills
@@ -41,7 +45,7 @@ mkdir -p "$HOME/.agents/skills"
 cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-다른 에이전트가 별도 전역 skills 디렉터리를 요구하면 `skills/` 아래의 네 디렉터리를 그 위치로 복사하세요. 이 패키지는 프로젝트별 스킬 복사본을 요구하지 않습니다.
+다른 에이전트가 별도 전역 skills 디렉터리를 요구하면 `skills/` 아래의 여섯 디렉터리를 그 위치로 복사하세요. 이 패키지는 프로젝트별 스킬 복사본을 요구하지 않습니다.
 
 ## 개발 및 검증
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "jhste-skills",
-  "version": "0.6.0",
-  "description": "A lean GPT-5.6-oriented engineering skill set for coding, decision interviews, GitHub tickets, and domain modeling.",
+  "version": "0.7.0",
+  "description": "A lean GPT-5.6-oriented engineering skill set for coding, pull request reviews and review follow-up, decision interviews, GitHub tickets, and domain modeling.",
   "type": "module",
   "license": "MIT",
   "repository": {

package/skills/jhste-pr-review/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: jhste-pr-review
+description: Review an identifiable GitHub pull request against its actual diff and directly related code, post only high-confidence actionable findings as GitHub review comments, and briefly summarize the result. Use when the user explicitly asks to review a PR, perform a PR code review, or identify problems in PR changes. Do not use merely because a pull request is mentioned, or for PR summaries, review-feedback follow-up, CI debugging, implementation, general code analysis, or branch inspection.
+---
+
+# JHSTE PR Review
+
+## Outcome
+
+Review the actual pull request changes, identify concrete engineering problems supported by inspected evidence, and post each remaining finding to GitHub whenever possible.
+
+Do not add an unrequested pull request overview, score, praise, or broad quality assessment. If the user explicitly requests an overall assessment, ground it in the findings and state any material inspection limit.
+
+## Required context
+
+Require an identifiable GitHub repository and pull request plus access to the actual diff and changed-file contents. Resolve a supplied URL, repository and number, or an unambiguous current-branch pull request. Do not guess between possible repositories or pull requests.
+
+If access, size, or tool limits prevent inspection of a material part of the changes, state the exact limit and do not imply that the complete pull request was reviewed.
+
+## Workflow
+
+1. Resolve the repository, pull request, base, and head.
+2. Read applicable repository and contributor guidance.
+3. Inspect the complete accessible diff and every changed file relevant to the requested review.
+4. Read only the surrounding code, callers, tests, contracts, or configuration needed to verify a changed path.
+5. Identify problems introduced or directly exposed by the pull request.
+6. For each candidate, verify the triggering condition, concrete consequence, affected scope, and correction direction.
+7. Cluster duplicate symptoms by root cause and remove speculative, stylistic, unrelated, or low-impact findings.
+8. Post each remaining finding to the narrowest accurate changed line when possible.
+9. Submit the review with the `COMMENT` event and summarize the result for the user.
+
+## Finding threshold
+
+Report a finding only when inspected code supports a credible material risk to one or more of:
+
+- user-visible behavior or accessibility;
+- runtime correctness, stability, error handling, data integrity, authorization, or sensitive information;
+- performance or resource use on an affected execution path;
+- compatibility with existing callers, types, APIs, ordering, nullability, or documented behavior;
+- maintainability when the change creates a concrete divergence or makes a directly related future change unsafe.
+
+Use design principles only to diagnose a demonstrated consequence. Do not assume production scale, a threat model, or a future extension that the repository and change do not support.
+
+Do not report personal preferences, formatting or naming without impact, optional abstractions, generic complexity advice, hypothetical extensions, praise, nice-to-have improvements, unrelated legacy issues, or repository-wide refactors. Prefer no finding over a low-confidence finding.
+
+## Finding format
+
+Make each finding self-contained and actionable. Include the changed location or behavior, the condition or execution path, the concrete consequence, and a scoped correction direction when clear.
+
+Keep unrelated findings separate. Do not add severity labels, category headers, scores, or principle names unless the user requests them. Do not include credentials, tokens, private payloads, or unrelated sensitive information.
+
+## GitHub actions
+
+Treat an explicit request to review a pull request as authorization to post review comments on that pull request.
+
+Prefer an inline comment on the narrowest accurate changed line. Use a general review comment only when no changed line is accurate. Submit with the `COMMENT` event by default.
+
+Use `APPROVE` or `REQUEST_CHANGES` only when the user explicitly requests that exact action. Do not post an empty review. Do not modify code, commits, branches, pull request metadata, labels, reviewers, issues, or merge state unless separately authorized.
+
+## Completion
+
+When findings were posted, report the number posted and summarize each finding in one sentence. If a finding could not be attached or posted accurately, provide it in full and explain the posting limit.
+
+When no finding remains, report that no high-confidence actionable finding was found and do not submit an empty review. Do not imply approval or absence of all defects. When the changes were unavailable, report the access limitation without inventing findings.
+
+Before completing, verify that every finding is supported by inspected code, introduced or exposed by the pull request, material, non-duplicative, within scope, and attached to an accurate changed line when possible.

package/skills/jhste-pr-review/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE PR Review"
+  short_description: "Review PR diffs and post actionable findings"
+  default_prompt: "Use $jhste-pr-review to review this pull request against the actual diff, post only high-confidence actionable inline comments, and briefly summarize the findings."
+
+policy:
+  allow_implicit_invocation: true

package/skills/jhste-review-followup/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: jhste-review-followup
+description: Validate review feedback already posted on an existing GitHub pull request, implement only justified fixes, validate the result, and update the existing PR head branch. Use when the user explicitly asks to inspect, verify, address, fix, or follow up on existing PR review comments. Do not use for an initial review, PR summary, CI debugging, unrelated implementation, merging, review-thread resolution, cleanup, or issue closure.
+---
+
+# JHSTE Review Follow-up
+
+## Outcome
+
+Evaluate existing pull request feedback against the code and actual execution context. Distinguish valid issues from incorrect, outdated, duplicate, informational, or already-satisfied comments. Fix only valid issues at their root cause, validate the result, and update the existing pull request branch.
+
+Existing review feedback defines the scope. Do not perform an initial review or manufacture additional findings as a substitute. The feedback may come from `jhste-pr-review` or any other reviewer; this skill does not depend on another skill.
+
+## Workflow
+
+### 1. Resolve the pull request and review state
+
+Identify the repository, pull request, base, head branch, and workspace. Inspect the working tree before editing. Use thread-aware review data when resolution, outdated state, or inline context matters; do not treat a flat comment list as complete.
+
+If the pull request or feedback cannot be identified reliably, report the missing context rather than guessing. If no existing feedback is found, report that state and stop.
+
+### 2. Assess the feedback
+
+Inspect the referenced code, nearby implementation, callers, tests, repository guidance, and execution path as needed. Cluster comments that describe the same root cause.
+
+Classify each relevant item as:
+
+- valid and requiring a change;
+- valid but already satisfied;
+- incorrect or based on a false assumption;
+- outdated or duplicated;
+- informational or better answered with explanation;
+- blocked by missing context.
+
+Do not implement a reviewer-proposed solution mechanically. Verify the underlying problem and the directly related scope.
+
+### 3. Apply justified fixes
+
+Implement the smallest change that fixes each verified root cause. Check directly equivalent branches only when they share that cause. Preserve established contracts, errors, ordering, nullability, and side-effect boundaries unless the verified issue requires changing them.
+
+Avoid unrelated refactoring, style cleanup, speculative hardening, generated-file churn, or repository-wide changes. Do not modify or include changes owned by another worker or session. Stage by file or hunk rather than with broad add, reset, clean, or formatting commands.
+
+If no code change is justified, do not create an empty commit or push.
+
+### 4. Validate
+
+Run the narrowest checks that exercise the changed behavior, then relevant module tests, type checks, lint, build, or smoke checks as needed. Distinguish task-caused failures from pre-existing failures, unrelated work, and environment problems. Never report a check as passed unless it ran successfully.
+
+### 5. Commit and push
+
+Inspect changed, staged, unstaged, and untracked files plus the final diff. Commit only task-owned changes traceable to validated feedback and push to the existing pull request head branch.
+
+Do not push to the base branch, create a replacement pull request, rewrite unrelated commits, or force-push without explicit authorization. If task-owned changes cannot be separated safely, do not commit or push.
+
+Do not merge or enable auto-merge, submit review replies, resolve threads, change issues, delete branches or worktrees, or clean temporary artifacts unless separately requested.
+
+## Blockers
+
+Attempt safe, scoped recovery such as retrieving missing thread context, running narrower validation, installing an already-declared dependency, separating changes by hunk, or using an isolated worktree. Stop when continuing would risk unrelated work, data loss, unreliable history, shared infrastructure, or scope expansion.
+
+## Completion
+
+Report the feedback inspected, classifications, fixes applied, items not changed and why, directly related scope checked, files changed, validation results and omissions, and commit and push status. State any material blocker or inspection limit.
+
+State explicitly that the pull request was not merged and that review replies, thread resolution, issue changes, branch deletion, worktree cleanup, and temporary-artifact cleanup were not performed unless separately authorized.

package/skills/jhste-review-followup/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Review Follow-up"
+  short_description: "Validate PR feedback and push justified fixes"
+  default_prompt: "Use $jhste-review-followup to verify the existing PR review feedback, implement only justified fixes, validate them, and update the existing PR head branch without merging or cleanup."
+
+policy:
+  allow_implicit_invocation: true