jhste-skills 0.8.0 → 0.9.0

package/CHANGELOG.md

@@ -1,5 +1,26 @@
 # Changelog
 
+## 0.9.0 - 2026-07-28
+
+### Added
+- Added `jhste-prototype` for deliberately disposable, runnable experiments that answer one concrete design question before production implementation.
+- Added static prototype routing contracts for state models, API surfaces, data shapes, UI structures, handoffs, non-triggers, and external-write policy.
+
+### Changed
+- Clarified prototype boundaries with `jhste-coding`, `jhste-diagnosing-bugs`, `jhste-grill`, `jhste-to-spec`, and `jhste-implementation-finalizer`.
+- Linked every skill name in both READMEs directly to its `SKILL.md`, synchronized the descriptions, and updated installation text from ten to eleven skills.
+- Bumped the package minor version for the new published capability and expanded static routing coverage from 52 to 78 scenarios across nine covered skills.
+- Updated upstream attribution to the reviewed Matt Pocock revision and documented which prototype concepts were adapted or deliberately softened.
+
+## 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,31 @@ 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-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-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`.
+- **[`jhste-coding`](skills/jhste-coding/SKILL.md)** — 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-prototype`](skills/jhste-prototype/SKILL.md)** — tests one important design question before production implementation with the smallest disposable runnable evidence.
+- **[`jhste-diagnosing-bugs`](skills/jhste-diagnosing-bugs/SKILL.md)** — diagnoses difficult bugs and performance regressions whose cause or correct fix is uncertain through reproduction, hypotheses, and measurement.
+- **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — resolves consequential decision branches one question at a time while continuously maintaining settled domain context and ADRs.
+- **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — clarifies domain terms, boundaries, and relationships, immediately recording settled glossary entries and qualifying ADRs.
+- **[`jhste-to-spec`](skills/jhste-to-spec/SKILL.md)** — synthesizes an already discussed or defined change into a reviewable engineering specification grounded in repository evidence.
+- **[`jhste-to-tickets`](skills/jhste-to-tickets/SKILL.md)** — splits defined work into GitHub parent/sub-issues with native dependencies.
+- **[`jhste-handoff`](skills/jhste-handoff/SKILL.md)** — creates or updates executor-neutral implementation handoffs with ownership, phase progress, verification, blockers, and an exact resume point.
+- **[`jhste-implementation-finalizer`](skills/jhste-implementation-finalizer/SKILL.md)** — independently audits and verifies claimed-complete or submitted implementation work, fixes gaps, finishes it, and completes already-authorized PR updates.
+- **[`jhste-pr-review`](skills/jhste-pr-review/SKILL.md)** — reviews explicitly requested PRs against the actual diff and posts only high-confidence actionable findings.
+- **[`jhste-review-followup`](skills/jhste-review-followup/SKILL.md)** — validates existing PR feedback and pushes only justified fixes to the existing PR branch.
+
+The skills do not require or automatically call one another, and `jhste-prototype` is not a mandatory pre-step for coding. A sufficiently clear implementation belongs to `jhste-coding`; only an important uncertainty about what to build that needs runnable evidence belongs to `jhste-prototype`; an unexplained failure in existing behavior belongs to `jhste-diagnosing-bugs`; and a user-owned policy decision belongs to `jhste-grill`. Once a prototype direction is selected, `jhste-coding` implements it for production and `jhste-to-spec` records it only when a specification is requested.
 
 ## 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-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-coding` applies to sufficiently understood code changes and ordinary continuation from an existing handoff or partial implementation. Executable experiments that test an important design assumption before production belong to `jhste-prototype`.
+- `jhste-prototype` answers one concrete question about a state model, business rule, data shape, API surface, interaction flow, or UI structure with disposable runnable evidence. It does not take over ordinary implementation, diagnosis of an existing failure, static mockups, open-ended ideation, or production-ready delivery.
+- `jhste-diagnosing-bugs` applies when an observed failure needs a reproduction signal, competing hypotheses, instrumentation, or measurement. Testing a design that has not been built yet belongs to `jhste-prototype`.
+- `jhste-grill` applies when the user wants an interview or decision stress test. It does not let a prototype guess a user-owned choice; once a decision is settled, representability or ergonomics that need executable evidence can move to `jhste-prototype`.
 - `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-spec` defines settled behavior, contracts, validation, and scope. It does not freeze a guess into a specification when an unresolved design assumption should first be tested.
 - `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 to production implementation explicitly submitted for independent audit, verification, correction, or final completion. It does not promote disposable prototype code; a selected direction is implemented properly with `jhste-coding`.
 - `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.
 
@@ -36,7 +38,7 @@ This package does not include a mandatory TDD workflow, Wayfinder, a generic del
 
 ## Install user-wide from npm
 
-This package has no CLI. It distributes the ten skills and their Codex metadata.
+This package has no CLI. It distributes the eleven skills and their Codex metadata.
 
 ```sh
 npm install -g jhste-skills
@@ -53,7 +55,7 @@ mkdir -p "$HOME/.agents/skills"
 cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-If another agent expects a different global skills directory, copy the ten directories under `skills/` there. This package does not require project-local skill copies.
+If another agent expects a different global skills directory, copy the eleven directories under `skills/` there. This package does not require project-local skill copies.
 
 ## Development and validation
 
@@ -62,6 +64,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 78 static routing scenarios across nine covered 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,31 @@ GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용
 
 ## 스킬
 
-- **`jhste-coding`** — 충분히 이해된 기능, 버그 수정, 리팩터링을 작은 변경과 관련 검증으로 구현합니다.
-- **`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-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`에 속합니다.
+- **[`jhste-coding`](skills/jhste-coding/SKILL.md)** — 충분히 이해된 기능, 버그 수정, 리팩터링과 handoff의 정확한 재개 지점부터 이어지는 일반 구현을 작은 변경과 관련 검증으로 수행합니다.
+- **[`jhste-prototype`](skills/jhste-prototype/SKILL.md)** — production 구현 전에 하나의 중요한 설계 질문을 가장 작은 폐기 가능한 실행 증거로 검증합니다.
+- **[`jhste-diagnosing-bugs`](skills/jhste-diagnosing-bugs/SKILL.md)** — 원인이나 올바른 수정이 불확실한 어려운 버그와 성능 저하를 재현, 가설, 측정으로 진단합니다.
+- **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — 중요한 결정 분기를 한 번에 한 질문씩 해소하면서 확정된 도메인 문맥과 ADR을 계속 갱신합니다.
+- **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — 도메인 용어, 경계, 관계를 명확히 하고 확정된 glossary 항목과 필요한 ADR을 바로 기록합니다.
+- **[`jhste-to-spec`](skills/jhste-to-spec/SKILL.md)** — 이미 논의되거나 정의된 변경을 저장소 근거에 맞춘 검토 가능한 엔지니어링 명세로 정리합니다.
+- **[`jhste-to-tickets`](skills/jhste-to-tickets/SKILL.md)** — 정의된 작업을 GitHub parent/sub-issue와 native dependency로 나눕니다.
+- **[`jhste-handoff`](skills/jhste-handoff/SKILL.md)** — 특정 실행 도구와 무관하게 소유권, 단계 진행, 검증, blocker, 정확한 재개 지점을 보존하는 구현 handoff를 만들거나 갱신합니다.
+- **[`jhste-implementation-finalizer`](skills/jhste-implementation-finalizer/SKILL.md)** — 완료 주장이나 제출된 구현을 독립적으로 감사·검증하고 부족한 부분을 직접 고쳐 최종 완료하며, 이미 승인된 동일 PR 업데이트까지 수행합니다.
+- **[`jhste-pr-review`](skills/jhste-pr-review/SKILL.md)** — 명시적으로 요청된 PR을 실제 diff 기준으로 검토하고 신뢰도 높은 실행 가능한 지적만 게시합니다.
+- **[`jhste-review-followup`](skills/jhste-review-followup/SKILL.md)** — 기존 PR 피드백을 검증하고 정당한 수정만 기존 PR 브랜치에 반영합니다.
+
+스킬은 서로를 의무적으로 호출하지 않으며, `jhste-prototype`도 모든 코딩의 필수 선행 단계가 아닙니다. 구현 경로가 충분히 명확하면 `jhste-coding`, 무엇을 만들지에 대한 중요한 설계 불확실성이 실행 가능한 증거를 필요로 할 때만 `jhste-prototype`, 이미 존재하는 동작의 원인이 불명확하면 `jhste-diagnosing-bugs`, 사용자 소유 정책 결정이 남아 있으면 `jhste-grill`이 담당합니다. 프로토타입에서 방향이 선택되면 `jhste-coding`으로 production 구현하고, 명세가 필요할 때만 `jhste-to-spec`으로 기록합니다.
 
 ## 동작 경계
 
-- `jhste-coding`은 구현 경로가 충분히 명확한 코드 변경을 담당합니다. 원인 규명이나 성능 측정이 핵심이면 `jhste-diagnosing-bugs`, 기존 작업 결과를 독립 감사하고 마무리해야 하면 `jhste-implementation-finalizer`를 사용합니다.
-- `jhste-diagnosing-bugs`는 재현 신호, 경쟁 가설, 계측, 측정이 필요한 문제를 담당하며, 명백한 오타나 이미 원인이 확인된 수정에는 과한 진단 절차를 강요하지 않습니다.
-- `jhste-grill`은 사용자가 인터뷰나 의사결정 검증을 원할 때만 동작합니다. 쓰기 가능한 저장소에서는 분석 전용 또는 수정 금지 요청이 아닌 한 확정된 glossary와 ADR을 갱신합니다.
+- `jhste-coding`은 구현 경로가 충분히 명확한 코드 변경과 기존 handoff 또는 부분 구현의 일반적인 이어서 하기를 담당합니다. production 전 실행 실험으로 중요한 설계 가정을 검증하는 작업은 `jhste-prototype`에 속합니다.
+- `jhste-prototype`은 state model, business rule, data shape, API surface, interaction flow, UI structure에 관한 하나의 구체적 질문을 폐기 가능한 실행 증거로 답합니다. 일반 구현, 기존 장애 원인 진단, 정적 mockup, 열린 아이디어 탐색, production-ready 전달을 가로채지 않습니다.
+- `jhste-diagnosing-bugs`는 이미 관찰된 실패에 재현 신호, 경쟁 가설, 계측, 측정이 필요할 때 담당합니다. 아직 만들지 않은 설계를 시험하는 작업은 `jhste-prototype`입니다.
+- `jhste-grill`은 사용자가 인터뷰나 의사결정 검증을 원할 때만 동작합니다. 사용자 소유 결정이 먼저 필요하면 프로토타입으로 추측하지 않고 인터뷰하며, 결정된 가정의 representability나 ergonomics가 실행 증거를 필요로 하면 `jhste-prototype`으로 넘깁니다.
 - `jhste-domain-modeling`은 도메인 언어와 개념 경계를 담당하며, 단순 변수명 변경이나 일반적인 아키텍처 설명을 가로채지 않습니다.
-- `jhste-to-spec`은 확정된 동작, 계약, 검증, 범위를 정의합니다. 작업자 진행 상황이나 영구 재개 문서로 사용하지 않습니다.
+- `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`는 완료 주장, 독립 검증, 최종 감사·수정 의도가 명시된 production 구현을 담당합니다. 폐기 가능한 프로토타입을 production 코드로 승격하는 수단이 아니며, 선택된 방향은 `jhste-coding`으로 다시 구현합니다.
 - `jhste-pr-review`는 검토 전용 요청에만 적용되며 브랜치를 수정하지 않습니다.
 - `jhste-review-followup`은 이미 존재하는 PR 피드백이 범위를 정의할 때만 적용됩니다. 일반적인 작업자 결과 마무리 용도가 아닙니다.
 
@@ -36,7 +38,7 @@ GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용
 
 ## npm에서 사용자 전역 설치
 
-이 패키지는 CLI를 제공하지 않습니다. 열 개 스킬과 Codex metadata를 배포합니다.
+이 패키지는 CLI를 제공하지 않습니다. 열한 개 스킬과 Codex metadata를 배포합니다.
 
 ```sh
 npm install -g jhste-skills
@@ -53,7 +55,7 @@ mkdir -p "$HOME/.agents/skills"
 cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-다른 agent가 다른 전역 skills 디렉터리를 사용하면 `skills/` 아래 열 개 디렉터리를 그 위치에 복사하세요. 프로젝트별 복사본은 필수가 아닙니다.
+다른 agent가 다른 전역 skills 디렉터리를 사용하면 `skills/` 아래 열한 개 디렉터리를 그 위치에 복사하세요. 프로젝트별 복사본은 필수가 아닙니다.
 
 ## 개발 및 검증
 
@@ -62,6 +64,6 @@ npm test
 npm pack --dry-run
 ```
 
-`npm test`는 패키지, metadata, 문서 일관성과 변경된 여덟 스킬의 정적 라우팅 시나리오 48개를 검사합니다. 이 fixture는 모델을 실제 호출하거나 자동 trigger 정확도를 측정하지 않습니다.
+`npm test`는 패키지, metadata, 문서 일관성과 아홉 스킬을 다루는 정적 라우팅 시나리오 78개를 검사합니다. 이 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/THIRD_PARTY_NOTICES.md

@@ -9,11 +9,19 @@ The JHSTE workflow set is independently maintained, but parts of the workflow st
 - `jhste-to-spec`: conversation and codebase synthesis, behavioral test seams, and avoiding stale implementation recipes;
 - `jhste-diagnosing-bugs`: feedback-loop construction, falsifiable hypotheses, targeted instrumentation, regression verification, and cleanup;
 - `jhste-to-tickets`: tracer-bullet slices, blocking edges, bounded preparatory work, and expand-migrate-contract sequencing;
-- `jhste-coding`: module/interface/seam reasoning, caller-visible contracts, and avoiding shallow pass-through abstractions.
+- `jhste-coding`: module/interface/seam reasoning, caller-visible contracts, and avoiding shallow pass-through abstractions;
+- `jhste-prototype`: disposable runnable evidence for one design question, separate logic and UI exploration modes, visible state, in-memory or stubbed side effects by default, structurally distinct UI variants, and preserving the question and verdict separately from production implementation.
 
-Upstream reviewed at commit `ed37663cc5fbef691ddfecd080dff42f7e7e350d` and compared with the current `main` branch on 2026-07-25:
+Upstream reviewed at commit `2ab958093e83e0ec752e6c1c5932da465bf23e0c` on 2026-07-28:
 
 - https://github.com/mattpocock/skills
+- https://github.com/mattpocock/skills/tree/2ab958093e83e0ec752e6c1c5932da465bf23e0c/skills/engineering/prototype
+
+The prototype review also considered the upstream history that made the skill model-invoked and later reframed the runnable prototype as primary-source evidence retained outside the main branch. `jhste-prototype` does not copy the upstream files verbatim: it does not require a terminal UI, URL-parameter switcher, floating bar, a blanket prohibition on tests, or automatic branch, push, and issue-link writes. Those external writes remain subject to explicit user authorization.
+
+The related GitHub article was reviewed as contextual evidence for both early executable exploration and the maintenance risk of adding too many skills; no article text is copied:
+
+- https://github.blog/ai-and-ml/github-copilot/the-harness-is-all-you-need-mostly/
 
 No upstream skill file is distributed verbatim. The full upstream MIT notice is retained because the resulting instructions adapt workflow structure and some terminology.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "jhste-skills",
-  "version": "0.8.0",
-  "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.",
+  "version": "0.9.0",
+  "description": "A lean GPT-5.6-oriented engineering skill set for prototyping, coding, diagnosis, specifications, handoffs, implementation finalization, GitHub tickets, pull request review and follow-up, decision interviews, and domain modeling.",
   "type": "module",
   "license": "MIT",
   "repository": {

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 production repository code and the path to a correction or next implementation step is reasonably clear. For a disposable runnable experiment that answers an important design question before production, use jhste-prototype; for uncertain root-cause work, use jhste-diagnosing-bugs; for an independent completion audit, use jhste-implementation-finalizer. Do not use for read-only analysis, planning, interviewing, issue creation, domain documentation, or review-only work.
 ---
 
 # JHSTE Coding
@@ -20,6 +20,8 @@ Deliver the requested behavior with the smallest clear change that fits the repo
 
 Before editing, identify the requested outcome, material non-goals, caller-visible contract, and important failure states. Locate the module that owns the behavior and the seam through which callers or tests observe it. For a trivial change this can be a brief check; expand the analysis only when the change crosses boundaries or alters a contract.
 
+If an important uncertainty is about what should be built rather than how to implement an approved direction, and the uncertainty is best resolved through disposable executable evidence, use `jhste-prototype` instead of embedding exploration in production code. Once a direction is selected, treat the prototype as evidence: implement the production behavior cleanly here rather than promoting prototype scaffolding, shortcuts, variants, or test gaps.
+
 ## Working contract
 
 Inspect the affected code, repository guidance, and nearby patterns before editing. Keep behavior that changes for the same reason together. Reuse established boundaries and abstractions when they fit.
@@ -28,11 +30,11 @@ 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
 
-Choose checks that exercise the changed behavior: targeted tests first, then applicable type, lint, build, or smoke checks. Add tests at a seam that represents the caller-visible behavior rather than creating an artificial seam to claim coverage. Re-read the final diff for scope creep, stale compatibility paths, and temporary instrumentation. Do not imply that a check ran when it did not.
+Choose checks that exercise the changed behavior: targeted tests first, then applicable type, lint, build, or smoke checks. Add tests at a seam that represents the caller-visible behavior rather than creating an artificial seam to claim coverage. Re-read the final diff for scope creep, stale compatibility paths, temporary instrumentation, and prototype-only artifacts. Do not imply that a check ran when it did not.
 
 ## Final response
 

package/skills/jhste-diagnosing-bugs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jhste-diagnosing-bugs
-description: Diagnose difficult bugs and performance regressions whose cause or correct fix is uncertain, intermittent, environment-dependent, or spread across components. Use for explicit root-cause investigation that needs reproduction, competing hypotheses, instrumentation, or measurement. Do not use for an obvious typo, a direct compile or lint error, a known fix, CI inspection alone, or ordinary implementation.
+description: Diagnose difficult bugs and performance regressions in existing behavior whose cause or correct fix is uncertain, intermittent, environment-dependent, or spread across components. Use for explicit root-cause investigation that needs reproduction, competing hypotheses, instrumentation, or measurement. Do not use for an obvious typo, a direct compile or lint error, a known fix, ordinary implementation, or executable exploration of what should be built before production; use jhste-prototype for the latter.
 ---
 
 # JHSTE Diagnosing Bugs
@@ -11,9 +11,9 @@ Establish an evidence-backed root cause and, when a fix is in scope, prove that
 
 ## Frame the investigation
 
-Confirm the exact symptom, affected environment, expected behavior, known-good comparison, and whether the user requested diagnosis only or diagnosis plus a fix. Read repository guidance, relevant code, recent changes, tests, logs, traces, and operational evidence that are available.
+Confirm the exact observed symptom, affected environment, expected behavior, known-good comparison, and whether the user requested diagnosis only or diagnosis plus a fix. Read repository guidance, relevant code, recent changes, tests, logs, traces, and operational evidence that are available.
 
-When the cause and correction are already clear, use `jhste-coding` instead. Route failing pull request checks to the repository's CI workflow unless the user is asking for a deeper root-cause investigation.
+When the cause and correction are already clear, use `jhste-coding` instead. When there is no existing failure to explain and the question is whether a proposed state model, data shape, API surface, interaction flow, or UI structure should be built, use `jhste-prototype`. Route failing pull request checks to the repository's CI workflow unless the user is asking for a deeper root-cause investigation.
 
 ## Build a useful feedback loop
 

package/skills/jhste-grill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jhste-grill
-description: Interview the user one consequential decision at a time to sharpen or stress-test a plan, product behavior, or design while maintaining settled domain context and qualifying ADRs in the repository. 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.
+description: Interview the user one consequential decision at a time to sharpen or stress-test a plan, product behavior, or design while maintaining settled domain context and qualifying ADRs in the repository. Use when the user asks to be interviewed, grilled, questioned, or guided through unresolved user-owned decisions. Do not invoke merely because an ordinary request has a small ambiguity; when the decision is settled and the remaining uncertainty needs executable evidence, use jhste-prototype.
 ---
 
 # JHSTE Grill
@@ -17,7 +17,7 @@ Ask one decision question at a time. For each question, provide a recommended an
 
 Treat a branch as consequential when it can change the goal, success criteria, scope, user-visible behavior, compatibility, data or security behavior, recovery from failure, or a costly-to-reverse trade-off. Resolve every consequential branch or record it as an explicit blocker. Skip reversible preferences and implementation details that the next worker can decide safely.
 
-Challenge contradictions and unsupported assumptions directly. Preserve explicit user choices. Do not implement code or publish issues as part of this skill alone.
+Challenge contradictions and unsupported assumptions directly. Preserve explicit user choices. Do not use a prototype to choose a product policy, priority, or trade-off that belongs to the user. Once those choices are settled, use `jhste-prototype` when representability, API ergonomics, interaction flow, or UI structure still needs runnable evidence. Do not implement code or publish issues as part of this skill alone.
 
 ## Maintain decision documents
 

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,17 +1,17 @@
 ---
 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 production implementation that is claimed complete, submitted for independent acceptance, or explicitly requested for finalization and, when applicable, 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 for ordinary continuation, initial PR review, review-feedback follow-up alone, CI-log diagnosis, merging, or promoting disposable prototype code; a selected prototype direction belongs to jhste-coding.
 ---
 
 # JHSTE Implementation Finalizer
 
 ## Goal
 
-Treat completion claims as unverified input. Determine whether the requested outcome is complete, correct, integrated, and ready to publish, then directly fix in-scope gaps instead of stopping at review comments.
+Treat completion claims as unverified input. Determine whether the requested production outcome is complete, correct, integrated, and ready to publish, then directly fix in-scope gaps instead of stopping at review comments.
 
 ## 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, ordinary continuation from a handoff's exact resume point, and proper production implementation of a direction selected through `jhste-prototype`. Prototype scaffolding, shortcuts, losing variants, switchers, missing hardening, and intentionally limited validation are not a completion claim to finalize or code to promote. Use this skill only when existing production work requires an independent acceptance audit, verification of a completion claim, or final correction and completion. 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.
 

package/skills/jhste-prototype/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: jhste-prototype
+description: Build a deliberately disposable, runnable experiment to answer one concrete design question before production implementation. Use when the user explicitly asks for a prototype, or when an important uncertainty about a state model, business rule, data shape, API or module surface, interaction flow, or UI structure is best resolved through executable evidence. Do not use for ordinary implementation with a clear path, known fixes, root-cause diagnosis of existing failures, user-owned policy decisions, static mockups or image generation, open-ended ideation without a testable question, trivial reversible choices, or production-ready delivery.
+---
+
+# JHSTE Prototype
+
+## Goal
+
+Answer one concrete and important design question with the smallest deliberately disposable runnable evidence before production implementation.
+
+A prototype is not a mandatory pre-step for coding and is not production code. Use `jhste-coding` when the direction is sufficiently understood, `jhste-diagnosing-bugs` when an existing observed failure needs a root cause, `jhste-grill` when a user-owned policy or trade-off is unresolved, and `jhste-to-spec` when settled behavior needs a written contract. A selected prototype direction returns to `jhste-coding` for proper implementation and validation rather than being promoted directly.
+
+## Frame the experiment
+
+State the exact question, why it matters, what observation would support or falsify the assumption, and what the prototype will not decide. Inspect the host repository first and reuse its language, runtime, task runner, routing, component system, data conventions, and nearby vocabulary. Do not add a new framework or general architecture merely to run the experiment.
+
+If the question is open-ended, trivial and reversible, or still depends on a user-owned choice, do not build a prototype to manufacture certainty. Narrow the question, use `jhste-grill`, or proceed with ordinary implementation as appropriate.
+
+## Build the smallest useful evidence
+
+Make the prototype runnable through one obvious command or URL. Mark prototype-only files, routes, flags, variants, fixtures, and notes clearly enough that they cannot be mistaken for production behavior.
+
+Keep state in memory and side effects stubbed, fixture-backed, or read-only by default. Use a scratch dependency only when persistence or integration is itself the question and the target is safe and authorized. Never treat a prototype request as permission for destructive or production mutation.
+
+Expose the relevant state, outputs, transitions, or variant identity after each meaningful action so the evidence can be inspected. Skip production polish, broad error handling, compatibility layers, speculative abstraction, and generalization beyond the question. A focused executable test or fixture is allowed when it is the smallest useful harness; do not build a production regression suite to legitimize disposable code.
+
+### Logic and contract questions
+
+For state, business-rule, data-shape, or API-surface questions, isolate the experiment behind the smallest clear interface: a reducer, state machine, pure functions, fixture-driven module, or small stateful object according to the question. Keep the driver thin. Choose a script, focused test harness, REPL, terminal interaction, browser route, or existing development surface by fit rather than requiring a terminal UI. Show relevant before-and-after state and exercise the awkward cases that distinguish the alternatives.
+
+### UI and interaction questions
+
+Prefer variants inside the existing product surface with realistic data density and surrounding context when safe. Default to three materially different variants and cap at five; fewer are enough when the design space is narrower. Variants must differ in structure, information hierarchy, interaction flow, or primary affordance rather than only color, spacing, typography, or copy. Make them easy to identify and switch, stub mutations and externally visible actions, and ensure losing variants or prototype switchers cannot ship.
+
+## Validate and record the answer
+
+Run the documented command or open the documented URL, exercise the target cases or variants, and confirm that the evidence needed to answer the question is observable. Record the question, observations, verdict or remaining uncertainty, and the one obvious run instruction. Smoke validation proves only that the prototype runs and exposes the intended evidence; it does not make the artifact production-ready.
+
+When a direction is accepted, hand the verdict and relevant evidence to `jhste-coding` for a clean implementation with normal contracts, error handling, tests, and integration checks. Use `jhste-to-spec` only when the user requests a durable specification. Do not send disposable prototype code to `jhste-implementation-finalizer` as though its intentional shortcuts were incomplete production work.
+
+## Artifact and write policy
+
+A request to build a prototype authorizes the in-scope local prototype edits, not branch creation, commit, push, issue comments, pull requests, or other external writes. Perform those actions only when the user explicitly names them. If retention outside the main branch is authorized, the runnable prototype may be preserved as primary-source evidence with a pointer from the relevant issue while the validated decision is implemented separately. Otherwise keep it isolated locally and remove prototype-only artifacts before production delivery.
+
+## Completion
+
+Finish when the question and observation criteria are explicit, the smallest useful experiment runs, the relevant evidence and verdict are recorded, prototype-only artifacts are separated from production, and every external or destructive action stayed within explicit authorization. Report the run command or URL, cases or variants exercised, answer or remaining uncertainty, changed files, smoke validation, and the next owning skill.

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

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Prototype"
+  short_description: "Test design questions with disposable runnable evidence"
+  default_prompt: "Use $jhste-prototype to build the smallest disposable runnable experiment that answers this design question."
+
+policy:
+  allow_implicit_invocation: true

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

@@ -1,6 +1,6 @@
 ---
 name: jhste-to-spec
-description: Synthesize an already discussed or otherwise defined engineering change into a decision-grounded specification using relevant repository evidence. Use when the user asks for a spec, PRD, design brief, or written behavior contract. Do not use to interview unresolved requirements, create execution handoffs, split work into tickets, implement code, or publish an artifact unless the user requests that write.
+description: Synthesize an already discussed or otherwise defined engineering change into a decision-grounded specification using relevant repository evidence. Use when the user asks for a spec, PRD, design brief, or written behavior contract. Do not use to interview unresolved requirements, prototype an unsettled design assumption, create execution handoffs, split work into tickets, implement code, or publish an artifact unless the user requests that write.
 ---
 
 # JHSTE To Spec
@@ -13,7 +13,7 @@ Produce a reviewable specification that separates established decisions from unr
 
 Read the relevant conversation, referenced artifacts, repository guidance, glossary or ADRs, current code, and nearby tests or contracts. Use repository vocabulary where it is established. Treat code as evidence of the current state rather than proof that the current state is intended.
 
-Ask only when a missing decision would materially change the requested outcome. When useful progress is still possible, draft with the uncertainty named instead of inventing an answer. Route a decision interview to `jhste-grill` and domain-language conflicts to `jhste-domain-modeling`.
+Ask only when a missing decision would materially change the requested outcome. When useful progress is still possible, draft with the uncertainty named instead of inventing an answer. Route a decision interview to `jhste-grill`, domain-language conflicts to `jhste-domain-modeling`, and a concrete unsettled design assumption that needs executable evidence to `jhste-prototype` before freezing it into a contract.
 
 ## Write the specification