jhste-skills 0.8.0 → 0.8.1

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## 0.8.1 - 2026-07-27
+
+### Changed
+- Narrowed `jhste-implementation-finalizer` so an existing handoff, partial implementation, branch, diff, worktree, or worker result does not select finalization without an explicit independent audit, verification, or completion intent.
+- Routed ordinary implementation continuation from a handoff's exact resume point to `jhste-coding`, with unresolved root-cause work remaining in `jhste-diagnosing-bugs`.
+- Clarified that `jhste-handoff` authors and updates handoff documents rather than owning implementation merely because a handoff must be read.
+- Expanded static routing coverage from 48 to 52 scenarios for handoff continuation, uncertain diagnosis, and independent finalization boundaries.
+- Updated npm publishing so a package version bump merged to `main` runs release checks and publishes an unpublished version, while tag pushes remain supported without duplicate publication.
+
 ## 0.8.0 - 2026-07-26
 
 ### Added

package/README.en.md

@@ -6,29 +6,29 @@ A personal engineering skill set maintained around GPT-5.6's outcome-first, lean
 
 ## Skills
 
-- **`jhste-coding`** — implements sufficiently understood features, bug fixes, and refactors with a small change and relevant validation.
+- **`jhste-coding`** — implements sufficiently understood features, bug fixes, refactors, and ordinary continuation from a handoff's exact resume point with a small change and relevant validation.
 - **`jhste-diagnosing-bugs`** — diagnoses difficult bugs and performance regressions whose cause or correct fix is uncertain through reproduction, hypotheses, and measurement.
 - **`jhste-grill`** — resolves consequential decision branches one question at a time while continuously maintaining settled domain context and ADRs.
 - **`jhste-domain-modeling`** — clarifies domain terms, boundaries, and relationships, immediately recording settled glossary entries and qualifying ADRs.
 - **`jhste-to-spec`** — synthesizes an already discussed or defined change into a reviewable engineering specification grounded in repository evidence.
 - **`jhste-to-tickets`** — splits defined work into GitHub parent/sub-issues with native dependencies.
-- **`jhste-handoff`** — creates executor-neutral implementation handoffs with ownership, phase progress, verification, blockers, and an exact resume point.
-- **`jhste-implementation-finalizer`** — independently audits and finishes an existing implementation, synchronizes its handoff, and completes already-authorized PR updates.
+- **`jhste-handoff`** — creates or updates executor-neutral implementation handoffs with ownership, phase progress, verification, blockers, and an exact resume point.
+- **`jhste-implementation-finalizer`** — independently audits and verifies claimed-complete or submitted implementation work, fixes gaps, finishes it, and completes already-authorized PR updates.
 - **`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.
 
-The skills do not require or automatically call one another. A request may use more than one when it contains multiple intents. Consequential choices can be resolved with `jhste-grill` and domain language with `jhste-domain-modeling`; settled behavior can become a `jhste-to-spec` artifact and GitHub work can be split with `jhste-to-tickets`. `jhste-handoff` preserves execution state for any implementation mechanism, while `jhste-implementation-finalizer` independently verifies and completes the resulting implementation. Difficult root-cause work remains with `jhste-diagnosing-bugs`, and a known correction belongs to `jhste-coding`.
+The skills do not require or automatically call one another. Merely reading a handoff does not select `jhste-handoff` or `jhste-implementation-finalizer`. Ordinary continuation from a clear resume point belongs to `jhste-coding`, unresolved root-cause work belongs to `jhste-diagnosing-bugs`, and an explicit independent audit or final acceptance of a completion claim belongs to `jhste-implementation-finalizer`.
 
 ## Behavioral boundaries
 
-- `jhste-coding` applies to implementation and fixes whose code-change path is sufficiently understood. Problems centered on uncertain root cause, intermittency, or performance measurement belong to `jhste-diagnosing-bugs`; an existing worker result that needs an independent completion audit belongs to `jhste-implementation-finalizer`.
+- `jhste-coding` applies to sufficiently understood code changes and ordinary continuation from an existing handoff or partial implementation.
 - `jhste-diagnosing-bugs` applies when root-cause work needs a reproduction signal, competing hypotheses, instrumentation, or measurement. It avoids imposing the full diagnostic loop on an obvious typo, direct compile or lint error, or already established fix.
 - `jhste-grill` applies when the user wants an interview or decision stress test; ordinary ambiguity alone does not start a long interview. In a writable repository it maintains settled glossary entries and qualifying ADRs unless the request is analysis-only or forbids edits.
 - `jhste-domain-modeling` owns focused domain-language clarification and the corresponding glossary and qualifying ADR updates, not incidental code naming or generic architecture discussion.
 - `jhste-to-spec` defines settled behavior, contracts, validation, and scope. It does not act as a worker-progress tracker or durable resume document.
 - `jhste-to-tickets` drafts or publishes a GitHub issue graph. It does not duplicate local handoff state across issue bodies.
-- `jhste-handoff` runs only for an explicit handoff, resume, or implementation-context request. It follows an existing repository convention or defaults to `docs/handoff/indexes/` plus optional `docs/handoff/phases/`, and it remains independent of the eventual executor.
-- `jhste-implementation-finalizer` starts from an existing or partial implementation and treats completion claims as unverified. It fixes in-scope gaps and may commit, push, or update the named existing PR only when those writes were already authorized; it does not merge by default.
+- `jhste-handoff` runs only when the user asks to create, update, refresh, or phase a handoff document. It does not own implementation merely because an existing handoff must be read.
+- `jhste-implementation-finalizer` applies when existing work is explicitly submitted for independent audit, verification, correction, or final completion. The existence of a handoff, partial implementation, branch, diff, worktree, or worker result alone is not enough.
 - `jhste-pr-review` applies only to an explicit review-only request and does not modify the branch.
 - `jhste-review-followup` applies only when existing PR feedback defines the scope. It is not the general completion workflow for a worker result or partially implemented branch.
 
@@ -62,6 +62,6 @@ npm test
 npm pack --dry-run
 ```
 
-`npm test` checks package, metadata, and documentation consistency plus 48 static routing scenarios for the eight changed skills. The fixture does not invoke a model or measure live automatic-trigger accuracy.
+`npm test` checks package, metadata, and documentation consistency plus 52 static routing scenarios for the eight changed skills. The fixture does not invoke a model or measure live automatic-trigger accuracy.
 
-External sources and license attribution are recorded in [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md). Pushing a `v*.*.*` release tag runs GitHub Actions checks and publishes the package through npm trusted publishing.
+External sources and license attribution are recorded in [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md). When a change containing a new package version is merged to `main`, or a `v*.*.*` release tag is pushed, GitHub Actions runs release checks and publishes the version through npm trusted publishing if it is not already present.

package/README.md

@@ -6,29 +6,29 @@ GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용
 
 ## 스킬
 
-- **`jhste-coding`** — 충분히 이해된 기능, 버그 수정, 리팩터링을 작은 변경과 관련 검증으로 구현합니다.
+- **`jhste-coding`** — 충분히 이해된 기능, 버그 수정, 리팩터링과 handoff의 정확한 재개 지점부터 이어지는 일반 구현을 작은 변경과 관련 검증으로 수행합니다.
 - **`jhste-diagnosing-bugs`** — 원인이나 올바른 수정이 불확실한 어려운 버그와 성능 저하를 재현, 가설, 측정으로 진단합니다.
 - **`jhste-grill`** — 중요한 결정 분기를 한 번에 한 질문씩 해소하면서 확정된 도메인 문맥과 ADR을 계속 갱신합니다.
 - **`jhste-domain-modeling`** — 도메인 용어, 경계, 관계를 명확히 하고 확정된 glossary 항목과 필요한 ADR을 바로 기록합니다.
 - **`jhste-to-spec`** — 이미 논의되거나 정의된 변경을 저장소 근거에 맞춘 검토 가능한 엔지니어링 명세로 정리합니다.
 - **`jhste-to-tickets`** — 정의된 작업을 GitHub parent/sub-issue와 native dependency로 나눕니다.
-- **`jhste-handoff`** — 특정 실행 도구와 무관하게 소유권, 단계 진행, 검증, blocker, 정확한 재개 지점을 보존하는 구현 handoff를 만듭니다.
-- **`jhste-implementation-finalizer`** — 기존 또는 부분 구현을 독립적으로 감사하고 부족한 부분을 직접 고쳐 검증하며, 이미 승인된 동일 PR 업데이트까지 완료합니다.
+- **`jhste-handoff`** — 특정 실행 도구와 무관하게 소유권, 단계 진행, 검증, blocker, 정확한 재개 지점을 보존하는 구현 handoff를 만들거나 갱신합니다.
+- **`jhste-implementation-finalizer`** — 완료 주장이나 제출된 구현을 독립적으로 감사·검증하고 부족한 부분을 직접 고쳐 최종 완료하며, 이미 승인된 동일 PR 업데이트까지 수행합니다.
 - **`jhste-pr-review`** — 명시적으로 요청된 PR을 실제 diff 기준으로 검토하고 신뢰도 높은 실행 가능한 지적만 게시합니다.
 - **`jhste-review-followup`** — 기존 PR 피드백을 검증하고 정당한 수정만 기존 PR 브랜치에 반영합니다.
 
-스킬은 서로를 의무적으로 호출하지 않습니다. 한 요청에 여러 의도가 있으면 필요한 스킬을 조합할 수 있습니다. 중요한 선택은 `jhste-grill`, 도메인 언어는 `jhste-domain-modeling`, 확정된 동작 명세는 `jhste-to-spec`, GitHub 작업 분해는 `jhste-to-tickets`가 담당합니다. `jhste-handoff`는 어떤 구현 수단을 사용하더라도 실행 상태를 보존하고, `jhste-implementation-finalizer`는 그 결과를 독립 검증하고 끝까지 완성합니다. 원인 불명의 문제는 `jhste-diagnosing-bugs`, 수정 방향이 이미 명확한 구현은 `jhste-coding`에 속합니다.
+스킬은 서로를 의무적으로 호출하지 않습니다. 한 요청에 여러 의도가 있으면 필요한 스킬을 조합할 수 있습니다. handoff를 읽는다는 사실만으로 `jhste-handoff`나 `jhste-implementation-finalizer`가 선택되지는 않습니다. 정확한 재개 지점부터 알려진 구현을 계속하면 `jhste-coding`, 원인이 아직 불명확하면 `jhste-diagnosing-bugs`, 완료 주장에 대한 독립 감사와 최종 마무리를 요청하면 `jhste-implementation-finalizer`가 담당합니다.
 
 ## 동작 경계
 
-- `jhste-coding`은 구현 경로가 충분히 명확한 코드 변경을 담당합니다. 원인 규명이나 성능 측정이 핵심이면 `jhste-diagnosing-bugs`, 기존 작업 결과를 독립 감사하고 마무리해야 하면 `jhste-implementation-finalizer`를 사용합니다.
+- `jhste-coding`은 구현 경로가 충분히 명확한 코드 변경과 기존 handoff 또는 부분 구현의 일반적인 이어서 하기를 담당합니다.
 - `jhste-diagnosing-bugs`는 재현 신호, 경쟁 가설, 계측, 측정이 필요한 문제를 담당하며, 명백한 오타나 이미 원인이 확인된 수정에는 과한 진단 절차를 강요하지 않습니다.
 - `jhste-grill`은 사용자가 인터뷰나 의사결정 검증을 원할 때만 동작합니다. 쓰기 가능한 저장소에서는 분석 전용 또는 수정 금지 요청이 아닌 한 확정된 glossary와 ADR을 갱신합니다.
 - `jhste-domain-modeling`은 도메인 언어와 개념 경계를 담당하며, 단순 변수명 변경이나 일반적인 아키텍처 설명을 가로채지 않습니다.
 - `jhste-to-spec`은 확정된 동작, 계약, 검증, 범위를 정의합니다. 작업자 진행 상황이나 영구 재개 문서로 사용하지 않습니다.
 - `jhste-to-tickets`는 GitHub issue graph를 초안 작성하거나 게시합니다. 로컬 handoff 상태를 여러 issue 본문에 중복하지 않습니다.
-- `jhste-handoff`는 명시적인 handoff, 재개, 구현 문맥 요청에서만 동작합니다. 저장소 관례가 없으면 `docs/handoff/indexes/`와 필요할 때만 `docs/handoff/phases/`를 사용하며, 최종 실행 수단과 독립적입니다.
-- `jhste-implementation-finalizer`는 기존 또는 부분 구현에서 시작하고 완료 보고를 증거로 믿지 않습니다. 범위 내 누락을 직접 고치며, commit·push·기존 PR 업데이트는 이미 허가된 경우에만 수행하고 기본적으로 merge하지 않습니다.
+- `jhste-handoff`는 handoff 문서를 새로 만들거나 갱신하고, 재개 가능한 단계로 나누는 명시적 요청에서만 동작합니다. 기존 handoff를 읽고 구현을 계속하는 작업 자체는 담당하지 않습니다.
+- `jhste-implementation-finalizer`는 완료 주장, 독립 검증, 최종 감사·수정 의도가 명시된 기존 구현을 담당합니다. 기존 handoff, 부분 구현, branch, diff, worktree, worker result가 있다는 사실만으로 선택되지 않습니다.
 - `jhste-pr-review`는 검토 전용 요청에만 적용되며 브랜치를 수정하지 않습니다.
 - `jhste-review-followup`은 이미 존재하는 PR 피드백이 범위를 정의할 때만 적용됩니다. 일반적인 작업자 결과 마무리 용도가 아닙니다.
 
@@ -62,6 +62,6 @@ npm test
 npm pack --dry-run
 ```
 
-`npm test`는 패키지, metadata, 문서 일관성과 변경된 여덟 스킬의 정적 라우팅 시나리오 48개를 검사합니다. 이 fixture는 모델을 실제 호출하거나 자동 trigger 정확도를 측정하지 않습니다.
+`npm test`는 패키지, metadata, 문서 일관성과 변경된 여덟 스킬의 정적 라우팅 시나리오 52개를 검사합니다. 이 fixture는 모델을 실제 호출하거나 자동 trigger 정확도를 측정하지 않습니다.
 
-외부 출처와 라이선스 표기는 [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md)에 기록합니다. `v*.*.*` release tag를 push하면 GitHub Actions 검증 후 npm trusted publishing으로 패키지를 배포합니다.
+외부 출처와 라이선스 표기는 [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md)에 기록합니다. 새 package version을 포함한 변경이 `main`에 병합되거나 `v*.*.*` release tag가 push되면 GitHub Actions 검증 후 아직 게시되지 않은 버전을 npm trusted publishing으로 배포합니다.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jhste-skills",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "description": "A lean GPT-5.6-oriented engineering skill set for coding, diagnosis, specifications, handoffs, implementation finalization, GitHub tickets, pull request review and follow-up, decision interviews, and domain modeling.",
   "type": "module",
   "license": "MIT",

package/skills/jhste-coding/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jhste-coding
-description: Implement features, sufficiently understood bug fixes, and refactors with a small contract-preserving code change and relevant validation. Use when the requested outcome requires modifying repository code and the path to a correction is reasonably clear. For uncertain root-cause work, use jhste-diagnosing-bugs; for independently auditing and finishing an existing implementation, use jhste-implementation-finalizer. Do not use for read-only analysis, planning, interviewing, issue creation, domain documentation, or implementation finalization.
+description: Implement features, sufficiently understood bug fixes, refactors, and ordinary continuation from a handoff's exact resume point with a small contract-preserving code change and relevant validation. Use when the requested outcome requires modifying repository code and the path to a correction or next implementation step is reasonably clear, including partial progress from another worker when no independent completion audit was requested. For uncertain root-cause work, use jhste-diagnosing-bugs; for independently auditing, verifying, and finalizing claimed-complete or submitted implementation work, use jhste-implementation-finalizer. Do not use for read-only analysis, planning, interviewing, issue creation, domain documentation, or review-only work.
 ---
 
 # JHSTE Coding
@@ -28,7 +28,7 @@ Introduce a new abstraction when the current change demonstrates real variation,
 
 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.
 
-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. When the root cause remains materially uncertain, avoid widening speculative edits and hand the investigation to `jhste-diagnosing-bugs`. When the starting point is a worker result, branch, diff, or partial implementation that must be independently audited and completed, use `jhste-implementation-finalizer` rather than treating its completion claim as evidence.
+For implementation requests, make in-scope local edits and run the narrowest useful validation without pausing for routine confirmation. Continue from an existing handoff or partial implementation with this skill when the exact next step is clear and the user asks to proceed, implement, or resume; prior work alone is not evidence that an independent completion audit is wanted. Stop before an external write, destructive action, or material expansion of scope unless the user authorized it. When the root cause remains materially uncertain, avoid widening speculative edits and hand the investigation to `jhste-diagnosing-bugs`. When the user asks to independently audit, verify, correct, and finalize a completion claim or submitted implementation, use `jhste-implementation-finalizer`.
 
 ## Validation
 

package/skills/jhste-handoff/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jhste-handoff
-description: Create or update executor-neutral implementation handoff documents that preserve settled decisions, scope, ownership, progress, verification, blockers, and an exact resume point. Use when the user explicitly asks to hand work off, prepare implementation context for another worker or session, split long work into resumable phases, or refresh an existing handoff. Do not use for a specification, GitHub ticket graph, ordinary plan, implementation itself, or automatic worker orchestration.
+description: Create or update executor-neutral implementation handoff documents that preserve settled decisions, scope, ownership, progress, verification, blockers, and an exact resume point. Use when the user explicitly asks to create, prepare, refresh, or restructure a handoff for another worker or session, or to split long work into resumable phases. Do not use merely because an existing handoff must be read before implementation resumes; ordinary continuation belongs to jhste-coding, uncertain investigation to jhste-diagnosing-bugs, and independent completion audit to jhste-implementation-finalizer. Do not use for a specification, GitHub ticket graph, ordinary plan, implementation itself, or automatic worker orchestration.
 ---
 
 # JHSTE Handoff
@@ -17,6 +17,8 @@ Keep the handoff independent of any agent, provider, model, CLI, branch strategy
 
 A handoff records execution state; it is not a substitute for a specification, ADR, domain glossary, or GitHub issue graph. Link to those sources instead of copying them.
 
+Reading an existing handoff does not itself select this skill. When the user asks to continue implementation from its exact resume point, route to `jhste-coding`; when unresolved root cause remains the work, route to `jhste-diagnosing-bugs`; when the user requests independent verification or final acceptance of claimed-complete work, route to `jhste-implementation-finalizer`.
+
 ## Inspect and settle the contract
 
 Read current user instructions, repository guidance, relevant specs, ADRs, domain context, issues, existing handoffs, code, tests, interfaces, current diff, and parallel ownership before writing.

package/skills/jhste-implementation-finalizer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jhste-implementation-finalizer
-description: Independently audit, correct, verify, and finish an implementation already produced or partially produced and, when applicable, synchronize an existing handoff and complete already-authorized updates to the same pull request. Use when the user asks to take over, inspect and finish, finalize, or independently verify a branch, diff, worktree, worker result, or incomplete implementation. Do not use for an initial PR review, existing review-comment follow-up alone, ordinary implementation from scratch, CI-log diagnosis alone, or merging.
+description: Independently audit, correct, verify, and finish an implementation that is claimed complete, submitted as a worker result for independent acceptance, or explicitly requested for finalization and, when applicable, synchronize an existing handoff and complete already-authorized updates to the same pull request. Use only when the user asks to independently audit, verify, finalize, or finish existing implementation work. Do not use merely because work resumes from a handoff, partial implementation, branch, diff, worktree, or another worker; ordinary continuation with a clear next step belongs to jhste-coding. Do not use for an initial PR review, existing review-comment follow-up alone, ordinary implementation from scratch, CI-log diagnosis alone, or merging.
 ---
 
 # JHSTE Implementation Finalizer
@@ -11,7 +11,7 @@ Treat completion claims as unverified input. Determine whether the requested out
 
 ## Route the right work
 
-Use `jhste-coding` when no prior implementation needs an independent audit and the requested change is sufficiently understood. Use `jhste-diagnosing-bugs` when uncertain root cause or measurement is the primary work. Use `jhste-pr-review` for review-only findings and `jhste-review-followup` when existing review comments define the scope.
+Use `jhste-coding` for implementation from scratch and for ordinary continuation from a handoff's exact resume point when the next change is sufficiently understood. The mere existence of prior edits, a worker result, partial work, a branch, a diff, a worktree, or a handoff does not select this skill. Use this skill when the request requires an independent acceptance audit, verification of a completion claim, or final correction and completion of existing implementation work. Use `jhste-diagnosing-bugs` when uncertain root cause or measurement is the primary work. Use `jhste-pr-review` for review-only findings and `jhste-review-followup` when existing review comments define the scope.
 
 Do not merge, enable auto-merge, resolve review threads, or make unrelated issue changes unless the user explicitly requests those actions.