corp-v1-channel-releases/SKILL.md

name, description, version, author, license, metadata

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

Corp v1 Releases Channel

Overview

This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's general, scope, architecture, kanban, delivery, 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.

When to Use

Use this skill when:

• operating in corp-v1-<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:

corp-v1-<code>-general
corp-v1-<code>-scope
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 five 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. If version, environment, artifact, or scope is missing, prepare a readiness summary and ask for the missing decision 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.

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;
• monitor actual deployment state;
• verify health and release-specific acceptance checks;
• post version, commit, PR, deployment, and rollback evidence;
• record post-release outcomes and unresolved follow-up.

Never claim deployment from a merged PR alone.

Synchronization Workflow

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, 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 with documentation and verification evidence, or the concrete gate that prevented useful work.

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.

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.