diff --git a/SKILL.md b/SKILL.md index 81092c4..5d1963a 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,7 +1,7 @@ --- name: corp-v1-channel-delivery description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation." -version: 1.8.0 +version: 1.9.0 author: Hermes Agent license: MIT metadata: @@ -30,13 +30,15 @@ Tasks: IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE ``` +`READY_FOR_DELIVERY` is the exact Task's Focus-admitted, pickup-ready state. It means Architecture, dependencies, implementation boundaries, verification steps, and Kanban selection are complete; implementation has not started. Delivery claims that Task by moving it directly to `IN_PROGRESS`. Never require or invent a second Focus-admission decision after `READY_FOR_DELIVERY`. + `CANCELLED` is an exceptional terminal status. `BLOCKED` is a separate flag with a reason and evidence; it never replaces the lifecycle status. Never invent, abbreviate, or substitute lifecycle values such as `Ready`, `Active`, `Delivered`, `Complete`, `Awaiting CI`, or `Overrun`. Those phrases may describe activity only when clearly separated from the canonical status field. If the canonical status cannot be verified, report `status unverified` and inspect the source record rather than guessing. A merge or successful CI does not automatically mean `DONE`. Releasable application Tasks normally move from `IN_PROGRESS` to `TO_BE_RELEASED`; `DONE` requires the applicable release or completion evidence. Status reports must show the exact canonical value even when a separate plain-language action is also included. -This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and which a human team member separately admitted to Kanban Focus `InBacklog`. +This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and whose exact Task status is `READY_FOR_DELIVERY`. That status is the Focus-admitted pickup handoff; no separate post-status admission gate exists. Its scope includes coding, unit testing, builds, continuous integration, review readiness, delivery blockers, and maintenance of the project documentation's `Ways of Working` and `Engineering` areas. @@ -79,13 +81,13 @@ Before starting or continuing Feature implementation, verify in project document - task breakdown and dependencies; - target version and status; - acceptance evidence expected from delivery. -- explicit human Kanban approval admitting the exact task to Focus `InBacklog`. +- exact Task `READY_FOR_DELIVERY` evidence, which itself records human Kanban Focus admission. -Hermes cannot approve a Feature for implementation or admit a task to Focus `InBacklog`. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code. +Hermes cannot approve a Feature for implementation or move a Task to `READY_FOR_DELIVERY`. Once that exact state exists, Hermes must not require a second Focus-admission decision; Delivery claims the Task by moving it to `IN_PROGRESS`. ## Proactive Iteration Requirement -Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from Kanban Focus `InBacklog`, backed by architecture's approved task/dependency plan, and update progress in project documentation. +Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current. ## Approved Information Boundary @@ -212,7 +214,7 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package ## Synchronization Workflow 1. Read new same-project activity and enough delivery history to avoid duplicates. -2. Verify human `Approved for Implementation` evidence, explicit human Kanban Focus `InBacklog` admission, task dependencies, and target version before task work. +2. Verify human `Approved for Implementation` evidence, exact Task `READY_FOR_DELIVERY` state, task dependencies, and target version before task work. 3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift. 4. Load all applicable project engineering skills. 5. Complete at least one useful safe activity when an authorized path exists; otherwise document and route the exact blocker. @@ -262,7 +264,7 @@ Include repository, branch, commit SHA, changed paths, commands, local results, - [ ] Only same-project channels and repositories were used. - [ ] Work maps to approved requirements/architecture. - [ ] Feature has explicit human `Approved for Implementation` evidence and a documented target version. -- [ ] Selected tasks respect documented dependencies and have explicit human Focus `InBacklog` admission. +- [ ] Selected tasks respect documented dependencies and carry exact Task `READY_FOR_DELIVERY` evidence. - [ ] At least one useful delivery activity was completed, or a concrete blocker was documented and routed. - [ ] Applicable project skills were loaded. - [ ] Tests and builds were actually run.