channel-releases-skic/SKILL.md

name, description, version, author, license, metadata

name	description	version	author	license	metadata
channel-releases-skic	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.	1.7.1	Hermes Agent	MIT	hermes tags related_skills corp-v1 discord channel releases gondor-v1 gitops pull-request channel-board-skic home-v1-discord gondor-v1-nodes documentation-docusaurus corp-v1-glossary

SKIC Releases Channel Reference

Overview

Hermes Kanban direct-link contract

Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form [descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>). Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.

This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's general, scope, architecture, ui-ux, kanban, delivery, uat, and releases channels for release implications, but it starts release execution only after an explicit team request.

Load the global documentation-docusaurus skill from https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.

The release workflow updates the project-specific portion of:

https://gitea.lego-cloud.eu/home-v1/gondor-v1-tmpl

It then runs the repository's authoritative rendering process and pushes the rendered change to a separate branch in:

https://gitea.lego-cloud.eu/home-v1/gondor-v1

The skill opens a pull request for team review. Deployment must not proceed until the team approves the pull request and all required gates pass.

Load the global corp-v1-glossary skill from https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level Glossary area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.

Shared Corp v1 System Login

When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in channel-board-skic and use only the Bitwarden-injected runtime secrets named:

HL_V1_SSO_EMAIL
HL_V1_SSO_PASSWORD

Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.

When to Use

Use this skill when:

• operating in <code>-releases;
• running its recurring synchronization job;
• assessing release readiness;
• preparing version/changelog/deployment evidence;
• the team explicitly asks to release the project;
• updating Gondor v1 template/rendered configuration through a reviewable PR;
• tracking migration, rollback, deployment, and post-release outcomes.

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:

<code>-general
<code>-scope
<code>-architecture
<code>-ui-ux
<code>-kanban
<code>-delivery
<code>-uat
<code>-releases

Use mapped-channel history to avoid duplicate work and new relevant activity from the other seven channels. Never inspect another project's channels.

Release Readiness

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;
• migrations, compatibility, dependencies, capacity, and operational risk;
• rollback strategy and previous known-good state;
• deployment verification and ownership plan;
• unresolved blockers and required approvals.

Readiness reporting does not itself authorize deployment.

Controlled Gondor v1 Release Workflow

Gate 1 — explicit request

Require an unambiguous request from the project team identifying the project and intended release, and satisfy the UAT promotion gate below. If version, environment, artifact, scope, or required UAT evidence is missing, prepare a readiness summary and route the missing decision or evidence rather than guessing.

Gate 2 — discover repositories and instructions

1. Load applicable Gitea and Gondor v1 skills.
2. Fetch both repositories and verify authenticated identity, remotes, default branches, clean worktrees, and divergence.
3. Inspect repository-native instructions, Taskfiles/scripts, schemas, and validation commands.
4. Identify the exact project-owned template subtree and generated destination.
5. Verify no unrelated project configuration will be modified.

Gate 3 — update template source

Make the smallest project-scoped change in home-v1/gondor-v1-tmpl. The template repository remains the source of truth; do not patch generated Gondor output manually as a substitute.

Validate template syntax, project values, artifact references, naming, and any repository-specific schema/checks. Keep secrets out of files, logs, commits, and chat.

Gate 4 — render

Run the repository's authoritative rendering command. Do not invent a renderer command. Compare generated output and confirm:

• only expected project files changed;
• output matches the requested release inputs;
• no unrelated generated content drifted;
• generated configuration passes repository validation.

If rendering changes unexpected projects/resources, stop and report the discrepancy.

Gate 5 — separate branch in Gondor v1

Create a dedicated, descriptive branch in home-v1/gondor-v1, for example:

release/corp-v1-<code>-<version>

Use the project's actual branching convention when defined. Commit only intended rendered artifacts, push the branch, and verify remote SHA equality and readback.

If the template repository itself also requires a reviewed source change, follow its repository policy and preserve traceability between source and rendered commits. Never force-push or bypass protected branches.

Gate 6 — pull request

Open a PR against the configured deployment branch with:

• project, environment, version, and requested scope;
• source application commit and artifact/image references;
• template source commit;
• rendered Gondor commit;
• changed resources;
• validation and CI evidence;
• migration and rollback notes;
• risks, blockers, and required reviewers;
• explicit statement: team approval required before deployment.

Read back the PR URL, number, head/base SHAs, state, checks, and review status.

Gate 7 — stop before deployment

Opening the PR completes autonomous release preparation. Do not merge, synchronize GitOps, or deploy unless the team separately approves that action and the applicable deployment workflow explicitly authorizes execution.

UAT promotion gate

For runtime releases, independently verify UAT_PASSED against the exact application commit, immutable image/chart identities, rendered non-production GitOps revision, controller revisions/sync/health, environment/base URL, E2E commit, and complete required journey set. Reject failed, blocked, stale, partial, or mismatched evidence and return it to UAT/Delivery. A release request does not waive UAT; a UAT pass does not authorize release. Non-runtime work may use only an explicitly justified, verified non-applicability record under the project release policy.

Promotion preserves the tested application/artifact identity but creates a distinct production desired-state revision. Record the mapping and verify production separately; the UAT environment's GitOps commit or healthy state is not production deployment evidence.

Post-Approval and Deployment Evidence

When separately authorized after approval:

• verify approval and required checks still apply to the exact head SHA;
• follow Gondor/GitOps deployment instructions;
• verify the owning controller's deployed revision, runtime source/chart identity, pod image digests, and endpoint against the approved production desired state; for app-of-apps, reconcile through the owning root rather than directly patching a managed child;
• verify release-specific acceptance through ordinary user-visible controls and meaningful runtime outcomes; forced interactions or hidden state/API bypasses are diagnostic only, and healthy infrastructure cannot excuse an unusable journey;
• record technical deployment health, automated acceptance, and human post-release acceptance separately; the latter remains PENDING until explicit confirmation, and a human-reported blocking defect makes it FAILED;
• post version, commit, PR, deployment, and rollback evidence;
• record post-release outcomes and unresolved follow-up.

Never claim deployment from a merged PR alone, or human acceptance from release authorization. If a deployed release fails a core journey, record it as rejected but still deployed until containment is verified. Preserve its immutable version, artifacts, and failure evidence; agree authorized rollback or maintenance with the release owner and route a new immutable corrective release through Delivery, UAT, and Releases. Do not silently retag or overwrite the rejected version. Unapproved containment remains an explicit risk, not an action this skill authorizes.

UI/UX Coordination

For frontend-affecting releases, Releases verifies the approved UI/UX acceptance evidence and records production design regressions or user-feedback deltas for the ui-ux channel. Release approval and deployment remain owned by Releases.

Synchronization Workflow

1. Read new activity from all eight mapped same-project channels 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, 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. Return a concise release update with evidence or the blocking gate. If the execution context auto-delivers the final response, do not post a duplicate message. Claim message delivery only with a verified receipt; repository readback is not message delivery evidence.

Authority and Escalation

May autonomously after explicit release request:

• assess readiness;
• update project-scoped template configuration;
• run rendering and validation;
• create commits and a separate branch;
• push the branch and open a PR;
• prepare release notes and rollback guidance.

Requires separate approval for:

• merging the release PR;
• deployment/GitOps synchronization;
• migrations with impact;
• rollback execution;
• changing secrets, permissions, costs, or unrelated infrastructure;
• destructive or irreversible operations.

Mined Project-Adoption Improvements

Review provenance and exclusions: AeroSim lessons review.

Dedicated Project Channel Workspace

Every project adoption must bind this channel to a dedicated local workspace under the active working root. Keep clones, worktrees, plans, reports, screenshots, generated artifacts, retained logs, and channel inputs inside that channel root. Use run-unique or task-specific children under workspace/; keep durable project truth in approved repositories. A local folder boundary organizes execution only—it neither broadens authority nor replaces remote evidence. Delivery adoptions should additionally use a channel-level cache/ for reusable pinned toolchains and dependencies, while keeping Task evidence isolated by Task.

Project-Adoption Release Lessons

Releases—not Delivery—owns the final TO_BE_RELEASED → DONE transition. Apply it only from canonical TO_BE_RELEASED, after the approved release/deployment is promoted and verified and the UAT promotion gate passes. Record the actual version, immutable artifact/digest where applicable, deployment revision, runtime health, acceptance evidence, actor/time, and append-only history linkage. The exit gate is remote documentation showing DONE after the release-specific checks pass; merged code, green integration CI, or a published image alone is insufficient.

Recurring readiness work must refresh mutable owner PR heads and the latest exact-head CI tasks, prevent self-stale references to the readiness PR's own head, guard against concurrent writers, replace stale open/pending wording after merges, and verify exact remote artifact bytes before reporting. Follow references/recurring-readiness-pr-refresh.md.

Common Pitfalls

1. Treating green CI as a release request.
2. Editing generated Gondor files without updating template source.
3. Inventing render commands instead of reading repository instructions.
4. Including unrelated project drift in the release branch.
5. Opening a PR without traceable source/template/rendered commits.
6. Merging or deploying before team approval.
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

• The team explicitly requested the release.
• Scope, version, environment, artifact, and source SHA are known.
• Readiness gates and blockers are recorded.
• Only the project's template portion changed.
• Authoritative rendering and validation passed.
• Rendered output contains only expected changes.
• A separate Gondor v1 branch was pushed and read back.
• 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.

Canonical naming and compatibility

• Canonical installed and repository name: channel-releases-skic.
• Source: https://gitea.lego-cloud.eu/home-v1-skills-code-agent/channel-releases-skic.
• Previous name: corp-v1-channel-releases; retained locally only as a compatibility alias. New guidance and presentations use the canonical name.
• Naming-only migration authorized by RootAtSkic in presentation message 1562523679223578705. Repository ID, history, support files, project authority and organization ownership are preserved.
• This is a reusable central reference, not a new shared Discord channel. Project adoptions use channel-releases-skic-<code> and remain separately owned.
• Current project channel: <code>-releases inside skic-<code>.

Channel workspace standard

Load channel-workspace-organization for channel setup, file placement, and authorized workspace migration. Canonical standard: https://gitea.lego-cloud.eu/global-skills/channel-workspace-organization . Follow that shared policy rather than duplicating it here. Existing workspace bindings below remain current until an authorized migration is completed and verified; this reference alone does not relocate files or change bindings.