| name | looply-release |
| description | Use to prepare and validate a software release. Includes security, performance, monitoring, rollback and operability checklist. Final delivery gate before production deploy. |
Use this skill when the user explicitly invokes $looply-release, asks to run /looply:release, or when preparing a release for production deployment.
Workflow phase: delivery.
Primary orchestrator: devops.
Quick usage:
$looply-release <feature-name> <story-reference> "[notes...]"
Primary references:
- Workflow playbook: ../../../../.looply/state/workflow-playbook.opencode.md
- Host status contract: ../../../../.looply/state/host-status-contract.json
- Managed pack: ../../../../.looply/managed/packs/software-delivery-suite
- Custom overrides: ../../../../.looply/custom
- Execution hints: ../../../../.looply/state/execution-hints.opencode.json
- Context index: ../../../../.looply/state/context-index.md
- Project context: ../../../../.looply/custom/project-context.md
- Session context: ../../../../.looply/custom/session-context.md
- Knowledge graph: ../../../../.looply/state/knowledge-graph.json
Usage:
- Explicit mention:
$looply-release
- Workflow alias to honor:
/looply:release
- Syntax in Codex:
$looply-release <feature-name> <story-reference> "[notes...]"
Example:
- $looply-release pix-webhook-retry story-01-retry-automatico "deploy during low-traffic window"
When to use:
- Release preparation for production
- Pre-deploy validation of security, performance and operability
- Final delivery pipeline gate
Curated example guidance:
- ICL mode:
on
- Use examples only for style, structure and quality calibration.
- Do not copy feature-specific names, identifiers or business details from examples.
- No example was selected for this workflow.
Release Flow
Stage 1: Pre-Release Checklist
Execute pre-release checklist:
Security:
Performance:
Monitoring:
Rollback:
Stage 2: Operability Assessment
Assess feature operability:
Deploy:
Resilience:
Observability:
Stage 3: Release Plan
Generate the release plan in .looply/custom/features/<feature-name>/release-plan.md:
# Release Plan
## Feature
pix-webhook-retry
## Story
story-01-retry-automatico
## Pre-Release Checklist
- [x] Security (4/4)
- [x] Performance (4/4)
- [x] Monitoring (3/4) - Pending: business metrics
- [x] Rollback (3/3)
- [x] Deploy (3/3)
- [ ] Resilience (2/3) - Pending: circuit breaker
## Deploy Plan
- Strategy: Rolling update
- Time: 02:00-04:00 (low traffic)
- Dependencies: None
- Estimated duration: 15 min
## Rollback Plan
1. Revert deploy via CI/CD (rollback button)
2. Disable feature flag `pix-retry-enabled`
3. Migrations are reversible (add column only)
## Post-Deploy Verification
- [ ] Service health check responds 200
- [ ] Webhook metrics show retry working
- [ ] No alerts fired in 30min
- [ ] On-call team notified
## Approval
[ ] Approved for deploy
[ ] Blocked - resolve pending items
Stage 4: Release Decision
Present the plan to the user:
# Release Decision
Checklist: 17/20 items completed
Pending: business metrics, circuit breaker
[a] Approve release - proceed with deploy
[b] Block - resolve pending items first
[v] View detailed checklist
Execution rules:
- Start by reading the workflow playbook and the feature state file.
- If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
- Execute complete pre-release checklist before approving.
- Verify security, performance, monitoring and rollback.
- Document deploy and rollback plan.
- Use managed pack files as canonical process definition and write local state only under
.looply/custom.
- Respond in the same language as the user's input.
- For existing projects, use the real local codebase as the primary source of truth.
- Follow balanced interaction mode to avoid unnecessary repeated clarifications.
- Keep the response visually structured with clear Markdown section titles.
- Do not use emojis.
Composed Agent Context
The sections below were pre-composed by looply from agent context_slots.
Constraints
- Do not approve release with pending critical security items
- Rollback plan mandatory for every release
- Verify compliance with project security policies
Escalation
- Escalate security concerns to sre
- Escalate deploy blockers to devops
- Escalate product sign-off to pm-analyst
Arguments:
- feature-name: short identifier for the feature (required)
- story-reference: story being released (required)
- notes: optional notes about deploy constraints or timing (optional)