home-v1-skills-code-agent/corp-v1-channel-releases
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: enforce proactive feature lifecycle

Browse Source
This commit is contained in:
jarvis-at-skic
2026-08-13 13:33:59 +00:00
parent da28426411
commit 1a27fdb6d0
1 changed files with 9 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+9 -3
View File
@@ -1,7 +1,7 @@
--- ---
name: corp-v1-channel-releases 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." 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 author: Hermes Agent
license: MIT license: MIT
metadata: 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. 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 ## Approved Information Boundary
Inspect only: 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. 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. 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. 4. With an explicit request, execute the controlled workflow through PR creation.
5. Verify every repository, branch, commit, render, check, and PR claim. 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 ## Authority and Escalation
@@ -190,6 +194,7 @@ Requires separate approval for:
7. Claiming deployment from PR or commit state alone. 7. Claiming deployment from PR or commit state alone.
8. Exposing secret values while validating configuration. 8. Exposing secret values while validating configuration.
9. Inspecting another project's channels. 9. Inspecting another project's channels.
10. Remaining passive when readiness, versioning, rollback, or release documentation can be safely improved.
## Verification Checklist ## Verification Checklist
@@ -203,3 +208,4 @@ Requires separate approval for:
- [ ] PR head/base SHAs, checks, and URL were verified. - [ ] PR head/base SHAs, checks, and URL were verified.
- [ ] The PR clearly requires team approval before deployment. - [ ] The PR clearly requires team approval before deployment.
- [ ] No merge or deployment occurred without separate authorization. - [ ] 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.