jhste-skills 0.9.0 → 0.10.0

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## 0.10.0 - 2026-08-03
+
+### Added
+- Added `jhste-subagent-orchestration` for bounded investigation, implementation, and read-only acceptance workers under a decision-owning head.
+- Added static routing contracts for explicit delegation, implicit structural benefit, ordinary-work exclusions, handoff boundaries, and external-write authority.
+
+### Changed
+- Reduced the reviewed orchestration package from 469 to 264 lines while preserving the four-file structure and critical head, worker, ownership, and verification invariants.
+- Separated worker stage from task skill, read-only acceptance from corrective finalization, worker lifecycle from head verification and disposition, and logical mutation leases from harness-enforced permissions.
+- Moved worker concurrency limits entirely to the harness boundary and excluded worker model and reasoning-effort routing from the skill.
+- Added wave-level result dispositions, source-basis checks for stale verification, resumable clarification rules, live-activity transfer, and assignment-defect recovery after repeated independent failures.
+- Updated both READMEs and package metadata from eleven to twelve skills and expanded static routing coverage from 78 to 88 scenarios across ten covered skills.
+- Recorded the reviewed Codexclaw revision and the orchestration concepts adapted or deliberately omitted.
+
 ## 0.9.0 - 2026-07-28
 
 ### Added

package/README.en.md

@@ -8,6 +8,7 @@ A personal engineering skill set maintained around GPT-5.6's outcome-first, lean
 
 - **[`jhste-coding`](skills/jhste-coding/SKILL.md)** — implements sufficiently understood features, bug fixes, refactors, and ordinary continuation from a handoff's exact resume point with a small change and relevant validation.
 - **[`jhste-prototype`](skills/jhste-prototype/SKILL.md)** — tests one important design question before production implementation with the smallest disposable runnable evidence.
+- **[`jhste-subagent-orchestration`](skills/jhste-subagent-orchestration/SKILL.md)** — coordinates bounded investigation, implementation, and acceptance workers under a decision-owning head when delegation is explicit or has concrete structural benefit.
 - **[`jhste-diagnosing-bugs`](skills/jhste-diagnosing-bugs/SKILL.md)** — diagnoses difficult bugs and performance regressions whose cause or correct fix is uncertain through reproduction, hypotheses, and measurement.
 - **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — resolves consequential decision branches one question at a time while continuously maintaining settled domain context and ADRs.
 - **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — clarifies domain terms, boundaries, and relationships, immediately recording settled glossary entries and qualifying ADRs.
@@ -18,27 +19,28 @@ A personal engineering skill set maintained around GPT-5.6's outcome-first, lean
 - **[`jhste-pr-review`](skills/jhste-pr-review/SKILL.md)** — reviews explicitly requested PRs against the actual diff and posts only high-confidence actionable findings.
 - **[`jhste-review-followup`](skills/jhste-review-followup/SKILL.md)** — validates existing PR feedback and pushes only justified fixes to the existing PR branch.
 
-The skills do not require or automatically call one another, and `jhste-prototype` is not a mandatory pre-step for coding. A sufficiently clear implementation belongs to `jhste-coding`; only an important uncertainty about what to build that needs runnable evidence belongs to `jhste-prototype`; an unexplained failure in existing behavior belongs to `jhste-diagnosing-bugs`; and a user-owned policy decision belongs to `jhste-grill`. Once a prototype direction is selected, `jhste-coding` implements it for production and `jhste-to-spec` records it only when a specification is requested.
+Most skills do not require or automatically call one another. `jhste-subagent-orchestration` composes existing task skills into bounded worker assignments only when real worker execution exists and delegation is explicit or provides concrete structural benefit; it does not copy their contracts or expand their authority. A sufficiently clear implementation belongs to `jhste-coding`; only an important uncertainty about what to build that needs runnable evidence belongs to `jhste-prototype`; an unexplained failure in existing behavior belongs to `jhste-diagnosing-bugs`; and a user-owned policy decision belongs to `jhste-grill`. Once a prototype direction is selected, `jhste-coding` implements it for production and `jhste-to-spec` records it only when a specification is requested.
 
 ## Behavioral boundaries
 
 - `jhste-coding` applies to sufficiently understood code changes and ordinary continuation from an existing handoff or partial implementation. Executable experiments that test an important design assumption before production belong to `jhste-prototype`.
 - `jhste-prototype` answers one concrete question about a state model, business rule, data shape, API surface, interaction flow, or UI structure with disposable runnable evidence. It does not take over ordinary implementation, diagnosis of an existing failure, static mockups, open-ended ideation, or production-ready delivery.
+- `jhste-subagent-orchestration` applies whenever the user explicitly requests subagents, delegation, multi-worker execution, or a separate-agent acceptance pass. Implicit use requires decision-complete, independently verifiable work whose consequential judgment remains with the head. It does not take over ordinary linear coding, diagnosis, prototyping, handoff authoring, finalization, PR review, or domain meanings such as Kubernetes orchestration. The harness owns worker limits and actual permission or isolation enforcement.
 - `jhste-diagnosing-bugs` applies when an observed failure needs a reproduction signal, competing hypotheses, instrumentation, or measurement. Testing a design that has not been built yet belongs to `jhste-prototype`.
 - `jhste-grill` applies when the user wants an interview or decision stress test. It does not let a prototype guess a user-owned choice; once a decision is settled, representability or ergonomics that need executable evidence can move to `jhste-prototype`.
 - `jhste-domain-modeling` owns focused domain-language clarification and the corresponding glossary and qualifying ADR updates, not incidental code naming or generic architecture discussion.
 - `jhste-to-spec` defines settled behavior, contracts, validation, and scope. It does not freeze a guess into a specification when an unresolved design assumption should first be tested.
 - `jhste-to-tickets` drafts or publishes a GitHub issue graph. It does not duplicate local handoff state across issue bodies.
 - `jhste-handoff` runs only when the user asks to create, update, refresh, or phase a handoff document. It does not own implementation merely because an existing handoff must be read.
-- `jhste-implementation-finalizer` applies to production implementation explicitly submitted for independent audit, verification, correction, or final completion. It does not promote disposable prototype code; a selected direction is implemented properly with `jhste-coding`.
+- `jhste-implementation-finalizer` applies to production implementation explicitly submitted for independent audit, verification, correction, or final completion. It does not promote disposable prototype code or serve as a read-only acceptance worker; a selected direction is implemented properly with `jhste-coding`.
 - `jhste-pr-review` applies only to an explicit review-only request and does not modify the branch.
 - `jhste-review-followup` applies only when existing PR feedback defines the scope. It is not the general completion workflow for a worker result or partially implemented branch.
 
-This package does not include a mandatory TDD workflow, Wayfinder, a generic delivery orchestrator, or a separate architecture-audit skill. Existing skills and available implementation mechanisms can be composed without adding a routing layer until repeated real failures justify its context and maintenance cost.
+This package does not include a mandatory TDD workflow, Wayfinder, or a separate architecture-audit skill. Orchestration is narrowly limited to real worker coordination and does not replace ordinary single-agent delivery.
 
 ## Install user-wide from npm
 
-This package has no CLI. It distributes the eleven skills and their Codex metadata.
+This package has no CLI. It distributes the twelve skills and their Codex metadata.
 
 ```sh
 npm install -g jhste-skills
@@ -55,7 +57,7 @@ mkdir -p "$HOME/.agents/skills"
 cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-If another agent expects a different global skills directory, copy the eleven directories under `skills/` there. This package does not require project-local skill copies.
+If another agent expects a different global skills directory, copy the twelve directories under `skills/` there. This package does not require project-local skill copies.
 
 ## Development and validation
 
@@ -64,6 +66,6 @@ npm test
 npm pack --dry-run
 ```
 
-`npm test` checks package, metadata, and documentation consistency plus 78 static routing scenarios across nine covered skills. The fixture does not invoke a model or measure live automatic-trigger accuracy.
+`npm test` checks package, metadata, and documentation consistency plus 88 static routing scenarios across ten covered skills. The fixture does not invoke a model or measure live automatic-trigger accuracy.
 
 External sources and license attribution are recorded in [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md). When a change containing a new package version is merged to `main`, or a `v*.*.*` release tag is pushed, GitHub Actions runs release checks and publishes the version through npm trusted publishing if it is not already present.

package/README.md

@@ -8,6 +8,7 @@ GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용
 
 - **[`jhste-coding`](skills/jhste-coding/SKILL.md)** — 충분히 이해된 기능, 버그 수정, 리팩터링과 handoff의 정확한 재개 지점부터 이어지는 일반 구현을 작은 변경과 관련 검증으로 수행합니다.
 - **[`jhste-prototype`](skills/jhste-prototype/SKILL.md)** — production 구현 전에 하나의 중요한 설계 질문을 가장 작은 폐기 가능한 실행 증거로 검증합니다.
+- **[`jhste-subagent-orchestration`](skills/jhste-subagent-orchestration/SKILL.md)** — 명시적 서브에이전트 요청이나 구조적 이익이 분명한 작업에서, 결정권을 가진 헤드 아래 bounded investigation, implementation, acceptance 워커를 조정합니다.
 - **[`jhste-diagnosing-bugs`](skills/jhste-diagnosing-bugs/SKILL.md)** — 원인이나 올바른 수정이 불확실한 어려운 버그와 성능 저하를 재현, 가설, 측정으로 진단합니다.
 - **[`jhste-grill`](skills/jhste-grill/SKILL.md)** — 중요한 결정 분기를 한 번에 한 질문씩 해소하면서 확정된 도메인 문맥과 ADR을 계속 갱신합니다.
 - **[`jhste-domain-modeling`](skills/jhste-domain-modeling/SKILL.md)** — 도메인 용어, 경계, 관계를 명확히 하고 확정된 glossary 항목과 필요한 ADR을 바로 기록합니다.
@@ -18,27 +19,28 @@ GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용
 - **[`jhste-pr-review`](skills/jhste-pr-review/SKILL.md)** — 명시적으로 요청된 PR을 실제 diff 기준으로 검토하고 신뢰도 높은 실행 가능한 지적만 게시합니다.
 - **[`jhste-review-followup`](skills/jhste-review-followup/SKILL.md)** — 기존 PR 피드백을 검증하고 정당한 수정만 기존 PR 브랜치에 반영합니다.
 
-스킬은 서로를 의무적으로 호출하지 않으며, `jhste-prototype`도 모든 코딩의 필수 선행 단계가 아닙니다. 구현 경로가 충분히 명확하면 `jhste-coding`, 무엇을 만들지에 대한 중요한 설계 불확실성이 실행 가능한 증거를 필요로 할 때만 `jhste-prototype`, 이미 존재하는 동작의 원인이 불명확하면 `jhste-diagnosing-bugs`, 사용자 소유 정책 결정이 남아 있으면 `jhste-grill`이 담당합니다. 프로토타입에서 방향이 선택되면 `jhste-coding`으로 production 구현하고, 명세가 필요할 때만 `jhste-to-spec`으로 기록합니다.
+대부분의 스킬은 서로를 의무적으로 호출하지 않습니다. `jhste-subagent-orchestration`은 실제 워커 실행 수단이 있고 명시적 위임 요청이나 구체적인 구조적 이익이 있을 때 기존 task skill을 bounded assignment에 조합하지만, 그 스킬의 계약을 복제하거나 권한을 확장하지 않습니다. 구현 경로가 충분히 명확하면 `jhste-coding`, 무엇을 만들지에 대한 중요한 설계 불확실성이 실행 가능한 증거를 필요로 할 때만 `jhste-prototype`, 이미 존재하는 동작의 원인이 불명확하면 `jhste-diagnosing-bugs`, 사용자 소유 정책 결정이 남아 있으면 `jhste-grill`이 담당합니다. 프로토타입에서 방향이 선택되면 `jhste-coding`으로 production 구현하고, 명세가 필요할 때만 `jhste-to-spec`으로 기록합니다.
 
 ## 동작 경계
 
 - `jhste-coding`은 구현 경로가 충분히 명확한 코드 변경과 기존 handoff 또는 부분 구현의 일반적인 이어서 하기를 담당합니다. production 전 실행 실험으로 중요한 설계 가정을 검증하는 작업은 `jhste-prototype`에 속합니다.
 - `jhste-prototype`은 state model, business rule, data shape, API surface, interaction flow, UI structure에 관한 하나의 구체적 질문을 폐기 가능한 실행 증거로 답합니다. 일반 구현, 기존 장애 원인 진단, 정적 mockup, 열린 아이디어 탐색, production-ready 전달을 가로채지 않습니다.
+- `jhste-subagent-orchestration`은 서브에이전트, 위임, multi-worker 실행, 별도-agent acceptance가 명시적으로 요청되면 선택됩니다. 암묵적으로는 assignment가 decision-complete하고 독립 검증 가능하며, 중요한 판단이 헤드에 남는 경우에만 사용합니다. 일반적인 선형 코딩·진단·프로토타이핑·handoff 작성·finalization·PR review 또는 Kubernetes 같은 도메인 의미의 orchestration은 가로채지 않습니다. 워커 수와 실제 권한·격리는 하네스가 관리합니다.
 - `jhste-diagnosing-bugs`는 이미 관찰된 실패에 재현 신호, 경쟁 가설, 계측, 측정이 필요할 때 담당합니다. 아직 만들지 않은 설계를 시험하는 작업은 `jhste-prototype`입니다.
 - `jhste-grill`은 사용자가 인터뷰나 의사결정 검증을 원할 때만 동작합니다. 사용자 소유 결정이 먼저 필요하면 프로토타입으로 추측하지 않고 인터뷰하며, 결정된 가정의 representability나 ergonomics가 실행 증거를 필요로 하면 `jhste-prototype`으로 넘깁니다.
 - `jhste-domain-modeling`은 도메인 언어와 개념 경계를 담당하며, 단순 변수명 변경이나 일반적인 아키텍처 설명을 가로채지 않습니다.
 - `jhste-to-spec`은 확정된 동작, 계약, 검증, 범위를 정의합니다. 해결되지 않은 설계 가정을 실행해 보는 대신 명세에 추측을 고정하지 않습니다.
 - `jhste-to-tickets`는 GitHub issue graph를 초안 작성하거나 게시합니다. 로컬 handoff 상태를 여러 issue 본문에 중복하지 않습니다.
 - `jhste-handoff`는 handoff 문서를 새로 만들거나 갱신하고, 재개 가능한 단계로 나누는 명시적 요청에서만 동작합니다. 기존 handoff를 읽고 구현을 계속하는 작업 자체는 담당하지 않습니다.
-- `jhste-implementation-finalizer`는 완료 주장, 독립 검증, 최종 감사·수정 의도가 명시된 production 구현을 담당합니다. 폐기 가능한 프로토타입을 production 코드로 승격하는 수단이 아니며, 선택된 방향은 `jhste-coding`으로 다시 구현합니다.
+- `jhste-implementation-finalizer`는 완료 주장, 독립 검증, 최종 감사·수정 의도가 명시된 production 구현을 담당합니다. 폐기 가능한 프로토타입을 production 코드로 승격하거나 읽기 전용 acceptance를 수행하는 수단이 아니며, 선택된 방향은 `jhste-coding`으로 다시 구현합니다.
 - `jhste-pr-review`는 검토 전용 요청에만 적용되며 브랜치를 수정하지 않습니다.
 - `jhste-review-followup`은 이미 존재하는 PR 피드백이 범위를 정의할 때만 적용됩니다. 일반적인 작업자 결과 마무리 용도가 아닙니다.
 
-이 패키지는 의무적인 TDD workflow, Wayfinder, 범용 delivery orchestrator, 별도 architecture-audit 스킬을 포함하지 않습니다. 현재 스킬과 사용 가능한 구현 수단만으로 조합할 수 있으며, 반복되는 실제 실패가 확인되기 전에는 라우팅 계층을 추가해 문맥과 유지보수 비용을 늘리지 않습니다.
+이 패키지는 의무적인 TDD workflow, Wayfinder, 별도 architecture-audit 스킬을 포함하지 않습니다. 오케스트레이션은 실제 워커 조정에만 좁게 적용되며 일반적인 단일-agent delivery workflow를 대체하지 않습니다.
 
 ## npm에서 사용자 전역 설치
 
-이 패키지는 CLI를 제공하지 않습니다. 열한 개 스킬과 Codex metadata를 배포합니다.
+이 패키지는 CLI를 제공하지 않습니다. 열두 개 스킬과 Codex metadata를 배포합니다.
 
 ```sh
 npm install -g jhste-skills
@@ -55,7 +57,7 @@ mkdir -p "$HOME/.agents/skills"
 cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-다른 agent가 다른 전역 skills 디렉터리를 사용하면 `skills/` 아래 열한 개 디렉터리를 그 위치에 복사하세요. 프로젝트별 복사본은 필수가 아닙니다.
+다른 agent가 다른 전역 skills 디렉터리를 사용하면 `skills/` 아래 열두 개 디렉터리를 그 위치에 복사하세요. 프로젝트별 복사본은 필수가 아닙니다.
 
 ## 개발 및 검증
 
@@ -64,6 +66,6 @@ npm test
 npm pack --dry-run
 ```
 
-`npm test`는 패키지, metadata, 문서 일관성과 아홉 스킬을 다루는 정적 라우팅 시나리오 78개를 검사합니다. 이 fixture는 모델을 실제 호출하거나 자동 trigger 정확도를 측정하지 않습니다.
+`npm test`는 패키지, metadata, 문서 일관성과 열 개 스킬을 다루는 정적 라우팅 시나리오 88개를 검사합니다. 이 fixture는 모델을 실제 호출하거나 자동 trigger 정확도를 측정하지 않습니다.
 
 외부 출처와 라이선스 표기는 [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md)에 기록합니다. 새 package version을 포함한 변경이 `main`에 병합되거나 `v*.*.*` release tag가 push되면 GitHub Actions 검증 후 아직 게시되지 않은 버전을 npm trusted publishing으로 배포합니다.

package/THIRD_PARTY_NOTICES.md

@@ -46,3 +46,43 @@ 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.
+
+## 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.

package/package.json

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

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

@@ -0,0 +1,93 @@
+---
+name: jhste-subagent-orchestration
+description: Coordinate low-retention worker agents under a decision-owning head through bounded investigation, implementation, or acceptance assignments, isolated mutation leases, and head-verified evidence. Use whenever the user explicitly asks ChatGPT to delegate to subagents or workers, fan out work across agents, run multi-agent execution, or obtain a separate-agent acceptance pass. Invoke implicitly only when real worker execution exists and decision-complete, independently verifiable workstreams or a genuinely independent check provide concrete structural benefit. Do not invoke implicitly for ordinary coding, diagnosis, prototyping, handoff authoring, implementation finalization, PR review, large-but-linear work, unresolved user decisions, or domain uses of orchestration unrelated to ChatGPT workers. Compose task skills without replacing their contracts.
+---
+
+# JHSTE Subagent Orchestration
+
+## Goal
+
+Coordinate bounded workers while the head retains canonical state, consequential judgment, ownership, integration, and final verification.
+
+Treat each worker as a low-retention leaf with one stage and one outcome. Use workers to widen evidence or execute separable work, not to outsource decisions the head must own.
+
+## Establish runtime and authority
+
+Confirm that a real worker mechanism is available. An explicit delegation request selects this skill even when the mechanism is unavailable; report the limitation instead of simulating workers or inventing results.
+
+Treat harness controls as authoritative for concurrency and actual permissions. Do not set a worker-count limit in this skill. Treat mutation ownership as a head-maintained lease, not a runtime lock, unless the harness provides real isolation.
+
+Keep these responsibilities in the head:
+
+- Spawn, assign, interrupt, replace, and retire workers.
+- Resolve consequential product, scope, security, data, compatibility, and architecture decisions.
+- Maintain canonical state, dependencies, mutation leases, and live-activity ownership.
+- Verify evidence, choose dispositions, integrate results, and decide completion.
+
+Use a star topology. Workers report only to the head and must not spawn, delegate, hand off to one another, or invoke this orchestration skill.
+
+## Decide what to delegate
+
+For implicit invocation, delegate only when the assignment is:
+
+- **Decision-complete:** the packet can state the outcome, settled facts, and decision boundary without asking the worker to invent policy.
+- **Independently verifiable:** the head can check the return through code, a diff, tests, measurements, artifacts, or external state.
+- **Judgment-bounded:** consequential selection and integration remain with the head.
+
+Complexity alone is not a reason to delegate. Keep large-but-linear work in the owning task skill when workers would add only coordination cost. Dispatch within harness capacity and use the smallest set of independently ownable assignments that creates a concrete benefit.
+
+## Separate stage from task skill
+
+Assign exactly one stage independently of the skill used to perform it:
+
+- `investigation`: gather evidence without changing production behavior. Explicitly authorized disposable prototype artifacts may support the investigation.
+- `implementation`: execute a settled decision within a fixed mutation and external-write boundary.
+- `acceptance`: independently inspect and verify; keep it read-only by default.
+
+Name one primary task skill when a matching installed skill materially improves execution. Supporting skills are optional. The assignment narrows every invoked skill and no skill may expand mutation, delegation, decision, or external-write authority.
+
+Use `jhste-diagnosing-bugs` for uncertain root-cause investigation and `jhste-coding` for defined implementation. Use `jhste-prototype` only for a bounded executable experiment, normally inside investigation with explicit artifact authority. Use `jhste-pr-review` only for an identifiable PR review. Do not use `jhste-implementation-finalizer` as a read-only acceptance worker; it belongs to implementation/finalization work that is authorized to correct gaps. Resolve user-owned decisions in the head, using `jhste-grill` before dispatch when needed.
+
+Keep investigation, implementation, and acceptance workers separate. Verify investigation evidence before selecting an implementation. After a material correction, use a fresh acceptance worker when the reviewed surface changed enough to invalidate the prior pass.
+
+## Maintain canonical state
+
+Keep one compact ledger of the objective, user authority, settled decisions, repository state, assignment graph, mutation leases, live activity, evidence, verification, dispositions, and next-wave gates.
+
+Treat every worker return as an unverified claim. Check the relevant source, diff, test output, artifact, or external state before changing canonical state. Record each needed return as `accepted`, `rejected`, `merged`, or `superseded` with a short rationale before opening the next dependent wave.
+
+When verification evidence can become stale, record the source state it covered, such as the workspace, commit, tree state, or task-owned diff. Re-run affected checks after later integration changes invalidate that basis.
+
+Read [references/control-state.md](references/control-state.md) for mutation leases, lifecycle, wave triage, background work, recovery, and completion.
+
+## Dispatch self-contained assignments
+
+Write every assignment in English as a standalone contract. Include verified context and settled decisions rather than forwarding conversation history. State exact paths, symbols, resources, and expected observations when known.
+
+Dispatch only when the packet defines:
+
+- One stage, one outcome, and a fixed starting state.
+- The worker's decision boundary and unresolved matters it must return.
+- Read, mutation, and external-write authority, including an exclusive mutation lease where applicable.
+- Deterministic done criteria, verification, and hard-stop conditions.
+- A compact evidence-based report and any live-activity transfer requirement.
+
+Do not dispatch an assignment that requires rediscovering requirements, choosing among consequential alternatives, inferring permission, or coordinating with another worker.
+
+Read [references/worker-contract.md](references/worker-contract.md) before the first dispatch, a clarification response, or report evaluation.
+
+## Operate in verified waves
+
+Dispatch the current independent wave within harness capacity, then synthesize its required returns before opening a dependent wave. Prefer safe completion notifications over continuous polling for long-running commands or remote jobs.
+
+A worker may enter `waiting_for_head` only for an essential clarification and only when the harness can resume that worker. Reply with a self-contained amendment. If resumption is unavailable, or the outcome, stage, ownership domain, external authority, or consequential decision changes, terminate the assignment and send a fresh contract to a new worker.
+
+Do not resume a terminal worker. Give replacements canonical state, not the prior worker conversation. When independent replacements repeatedly fail the same unchanged packet, treat the packet as defective: recheck its context, decision boundary, ownership, and verification oracle, then rewrite, narrow, or reclaim it instead of spawning another copy.
+
+Do not release or reassign a mutation lease while its worker owns live activity. Require the worker to stop it or transfer a stable identifier, notification path, intervention limit, termination method, and verification requirement to the head.
+
+## Complete in the head
+
+Finish only when material requirements have verified status, required returns have dispositions, the integrated result and relevant checks are current, no worker mutation lease remains, every live activity is completed, terminated, or explicitly owned by the head, and authorized external state matches the intended target.
+
+Report the verified outcome, checks performed, material limitations, and remaining risks. Never substitute a worker completion claim for head verification.

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

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Subagent Orchestration"
+  short_description: "Coordinate bounded workers under head-owned decisions"
+  default_prompt: "Use $jhste-subagent-orchestration to coordinate bounded worker assignments under head-owned decisions, isolated mutation leases, and head verification."
+
+policy:
+  allow_implicit_invocation: true

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

@@ -0,0 +1,67 @@
+# Head Control State
+
+Use this reference for dependent assignments, mutation leases, live background activity, replacement workers, or multiple waves.
+
+## Compact ledger
+
+```text
+Mission
+- Objective, user authority, forbidden actions
+- Settled decisions and unresolved head decisions
+
+Repository
+- Repository, workspace, base, branch, starting commit
+- Known unrelated changes
+
+Assignments
+- ID, stage, primary skill, dependencies
+- State: planned | active | waiting_for_head | completed | blocked | failed | discarded
+- Verification: unverified | verified
+- Disposition: pending | accepted | rejected | merged | superseded
+- Disposition rationale
+
+Mutation leases
+- 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 leases
+```
+
+Track only state that prevents conflicting work, stale evidence, or false completion.
+
+## Lifecycle and dispositions
+
+```text
+planned -> active <-> waiting_for_head
+active -> completed | blocked | failed -> discarded
+```
+
+Use `waiting_for_head` only when the same worker can resume safely. Never return a terminal worker to `active`.
+
+Keep lifecycle, verification, and disposition separate. `completed` is a worker claim. Verify it through direct head inspection, then record each required return as accepted, rejected, merged, or superseded before dependent work proceeds.
+
+## Leases and live activity
+
+A mutation lease is the head's logical reservation, not proof of a runtime lock. The harness controls actual isolation and permissions. Do not overlap leases 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 a lease.
+
+## Waves and evidence freshness
+
+Dispatch independent work within harness capacity and triage required returns before opening a dependent wave.
+
+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 a fresh acceptance worker after a material correction, not merely to accumulate agreement.
+
+## Recovery
+
+Classify failure as infrastructure, stale precondition, contract gap, implementation defect, ownership conflict, unauthorized action, or unusable evidence. Give replacements a fresh packet from canonical state.
+
+When independent replacements 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 lease 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

@@ -0,0 +1,97 @@
+# Worker Contract Protocol
+
+Use this reference to create a self-contained assignment, handle one clarification, and evaluate the return. Omit fields that do not affect execution.
+
+## Assignment template
+
+```markdown
+# Worker Assignment
+## Identity
+- Assignment ID:
+- Stage: investigation | implementation | acceptance
+- Primary task skill: optional
+- Supporting skills: optional
+- Repository, workspace, and starting state:
+## Single outcome
+State the one result this worker must produce.
+## Context and decisions
+List only verified facts, settled decisions, paths, symbols, and identifiers needed here.
+## Decision boundary
+- Worker may decide:
+- Worker must return unresolved:
+## Scope and authority
+- Read scope:
+- Mutation lease: none | exact files, workspace, host, or resource
+- Allowed external writes: none | exact targets and actions
+- Forbidden scope:
+Execution authority: Perform this assignment directly. Do not spawn, delegate, hand off, coordinate with another worker, or invoke `jhste-subagent-orchestration`.
+Authority ceiling: This assignment may narrow any invoked skill. No skill grants additional decision, mutation, delegation, destructive-action, or external-write authority.
+## Procedure, hard stops, and completion
+- Ordered steps, only where sequence matters:
+- Stop conditions:
+- Done criteria:
+- Required verification and expected result:
+- Evidence basis to record, when staleness matters:
+## Required report
+Return the compact report below without routine progress narration.
+```
+
+Allow read-only inspection inside the stated scope unless forbidden. Enumerate mutation, destructive actions, and external writes rather than every harmless read command.
+
+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 and amendment
+
+Use `waiting_for_head` only when the harness can resume the same worker safely.
+
+```markdown
+# Clarification Request
+- Assignment ID:
+- Verified fact or mismatch:
+- Decision or information required:
+- Current live activity and held lease:
+```
+
+Reply without references to prior conversation:
+
+```markdown
+# Assignment Amendment
+- Assignment ID:
+- Changed fact or decision:
+- Scope and authority impact:
+- Hard-stop impact:
+- Verification impact:
+- Everything else remains unchanged: yes | no
+```
+
+Replace the assignment when the outcome, stage, ownership domain, external authority, or consequential decision changes.
+
+## Report template
+
+```markdown
+# Worker Report
+## Status
+completed | blocked | failed
+## Result and evidence
+State the result first, then cite relevant paths, lines, diff, measurements, artifacts, logs, or external state.
+## Changed resources
+List every modified path or external resource, or `None`.
+## Verification
+- Command or inspection:
+- Observed result and exit status:
+- Evidence basis: workspace, commit, tree state, or task-owned diff when relevant
+## Deviation or blocker
+State any deviation, unmet criterion, or unresolved item, or `None`.
+## Live activity and lease
+- Active commands or jobs, stable identifiers, and notification path:
+- Locks or resources still held:
+- Safe for the head to release or reassign the lease: 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 choose the final consequential decision or change production behavior. Create disposable artifacts only when explicitly authorized.
+- **Implementation:** apply the selected solution inside the lease, preserve named contracts, and stop on a material mismatch. Do not rediscover product requirements or invent recovery policy.
+- **Acceptance:** inspect the complete task-owned change and relevant integration surface. Return evidence-backed findings and a verdict without editing; corrections require a new implementation assignment.