feat: enforce proactive feature lifecycle

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.