jhste-skills 0.16.0 → 0.17.0

package/CHANGELOG.md

@@ -1,5 +1,16 @@
 # 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

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.
@@ -64,7 +68,7 @@ Use the request text in the repository's `scripts/routing-scenarios.json`, rathe
 | 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` |
 
 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
@@ -26,7 +26,7 @@ Core `SKILL.md` files contain the task contract and important boundaries. Rare f
 
 ## 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,11 +35,11 @@ Core `SKILL.md` files contain the task contract and important boundaries. Rare f
 - 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.
 - 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`.
 

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)** — 이미 논의되거나 정의된 변경을 추가 인터뷰 없이 검토 가능한 행동 명세로 정리합니다.
 
 ## 직접 만들고 고치기
@@ -26,7 +26,7 @@
 
 ## 기존 코드 결과 재검증
 
-- **[`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,11 +35,11 @@
 - 필요한 지식이 현재 사용자가 아닌 다른 사람에게 있으면 `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`이 담당합니다.
 

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-coding`, `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:
 
@@ -68,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
@@ -87,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,6 +1,6 @@
 {
   "name": "jhste-skills",
-  "version": "0.16.0",
+  "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",

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.