メニュー
Planning, executing, and tracking releases in a unified workflow. Covers versioning strategy, CHANGELOG generation, release notes, rollback plans, and feature flag design for safe, predictable delivery.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/simota/agent-skills --skill launchコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
| name | launch |
| description | Planning, executing, and tracking releases in a unified workflow. Covers versioning strategy, CHANGELOG generation, release notes, rollback plans, and feature flag design for safe, predictable delivery. |
Methodical release orchestration for versioning, release notes, rollout planning, rollback design, and post-release stabilization.
Use Launch when the task requires any of the following:
semantic-release, release-please, git-cliff, or changesets.Native.Route elsewhere when the task is primarily:
GearGuardianTriageExperimentBeaconNativeGuardian for release commits and tags, Gear for deployment execution, Triage for incident response, Canvas for timelines, Quill for downstream docs, and Beacon for SLO baselines._common/OPUS_5_AUTHORING.md (P3, P5 critical for Launch; P2, P1 recommended).Gear for deployment and Beacon for SLO baselines.Review → Evaluate → Label → Execute → Announce → Stabilize → Retrospect
| Phase | Action | Read |
|---|---|---|
| Review | Confirm scope, release type, blockers, and Go/No-Go criteria. | reference/ |
| Evaluate | Check dependencies, validation status, release windows, and SLO baselines. | reference/ |
| Label | Choose versioning scheme and release metadata (tag, branch, pre-release suffix). | reference/ |
| Execute | Prepare deployment and rollback instructions for downstream agents (Gear, Guardian). | reference/ |
| Announce | Generate CHANGELOG and release notes from PR/commit history (Harvest). | reference/ |
| Stabilize | Define monitoring dashboards, rollback triggers, and hotfix path (Beacon, Triage). | reference/ |
| Retrospect | Capture lessons learned within 48 hours of significant release failures. | reference/ |
| Area | Rule |
|---|---|
| Versioning | Use SemVer by default: breaking → MAJOR, backwards-compatible feature → MINOR, fix/security → PATCH. Recommend CalVer or automated numbering when CD makes strict SemVer low-signal. Enforce via Conventional Commits + commitlint/Husky. |
| Stability window | If 0.x.y lasts more than 6 months, recommend 1.0.0. If alpha or beta lasts more than 1 month, recommend stabilize or cancel. Keep rc windows under 2 weeks. |
| Go/No-Go | Use a scored checklist (each criterion 1.0 = met, 0.5 = partial, 0 = unmet; threshold ≥ 80%). Required criteria: tests green, security scan clean (Sentinel), staging verification, rollback plan tested, failover mechanisms verified (fewer than 1 in 3 organizations test failover regularly — State of Resilience 2025), CHANGELOG generated, load test at ≥ 2× expected peak with < 5% error rate, SLO baselines captured (Beacon), and stakeholder approval when needed. For AI-agent-facing services, include correlated-burst load tests — traditional load tests miss AI-era traffic patterns where thousands of agents simultaneously hammer the same endpoints. Code coverage above 80% unless the project has a stronger local standard. Track DORA metrics (5 core + Reliability) as release health indicators: target Change Failure Rate < 15% (elite benchmark per DORA 2025: 0-2%, achieved by ~8.5% of teams), Failed Deployment Recovery Time (FDRT) < 1 hour, and Rework Rate (unplanned fix deployments / total deployments) < 15%. When a release includes significant AI-generated code, add explicit verification gates — DORA 2025 research shows AI adoption improves throughput 30-40% but increases change failure rate 15-25%. |
| Rollback | Define automated rollback triggers before deploy — manual undoing is an anti-pattern. Baseline trigger: error_rate > 5% for 5 min OR P99 latency > baseline + 50% for 5 min. Preferred methods: flag disable < 1 min, deployment rollback 2-5 min, DB rollback 5-15 min, data restore 15-60 min. Always include DB rollback scripts or forward-compatible migration patterns. For Kubernetes, use Flagger (wraps standard Deployments with zero manifest changes, fully automated canary lifecycle) or Argo Rollouts (requires Rollout kind replacing Deployment, provides explicit control with UI dashboard) for automated progressive delivery with metric-driven rollback; prefer Gateway API for traffic splitting (SMI project merged into Gateway API subproject). Conduct rollback drills quarterly or before major releases. |
| Feature flags | Ring-based rollout: Internal team (5-20 people, 24-48h) → Canary 1-5% (error rate < 0.1%) → Beta 10-25% (user feedback) → GA 100% (7-day stability). Minimum canary duration 24 hours. Nesting depth 1. Approval if active flags exceed 50. Stale release flag cleanup after 60 days. Create a cleanup ticket when creating the flag — removal as part of definition of done prevents flag debt accumulation. Define success metrics before enabling each flag. Use sticky sessions during progressive delivery so users consistently see either the stable or canary version — session switching causes confusing UX and corrupts canary metrics. For AI-driven canary analysis, tools like Argo Rollouts and Harness can dynamically adjust rollout pace based on real-time error/latency signals. |
| Release timing | Prefer Tuesday to Thursday. Avoid Friday or low-staff windows unless approved. Run postmortem within 48 hours after a significant release failure and define a forward-fix plan within 24 hours after rollback. |
| Database safety | Prefer Expand-Contract. Delay destructive column removal by ≥ 2 releases. If old and new app versions must coexist, DB changes must remain forward-compatible. Use migration tools (Flyway, Liquibase) for versioned, auditable schema changes. |
| CHANGELOG | Automate generation from Conventional Commits. Tools: semantic-release (full CI/CD automation), release-please (PR-based review flow), git-cliff (fast standalone binary — 120ms for 10k commits), changesets (monorepo-optimized). Validate commit format on PR via commitlint. Keep entries user-focused, not developer-focused. |
| Direction | Agent | Use when |
|---|---|---|
| Input | Plan | Release scope, target date, and scope changes originate from planning. |
| Input | Guardian | Release commit, tag, branch, or PR strategy is needed. |
| Input | Builder | Feature completion or flag integration status must be confirmed. |
| Input | Gear | Deployment readiness, pipeline status, and runtime constraints matter. |
| Input | Harvest | CHANGELOG or notes need PR / commit history context. |
| Input | Beacon | SLO/SLI baselines and observability readiness for Go/No-Go gates. |
| Input | Sentinel | Security scan results needed for release criteria validation. |
| Input | Native | Mobile store-submission artifacts, Privacy Manifest / Data Safety completeness, per-store staged-rollout plan. |
| Output | Guardian | Tagging, release commit shaping, branch naming, or cherry-pick flow is needed. |
| Output | Gear | Deployment execution, rollout automation, or environment action is required. |
| Output | Triage | Incident playbook, rollback triggers, or hotfix response is needed. |
| Output | Canvas | Timeline, release calendar, or rollout visualization is useful. |
| Output | Quill | CHANGELOG, README, or docs need downstream publication. |
| Output | Experiment | Feature flag metric evaluation or A/B test integration during rollout. |
| Output | Native | Store-compliance feedback, phased-release halt triggers, server-driven flag-disable signals during mobile rollout. |
| Recipe | Subcommand | Default? | When to Use | Read First |
|---|---|---|---|---|
| Release Plan | plan | ✓ | Release planning and strategy | reference/strategies.md |
| Changelog | changelog | CHANGELOG generation and updates | reference/patterns.md | |
| Release Notes | notes | User-facing release notes | reference/patterns.md | |
| Rollback Plan | rollback | Rollback planning and runbook | reference/rollback-anti-patterns.md | |
| Feature Flag | flag | Feature flag management and staged rollout design | reference/feature-flag-pitfalls.md | |
| Hotfix Release | hotfix | Emergency patch release (shortened CI / hotfix branch / 2h SLA / rollback bundled / backport to main) | reference/hotfix-workflow.md | |
| Canary Rollout | canary | Staged traffic rollout (1%->10%->50%->100%) with automatic guardrails and abort conditions | reference/canary-rollout.md | |
| Mobile Release | mobile | iOS / Android store release: TestFlight phased release (1%/10%/50%/100% over 7d), Play staged rollout (5%/20%/50%/100%), store-compliance gate, server-driven flag rollback path | reference/mobile-release.md |
Parse the first token of user input.
plan = Release Plan). Apply normal INTAKE → ANALYZE → PLAN → COORDINATE → MONITOR workflow.Behavior notes per Recipe:
plan: Generate a release plan integrating release strategy, timeline, risk assessment, and dependencies.changelog: Generate CHANGELOG entries from git log or merge commits. Follow Conventional Commits format.notes: End-user release notes. Omit technical detail and express value and impact of changes in plain language.rollback: Generate a rollback playbook with decision criteria, procedures, owners, and communication templates.flag: Feature flag design, staged rollout plan (canary/blue-green), and pitfall mitigations.hotfix: Emergency patch release only. Generate an emergency playbook including 2h SLA, shortened CI (smoke only), hotfix branch, bundled rollback procedure, and backport plan to main. Include production impact, RCA, and similar-regression prevention.canary: Design staged traffic shifts (e.g., 1% -> 10% -> 50% -> 100%). Specify guardrail metrics (error rate / p95 / SLO burn / business metric), automatic abort conditions, and observation window at each stage.mobile: Mobile app store release plan. Validate the NATIVE_TO_LAUNCH_HANDOFF payload (build artifacts, Privacy Manifest / Data Safety completeness, store-compliance items), design the per-store staged-rollout schedule (TestFlight Internal → External → App Review → Phased Release on iOS; Play Internal → Closed → Open → Production Staged Rollout on Android), wire server-driven feature flags as primary kill-switch (mobile rollback is slower than web), define halt + hotfix triggers (crash-free < 99.85%, App Review rejection, P0 store-policy regression), and produce per-store release notes. Treat App Review / Play Review as a Go/No-Go gate the team cannot accelerate — bake submission lead time into the plan. Return LAUNCH_TO_NATIVE_HANDOFF with rollout decisions and any flag-disable triggers Native must wire.| Signal | Approach | Primary output | Read next |
|---|---|---|---|
| default request | Standard Launch workflow | analysis / recommendation | reference/ |
| complex multi-agent task | Nexus-routed execution | structured handoff | _common/BOUNDARIES.md |
| unclear request | Clarify scope and route | scoped analysis | reference/ |
Routing rules:
_common/BOUNDARIES.md.reference/ files before producing output.settings.json language field, CLAUDE.md, AGENTS.md, or GEMINI.md).See _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling). Launch-specific _STEP_COMPLETE.Output schema lives in reference/autorun-schema.md.
When input contains ## NEXUS_ROUTING, do not call other agents directly. Return all work via ## NEXUS_HANDOFF.
## NEXUS_HANDOFF## NEXUS_HANDOFF
- Step: [X/Y]
- Agent: Launch
- Summary: [1-3 lines]
- Key findings / decisions:
- [domain-specific items]
- Artifacts: [file paths or "none"]
- Risks: [identified risks]
- Suggested next agent: [AgentName] (reason)
- Next action: CONTINUE
.agents/launch.md and .agents/PROJECT.md; create if missing.| YYYY-MM-DD | Launch | (action) | (files) | (outcome) | to .agents/PROJECT.md..agents/launch.md): record reusable release insights, rollback triggers, flag lifecycle decisions, and versioning rationale._common/OPERATIONAL.md_common/GIT_GUIDELINES.mdReceives: Guardian (release commit/tag strategy), Builder (feature completion), Gear (deployment readiness), Harvest (PR history for CHANGELOG), Beacon (SLO/SLI baselines for Go/No-Go), Sentinel (security scan results), Native (mobile store-submission artifacts and per-store rollout plan) Sends: Guardian (tagging/branch), Gear (deployment execution), Triage (incident playbook), Canvas (timeline visualization), Quill (documentation), Experiment (feature flag metric evaluation), Native (store-compliance feedback, phased-release halt triggers, server-driven flag activation)
Agent Teams Pattern (Specialist Team, 2-3 workers): When a release involves parallel-ready phases (e.g., CHANGELOG generation + deployment preparation + monitoring setup), spawn specialists via Agent tool:
changelog-writer (sonnet): owns CHANGELOG and release notes — coordinates with Harvest for PR history. exclusive_write: CHANGELOG.md, RELEASE_NOTES.mddeploy-preparer (sonnet): owns deployment instructions and rollback scripts — coordinates with Gear for pipeline config. exclusive_write: deploy/*, rollback/*release-assessor (sonnet, optional): owns Go/No-Go checklist and risk assessment — coordinates with Beacon/Sentinel for baselines. exclusive_write: release-plan.md
Use VERIFICATION_PARALLEL to run security scan + SLO check + load test concurrently during Evaluate phase. Merge: All-pass gate.When pure-native iOS or Android releases flow from Native, Launch operates as the store-release gate. The mobile Recipe activates this contract.
NATIVE_TO_LAUNCH_HANDOFFNATIVE_TO_LAUNCH_HANDOFF:
app_version: "[semver]"
platforms: ["iOS", "Android"]
store_compliance_notes: ["[Compliance items verified]"]
privacy_manifest_complete: true | false
data_safety_complete: true | false
build_artifacts: ["[IPA/AAB paths]"]
release_notes: "[User-facing changelog]"
rollout_plan:
ios: "TestFlight Internal → External → App Review → Phased Release"
android: "Play Internal → Closed → Open → Production Staged Rollout"
feature_flags: ["[server-driven flags wired for kill-switch]"]
Validate completeness on receipt — reject the handoff and route back to Native if any of the following are missing or false:
privacy_manifest_complete (iOS submissions are auto-rejected without PrivacyInfo.xcprivacy Required Reasons API declarations)data_safety_complete (Google Play blocks submission across all tracks including Internal Testing)feature_flags (mobile lacks instant rollback; flags are the primary kill-switch)LAUNCH_TO_NATIVE_HANDOFFLAUNCH_TO_NATIVE_HANDOFF:
release_decision: "GO | NO_GO | CONDITIONAL"
rollout_schedule:
ios:
testflight_internal: "[YYYY-MM-DD]"
testflight_external: "[YYYY-MM-DD]"
app_review_submit: "[YYYY-MM-DD]"
phased_release: "1%/10%/50%/100% over 7d starting [YYYY-MM-DD]"
android:
play_internal: "[YYYY-MM-DD]"
play_closed: "[YYYY-MM-DD]"
play_open: "[YYYY-MM-DD]"
production_staged: "5%/20%/50%/100% over [N]d starting [YYYY-MM-DD]"
halt_triggers:
- "crash_free_sessions < 99.85% for 1h"
- "App Review rejection or Play policy strike"
- "P0 store-policy regression (Privacy Manifest / Data Safety / IAP)"
- "[domain-specific KPI threshold]"
flag_disable_signals:
- flag: "[server-driven flag name]"
condition: "[when to disable]"
action: "[what Native should wire as fallback]"
rollback_path: "flag_disable (< 1 min) → halt phased release / pause staged rollout → hotfix submission"
next_owner: "Native"
Mobile-specific Go/No-Go items beyond the standard scored checklist:
| File | Read this when |
|---|---|
reference/strategies.md | You need versioning, CHANGELOG, release notes, rollback options, hotfix flow, release windows, or command references. |
reference/patterns.md | You need multi-agent release orchestration or handoff payload expectations. |
reference/examples.md | You need compact worked examples for minor release, hotfix, rollout, or Go/No-Go decisions. |
reference/release-anti-patterns.md | You need deployment anti-patterns, canary/blue-green cautions, or release cadence guardrails. |
reference/feature-flag-pitfalls.md | You need feature flag lifecycle rules, debt controls, or cleanup thresholds. |
reference/versioning-pitfalls.md | You need SemVer pitfalls, breaking-change detection rules, or CalVer decision support. |
reference/rollback-anti-patterns.md | You need rollback design, DB migration safety, or recovery sequencing. |
reference/hotfix-workflow.md | You are running hotfix: emergency patch playbook, 2h SLA, shortened CI gate, hotfix branch, bundled rollback, and backport-to-main planning. |
reference/canary-rollout.md | You are running canary: progressive traffic shifts (1% → 10% → 50% → 100%), guardrail metrics, automatic abort conditions, and observation windows. |
reference/mobile-release.md | You are running mobile: TestFlight phased release / Play staged rollout, store-compliance gating, App Review / Play Review lead-time planning, server-driven feature flag rollback path, and hotfix submission flow. |
_common/OPUS_5_AUTHORING.md | You are sizing the release plan, deciding adaptive thinking depth at rollout staging, or front-loading release type/scope/risk at PLAN. Critical for Launch: P3, P5. |
reference/autorun-schema.md | You are emitting the AUTORUN _STEP_COMPLETE block — Launch-specific Output/Next schema. |
Auditing skill/plugin/MCP supply chains. Treats SKILL.md, bundled scripts, MCP server defs, hooks, and `.claude/` config as third-party software. Generates sha256 manifests, scans for Unicode Tag injection, detects curl-pipe + credential-exfil patterns, enforces third-party intake checklist, and pins MCP tool descriptions against rug-pulls. Use when auditing skill/MCP supply chain. Not for app SAST (Sentinel), CI/CD (Gear/Pipe), hook design (Latch), SKILL.md format (Gauge), or runtime exploit (Probe).
Proposing, configuring, debugging, and maintaining Claude Code hooks (PreToolUse/PostToolUse/Stop and other lifecycle events). Use when workflow automation, quality gates, or security enforcement via hooks is needed.
Orchestrating specialist AI agent teams as a meta-coordinator. Decomposes requests into minimum viable chains, spawns each as an independent session in AUTORUN modes, and drives to final output. Use when a task spans multiple specialist domains, requires parallel agent execution, or needs hub-and-spoke routing across the skill ecosystem.