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

feat: consume Kanban release readiness

Browse Source
This commit is contained in:
jarvis-at-skic
2026-08-13 16:50:52 +00:00
parent 1a27fdb6d0
commit 7393ea705c
1 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+5 -3
View File
@@ -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.1.0
version: 1.2.0
author: Hermes Agent
license: MIT
metadata:
@@ -14,7 +14,7 @@ metadata:
## Overview
This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels for release implications, but it starts release execution only after an explicit team request.
This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's `general`, `architecture`, `kanban`, `delivery`, and `releases` channels for release implications, but it starts release execution only after an explicit team request.
The release workflow updates the project-specific portion of:
@@ -55,11 +55,12 @@ Inspect only:
```text
corp-v1-<code>-general
corp-v1-<code>-architecture
corp-v1-<code>-kanban
corp-v1-<code>-delivery
corp-v1-<code>-releases
```
Use mapped-channel history to avoid duplicate work and new relevant activity from the other three channels. Never inspect another project's channels.
Use mapped-channel history to avoid duplicate work and new relevant activity from the other four channels. Never inspect another project's channels.
## Release Readiness
@@ -68,6 +69,7 @@ Before proposing or executing a release, verify:
- explicit team release request and intended scope;
- target project, environment, version, image/artifact references, and source commit;
- approved requirements and architecture implications;
- Kanban `ToBeReleased` evidence for included Epic/Feature/task scope;
- required tests, builds, CI, security/quality gates, and artifacts;
- changelog/release notes accuracy;
- configuration and secret **names/references** without accessing secret values;