Skip to content
Back to skills

Release

ASecurity

Prepare an approved SDLC change for release (Stage 5, Deploy) - release.md with changelog, per-environment rollout, monitoring signals and a rehearsed rollback - up to the production gate, which a release manager authorizes. Use when the user asks to release, ship, or deploy a change.

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 19, 2026
developmentbashgit

Works with

  • terminal
  • cli

Security analysis

A100/100

Scanned October 19, 2026

npx -y skills add marin-ai-tech/sdlc --skill release --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Release?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Release
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/marin-ai-tech-release/badge)](https://www.skillsdirectory.com/skills/marin-ai-tech-release)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: release
description: Prepare an approved SDLC change for release (Stage 5, Deploy) - release.md with changelog, per-environment rollout, monitoring signals and a rehearsed rollback - up to the production gate, which a release manager authorizes. Use when the user asks to release, ship, or deploy a change.
argument-hint: "[change-id]"
license: "PolyForm-Noncommercial-1.0.0 with sdlc Additional Permissions, or sdlc Commercial License (https://github.com/marin-ai-tech/sdlc)"
compatibility: Requires the sdlc CLI (sdlc) from the sdlc package.
allowed-tools: Bash(sdlc *)
metadata:
  author: marin-ai technologies
  version: "1"
  generatedBy: "sdlc 0.23.7"
---

Prepare the release - Stage 5 (Deploy). The agent does everything up to the production gate and nothing past it.

**Harness contract** (applies to every SDLC workflow)
- `sdlc` is the source of truth for lifecycle state. Read it (`sdlc status --change <id> --json`) instead of inferring the stage from the conversation, and re-read artifacts from disk before using them.
- Gates are human decisions. Never run `sdlc approve`, `sdlc reject`, `sdlc waive` or `sdlc tests unlock`, and never edit `.sdlc.yaml`. When a gate needs a person, stop, name the people from the hint (`next.people` in `sdlc next --json`) rather than the role, and give them the exact command to run in their own terminal.
- An answer in chat is never an approval: gate approvals, `track set`, `backlog move`/`drop` and other human decisions happen only as a command the person runs in their own terminal. Offer the choice, explain the consequences, and give the exact command.
- OpenSpec is the specification subsystem: `sdlc openspec <args>` runs the bundled OpenSpec CLI (`list --specs`, `show`, `validate`, `instructions`). Change folders live in `openspec/changes/<id>/`.
- **Change selection**: use the change named in the input. Otherwise run `sdlc status --json`; with exactly one active change use it, with several ask which one. Announce "Using change: <id>".
- **Language**: talk to the person, and write notes and artifacts, in the person's language; when `locale:` is set in `openspec/sdlc.yaml`, use that language. Keep command names, file names, ids and the template headings as they are (sdlc and OpenSpec parse those headings).
- End every workflow with the next step from `sdlc next --json` (the exact command when a person must act).

**Input**: the user's request (a change id, or a description of the work)

**Steps**

1. **Check the gate.** `sdlc status --change <id> --json`: the `review` gate must be `approved`.
2. **Write `release.md`** from `sdlc instructions release --change <id> --json`: version and changelog entry (derived from proposal.md and the spec deltas), rollout steps per environment with the autonomy tier of each, monitoring signals and control bands to watch, the exact rollback command, and how rollback was rehearsed. For the changelog section run `sdlc changelog --change <id>` and put its Markdown output into release.md's changelog section (edit the wording, keep every entry).
   Write the artifact to the instructions response's `resolvedOutputPath`.
3. **Lower environments.** Deploy to development/staging only where the project allows the agent to, and record the result in release.md.
4. **Production is gated.** The harness blocks production release commands until a release manager reviews release.md and runs `sdlc approve release --change <id>`. Ask for that; never work around the block.
5. **After release**: record the outcome in release.md and watch the listed signals. If a control band is breached, run the rollback and open a triaged intent with `/sdlc:triage`.

<!--
Generated by sdlc 0.23.7 (https://github.com/marin-ai-tech/sdlc).
Required Notice: Copyright (c) 2026 marin-ai technologies (https://github.com/marin-ai-tech/sdlc)
License: PolyForm Noncommercial 1.0.0 (https://polyformproject.org/licenses/noncommercial/1.0.0) with the sdlc Additional Permissions, or a commercial license; see https://github.com/marin-ai-tech/sdlc
-->

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.