From 1a27fdb6d0c7425a830344b0f5ac79f27956973d 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 | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/SKILL.md b/SKILL.md index e34eec5..abcc363 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,7 +1,7 @@ --- name: corp-v1-channel-releases description: "Use when operating or synchronizing a Corp v1 project's releases channel. Assesses release readiness and, only when the team requests a release, updates the Gondor v1 template source, renders it, pushes a separate branch to Gondor v1, and opens a pull request requiring team approval before deployment." -version: 1.0.0 +version: 1.1.0 author: Hermes Agent license: MIT metadata: @@ -44,6 +44,10 @@ Use this skill when: Do not start a release merely because CI is green or a synchronization run detected changes. +## Proactive Iteration Requirement + +Every releases iteration must add or materially improve at least one useful, safe release artifact in project documentation: readiness evidence, version/changelog accuracy, release dependency mapping, migration or rollback guidance, deployment verification criteria, post-release follow-up, or a concrete approval/blocker record. Never create filler and never start release execution without an explicit human team request. + ## Approved Information Boundary Inspect only: @@ -154,10 +158,10 @@ Never claim deployment from a merged PR alone. 1. Read new same-project activity and enough release history to avoid duplicates. 2. Identify readiness changes, version/changelog drift, deployment evidence, migration/rollback risk, and release requests. -3. Without an explicit release request, maintain readiness information and proposals only. +3. Without an explicit release request, proactively improve readiness documentation, version/changelog evidence, rollback planning, or a concrete blocker/approval request only. 4. With an explicit request, execute the controlled workflow through PR creation. 5. Verify every repository, branch, commit, render, check, and PR claim. -6. Post a concise release update; otherwise remain silent. +6. Post a concise release update with documentation and verification evidence, or the concrete gate that prevented useful work. ## Authority and Escalation @@ -190,6 +194,7 @@ Requires separate approval for: 7. Claiming deployment from PR or commit state alone. 8. Exposing secret values while validating configuration. 9. Inspecting another project's channels. +10. Remaining passive when readiness, versioning, rollback, or release documentation can be safely improved. ## Verification Checklist @@ -203,3 +208,4 @@ Requires separate approval for: - [ ] PR head/base SHAs, checks, and URL were verified. - [ ] The PR clearly requires team approval before deployment. - [ ] No merge or deployment occurred without separate authorization. +- [ ] At least one useful release artifact was improved, or a concrete human-request/approval blocker was documented.