jhste-skills 0.5.2 → 0.7.0

package/CHANGELOG.md

@@ -2,6 +2,29 @@
 
 ## 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
+- Added `jhste-grill` for focused, one-question-at-a-time decision interviews.
+- Added `jhste-to-tickets` for GitHub-native parent issues, sub-issues, and dependency graphs.
+- Added `jhste-domain-modeling` for domain terminology, concept boundaries, glossaries, and selective ADR capture.
+- Added Codex UI metadata and explicit implicit-invocation policy for every bundled skill.
+
+### Changed
+- Reworked `jhste-coding` from a SOLID tutorial into a lean outcome, contract, autonomy, and validation discipline for GPT-5.6.
+- Expanded the npm package, documentation, and validation from one skill to four independent skills.
+- Replaced the recommendation to install Matt Pocock workflows separately with a curated JHSTE-owned workflow set.
+
+### Removed
+- Removed SOLID-first branding and exhaustive SOLID restatement from the coding skill.
+- Kept TDD, code review, debugging-process, Wayfinder, and architecture-audit workflows outside the package.
+
 ## 0.5.2 - 2026-07-12
 
 ### Changed
@@ -18,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

@@ -2,50 +2,56 @@
 
 [한국어](README.md) | ENG
 
-A tiny personal coding-discipline skill.
+A personal engineering skill set maintained around GPT-5.6's outcome-first, lean-prompt guidance. Each skill works independently and may be selected implicitly when the user's intent matches its narrow trigger.
 
-This repository provides one skill:
+## Skills
 
-- `jhste-coding`: a lightweight SOLID-first coding discipline for repository code edits.
+- **`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.
 
-It does not vendor workflow skills. Use `mattpocock/skills` separately for broader planning, issue, PRD, debugging, architecture, or review workflows.
+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, 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 does not provide a CLI. The npm package is a small distribution bundle for the skill file.
+This package has no CLI. It distributes the six skills and their Codex metadata.
 
 ```sh
 npm install -g jhste-skills
 mkdir -p "$HOME/.agents/skills"
-cp -R "$(npm root -g)/jhste-skills/skills/jhste-coding" "$HOME/.agents/skills/"
+cp -R "$(npm root -g)/jhste-skills/skills/." "$HOME/.agents/skills/"
 ```
 
-After updating the npm package, run the copy command again to refresh the installed skill.
+Run the copy command again after updating the npm package. Restart Codex if the updated skills do not appear.
 
 ## Install user-wide from the repository
 
 ```sh
 mkdir -p "$HOME/.agents/skills"
-cp -R skills/jhste-coding "$HOME/.agents/skills/"
+cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-For repository-scoped use, copy the skill from this checkout into the target repository's `.agents/skills` directory.
+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
 
 ```sh
-mkdir -p /path/to/target-repo/.agents/skills
-cp -R skills/jhste-coding /path/to/target-repo/.agents/skills/
+npm test
+npm pack --dry-run
 ```
 
-If another agent expects a different skills directory, copy `skills/jhste-coding/` there instead. Restart Codex if the updated skill does not appear.
-
-## SOLID-first discipline
-
-`jhste-coding` keeps code changes small and practical, with SOLID as the main lens:
-
-- **Single Responsibility:** keep each changed unit centered on one clear job.
-- **Open/Closed:** add extension seams only when real variation would otherwise keep changing the same core logic.
-- **Liskov Substitution:** preserve caller-facing expectations such as return shape, nullability, errors, and side effects.
-- **Interface Segregation:** depend on the smallest useful contract.
-- **Dependency Inversion:** keep business rules separate from concrete side effects when it improves clarity.
-
-The skill is for active coding discipline, not broader process automation or review pipelines.
+Pushing a `v*.*.*` release tag runs GitHub Actions checks and publishes the package through npm trusted publishing.

package/README.md

@@ -2,50 +2,56 @@
 
 한국어 | [ENG](README.en.md)
 
-작은 개인용 코딩 규율 스킬입니다.
+GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용 엔지니어링 스킬 모음입니다. 각 스킬은 독립적으로 동작하며, 필요한 경우 Codex가 사용자 의도에 맞춰 자동 호출할 수 있습니다.
 
-이 저장소는 하나의 스킬만 제공합니다.
+## 스킬
 
-- `jhste-coding`: 저장소 코드 수정 중 적용하는 가벼운 SOLID-first 코딩 규율
+- **`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에 반영합니다.
 
-이 저장소는 workflow 스킬을 vendoring하지 않습니다. 더 넓은 계획, 이슈, PRD, 디버깅, 아키텍처, 리뷰 workflow에는 `mattpocock/skills`를 별도로 사용하세요.
+스킬은 서로를 강제로 호출하지 않습니다. 하나의 요청이 여러 의도를 포함하면 함께 사용할 수 있습니다. `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·지침을 우선하고, 반복되는 실제 실패가 확인될 때만 새 스킬을 추가합니다.
 
 ## npm으로 사용자 전역 설치
 
-이 패키지는 CLI를 제공하지 않습니다. npm 패키지는 스킬 파일을 배포하기 위한 작은 번들입니다.
+이 패키지는 CLI를 제공하지 않습니다. npm 패키지는 여섯 스킬과 Codex 메타데이터를 배포하는 번들입니다.
 
 ```sh
 npm install -g jhste-skills
 mkdir -p "$HOME/.agents/skills"
-cp -R "$(npm root -g)/jhste-skills/skills/jhste-coding" "$HOME/.agents/skills/"
+cp -R "$(npm root -g)/jhste-skills/skills/." "$HOME/.agents/skills/"
 ```
 
-npm 패키지를 업데이트한 뒤에는 복사 명령을 다시 실행해야 설치된 스킬도 갱신됩니다.
+npm 패키지를 업데이트한 뒤에는 복사 명령을 다시 실행해야 설치된 스킬도 갱신됩니다. Codex가 변경된 스킬을 표시하지 않으면 다시 시작하세요.
 
 ## 저장소에서 사용자 전역 설치
 
 ```sh
 mkdir -p "$HOME/.agents/skills"
-cp -R skills/jhste-coding "$HOME/.agents/skills/"
+cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-특정 저장소에서만 사용하려면 이 저장소를 내려받은 위치에서 대상 저장소의 `.agents/skills`로 복사하세요.
+다른 에이전트가 별도 전역 skills 디렉터리를 요구하면 `skills/` 아래의 여섯 디렉터리를 그 위치로 복사하세요. 이 패키지는 프로젝트별 스킬 복사본을 요구하지 않습니다.
+
+## 개발 및 검증
 
 ```sh
-mkdir -p /path/to/target-repo/.agents/skills
-cp -R skills/jhste-coding /path/to/target-repo/.agents/skills/
+npm test
+npm pack --dry-run
 ```
 
-다른 에이전트가 별도 skills 디렉터리를 요구하면 `skills/jhste-coding/`을 그 위치로 복사하세요. Codex가 변경된 스킬을 표시하지 않으면 다시 시작하세요.
-
-## SOLID-first 규율
-
-`jhste-coding`은 작은 실제 코드 변경에 SOLID를 주된 렌즈로 적용합니다.
-
-- **단일 책임:** 변경한 단위가 하나의 분명한 일을 하도록 유지합니다.
-- **개방/폐쇄:** 실제 변형이 반복해서 같은 핵심 로직을 바꾸게 만들 때만 확장 지점을 둡니다.
-- **리스코프 치환:** 반환 형태, null 가능성, 오류, 부수 효과 같은 호출자 기대를 보존합니다.
-- **인터페이스 분리:** 필요한 만큼의 작은 계약에 의존합니다.
-- **의존성 역전:** 명확해질 때 비즈니스 규칙과 구체적인 부수 효과를 분리합니다.
-
-이 스킬은 코드 작성 중 쓰는 규율이며 더 넓은 프로세스 자동화나 리뷰 파이프라인이 아닙니다.
+릴리스 태그 `v*.*.*`를 푸시하면 GitHub Actions가 테스트 후 npm trusted publishing으로 공개 배포합니다.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "jhste-skills",
-  "version": "0.5.2",
-  "description": "A single lightweight SOLID-first coding discipline skill.",
+  "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": {
@@ -9,14 +9,14 @@
     "url": "git+https://github.com/jhste102lab/jhste-skills.git"
   },
   "files": [
-    "skills/jhste-coding/SKILL.md",
+    "skills",
     "README.md",
     "README.en.md",
     "CHANGELOG.md",
     "LICENSE"
   ],
   "scripts": {
-    "test": "node --input-type=module -e \"import fs from 'node:fs'; const exists = (p) => fs.existsSync(p); const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8')); const skill = 'skills/jhste-coding/SKILL.md'; if (!exists(skill)) throw new Error('missing skill'); const text = fs.readFileSync(skill, 'utf8'); if (!/^---\\nname: jhste-coding\\ndescription: .+\\n---/m.test(text)) throw new Error('invalid skill frontmatter'); const dirs = fs.readdirSync('skills', { withFileTypes: true }).filter((d) => d.isDirectory()).map((d) => d.name); if (dirs.length !== 1 || dirs[0] !== 'jhste-coding') throw new Error('expected only jhste-coding skill'); for (const file of pkg.files) if (!exists(file)) throw new Error('package file does not exist: ' + file); for (const file of ['README.md', 'README.en.md']) { const body = fs.readFileSync(file, 'utf8'); if (!body.includes('jhste-coding')) throw new Error(file + ' does not describe jhste-coding'); for (const match of body.matchAll(/\\[[^\\]]+\\]\\(([^)]+)\\)/g)) { const href = match[1]; if (!/^(https?:|mailto:|#)/.test(href) && !exists(href.split('#')[0])) throw new Error(file + ' has broken link: ' + href); } }\""
+    "test": "node scripts/validate-package.mjs"
   },
   "engines": {
     "node": ">=18"

package/skills/jhste-coding/SKILL.md

@@ -1,37 +1,33 @@
 ---
 name: jhste-coding
-description: Use for implementation, bug fixes, and refactors that modify repository code with lightweight SOLID-first discipline. Do not use for read-only review, planning, architecture discussion, or documentation-only work.
+description: Implement features, fix bugs, and refactor repository code with a small, contract-preserving change and relevant validation. Use when the requested outcome requires modifying code. Do not use for read-only analysis, planning, interviewing, issue creation, or domain documentation.
 ---
 
-# jhste-coding
+# JHSTE Coding
 
-Use this skill to write small, direct, readable code guided primarily by SOLID.
+## Goal
 
-SOLID is the main discipline. The guardrails below keep the code practical.
+Deliver the requested behavior with the smallest clear change that fits the repository.
 
-## Core rule
+## Success criteria
 
-Prefer the smallest clear change that fits the requested problem and keeps the code SOLID-aligned.
+- The requested behavior is implemented without unrelated scope.
+- Existing caller-visible contracts remain intact unless the request changes them.
+- Relevant non-destructive validation passes, or the unverified surface and reason are reported.
+- Uncertain, partial, and failed states are not silently treated as success.
 
-Use SOLID for the current change; speculative architecture, broad refactors, and abstraction layers are outside this skill's purpose.
+## Working contract
 
-## SOLID discipline
+Inspect the affected code, repository guidance, and nearby patterns before editing. Reuse established boundaries and abstractions when they fit. Introduce a new abstraction only when the current change has real variation, repeated logic, or a concrete side-effect boundary that becomes clearer by doing so.
 
-- **S — Single Responsibility:** keep each changed function, module, or class centered on one clear job. Choose names that make the job easy to see.
-- **O — Open/Closed:** add an extension seam when real variation or repeated branching would otherwise keep changing the same core logic. Keep simple branches when they read better.
-- **L — Liskov Substitution:** preserve caller-facing expectations: return shape, nullability, errors, side effects, timing assumptions, and documented behavior.
-- **I — Interface Segregation:** depend on the smallest useful contract. Prefer narrow parameters over broad objects, global context, or large config bags when only a small slice is needed.
-- **D — Dependency Inversion:** keep business rules separate from concrete side effects when that separation makes the code clearer. Make database, network, filesystem, browser, queue, email, payment, clock, environment, and secret boundaries easy to see.
+Treat public return shapes, nullability, errors, side effects, ordering, and documented behavior as contracts. Validate external input at its entry boundary. Keep credentials, sessions, authorization data, and sensitive payloads out of logs and responses.
 
-## Practical guardrails
+For implementation requests, make in-scope local edits and run the narrowest useful validation without pausing for routine confirmation. Stop before an external write, destructive action, or material expansion of scope unless the user authorized it.
 
-- Interfaces, factories, base classes, dependency containers, and strategy layers fit best when they clarify a real boundary, remove real repeated change, or protect a caller contract.
-- Validate external input where it enters the code path.
-- Make uncertain, partial, and failed states visible rather than silently treating them as success.
-- Keep secrets, tokens, credentials, cookies, authorization headers, sessions, and raw sensitive payloads out of logs and responses.
-- After changing code, run the narrowest relevant non-destructive validation. If it cannot run, state why; do not imply the change is verified.
-- When adding or changing tests, focus on observable behavior related to the change.
+## Validation
+
+Choose checks that exercise the changed behavior: targeted tests first, then applicable type, lint, build, or smoke checks. Do not add a test at an artificial seam merely to claim coverage. Never imply that a check ran when it did not.
 
 ## Final response
 
-Report what changed, what validation ran, and any material caveat; omit unchanged details and generic background.
+Report the outcome, validation performed, and any material caveat or remaining blocker. Omit generic background and unchanged details.

package/skills/jhste-coding/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Coding"
+  short_description: "Make scoped code changes with relevant validation"
+  default_prompt: "Use $jhste-coding to implement this change with the smallest clear patch and relevant validation."
+
+policy:
+  allow_implicit_invocation: true

package/skills/jhste-domain-modeling/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: jhste-domain-modeling
+description: Clarify domain terminology, concept boundaries, and relationships, and optionally maintain a project glossary or ADRs. Use when the user asks to define domain language, resolve conflicting terms, build a glossary, model domain concepts, or record a significant domain decision. Do not invoke for ordinary coding, generic architecture discussion, or incidental naming choices.
+---
+
+# JHSTE Domain Modeling
+
+## Goal
+
+Establish precise shared language that matches the intended domain and the behavior implemented by the code.
+
+## Investigate
+
+Read existing glossary, context-map, ADR, issue, and code conventions before proposing terms. Treat implementation as evidence, not unquestioned truth. Surface contradictions between the user's model, documentation, and code.
+
+Clarify one material concept at a time. Use concrete scenarios and edge cases to test boundaries, identities, state transitions, and relationships. Prefer one canonical term per concept and distinguish concepts that only appear similar.
+
+Keep the glossary free of implementation details. Keep specifications, task notes, and temporary decisions in their own artifacts.
+
+## Analyze versus write
+
+Analyze and propose changes by default. Edit `CONTEXT.md`, a repository-equivalent glossary, or an ADR only when the user asks to record, update, or apply the decisions. Follow the repository's existing location and format; create a new convention only with user authorization.
+
+Offer an ADR only when the decision is all three:
+
+- costly to reverse;
+- surprising without its rationale;
+- the result of a real trade-off between alternatives.
+
+Do not create an ADR for routine, temporary, or self-evident choices.
+
+## Completion
+
+Report:
+
+- terms added, changed, rejected, or still ambiguous;
+- scenarios used to test the model;
+- code or document mismatches found;
+- files changed, if writing was authorized;
+- ADR candidates and unresolved decisions that materially block the model.

package/skills/jhste-domain-modeling/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Domain Modeling"
+  short_description: "Clarify domain terms, boundaries, and decisions"
+  default_prompt: "Use $jhste-domain-modeling to clarify the domain language and surface any conflicting concepts."
+
+policy:
+  allow_implicit_invocation: true

package/skills/jhste-grill/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: jhste-grill
+description: Interview the user one decision at a time to sharpen or stress-test a plan, product behavior, or design. Use when the user asks to be interviewed, grilled, questioned, or guided through unresolved decisions. Do not invoke merely because an ordinary request has a small ambiguity.
+---
+
+# JHSTE Grill
+
+## Goal
+
+Reach enough shared understanding for the user to make or delegate the next layer of work confidently.
+
+## Interview
+
+Inspect available code, documents, and prior decisions instead of asking the user for discoverable facts. Ask about choices that belong to the user: desired behavior, scope, priorities, compatibility, failure behavior, and consequential trade-offs.
+
+Ask one decision question at a time. For each question, provide a recommended answer with its main reason and meaningful trade-off. Follow dependencies between decisions; do not explore branches that cannot affect the outcome.
+
+Challenge contradictions and unsupported assumptions directly. Preserve explicit user choices. Do not implement code, publish issues, or edit domain documents as part of this skill alone.
+
+## Stop condition
+
+Stop when the goal, success criteria, scope, important behavior, and material failure cases are clear enough for the intended next step. Do not continue into reversible preferences or implementation details that the next worker can decide safely.
+
+## Outcome
+
+Summarize only what the session established:
+
+- goal and success criteria;
+- decisions and their reasons;
+- constraints and out-of-scope items;
+- unresolved questions that still block progress;
+- domain terms affected and ADR candidates, when material.

package/skills/jhste-grill/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Grill"
+  short_description: "Sharpen plans through focused decision interviews"
+  default_prompt: "Use $jhste-grill to interview me one decision at a time and summarize what we decide."
+
+policy:
+  allow_implicit_invocation: true

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

package/skills/jhste-to-tickets/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: jhste-to-tickets
+description: Turn a defined plan, specification, or conversation into GitHub parent and sub-issues with acceptance criteria and native dependency relationships. Use when the user asks to draft, split, organize, or publish work as GitHub issues or tickets. Do not use for ordinary planning or work whose execution path still requires major investigation.
+---
+
+# JHSTE To Tickets
+
+## Goal
+
+Create a GitHub-native work graph whose ready issues can be claimed and completed independently by fresh workers.
+
+## Resolve context
+
+Identify the GitHub repository from the request or current remote. Read any referenced issue, specification, conversation context, repository guidance, and relevant code. Ask only for a missing decision that would materially change scope, issue boundaries, or dependencies.
+
+## Draft the work graph
+
+Use a parent issue to hold the shared goal, success criteria, decisions, constraints, open questions, and out-of-scope items. Reuse an existing parent when supplied. Otherwise draft one.
+
+Split implementation into tracer-bullet issues. Each issue must:
+
+- deliver a narrow but complete behavior across the layers it needs;
+- be independently demonstrable or verifiable;
+- fit one fresh worker context;
+- state observable acceptance criteria and relevant validation;
+- preserve only the shared context needed to execute it.
+
+Do not create separate database, API, UI, and test issues when none delivers behavior alone. Do not split work that is already safe and reviewable as one issue.
+
+For a wide mechanical change that cannot land green as vertical slices, use expand-migrate-contract: introduce the compatible form, migrate bounded batches, then remove the old form.
+
+Add a dependency only when the blocked issue cannot start until the blocker completes. Convenience or preferred order is not a dependency. The open, unblocked issues form the execution frontier.
+
+## Draft versus publish
+
+Draft by default. Present the parent, sub-issues, and dependency edges without writing to GitHub.
+
+Publish when the user explicitly asks to create, post, or publish the issues. That request authorizes these GitHub writes; it does not authorize unrelated repository changes. Create the parent and sub-issues, use GitHub's native parent and blocked-by relationships, then return their links and the initial frontier.
+
+When native relationships are unavailable, report the limitation before falling back to references in issue bodies.
+
+## Issue shape
+
+Each sub-issue should contain:
+
+```markdown
+## Outcome
+
+## Acceptance criteria
+- [ ] Observable result
+- [ ] Relevant validation
+
+## Context
+
+## Coordination
+- Blocked by: native GitHub relationship, or None
+- Integration point: branch, contract, or artifact when known
+```
+
+Avoid speculative file paths, implementation recipes, and code snippets that will go stale. Include a prototype-derived shape only when it records a decision more precisely than prose.
+
+## Completion
+
+Before finishing, verify that every issue has a clear outcome, every dependency is necessary, and at least one frontier issue exists unless an explicit external blocker prevents all work.

package/skills/jhste-to-tickets/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE To Tickets"
+  short_description: "Turn defined work into GitHub issue slices"
+  default_prompt: "Use $jhste-to-tickets to draft GitHub issues for this defined body of work."
+
+policy:
+  allow_implicit_invocation: true