jhste-skills 0.15.0 → 0.17.0

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # Changelog
 
+## 0.17.0 - 2026-10-07
+
+### Changed
+- Made `jhste-grill` and `jhste-domain-modeling` read-only with respect to repository documents unless the request also asks to record, write, update, edit, or maintain glossary or ADR artifacts.
+- Made `jhste-code-result-double-check` read-only for review, recheck, verify, audit, and double-check requests unless correction is explicitly requested; authorized fix requests still correct in-scope gaps and refresh invalidated evidence.
+- Changed new fallback domain-document naming to `GLOSSARY.md` and `GLOSSARY-MAP.md` while preserving repositories that already use legacy `CONTEXT.md` and `CONTEXT-MAP.md`.
+- Added a stop condition to `jhste-coding` so verified work does not start unrequested review or hardening rounds.
+- Added maintenance guidance to prefer deterministic validators, CI, linters, type checks, builds, or tests over model-facing prose for mechanically detectable recurring failures.
+- Re-reviewed Matt Pocock's upstream at `6fd9479`, OpenAI GPT-5.6 guidance, and Anthropic Claude Fable 5.1, Sonnet 5.5, Opus 5.5, and general prompting guidance; synchronized attribution, routing contracts, metadata, and both READMEs.
+- Kept `jhste-handoff` behavior unchanged after re-review and removed one stale reference to the retired `finalizer` role from its durable handoff guidance.
+
+## 0.16.0 - 2026-09-13
+
+### Changed
+- Left subagent selection, worker contracts, coordination, and verification policy to the active harness instead of maintaining a separate skill that cannot know worker capability or runtime configuration.
+- Synchronized package metadata, validation, maintenance guidance, attribution, routing fixtures, and both READMEs for the ten-skill package.
+
+### Removed
+- Removed `jhste-subagent-orchestration` and its worker-contract and control-state references.
+- Removed the orchestration-only routing fixture. Delegation requests now use the harness's native instructions and tools without loading a package skill.
+
+### Upgrade
+- Retire `jhste-subagent-orchestration` from every active copy-based discovery path so the removed skill cannot continue routing work from a stale installation. The tested README upgrade block backs it up alongside previously retired skills before copying the current package.
+
 ## 0.15.0 - 2026-09-12
 
 ### Added

package/MAINTENANCE.md

@@ -36,6 +36,10 @@ Do not add or retain:
 - work splitting based only on file count, task length, or context-window size; or
 - speculative rules for failures that have not been observed.
 
+## Prefer deterministic guardrails
+
+When a repeated failure can be detected mechanically from syntax, schema, file layout, a linter, type checker, build, test, or other deterministic signal, fix or add that guardrail instead of adding another model-facing instruction. Keep skill prose for judgment, authority, domain knowledge, output contracts, and failures that cannot be enforced mechanically.
+
 ## Progressive disclosure
 
 Treat `SKILL.md` as the control plane. It should contain the task contract, important boundaries, and pointers needed to begin.
@@ -57,16 +61,15 @@ Use token, time, and request data when the harness exposes it. Replace a sentine
 
 ### Code-result routing sentinels
 
-Use the request text in the repository's `scripts/routing-scenarios.json` and `scripts/routing-scenarios-orchestration.json`, rather than putting skill names into user requests. Start with these cases:
+Use the request text in the repository's `scripts/routing-scenarios.json`, rather than putting skill names into user requests. Start with these cases:
 
 | Intent | Fixture IDs |
 | --- | --- |
 | Natural completion-claim recheck | `double-check-trigger-korean-done`, with `double-check-trigger-korean-gaps` and `double-check-trigger-korean-requirements` as paraphrases |
 | Ordinary implementation without an automatic second pass | `coding-trigger-korean-feature`, `double-check-non-handoff-resume` |
 | Existing uncertain failure versus pre-implementation experiment | `double-check-non-uncertain-resume`, `double-check-non-design-experiment` |
-| Read-only result verification and review-only work | `double-check-trigger-read-only`, `coding-non-review` |
+| Read-only result verification and review-only work | `double-check-trigger-report-only`, `double-check-trigger-korean-done`, `double-check-trigger-read-only`, `coding-non-review` |
 | Known review correction versus whole-result rechecking | `double-check-handoff-feedback` |
-| Worker-result authorship versus explicit delegation | `orchestration-non-double-check`, `orchestration-trigger-separate-acceptance` |
 
 Run against a clean installed skill set with retired directories absent. Use a small code task with a known missing integration, an already-correct variant, stale pre-correction evidence, and unrelated owned changes. Inspect actual skill/tool calls as well as the final code: a correct first choice alone cannot prove that no unnecessary follow-on skill or worker ran. Check that corrections invalidate and refresh the relevant evidence, read-only assignments stay read-only, and unavailable checks are not reported as passed.
 

package/README.en.md

@@ -8,9 +8,9 @@ Core `SKILL.md` files contain the task contract and important boundaries. Rare f
 
 ## Decide what to build
 
-- **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — asks currently answerable consequential decisions in compact rounds while recording settled language and qualifying ADRs.
+- **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — asks currently answerable consequential decisions in compact rounds and writes settled glossary or ADR updates only when the request asks to record them.
 - **[`jhste-to-questionnaire`](skills/jhste-to-questionnaire/SKILL.md)** — turns facts or decisions the current user cannot supply into a focused questionnaire for the person or role that owns them.
-- **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — clarifies project-specific terms, concept boundaries, and relationships while updating the owning glossary and qualifying ADRs.
+- **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — clarifies project-specific terms, concept boundaries, and relationships, updating the owning glossary and qualifying ADRs only when requested.
 - **[`jhste-to-spec`](skills/jhste-to-spec/SKILL.md)** — turns an already discussed or defined change into a reviewable behavioral specification without restarting the interview.
 
 ## Build and fix
@@ -21,13 +21,12 @@ Core `SKILL.md` files contain the task contract and important boundaries. Rare f
 
 ## Divide and continue work
 
-- **[`jhste-subagent-orchestration`](skills/jhste-subagent-orchestration/SKILL.md)** — coordinates bounded workers when separation creates value while the head retains decisions, ownership, integration, and final verification.
 - **[`jhste-to-tickets`](skills/jhste-to-tickets/SKILL.md)** — turns defined work into one useful GitHub issue or an issue graph with real dependencies.
 - **[`jhste-handoff`](skills/jhste-handoff/SKILL.md)** — preserves verified state, authoritative references, ownership, abandoned approaches, and the exact next action for another executor.
 
 ## Recheck existing code results
 
-- **[`jhste-code-result-double-check`](skills/jhste-code-result-double-check/SKILL.md)** — independently compares a completed or submitted code result with requirements, the task-owned diff, current code, and verification evidence, fixes in-scope gaps, and verifies the resulting state.
+- **[`jhste-code-result-double-check`](skills/jhste-code-result-double-check/SKILL.md)** — independently compares a completed or submitted code result with requirements, the task-owned diff, current code, and verification evidence. It is read-only by default and fixes in-scope gaps only when correction is requested.
 
 ## Core principles
 
@@ -35,20 +34,17 @@ Core `SKILL.md` files contain the task contract and important boundaries. Rare f
 - Involve the user only for product policy, compatibility, security or data policy, external writes, and other decisions or permissions only they can supply. Batch independent questions.
 - When missing knowledge belongs to another person rather than the current user, use `jhste-to-questionnaire` to ask the actual owner only for what is needed.
 - Model, provider, reasoning or effort, worker count, concurrency, scheduling, and actual isolation belong to the user and harness. Skills do not choose or override them.
-- Use subagents only when separation saves more than repeated reading and coordination cost. Reuse current context for missing evidence or a small same-scope correction when independent judgment is not needed.
 - Choose the repository-native signal that most directly distinguishes the requested result from failure. Expand validation only for relevant risk, integration surface, or observed failures, and never claim an unrun check passed.
-- Requests for `jhste-grill` and `jhste-domain-modeling` include maintaining settled local glossary entries and qualifying ADRs. Commits, pushes, issues, PRs, releases, and other external writes remain limited to the request's authority.
+- `jhste-grill` and `jhste-domain-modeling` do not modify repository documents merely because an interview or analysis was requested. They update local glossary or ADR files only when the request asks to record or maintain them; commits, pushes, issues, PRs, releases, and other external writes still require separate authority.
 
 ## Main boundaries
 
-Use `jhste-coding` to implement a clear change and verify its own result. Use `jhste-code-result-double-check` when an existing result needs an independent second pass. A normal implementation request does not automatically chain into double-check. A branch, handoff, PR, or worker result alone is not a trigger; the requested outcome matters.
+Use `jhste-coding` to implement a clear change and verify its own result. Use `jhste-code-result-double-check` when an existing result needs an independent second pass. A review, recheck, verify, or audit request is read-only unless it also asks to fix or apply changes. A normal implementation request does not automatically chain into double-check. A branch, handoff, PR, or worker result alone is not a trigger; the requested outcome matters.
 
 Use `jhste-diagnosing-bugs` when an existing symptom has an uncertain cause, and `jhste-prototype` when a not-yet-built design question needs runnable evidence. User-owned decisions belong to `jhste-grill`; externally owned facts or decisions to `jhste-to-questionnaire`; changes to the domain model itself to `jhste-domain-modeling`.
 
 PR review-only work and read-only assessment of existing review comments use the harness or general GitHub tools. A verified review finding with a known correction belongs to `jhste-coding`; an uncertain root cause belongs to `jhste-diagnosing-bugs`. Double-check does not replace the removed review workflows or inherit automatic comment, commit, push, or merge authority.
 
-`jhste-subagent-orchestration` composes task skills into bounded outcomes without expanding their contracts. Acceptance workers remain read-only even when using a task skill that normally corrects code. An assignment's authority ceiling takes precedence; corrections need an authorized implementation assignment. Neither implementation completion nor double-check requires another worker by itself.
-
 `jhste-to-spec` records the behavior contract, `jhste-to-tickets` records executable issue boundaries and dependencies, and `jhste-handoff` records the current state another executor needs. They reference authoritative artifacts instead of duplicating them.
 
 This package does not include a mandatory TDD workflow, Wayfinder, or a separate architecture-audit skill.
@@ -76,7 +72,7 @@ cp -R skills/. "$HOME/.agents/skills/"
 
 ## Upgrade existing installations
 
-`npm update -g jhste-skills` updates the npm package, not copies already placed in an agent's skills directory. Version 0.15.0 removes `jhste-pr-review` and `jhste-review-followup`, and replaces `jhste-implementation-finalizer` with `jhste-code-result-double-check`. Re-copying alone leaves retired directories discoverable.
+`npm update -g jhste-skills` updates the npm package, not copies already placed in an agent's skills directory. Version 0.16.0 removes `jhste-subagent-orchestration`. Re-copying alone can leave that directory and the `jhste-pr-review`, `jhste-review-followup`, and `jhste-implementation-finalizer` directories retired in 0.15.0 discoverable.
 
 First identify every active installation path and whether it is a copy, symlink, or managed by another installer. Inspect local customizations. For the standard copy-based installation, update npm and then run the block below. It moves only this package's current and retired directories to a unique backup outside the skill discovery directory, preserving local edits and unrelated skills. Review customizations in the backup before selectively reapplying them; do not restore retired skill directories.
 
@@ -100,7 +96,7 @@ npm install -g jhste-skills@latest
       mv "$dst/$name" "$backup/$name"
     fi
   done
-  for name in jhste-pr-review jhste-review-followup jhste-implementation-finalizer; do
+  for name in jhste-pr-review jhste-review-followup jhste-implementation-finalizer jhste-subagent-orchestration; do
     if [ -e "$dst/$name" ] || [ -L "$dst/$name" ]; then
       mv "$dst/$name" "$backup/$name"
     fi
@@ -113,7 +109,7 @@ npm install -g jhste-skills@latest
 
 For a repository copy, use the absolute path to its `skills/` directory as `src`. For symlink or installer-managed setups, follow that setup's update mechanism instead of blindly running the copy procedure. Never delete the whole skills directory or all `jhste-*` paths; older custom or legacy installations need ownership inspection first.
 
-Refresh or restart the agent as its harness requires. Confirm the new skill is discovered, the three retired names are absent from every active discovery path, and unrelated skills remain intact. An npm version check alone is not proof that the agent loaded the new files.
+Refresh or restart the agent as its harness requires. Confirm the current skills are discovered, the four retired names are absent from every active discovery path, and unrelated skills remain intact. An npm version check alone is not proof that the agent loaded the new files.
 
 ## Maintenance
 

package/README.md

@@ -8,9 +8,9 @@
 
 ## 무엇을 만들지 정하기
 
-- **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — 지금 답할 수 있는 중요한 결정을 묶어 묻고, 확정된 용어와 필요한 ADR을 진행 중에 기록합니다.
+- **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — 지금 답할 수 있는 중요한 결정을 묶어 묻고, 요청받은 경우에만 확정된 용어와 필요한 ADR을 저장소에 기록합니다.
 - **[`jhste-to-questionnaire`](skills/jhste-to-questionnaire/SKILL.md)** — 현재 사용자가 답할 수 없는 사실이나 결정을 실제 지식 소유자에게 받을 질문지로 정리합니다.
-- **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — 프로젝트 고유 용어, 개념 경계, 관계를 명확히 하고 해당 glossary와 필요한 ADR을 갱신합니다.
+- **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — 프로젝트 고유 용어, 개념 경계, 관계를 명확히 하고, 요청받은 경우에만 해당 glossary와 필요한 ADR을 갱신합니다.
 - **[`jhste-to-spec`](skills/jhste-to-spec/SKILL.md)** — 이미 논의되거나 정의된 변경을 추가 인터뷰 없이 검토 가능한 행동 명세로 정리합니다.
 
 ## 직접 만들고 고치기
@@ -21,13 +21,12 @@
 
 ## 일을 나누고 이어가기
 
-- **[`jhste-subagent-orchestration`](skills/jhste-subagent-orchestration/SKILL.md)** — 분리 이익이 있는 작업을 워커에 맡기되, head가 결정·소유권·통합·최종 검증을 책임집니다.
 - **[`jhste-to-tickets`](skills/jhste-to-tickets/SKILL.md)** — 정의된 작업을 하나의 유용한 GitHub issue 또는 실제 dependency가 있는 issue graph로 나눕니다.
 - **[`jhste-handoff`](skills/jhste-handoff/SKILL.md)** — 다음 실행자에게 검증된 상태, authoritative reference, 소유권, 버린 접근과 정확한 다음 작업을 전달합니다.
 
 ## 기존 코드 결과 재검증
 
-- **[`jhste-code-result-double-check`](skills/jhste-code-result-double-check/SKILL.md)** — 완료됐다고 하거나 제출된 코드 결과를 요구사항·작업 소유 diff·현재 코드·검증 증거와 독립적으로 대조하고, 범위 내 누락과 오류를 고친 뒤 최종 상태를 검증합니다.
+- **[`jhste-code-result-double-check`](skills/jhste-code-result-double-check/SKILL.md)** — 완료됐다고 하거나 제출된 코드 결과를 요구사항·작업 소유 diff·현재 코드·검증 증거와 독립적으로 대조합니다. 기본은 읽기 전용 검증·보고이며, 고치라고 요청한 경우에만 범위 내 누락과 오류를 수정하고 다시 검증합니다.
 
 ## 핵심 원칙
 
@@ -35,20 +34,17 @@
 - 사용자는 제품 정책, 호환성, 보안·데이터 정책, 외부 쓰기처럼 사용자만 결정하거나 허가할 수 있는 문제에만 개입합니다. 서로 독립적인 질문은 묶습니다.
 - 필요한 지식이 현재 사용자가 아닌 다른 사람에게 있으면 `jhste-to-questionnaire`로 실제 소유자에게 받을 질문만 정리합니다.
 - 모델, provider, reasoning 또는 effort, worker 수, 동시성, scheduling, 실제 격리는 사용자와 하네스가 관리합니다. 스킬은 이를 선택하거나 덮어쓰지 않습니다.
-- 서브에이전트는 반복 읽기와 조정 비용보다 분리 이익이 클 때만 사용합니다. 독립 판단이 필요하지 않은 보충 증거나 작은 수정에는 기존 워커를 재사용할 수 있습니다.
 - 요청 결과를 실패와 가장 직접적으로 구분하는 저장소 고유 신호를 선택합니다. 관련 위험·통합 범위·관찰된 실패가 요구할 때만 검증을 확장하고, 실행하지 않은 검증을 성공했다고 말하지 않습니다.
-- `jhste-grill`과 `jhste-domain-modeling` 요청은 확정된 local glossary와 필요한 ADR 갱신을 포함합니다. commit, push, issue, PR, release 같은 외부 쓰기는 요청 범위에서만 수행합니다.
+- `jhste-grill`과 `jhste-domain-modeling`은 인터뷰·분석 요청만으로 저장소 문서를 수정하지 않습니다. glossary·ADR을 기록하거나 갱신하라는 요청이 있을 때만 local 문서를 바꾸고, commit, push, issue, PR, release 같은 외부 쓰기는 별도 요청 범위에서만 수행합니다.
 
 ## 주요 경계
 
-명확한 변경을 구현하고 자신의 결과를 검증하는 작업은 `jhste-coding`, 이미 존재하는 결과를 독립적으로 다시 확인하는 작업은 `jhste-code-result-double-check`가 담당합니다. 일반 구현 요청 뒤에 double-check를 자동 연쇄 실행하지 않습니다. branch, handoff, PR, worker 결과가 있다는 사실만으로 선택하지 않고 요청의 주목적을 봅니다.
+명확한 변경을 구현하고 자신의 결과를 검증하는 작업은 `jhste-coding`, 이미 존재하는 결과를 독립적으로 다시 확인하는 작업은 `jhste-code-result-double-check`가 담당합니다. double-check는 검토·재확인·검증 요청만 있으면 읽기 전용으로 동작하고, 수정 권한은 사용자가 고치거나 적용하라고 요청한 경우에만 생깁니다. 일반 구현 요청 뒤에 double-check를 자동 연쇄 실행하지 않습니다. branch, handoff, PR, worker 결과가 있다는 사실만으로 선택하지 않고 요청의 주목적을 봅니다.
 
 기존 증상의 원인이 불명확하면 `jhste-diagnosing-bugs`, 아직 만들지 않은 설계 질문을 실행 증거로 판단해야 하면 `jhste-prototype`이 담당합니다. 사용자 소유 결정은 `jhste-grill`, 다른 지식 소유자에게 받아야 하는 사실·결정은 `jhste-to-questionnaire`, 용어와 개념 모델 자체의 변경은 `jhste-domain-modeling`이 담당합니다.
 
 PR을 읽고 지적만 하는 작업이나 기존 리뷰 의견의 타당성만 확인하는 작업은 하네스 또는 일반 GitHub 도구로 처리합니다. 이미 타당성이 확인된 리뷰 지적의 명확한 수정은 `jhste-coding`, 원인이 불명확한 문제는 `jhste-diagnosing-bugs`가 담당합니다. double-check는 삭제된 리뷰 workflow를 대신 흡수하지 않으며, 댓글 게시·commit·push·merge 권한을 자동으로 상속하지 않습니다.
 
-`jhste-subagent-orchestration`은 다른 스킬의 계약을 확장하지 않고 bounded outcome으로 조합합니다. acceptance worker는 수정 기능이 있는 스킬을 사용해도 읽기 전용이며, 수정은 권한이 있는 구현 assignment로 처리합니다. 구현이 완료됐거나 double-check가 실행된다는 이유만으로 별도 워커를 추가하지 않습니다.
-
 `jhste-to-spec`은 요구사항 계약, `jhste-to-tickets`는 실행 issue 경계와 dependency, `jhste-handoff`는 다음 실행자가 이어갈 현재 상태를 기록합니다. 서로의 내용을 중복 저장하지 않고 authoritative artifact를 참조합니다.
 
 이 패키지는 의무적인 TDD workflow, Wayfinder, 별도 architecture-audit 스킬을 포함하지 않습니다.
@@ -76,7 +72,7 @@ cp -R skills/. "$HOME/.agents/skills/"
 
 ## 기존 설치 갱신
 
-`npm update -g jhste-skills`는 npm 패키지를 갱신하지만 에이전트의 skills 디렉터리에 복사한 파일까지 갱신하지는 않습니다. 0.15.0에서는 `jhste-pr-review`, `jhste-review-followup`을 삭제하고 `jhste-implementation-finalizer`를 `jhste-code-result-double-check`로 전환합니다. 다시 복사하기만 하면 이전 디렉터리가 남아 계속 선택될 수 있습니다.
+`npm update -g jhste-skills`는 npm 패키지를 갱신하지만 에이전트의 skills 디렉터리에 복사한 파일까지 갱신하지는 않습니다. 0.16.0에서는 `jhste-subagent-orchestration`을 삭제합니다. 다시 복사하기만 하면 이 디렉터리와 0.15.0에서 폐기된 `jhste-pr-review`, `jhste-review-followup`, `jhste-implementation-finalizer`가 남아 계속 선택될 수 있습니다.
 
 먼저 실제 사용 중인 모든 설치 경로와 복사·symlink·별도 installer 관리 여부, 로컬 수정본을 확인하세요. 표준 복사 설치는 npm을 갱신한 다음 아래 블록을 실행합니다. 이 패키지가 제공하는 현재 이름과 폐기된 이름의 디렉터리만 Skill 탐색 경로 밖의 고유 백업 폴더로 이동하므로, 로컬 수정본과 다른 스킬을 보존합니다. 백업의 필요한 사용자 변경은 비교 후 선별적으로 재적용하고, 폐기된 Skill 디렉터리를 다시 복원하지 마세요.
 
@@ -100,7 +96,7 @@ npm install -g jhste-skills@latest
       mv "$dst/$name" "$backup/$name"
     fi
   done
-  for name in jhste-pr-review jhste-review-followup jhste-implementation-finalizer; do
+  for name in jhste-pr-review jhste-review-followup jhste-implementation-finalizer jhste-subagent-orchestration; do
     if [ -e "$dst/$name" ] || [ -L "$dst/$name" ]; then
       mv "$dst/$name" "$backup/$name"
     fi
@@ -113,7 +109,7 @@ npm install -g jhste-skills@latest
 
 저장소 복사본에서 갱신할 때는 `src`를 해당 `skills/`의 절대 경로로 바꾸세요. symlink나 installer 관리 설치는 복사 절차를 무작정 실행하지 말고 해당 설치 방식으로 갱신하세요. 전체 skills 디렉터리나 모든 `jhste-*` 경로를 지우지 마세요. 오래된 설치와 사용자 정의 디렉터리는 소유권 확인이 먼저입니다.
 
-하네스에 맞게 에이전트를 새로고침하거나 재시작한 뒤 새 Skill이 발견되고, 모든 활성 탐색 경로에서 이전 세 이름이 사라졌으며, 다른 스킬이 유지됐는지 확인하세요. npm 버전 확인만으로 에이전트가 새 파일을 읽었다고 판단하지 않습니다.
+하네스에 맞게 에이전트를 새로고침하거나 재시작한 뒤 현재 Skill이 발견되고, 모든 활성 탐색 경로에서 폐기된 네 이름이 사라졌으며, 다른 스킬이 유지됐는지 확인하세요. npm 버전 확인만으로 에이전트가 새 파일을 읽었다고 판단하지 않습니다.
 
 ## 유지보수
 

package/THIRD_PARTY_NOTICES.md

@@ -14,20 +14,20 @@ The JHSTE workflow set is independently maintained, but parts of the workflow st
 - `jhste-coding`: module/interface/seam reasoning, caller-visible contracts, avoiding shallow pass-through abstractions, and conflict resolution guided by repository history and the intent of both sides rather than conflict text alone;
 - `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, non-developer-facing shareable logic experiments, and preserving the question and verdict separately from production implementation.
 
-Upstream was re-reviewed at commit `3cca18b368ae95cdbdebbff572ccafa662551015` on 2026-09-05 (previous review: `068b6e0c62393147daf03530149cdce209c93da8` on 2026-08-17):
+Upstream was re-reviewed at commit `6fd947921b935b7e1e69293a200400f0fdd5c15f` on 2026-10-07 (previous review: `3cca18b368ae95cdbdebbff572ccafa662551015` on 2026-09-05):
 
 - https://github.com/mattpocock/skills
-- https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebbff572ccafa662551015/skills/engineering/diagnosing-bugs
-- https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebbff572ccafa662551015/skills/engineering/resolving-merge-conflicts
-- https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebbff572ccafa662551015/skills/engineering/domain-modeling
-- https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebbff572ccafa662551015/skills/productivity/to-questionnaire
-- https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebbff572ccafa662551015/skills/engineering/prototype
-- https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebbff572ccafa662551015/skills/productivity/grilling
-- https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebbff572ccafa662551015/skills/productivity/handoff
+- https://github.com/mattpocock/skills/tree/6fd947921b935b7e1e69293a200400f0fdd5c15f/skills/engineering/domain-modeling
+- https://github.com/mattpocock/skills/tree/6fd947921b935b7e1e69293a200400f0fdd5c15f/skills/engineering/to-tickets
+- https://github.com/mattpocock/skills/tree/6fd947921b935b7e1e69293a200400f0fdd5c15f/skills/productivity/handoff
+- https://github.com/mattpocock/skills/tree/6fd947921b935b7e1e69293a200400f0fdd5c15f/skills/engineering/retro
+- https://github.com/mattpocock/skills/blob/6fd947921b935b7e1e69293a200400f0fdd5c15f/SCOPE.md
 
-The 2026-09-05 review found only punctuation cleanup, YAML description quoting, a grilling round display format, and two in-progress skills (`implement-spec`, `retro`) since the previous review. None was adopted: the display format is a presentation choice this set leaves open, and the in-progress skills cover flows already handled by `jhste-subagent-orchestration`, `jhste-to-tickets`, and `MAINTENANCE.md`.
+The 2026-10-07 review covered 68 upstream commits since the previous baseline. JHSTE adopted the newer `GLOSSARY.md` / `GLOSSARY-MAP.md` naming for newly created fallback domain documents while preserving repositories that already use legacy `CONTEXT.md` / `CONTEXT-MAP.md`. It also adopted the maintenance principle that recurring mechanically detectable failures should be enforced by deterministic validators, CI, linters, type checks, builds, or tests rather than by more model-facing prose.
 
-The current review considered upstream secret-redaction guidance for debugging evidence, intent-based merge/rebase conflict resolution, literal domain-artifact triggers, and the questionnaire boundary between the current user and another knowledge owner. JHSTE adapts these ideas into its existing authority and deletion-first model: it does not force merge completion when aborting or restarting is safer, does not turn every ADR into domain modeling, does not force questionnaires into repository files, and does not add a separate research, TDD, Wayfinder, wizard, or architecture-audit workflow.
+JHSTE did not adopt upstream `implement-spec`, `pr`, or `retro` as new package skills, fixed TDD/full-suite/reviewer sequences, context-window-based ticket sizing, or skill-level controls for subagent recursion. Those either duplicate existing JHSTE contracts or belong to the active harness. The current handoff flow already covered the material upstream behavior: portable handoffs prefer an artifact or temporary-file location, reference existing authoritative artifacts instead of copying them, redact sensitive information, and suggest only directly relevant next skills. No new handoff workflow was added; only stale retired `finalizer` terminology in the durable reference was cleaned up.
+
+The review also reconfirmed the existing JHSTE adaptations for secret redaction in debugging evidence, intent-based merge/rebase conflict resolution, questionnaire ownership, dependency-aware decision rounds, and issue dependency modeling.
 
 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:
 
@@ -57,51 +57,10 @@ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 
-## Codexclaw
-
-The `jhste-subagent-orchestration` design is independently maintained. Its review considered the following orchestration concepts from `lidge-jun/codexclaw`:
-
-- distinguish runtime-enforced harness controls from model-followed guidance;
-- delegate work that is decision-complete, independently verifiable, and bounded so consequential judgment remains with the head;
-- record a head disposition for each worker return before dependent work proceeds;
-- bind verification evidence to the source state it covered so later integration can invalidate stale evidence;
-- treat repeated independent failures of the same unchanged assignment as evidence that the assignment packet may be defective;
-- dispatch independent work in waves and triage required returns before opening dependent work.
-
-Upstream reviewed at commit `ecc644e7742dc516ea91777414baf3da1859a162` on 2026-08-03:
-
-- https://github.com/lidge-jun/codexclaw
-- https://github.com/lidge-jun/codexclaw/tree/ecc644e7742dc516ea91777414baf3da1859a162
-
-The JHSTE skill does not copy Codexclaw's PABCD state machine, hooks, evidence-receipt runtime, role TOMLs, model or reasoning-effort routing, worker-count limits, or fixed retry counts. No Codexclaw source file is distributed verbatim. The full upstream MIT notice is retained conservatively because the resulting instructions adapt several orchestration concepts and terms.
-
-### MIT License
-
-Copyright (c) 2026 lidge-jun
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-
 ## Anthropic Claude Fable 5.1 prompting guidance
 
-The 0.14.1 maintenance pass reviewed Anthropic's public prompting guidance for Claude Fable 5.1 and adapted two model-agnostic behaviors into the existing JHSTE contracts:
+The 0.14.1 maintenance pass reviewed Anthropic's public prompting guidance for Claude Fable 5.1 and adapted one model-agnostic behavior into the existing JHSTE contracts:
 
-- when the harness allows the head to keep working while delegated workers are pending, continue safe head-owned work that does not depend on those results and wait only at a real dependency barrier;
 - when behavior is equivalent, prefer a targeted edit over rewriting otherwise unchanged files.
 
 The 0.14.3 maintenance pass re-reviewed the Claude Fable 5.1 guidance together with the general Claude prompting best practices and adapted two more behaviors:
@@ -109,7 +68,9 @@ The 0.14.3 maintenance pass re-reviewed the Claude Fable 5.1 guidance together w
 - `jhste-coding` reports a pre-existing bug or unrelated problem noticed during the work as a follow-up instead of fixing it, unless the requested behavior cannot work without that fix;
 - the portable handoff records approaches tried and set aside, mirroring what a compaction summary must preserve so the next executor does not repeat them.
 
-Guidance reviewed on 2026-09-03 and 2026-09-05:
+The Fable 5.1 guidance was re-reviewed on 2026-10-07; no additional model-agnostic skill changes were needed beyond the behaviors already recorded below.
+
+Guidance reviewed on 2026-09-03 and 2026-09-05, and re-reviewed on 2026-10-07:
 
 - https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1
 - https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
@@ -128,3 +89,31 @@ Guidance reviewed on 2026-09-05:
 - https://developers.openai.com/api/docs/guides/latest-model
 
 No guide text is copied. User-versus-skill precedence, delegation encouragement, writing style, and model-specific API guidance remain harness- and user-owned and are not written into these skills.
+
+## OpenAI GPT-5.6 model guidance
+
+The 0.17.0 maintenance pass reviewed OpenAI's current GPT-5.6 model guidance on 2026-10-07. JHSTE adopted or reinforced three model-agnostic behaviors:
+
+- requests to answer, explain, review, diagnose, or plan inspect and report by default rather than mutating files unless the request also asks for a change;
+- requests to change, build, or fix may make safe in-scope local edits and run relevant non-destructive validation without routine confirmation;
+- prompts stay lean: each instruction should appear once, and duplicated ceremony or tool orchestration belongs outside task skills unless representative evaluation proves it is needed.
+
+These changes tighten write authority for `jhste-grill`, `jhste-domain-modeling`, and `jhste-code-result-double-check` without weakening explicit fix or update requests. Model-specific reasoning modes, effort, Programmatic Tool Calling, prompt caching, and multi-agent runtime configuration remain harness-owned.
+
+Guidance reviewed on 2026-10-07:
+
+- https://developers.openai.com/api/docs/guides/latest-model
+
+## Anthropic Claude Sonnet 5.5 and Opus 5.5 prompting guidance
+
+The 0.17.0 maintenance pass reviewed the Claude Sonnet 5.5 and Claude Opus 5.5 model-specific prompting guides together with the current general Claude prompting best practices.
+
+One model-agnostic behavior was added to `jhste-coding`: once the requested behavior is verified and the task-owned diff is clean, stop rather than starting extra review or hardening rounds that the user did not request. The existing JHSTE validation contract already requires a real task-appropriate signal, so no fixed test, typecheck, build, or full-suite ladder was added.
+
+Opus 5.5 unattended-work and multi-agent guidance was treated as harness-specific. JHSTE does not add time budgets, worker recursion limits, effort selection, progress transport, or multi-agent topology rules to individual task skills.
+
+Guidance reviewed on 2026-10-07:
+
+- https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-sonnet-5-5
+- https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5
+- https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "jhste-skills",
-  "version": "0.15.0",
-  "description": "A lean, harness-neutral engineering skill set for coding, diagnosis, prototyping, independent code-result double checks, subagent coordination, specifications, tickets, handoffs, decision interviews, external questionnaires, and domain modeling.",
+  "version": "0.17.0",
+  "description": "A lean, harness-neutral engineering skill set for coding, diagnosis, prototyping, independent code-result double checks, specifications, tickets, handoffs, decision interviews, external questionnaires, and domain modeling.",
   "type": "module",
   "license": "MIT",
   "repository": {

package/skills/jhste-code-result-double-check/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: jhste-code-result-double-check
-description: Independently recheck existing code results against requirements, the task-owned diff, current code, and verification evidence. Use when the user asks for a second pass on completed or submitted implementation work; correct in-scope omissions or errors and verify the resulting state.
+description: Independently recheck existing code results against requirements, the task-owned diff, current code, and verification evidence. Use when the user asks for a second pass on completed or submitted implementation work. Treat review, recheck, verify, and audit as read-only unless the request also asks to fix, correct, repair, or apply changes; when correction is authorized, fix in-scope omissions or errors and verify the resulting state.
 ---
 
 # JHSTE Code Result Double Check
 
 ## Goal
 
-Establish whether an existing code result satisfies its requested outcome, correct in-scope gaps, and leave an honestly verified final state. Treat completion claims as unverified input, not acceptance evidence. Independent judgment does not require another worker.
+Establish whether an existing code result satisfies its requested outcome and leave an honestly verified final assessment. Treat completion claims as unverified input, not acceptance evidence. Independent judgment does not require another worker.
 
 ## Recover the contract and scope
 
@@ -15,22 +15,24 @@ Resolve material requirements from the current request and authoritative reposit
 
 Inspect the complete task-owned change, including relevant committed and uncommitted work, the current source, and directly related integration points. Distinguish unrelated changes and other workstreams' ownership; neither a clean worktree nor a completion report proves the result is complete.
 
-## Correct within authority
+## Respect the requested authority
 
-Fix omissions, incorrect behavior, incomplete wiring, compatibility regressions, or misleading verification required by the established outcome. Preserve caller-visible contracts, authorization, and sensitive-data boundaries. Leave sound code alone and report unrelated problems rather than expanding into general cleanup.
+A request to review, recheck, verify, audit, or double-check an existing result is read-only with respect to code and repository files unless the same request also asks to fix, correct, repair, apply, or otherwise make changes.
 
-Make safe, reversible, repository-consistent corrections without routine confirmation. Do not invent unresolved product, compatibility, security, data, or migration decisions. Complete safe work and identify any consequential blocker, its impact, and the point where work can resume.
+Under read-only authority, return evidence-backed findings and do not edit files. When correction is authorized, fix omissions, incorrect behavior, incomplete wiring, compatibility regressions, or misleading verification required by the established outcome. Preserve caller-visible contracts, authorization, and sensitive-data boundaries. Leave sound code alone and report unrelated problems rather than expanding into general cleanup.
 
-Honor read-only requests and assignment authority. Invoking this skill grants no additional mutation, ownership, delegation, destructive-action, or external-write authority. Local rechecking and correction do not by themselves authorize commits, pushes, publication, or changes to external systems.
+Make safe, reversible, repository-consistent corrections without routine confirmation only when the request authorizes correction. Do not invent unresolved product, compatibility, security, data, or migration decisions. Complete safe authorized work and identify any consequential blocker, its impact, and the point where work can resume.
 
-## Verify the resulting state
+Invoking this skill grants no additional mutation, ownership, delegation, destructive-action, or external-write authority. Local correction does not by itself authorize commits, pushes, publication, or changes to external systems.
 
-Use the strongest available signal that distinguishes each material requirement's success from failure. Expand verification only for relevant risk, integration surface, or an observed failure. Reuse evidence only when its source state and coverage remain applicable; re-run checks invalidated by corrections or integration changes. Never claim that an unrun check passed.
+## Verify the assessed or resulting state
 
-When an existing handoff is authoritative and writable within scope, synchronize any changed status. Do not create a new handoff or other document merely because a second pass ran.
+Use the strongest available signal that distinguishes each material requirement's success from failure. Expand verification only for relevant risk, integration surface, or an observed failure. Reuse evidence only when its source state and coverage remain applicable; re-run checks invalidated by authorized corrections or integration changes. Never claim that an unrun check passed.
+
+When an existing handoff is authoritative and writable within the request's scope, synchronize changed status only if the request authorizes that document update. Do not create a new handoff or other document merely because a second pass ran.
 
 ## Completion
 
-Account for every material requirement with evidence or an explicit incomplete, blocked, or unverified status. Report the verified outcome, corrections, current verification, and remaining limitations. A completed inspection is not a claim that unresolved implementation gaps are complete.
+Account for every material requirement with evidence or an explicit incomplete, blocked, or unverified status. Report the verified outcome, findings, any authorized corrections, current verification, and remaining limitations. A completed inspection is not a claim that unresolved implementation gaps are complete.
 
-Under read-only authority, return evidence-backed findings without editing. Keep any separately authorized publication outcome distinct from the code-verification result.
+Keep any separately authorized publication outcome distinct from the code-verification result.

package/skills/jhste-code-result-double-check/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "JHSTE Code Result Double Check"
-  short_description: "Recheck existing code results and fix in-scope gaps"
-  default_prompt: "Use $jhste-code-result-double-check to independently recheck this existing code result against its requirements and current evidence, fix in-scope gaps, and verify the final state."
+  short_description: "Recheck code results with explicit correction authority"
+  default_prompt: "Use $jhste-code-result-double-check to independently recheck this existing code result against its requirements and current evidence. Report findings unless the request also authorizes in-scope corrections, and verify any corrected state."
 
 policy:
   allow_implicit_invocation: true

package/skills/jhste-coding/SKILL.md

@@ -39,6 +39,8 @@ When a cheap focused signal can establish the relevant starting behavior before
 
 Add or update a test only at a seam that represents the real caller-visible behavior. Inspect the final task-owned diff for scope creep, temporary instrumentation, stale compatibility paths, prototype-only artifacts, and anything unnecessary, over-complex, or resting on an assumption the evidence does not support; remove before simplifying, leave what already reads well unchanged, and re-run any check the cleanup invalidates. Never imply that an unrun check passed.
 
+Once the requested behavior is verified and the task-owned diff is clean, stop. Do not start a separate review or hardening pass unless the user asked for one; report worthwhile deeper review or unrelated follow-up separately instead of doing it automatically.
+
 ## Completion
 
 Report the implemented outcome, the evidence used to verify it, and any material limitation or blocker. Omit generic background and unchanged details.

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

@@ -1,17 +1,17 @@
 ---
 name: jhste-domain-modeling
-description: Clarify or change project-specific domain terms, identities, boundaries, and relationships while maintaining the owning glossary and qualifying ADRs. Use for conflicting or overloaded language, domain concepts, writing or editing the owning glossary or CONTEXT.md, or recording or editing an ADR about a significant domain decision. Merely following an existing glossary is ordinary work, not domain modeling.
+description: Clarify or change project-specific domain terms, identities, boundaries, and relationships. Use for conflicting or overloaded language, domain concepts, or requests to write or edit the owning GLOSSARY.md or GLOSSARY-MAP.md, including repositories that still use legacy CONTEXT.md or CONTEXT-MAP.md, and for recording or editing an ADR about a significant domain decision. By default, analysis-only domain-modeling requests are read-only with respect to repository files. Merely following an existing glossary is ordinary work, not domain modeling.
 ---
 
 # JHSTE Domain Modeling
 
 ## Goal
 
-Establish precise shared language that matches the intended domain and relevant behavior, then keep the owning domain documents synchronized as decisions settle.
+Establish precise shared language that matches the intended domain and relevant behavior, then keep owning domain documents synchronized when the request authorizes those updates.
 
 ## Investigate before asking
 
-Read the existing glossary, context map, ADRs, issues, repository conventions, and relevant code. Treat implementation as evidence, not unquestioned truth. Surface contradictions between the user's model, documentation, and code.
+Read the existing glossary or legacy context document, glossary or context map, ADRs, issues, repository conventions, and relevant code. Treat implementation as evidence, not unquestioned truth. Surface contradictions between the user's model, documentation, and code.
 
 Ask only where intended meaning, identity, boundary, or policy belongs to the user. Repository and environment facts are the agent's responsibility.
 
@@ -23,26 +23,26 @@ Use concrete scenarios and edge cases to test identity, boundaries, state transi
 
 Keep general programming vocabulary, implementation details, specifications, task notes, and temporary decisions out of the domain glossary.
 
-## Maintain the owning context
+## Maintain owning domain documents only when requested
 
-A domain-modeling request in a writable repository authorizes local glossary and qualifying ADR updates. Follow the repository's established locations and formats.
+Follow the repository's established domain-document convention. Prefer `GLOSSARY.md` and `GLOSSARY-MAP.md` when creating a new convention. If the repository already uses legacy `CONTEXT.md` or `CONTEXT-MAP.md`, preserve that convention rather than creating parallel glossary files.
 
-When `CONTEXT-MAP.md` exists, update the bounded context that owns the concept. Record a system-wide ADR only for a decision that crosses context boundaries; otherwise keep it with the owning context when that convention exists.
+Do not treat a request to analyze, clarify, discuss, or model the domain as permission to modify repository files. Edit local glossary, map, or ADR files only when the request also asks to create, record, write, update, edit, or maintain those artifacts.
 
-If no convention exists, read [references/formats.md](references/formats.md) and create fallback files lazily when the first term or qualifying decision settles.
+When documentation updates are authorized and no convention exists, read [references/formats.md](references/formats.md) and create fallback files lazily when the first term or qualifying decision settles.
 
-Update a settled term during the same round once a concrete scenario reveals no material contradiction.
+When documentation updates are not authorized, present the exact proposed glossary and ADR changes without editing files.
 
 ## Record qualifying decisions
 
-Write an ADR without separate confirmation when a selected decision is all three:
+When local decision-document updates are authorized, write an ADR without separate confirmation when a selected decision is all three:
 
 - costly to reverse;
 - surprising without its rationale; and
 - the result of a real trade-off.
 
-Do not create ADRs for routine, temporary, self-evident, or unresolved choices. If the user requests analysis only or forbids edits, present the exact proposed changes instead. Commit, push, and publication still require their own authorization.
+Do not create ADRs for routine, temporary, self-evident, or unresolved choices. Commit, push, and publication still require their own authorization.
 
 ## Completion
 
-Report the terms changed or still ambiguous, scenarios used, code or document mismatches, bounded contexts affected, glossary and ADR files changed, and unresolved user-owned decisions that block the model.
+Report the terms changed or still ambiguous, scenarios used, code or document mismatches, bounded contexts affected, glossary and ADR files changed or proposed, and unresolved user-owned decisions that block the model.

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

@@ -1,7 +1,7 @@
 interface:
   display_name: "JHSTE Domain Modeling"
-  short_description: "Clarify terms and maintain glossary and ADRs"
-  default_prompt: "Use $jhste-domain-modeling to clarify the domain language and keep the project glossary and qualifying ADRs synchronized."
+  short_description: "Clarify domain terms and update docs only when requested"
+  default_prompt: "Use $jhste-domain-modeling to clarify the domain language and identify exact glossary or ADR changes. Edit repository domain documents only when the request asks to record or update them."
 
 policy:
   allow_implicit_invocation: true

package/skills/jhste-domain-modeling/references/formats.md

@@ -1,10 +1,12 @@
 # Fallback Domain Document Formats
 
-Use these formats only when the repository has no established glossary or ADR convention.
+Use these formats only when the repository has no established glossary, legacy context-document, or ADR convention.
 
-## Context glossary
+## Domain glossary
 
-Create a root `CONTEXT.md` lazily for a single-context repository. When several bounded contexts exist, use a root `CONTEXT-MAP.md` that points to each owning `CONTEXT.md`.
+Create a root `GLOSSARY.md` lazily for a single-context repository. When several bounded contexts exist, use a root `GLOSSARY-MAP.md` that points to each owning `GLOSSARY.md`.
+
+If the repository already uses legacy `CONTEXT.md` or `CONTEXT-MAP.md`, preserve that established convention instead of creating parallel `GLOSSARY*` files.
 
 ```markdown
 # Context Name

package/skills/jhste-grill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jhste-grill
-description: Interview the user in dependency-aware decision rounds to sharpen or stress-test a plan, product behavior, or design while continuously 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; discover facts directly, and use jhste-prototype when settled decisions still need executable evidence.
+description: Interview the user in dependency-aware decision rounds 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 user-owned decisions. By default, keep the session read-only with respect to repository files; update settled glossary entries or qualifying ADRs only when the request also asks to record, write, update, or maintain those artifacts. Do not invoke merely because an ordinary request has a small ambiguity; discover facts directly, and use jhste-prototype when settled decisions still need executable evidence.
 ---
 
 # JHSTE Grill
@@ -11,7 +11,7 @@ Reach shared understanding across every consequential decision branch with as fe
 
 ## Discover facts before asking
 
-Inspect available code, documents, prior decisions, tools, and external evidence instead of asking the user for discoverable facts. Use bounded workers when independent fact-finding would be faster, and continue with questions that do not depend on the pending result.
+Inspect available code, documents, prior decisions, tools, and external evidence instead of asking the user for discoverable facts. Continue with frontier questions that do not depend on any still-pending fact-finding rather than blocking the whole interview.
 
 Ask the user only about choices that belong to them: desired behavior, scope, priorities, compatibility, failure behavior, data or security policy, and consequential trade-offs. Do not ask about reversible implementation details that a later executor can decide safely.
 
@@ -32,15 +32,17 @@ Treat a branch as consequential when it can change the goal, success criteria, s
 
 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 production code or publish issues as part of this skill alone.
 
-## Maintain decision documents
+## Record decision documents only when requested
 
-In a writable repository, treat the request to run this interview as authorization to maintain local domain and decision documents. Read the existing glossary, context map, ADRs, and repository conventions first. Follow their locations and formats. If none exists, create `CONTEXT.md` lazily when the first term settles and create `docs/adr/` lazily when the first qualifying ADR is needed.
+Do not treat an interview request by itself as authorization to modify repository files.
 
-When a domain term's meaning and boundary are agreed, test it with at least one concrete scenario. If no material contradiction remains, update the owning glossary during the same round. Keep implementation details, specifications, and temporary notes out of the glossary.
+When the user also asks to record, write, update, or maintain the settled results in a writable repository, read the existing glossary, glossary map, ADRs, and repository conventions first. Follow their locations and formats. Prefer `GLOSSARY.md` and `GLOSSARY-MAP.md` for new fallback documents; if the repository already uses legacy `CONTEXT.md` or `CONTEXT-MAP.md`, preserve that convention instead of creating a parallel glossary.
 
-When the user selects a decision that is costly to reverse, surprising without its rationale, and the result of a real trade-off, write an ADR immediately without requesting separate confirmation. Follow the repository's format. If none exists, use the next available `docs/adr/NNNN-<slug>.md` file with concise `Context` and `Decision` sections; add `Consequences` or `Alternatives` only when they preserve non-obvious information.
+When a domain term's meaning and boundary are agreed, test it with at least one concrete scenario. If no material contradiction remains and documentation updates are authorized, update the owning glossary during the same round. Keep implementation details, specifications, and temporary notes out of the glossary.
 
-Keep documents synchronized throughout the interview rather than batching updates at the end. If the user requests analysis only or forbids edits, present the exact proposed glossary and ADR changes instead. Do not commit, push, or publish repository changes without explicit authorization for those actions.
+When documentation updates are authorized and the user selects a decision that is costly to reverse, surprising without its rationale, and the result of a real trade-off, write an ADR without requesting separate confirmation. Follow the repository's format. If none exists, use the next available `docs/adr/NNNN-<slug>.md` file with concise `Context` and `Decision` sections; add `Consequences` or `Alternatives` only when they preserve non-obvious information.
+
+When repository documentation updates are not requested, keep the interview read-only and include the exact proposed glossary or ADR changes in the outcome instead. Commit, push, publication, and other external writes still require their own authorization.
 
 ## Stop condition
 
@@ -54,6 +56,6 @@ Summarize only what the session established:
 - decisions and their reasons;
 - constraints and out-of-scope items;
 - unresolved blockers;
-- domain terms added or changed;
-- ADRs created;
-- documentation files changed.
+- domain terms added, changed, or proposed;
+- ADRs created or proposed;
+- documentation files changed, when any.

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

@@ -1,7 +1,7 @@
 interface:
   display_name: "JHSTE Grill"
-  short_description: "Resolve decisions in rounds and maintain context docs"
-  default_prompt: "Use $jhste-grill to resolve every currently answerable consequential decision in compact rounds while updating settled context and qualifying ADRs."
+  short_description: "Resolve decisions in rounds without implicit repo writes"
+  default_prompt: "Use $jhste-grill to resolve every currently answerable consequential decision in compact rounds. Update repository glossary or ADR files only when the request also asks to record or maintain them."
 
 policy:
   allow_implicit_invocation: true

package/skills/jhste-handoff/references/durable.md

@@ -22,4 +22,4 @@ Omit empty sections. Add separate phase files only when outcomes have distinct o
 
 Do not treat an uncommitted tree or parallel workers as blockers by themselves. Stop only when ownership cannot be distinguished, isolation is insufficient, or continuing would overwrite another workstream.
 
-Update durable state at a material phase start, blocker or decision change, and verified phase completion. Avoid per-edit documentation churn. The active owner may update its section; the integration owner or finalizer verifies completion state.
+Update durable state at a material phase start, blocker or decision change, and verified phase completion. Avoid per-edit documentation churn. The active owner may update its section; the integration owner or final verifier checks completion state.

package/skills/jhste-subagent-orchestration/SKILL.md

@@ -1,78 +0,0 @@
----
-name: jhste-subagent-orchestration
-description: Coordinate bounded workers under a decision-owning head when explicit delegation or independently ownable work creates concrete value. Use for subagents, workers, head-worker splits, parallel agent fan-out, or a separate-agent check. Do not use for ordinary linear work, unresolved user decisions, or domain meanings such as container orchestration. Models, providers, reasoning, concurrency, and isolation remain user- and harness-owned.
----
-
-# JHSTE Subagent Orchestration
-
-## Goal
-
-Use workers only where separation improves execution while the head retains decisions, canonical state, ownership, integration, and final verification.
-
-## Choose a topology, not a fixed workflow
-
-Select the lightest shape that fits the work:
-
-- **Direct:** for implicit use, leave small linear work with the owning task skill.
-- **Single owner:** one worker owns one coherent outcome.
-- **Parallel owners:** independent outcomes proceed concurrently without overlapping mutation ownership.
-- **Dynamic waves:** later assignments are created from verified earlier results when the work cannot be planned honestly in one pass.
-
-An explicit delegation request still selects this skill. If no real worker mechanism exists, report that limitation instead of simulating workers.
-
-Delegate only when the outcome is decision-complete enough to assign, independently verifiable, and separable without hidden coordination. Complexity alone is not a reason to fan out. Repeated reading, duplicated setup, and integration cost count against delegation.
-
-When the harness permits the head to continue while workers are pending, continue safe head-owned work that does not depend on those results. Wait only at a real dependency barrier.
-
-## Respect the harness boundary
-
-Treat model selection, provider selection, reasoning or effort, worker count, concurrency, concrete agent configuration, isolation, and scheduling as user- and harness-owned. Do not choose, recommend, or override them.
-
-Use harness-native shared context, structured output, artifacts, worker reuse, isolation, peer messaging, and completion notifications when available. Fall back to self-contained assignments and compact reports when they are unavailable.
-
-## Keep consequential control in the head
-
-The head owns:
-
-- product, scope, security, data, compatibility, and architecture decisions;
-- assignment boundaries, dependencies, mutation ownership, and live activity;
-- acceptance or rejection of worker claims;
-- integration and the final completion decision.
-
-Workers may exchange head-authorized factual information through a harness-native channel, but must not transfer ownership, broaden authority, settle consequential decisions, or hide additional work. A worker may request permission before spawning another worker; it may not invoke this orchestration skill on its own.
-
-## Define bounded outcomes
-
-A worker assignment needs only:
-
-- one outcome;
-- task-specific verified context;
-- scope and authority, including mutation and external-write boundaries;
-- a done signal and required evidence; and
-- stop conditions for mismatched state, missing decisions, ownership conflict, broader authority, or unusable verification.
-
-Put shared facts in the harness's shared-context mechanism when one exists. Keep verbose evidence in a stable artifact and return a compact result with its location. Read [references/worker-contract.md](references/worker-contract.md) only when detailed stage, amendment, reuse, or report rules are needed.
-
-One worker may investigate and implement when a fix is already authorized, the policy is settled, ownership is narrow, and the verification signal is clear. Separate investigation when the search is broad, the implementation choice is unsettled, or the work must remain read-only.
-
-Reuse a current worker for missing evidence, explanation, or a small correction within the same outcome and ownership boundary when its context remains valid. Use a fresh worker when independence is the purpose, ownership changes, the source state changed materially, or prior context is stale or anchored to a failed approach.
-
-## Add independent acceptance only when it earns its cost
-
-Use a separate acceptance worker only when the user requests one or when risk, integration surface, or weak verification makes head inspection insufficient. Do not add one merely because implementation completed, and do not duplicate an independent review already supplied by the harness.
-
-Acceptance remains read-only. A material correction becomes an implementation assignment, and fresh acceptance is needed only when that correction invalidates the previous evidence basis.
-
-## Maintain only necessary control state
-
-Treat every worker result as an unverified claim. Check the relevant source, diff, command output, measurement, artifact, or external state before using it. Bind important evidence to the source state it covered and re-run it after relevant integration changes.
-
-Keep no separate ledger for one independent wave. Read [references/control-state.md](references/control-state.md) only for dependent waves, overlapping ownership domains, live activity, worker replacement, or state that must survive into later work.
-
-When repeated workers fail the same unchanged assignment, inspect the assignment rather than blindly retrying. Rewrite, narrow, or reclaim work whose context, decision boundary, ownership, or verification signal is defective.
-
-## Completion
-
-Finish only when material outcomes are verified, required worker results have final dispositions, the integrated state and checks are current, mutation ownership is released, live activity is completed, terminated, or head-owned, and authorized external state matches the intended result.
-
-Report the verified outcome, evidence, material limitations, and remaining risks. Never substitute a worker completion claim for head verification.

package/skills/jhste-subagent-orchestration/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "JHSTE Subagent Orchestration"
-  short_description: "Choose the lightest useful worker topology"
-  default_prompt: "Use $jhste-subagent-orchestration to choose the lightest useful worker topology, preserve head-owned decisions and ownership, and verify every result without changing harness runtime settings."
-
-policy:
-  allow_implicit_invocation: true

package/skills/jhste-subagent-orchestration/references/control-state.md

@@ -1,75 +0,0 @@
-# Head Control State
-
-Use this reference for dependent assignments, overlapping mutation domains, live background activity, worker reuse or replacement, or multiple verified waves.
-
-## Compact ledger
-
-```text
-Mission
-- Objective, user authority, forbidden actions
-- Settled decisions and unresolved head decisions
-
-Repository
-- Repository, workspace, base, branch, starting source state
-- Known unrelated changes
-
-Assignments
-- ID, stage, primary skill, dependencies, worker identity when reusable
-- State: planned | active | waiting_for_head | completed | blocked | failed | discarded
-- Verification: unverified | verified
-- Disposition: pending | accepted | rejected | merged | superseded
-- Disposition rationale
-
-Mutation ownership
-- Domain, owner assignment, release or transfer condition
-
-Live activity
-- Owner, command or job ID, notification path
-- Intervention limit, termination method, verification requirement
-
-Next-wave gate
-- Required evidence, decisions, dispositions, and available ownership domains
-```
-
-Track only state that prevents conflicting work, stale evidence, or false completion. Skip the ledger for a single independent wave; packets and verified returns are enough.
-
-## Assignment lifecycle and worker reuse
-
-```text
-planned -> active <-> waiting_for_head
-active -> completed | blocked | failed -> discarded
-```
-
-Lifecycle belongs to an assignment, not to the reusable worker process. Do not return a terminal assignment to `active`. A current worker may receive a follow-up assignment for clarification, missing evidence, or a bounded correction when independence is not required and its context remains valid.
-
-Use a fresh worker when ownership or outcome changes, independent judgment matters, the source state changed materially, or prior context is stale or anchored to a failed approach.
-
-Keep lifecycle, verification, and disposition separate. `completed` is a worker claim. Verify it through head inspection, then record each required return as accepted, rejected, merged, or superseded before dependent work proceeds.
-
-## Mutation ownership and live activity
-
-Mutation ownership is the head's logical reservation, not proof of a runtime lock. The harness controls actual isolation and permissions. Do not overlap ownership for the same mutation domain.
-
-Before release or reassignment, verify the resulting state and ensure live activity is completed, terminated, or transferred to the head. A transfer needs a stable identifier, completion notification, intervention limit, termination method, and release check. Silence or worker termination does not release ownership.
-
-## Peer fact exchange
-
-When the harness supports peer communication, record any head-approved factual exchange that affects execution. Do not allow peer messages to change ownership, authority, dependencies, or consequential decisions. Any such change returns to the head and updates canonical state.
-
-## Waves and evidence freshness
-
-Dispatch independent work within harness capacity and triage required returns before opening dependent work.
-
-Record the source state covered by important tests, measurements, or acceptance evidence. Re-run affected verification when later integration changes the relevant tree, configuration, data, or external target.
-
-Use an acceptance worker only for an uncovered risk, explicit user request, broad integration surface, or weak verification. Do not create one simply because implementation completed, and do not duplicate a harness-provided independent review. After a material correction, obtain fresh acceptance only when the previous evidence basis became invalid.
-
-## Recovery
-
-Classify failure as infrastructure, stale precondition, contract gap, implementation defect, ownership conflict, unauthorized action, or unusable evidence. Give replacements canonical state rather than the previous worker conversation.
-
-When independent workers repeatedly fail the same unchanged packet, inspect the packet. Rewrite, narrow, or reclaim it when its context, decision boundary, ownership, or verification oracle is defective. Preserve partial work only when its owner and actual state are known.
-
-## Completion gate
-
-Complete only when material requirements have verified implementation and verification status, required returns have final dispositions, the integrated surface was inspected, checks are current for the final state, no worker mutation ownership remains, live activity is completed, terminated, or head-owned, and authorized external state matches the target with remaining risks explicit.

package/skills/jhste-subagent-orchestration/references/worker-contract.md

@@ -1,106 +0,0 @@
-# Worker Contract Protocol
-
-Use this reference when a compact assignment needs detailed authority, amendment, reuse, or stage rules. Omit fields that do not affect execution.
-
-## Shared and task-specific context
-
-Put verified facts common to several workers in a harness-native shared-context mechanism when one exists. Keep each assignment limited to task-specific differences. When shared context is unavailable, include every fact needed to execute the assignment without conversation history.
-
-## Assignment template
-
-```markdown
-# Worker Assignment
-## Identity
-- Assignment ID:
-- Stage: investigation | implementation | investigation-and-implementation | acceptance
-- Primary task skill: optional
-## Outcome
-State the one result this worker must produce.
-## Context
-List task-specific verified facts, settled decisions, exact paths, symbols, identifiers, and the starting state only when material.
-## Scope and authority
-- Read scope:
-- Mutation ownership: none | exact files, workspace, host, or resource
-- Allowed external writes: none | exact targets and actions
-- Forbidden scope:
-- Permitted peer fact exchange: none | exact workers and topic
-- Worker may decide:
-- Worker must return unresolved:
-Authority ceiling: No invoked skill or peer message grants additional decision,
-mutation, delegation, destructive-action, or external-write authority.
-## Completion
-- Done signal:
-- Required verification and expected result:
-- Stop conditions:
-- Evidence basis to record when staleness matters:
-## Return
-Provide the compact report below and place verbose evidence in a harness artifact when available.
-```
-
-Allow read-only inspection inside the stated scope unless forbidden. Enumerate mutation, destructive actions, and external writes rather than every harmless read command.
-
-A worker must not transfer its assignment, broaden its authority, or invoke `jhste-subagent-orchestration`. It may request a head grant before spawning another worker. Permitted peer communication is factual only and must not transfer ownership, settle consequential decisions, or conceal new work.
-
-Always stop on a material starting-state mismatch, ownership conflict, missing consequential decision, unavailable required skill or evidence source, need for broader authority, or verification that cannot measure the claimed outcome.
-
-## Clarification, amendment, and reuse
-
-Use `waiting_for_head` only when the harness can safely resume the same worker.
-
-```markdown
-# Clarification Request
-- Assignment ID:
-- Verified fact or mismatch:
-- Decision or information required:
-- Current live activity and held ownership:
-```
-
-Reply without depending on prior conversation:
-
-```markdown
-# Assignment Amendment
-- Assignment ID:
-- Changed fact or decision:
-- Scope and authority impact:
-- Stop-condition impact:
-- Verification impact:
-- Everything else remains unchanged: yes | no
-```
-
-Reuse the same worker for missing evidence, explanation, or a small correction within the same outcome and ownership boundary when its context is current. Create a new assignment when the outcome, stage, ownership domain, external authority, or consequential decision changes. Use a fresh worker when independent judgment is part of the purpose or prior context is stale or biased.
-
-Do not reopen a completed assignment as though it never ended. Record a follow-up assignment or amendment that identifies the prior result and the current source state.
-
-## Report template
-
-```markdown
-# Worker Report
-## Status
-completed | blocked | failed
-## Result
-State the outcome first.
-## Evidence
-Give compact paths, lines, diff, measurements, logs, or external-state references.
-Point to the full artifact when the harness preserves one.
-## Changed resources
-List every modified path or external resource, or `None`.
-## Verification
-- Command or inspection:
-- Observed result and exit status:
-- Evidence basis: commit, workspace, tree state, task-owned diff, configuration, or external target
-## Deviation or blocker
-State any deviation, unmet criterion, or unresolved item, or `None`.
-## Live activity and ownership
-- Active commands or jobs, stable identifiers, and notification path:
-- Resources still held:
-- Safe for the head to release or reassign ownership: yes | no
-```
-
-Include adjacent observations only when they affect completion, safety, or the next assignment.
-
-## Stage constraints
-
-- **Investigation:** return facts, evidence, candidate explanations, and uncertainty. Do not select a consequential product or architecture decision or change production behavior. Create disposable artifacts only when authorized.
-- **Implementation:** apply a settled solution inside the assigned ownership boundary, preserve named contracts, and stop on a material mismatch. Do not rediscover product requirements or invent policy.
-- **Investigation-and-implementation:** diagnose and correct only when a fix is already authorized, correction policy is settled, ownership is narrow, and verification is clear. Stop before crossing into a consequential decision or broader mutation domain.
-- **Acceptance:** inspect the complete task-owned change and relevant integration surface. Return evidence-backed findings and a verdict without editing. Corrections require an implementation assignment. Do not duplicate an independent check already supplied by the harness unless the head identifies a distinct uncovered risk.