From 84f2e5cde81b441802db6289a77888a0ad8d70ab Mon Sep 17 00:00:00 2001 From: Jarvis Jr Hermes Date: Thu, 13 Aug 2026 13:33:59 +0000 Subject: [PATCH] feat: enforce proactive feature lifecycle --- SKILL.md | 44 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 34 insertions(+), 10 deletions(-) diff --git a/SKILL.md b/SKILL.md index 6e366d1..d49343c 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.0.0 +version: 1.1.0 author: Hermes Agent license: MIT metadata: @@ -14,7 +14,7 @@ metadata: ## Overview -This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels and turns approved requirements and architecture into implemented, tested, integrated, documented work. +This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels and implements only Features that architecture documentation marks `Approved for Implementation` through an explicit human team-member decision. 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. @@ -32,6 +32,23 @@ Use this skill when: Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections. +## Implementation Entry Gate + +Before starting or continuing Feature implementation, verify in project documentation: + +- Feature ID and parent Epic; +- explicit human `Approved for Implementation` evidence; +- linked FRs/NFRs and accepted solution/ADR context; +- task breakdown and dependencies; +- target version and status; +- acceptance evidence expected from delivery. + +Hermes cannot approve a Feature for implementation. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code. + +## 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 from architecture's approved task/dependency plan and update progress in project documentation. + ## Approved Information Boundary Inspect only the project's four channels: @@ -49,7 +66,7 @@ Use enough delivery history to avoid duplicate work and only relevant new activi ### Coding -- implement only approved/authorized scope; +- implement only human-approved Features and their authorized tasks; - load applicable project engineering skills before changing code; - preserve project structure, conventions, and environment namespace; - keep changes small, reviewable, and traceable to requirements/issues; @@ -127,13 +144,14 @@ Update these pages from verified project practice. Do not document a planned pro ## Synchronization Workflow 1. Read new same-project activity and enough delivery history to avoid duplicates. -2. Identify executable work, CI failures, blockers, requirements/ADR implications, and documentation drift. -3. Load all applicable project engineering skills. -4. Perform safe authorized work when scope and expected outcome are clear. -5. Escalate uncertainty or contradiction rather than selecting direction. -6. Verify local and remote results. -7. Maintain Ways of Working and Engineering pages when durable practice changed. -8. Post a concise update with work completed, evidence, blockers, and required decisions; otherwise stay silent. +2. Verify human `Approved for Implementation` evidence, task dependencies, and target version before Feature 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. +6. Escalate uncertainty or contradiction rather than selecting direction. +7. Verify local and remote results and update task/Feature progress in project documentation. +8. Maintain Ways of Working and Engineering pages when durable practice changed. +9. Post a concise update with work completed, evidence, blockers, and required decisions. ## Authority and Escalation @@ -167,11 +185,17 @@ Include repository, branch, commit SHA, changed paths, commands, local results, 6. Updating documentation with aspirational rather than actual practice. 7. Repeatedly posting unchanged failure summaries. 8. Inspecting another project. +9. Starting implementation because requirements exist but human implementation approval is absent. +10. Ignoring architecture task dependencies or target-version allocation. +11. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available. ## Verification Checklist - [ ] 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. +- [ ] 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. - [ ] Remote branch and matching CI head SHA were verified.