Aspire
microsoft/aspire.dev
Orchestrates Aspire distributed applications using the Aspire CLI for running, debugging, and managing distributed apps.
Software deployment workflow for systems with separate UAT and PROD environments.
Install Tonic System Deploy
$ npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install LeoYeAI/openclaw-master-skills tonic-system-deploy --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/tonic-system-deploy .claude/skills/tonic-system-deploy && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "tonic-system-deploy" agent skill from https://github.com/LeoYeAI/openclaw-master-skills/tree/main/skills/tonic-system-deploy into .claude/skills/tonic-system-deploy/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "tonic-system-deploy", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/LeoYeAI/openclaw-master-skills/tree/main/skills/tonic-system-deployType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install LeoYeAI/openclaw-master-skills tonic-system-deploy --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/tonic-system-deploy .agents/skills/tonic-system-deploy && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "tonic-system-deploy" agent skill from https://github.com/LeoYeAI/openclaw-master-skills/tree/main/skills/tonic-system-deploy into .agents/skills/tonic-system-deploy/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "tonic-system-deploy", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install LeoYeAI/openclaw-master-skills tonic-system-deploy --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/tonic-system-deploy .cursor/skills/tonic-system-deploy && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "tonic-system-deploy" agent skill from https://github.com/LeoYeAI/openclaw-master-skills/tree/main/skills/tonic-system-deploy into .cursor/skills/tonic-system-deploy/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "tonic-system-deploy", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/LeoYeAI/openclaw-master-skills.git --path skills/tonic-system-deploy--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install LeoYeAI/openclaw-master-skills tonic-system-deploy --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/tonic-system-deploy .gemini/skills/tonic-system-deploy && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "tonic-system-deploy" agent skill from https://github.com/LeoYeAI/openclaw-master-skills/tree/main/skills/tonic-system-deploy into .gemini/skills/tonic-system-deploy/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "tonic-system-deploy", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install LeoYeAI/openclaw-master-skills tonic-system-deployInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/tonic-system-deploy .github/skills/tonic-system-deploy && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "tonic-system-deploy" agent skill from https://github.com/LeoYeAI/openclaw-master-skills/tree/main/skills/tonic-system-deploy into .github/skills/tonic-system-deploy/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "tonic-system-deploy", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install LeoYeAI/openclaw-master-skills tonic-system-deploy --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/tonic-system-deploy .opencode/skills/tonic-system-deploy && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "tonic-system-deploy" agent skill from https://github.com/LeoYeAI/openclaw-master-skills/tree/main/skills/tonic-system-deploy into .opencode/skills/tonic-system-deploy/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "tonic-system-deploy", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
tonic-system-deploy- GitHub stars
- 2.2k
- Token cost
- ~4.5k tokens
- SKILL.md length
- 1,487 words
- Files
- 2
- Skills in repo
- 1,235
- Repo updated
- First seen
- Licence
- MIT
At a glance
Software deployment workflow for systems with separate UAT and PROD environments.
- Works in 9 steps: Define T1 and T2 — pick times based on… → Set severity policy — confirm which… → Configure Telegram/notification channels… → …
- : planning a bug fix deployment
- SKILL.md covers Background & Design Rationale, Prerequisites — Before…, Flow 1 — UAT-First (Versions… and Flow 2 — PROD-First (Versions…, plus 6 more sections
- Calls git and docker
What it does
Tonic System Deploy is an agent skill from LeoYeAI/openclaw-master-skills. Software deployment workflow for systems with separate UAT and PROD environments. Use when: planning a bug fix deployment, choosing between Flow 1 (UAT-first) and Flow 2 (PROD-first), handling emergency hotfixes, executing rollbacks, or designing automated nightly deploy pipelines. Covers approval gates, human checkpoints, system automation nodes, Telegram notifications, and rollback procedures.
Its SKILL.md is about 4.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `_meta.json`).
It sits in DevOps & Cloud, covering Deployment and Debugging. It works with Telegram. The repository describes itself as: 🧠 Curated collection of 1209+ best OpenClaw skills — weekly updated by MyClaw.ai. The licence is MIT.
When your agent uses it
- : planning a bug fix deployment
- Choosing between Flow 1 (UAT-first) and Flow 2 (PROD-first)
- Handling emergency hotfixes
- Executing rollbacks
Example prompts
- “/tonic-system-deploy”
Requirements
- Docker
Workflow steps
9 steps, taken from the first numbered list in SKILL.md.
- Define T1 and T2 — pick times based on traffic patterns and SLA
- Set severity policy — confirm which severities enter pipeline vs emergency hotfix
- Configure Telegram/notification channels — who receives which notifications
- Add DB columns — fix_flow, found_in_env, and status enum (see Status Reference)
- Implement Phase 1 + Phase 2 cron jobs — schedule at T1 and T2
- Add approval endpoints — approve-prod, approve-uat-merge, batch variants
- Add status badges + action buttons — frontend must reflect all statuses clearly
- Test the full cycle in UAT first — simulate a bug through both flows before going live
- Document rollback steps — specific to the project's tech stack and DB
What it can do on your machine
Read from SKILL.md and the folder at commit e5199b5. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
gitdocker
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use git and docker, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Tonic System Deploy loads about 4.5k tokens when it runs. Until then it costs about 105 tokens; SKILL.md has 1,487 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from LeoYeAI/openclaw-master-skills at commit e5199b5, republished under its MIT licence (© LeoYeAI). 1,487 words, ~4,550 tokens.
Download SKILL.mdSave it as
.claude/skills/tonic-system-deploy/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.- name
- tonic-system-deploy
- description
- Software deployment workflow for systems with separate UAT and PROD environments. Use when: planning a bug fix deployment, choosing between Flow 1 (UAT-first) and Flow 2 (PROD-first), handling emergency hotfixes, executing rollbacks, or designing automated nightly deploy pipelines. Covers approval gates, human checkpoints, system automation nodes, Telegram notifications, and rollback procedures.
tonic-system-deploy
Software Deployment Workflow — Dual-Environment (UAT + PROD)
Background & Design Rationale
This skill was designed for systems where:
- Two live environments co-exist: UAT (testing/staging) and PROD (production)
- Versions can diverge: UAT may be ahead of PROD by several releases
- Deployments are nightly: automated pipelines run at scheduled times
- Human approval is mandatory: no code goes to PROD without explicit admin sign-off
- Bugs require structured triage: severity, origin environment, and version state all affect the deploy path
The key insight: choosing the wrong deploy flow when versions are mismatched can introduce regressions. Flow 1 assumes parity; Flow 2 handles divergence safely.
Prerequisites — Before Choosing a Flow
Step 0: Version Check (always do this first)
| Question | Answer → |
|---|---|
| Are UAT and PROD on the same version? | → Flow 1 |
| Is UAT ahead of PROD by any version? | → Flow 2 |
| Is this a critical/high severity bug? | → Emergency Hotfix (bypass pipeline) |
| Do you need to undo a bad deploy? | → Rollback |
Version Mismatch Decision Tree
Bug found
│
├─ severity = critical/high?
│ └─ YES → Emergency Hotfix (skip pipeline)
│
├─ UAT version == PROD version?
│ └─ YES → Flow 1
│
└─ UAT version > PROD version?
└─ YES → Flow 2Flow 1 — UAT-First (Versions Aligned)
Scenario: Bug found in UAT or PROD when both environments run the same version. Goal: Fix → validate in UAT → promote to PROD. Result: UAT and PROD converge to same patched version.
Timeline
Bug reported
│
│ 🧑 HUMAN: Admin reviews + confirms bug (status: confirmed)
▼
[confirmed] — severity: low/medium only
│
│ 🤖 SYSTEM: Scheduled deploy time T1 (e.g. 20:00)
│ - AI analyses root cause + records fix plan
│ - Deploys fix to UAT environment
│ - Status → deployed_uat
▼
[deployed_uat]
│ 📲 Telegram: "Fix deployed to UAT. Please validate."
│
│ 🧑 HUMAN: Admin logs into UAT, validates fix
│ - Runs through affected workflows
│ - Confirms no regression
│ - Clicks "Approve PROD Deploy" → status: pending_prod
▼
[pending_prod]
│ 📲 Telegram: "Queued for PROD at T2."
│
│ 🤖 SYSTEM: Scheduled deploy time T2 (e.g. 22:00)
│ - Deploys fix to PROD environment
│ - Status → deployed_prod
▼
[deployed_prod] ✅ Flow 1 Complete
│ 📲 Telegram: "Deployed to PROD. Flow 1 complete."Human Checkpoints (Flow 1)
| Checkpoint | Who | Action | Gate Condition |
|---|---|---|---|
| Confirm bug | Admin/Manager | Mark as confirmed | Bug is reproducible and valid |
| UAT validation | Admin/Manager | Click "Approve PROD Deploy" | Fix works, no regression in UAT |
Automation Nodes (Flow 1)
| Time | Node | Input Status | Output Status | Action |
|---|---|---|---|---|
| T1 | Phase 1 | confirmed/planned | deployed_uat | AI analysis + UAT deploy |
| T2 | Phase 2 | pending_prod | deployed_prod | PROD deploy |
Flow 2 — PROD-First (Versions Misaligned)
Scenario: Bug found in PROD when UAT is ahead by one or more versions. Why not Flow 1? Validating a PROD fix in a newer UAT environment risks false confidence — the fix may behave differently on the older PROD codebase. Goal: Fix PROD directly → validate in PROD → cherry-pick back to UAT. Result: PROD gets the fix immediately; UAT gets it merged back after PROD validation.
Timeline
Bug found in PROD (UAT is ahead)
│
│ 🧑 HUMAN: Admin reviews + confirms bug
│ - Selects: found_in_env = prod, fix_flow = flow2
│ - Status → confirmed
▼
[confirmed]
│
│ 🤖 SYSTEM: Scheduled deploy time T1 (e.g. 20:00)
│ - AI analyses root cause + records fix plan
│ - Skips UAT entirely
│ - Queues for PROD deploy → status: pending_prod
▼
[pending_prod]
│ 📲 Telegram: "PROD deploy queued for T2 (Flow 2)."
│
│ 🤖 SYSTEM: Scheduled deploy time T2 (e.g. 22:00)
│ - Deploys fix to PROD
│ - Status → deployed_prod
▼
[deployed_prod]
│ 📲 Telegram: "Deployed to PROD. Please validate PROD. Approve UAT merge when ready."
│
│ 🧑 HUMAN: Admin validates fix in PROD
│ - Confirms fix works on production data/config
│ - No regression in PROD workflows
│ - Clicks "Approve Merge UAT" → status: pending_uat_merge
▼
[pending_uat_merge]
│ 📲 Telegram: "UAT merge queued for T2 tonight."
│
│ 🤖 SYSTEM: Next T2 cycle (22:00)
│ - Deploys/merges fix into UAT environment
│ - Status → uat_merged
▼
[uat_merged] ✅ Flow 2 Complete
│ 📲 Telegram: "Merged to UAT. Flow 2 complete."Human Checkpoints (Flow 2)
| Checkpoint | Who | Action | Gate Condition |
|---|---|---|---|
| Confirm bug | Admin/Manager | Mark as confirmed + select flow2 | Bug confirmed in PROD, version mismatch verified |
| PROD validation | Admin/Manager | Click "Approve Merge UAT" | Fix verified in PROD, no regression |
Automation Nodes (Flow 2)
| Time | Node | Input Status | Output Status | Action |
|---|---|---|---|---|
| T1 | Phase 1 | confirmed/planned | pending_prod | AI analysis (skip UAT) |
| T2 | Phase 2a | pending_prod | deployed_prod | PROD deploy |
| T2 (next) | Phase 2b | pending_uat_merge | uat_merged | UAT deploy/merge |
Flow 2 Important Note
T2 deadline matters. If admin approves UAT merge before T2 on the same day, the merge runs that night. If approved after T2, it runs the following night's T2. Always communicate the cutoff time to the team.
Status Reference
| Status | Flow | Colour | Meaning | Next Action |
|---|---|---|---|---|
submitted | Both | Grey | Bug reported, awaiting review | Admin confirms/rejects |
confirmed | Both | Blue | Valid bug, enters pipeline | T1 auto-process |
analyzing | Both | Purple | AI analysis running (transient) | Auto → planned |
planned | Both | Indigo | AI fix plan recorded | T1 auto-deploy |
deployed_uat | Flow 1 | Cyan | UAT deployed, awaiting human validation | Admin approves PROD |
pending_prod | Both | Yellow | Queued for PROD at next T2 | T2 auto-deploy |
deployed_prod | Both | Green | PROD deployed | Flow1: done; Flow2: admin approves UAT merge |
pending_uat_merge | Flow 2 | Purple | Queued for UAT merge at next T2 | T2 auto-merge |
uat_merged | Flow 2 | Teal | UAT updated with PROD fix | Flow 2 complete ✅ |
closed | Both | Emerald | Manually closed | — |
rejected | Both | Red | Not a valid bug | — |
Severity Rules
| Severity | Pipeline Eligible? | Notes |
|---|---|---|
low | ✅ Yes | Both flows |
medium | ✅ Yes | Both flows |
high | ❌ No | Emergency Hotfix only |
critical | ❌ No | Emergency Hotfix, immediate escalation |
Never let high/critical bugs wait for a scheduled pipeline. Treat them as emergency hotfixes.
Emergency Hotfix (Bypass Pipeline)
Scenario: Critical or high severity bug in PROD. Cannot wait for scheduled T1/T2.
Process
Critical bug found in PROD
│
│ 🧑 HUMAN: Admin confirms severity = critical/high
│ - Does NOT enter pipeline (no confirmed status)
│ - Opens direct hotfix branch
▼
Fix developed (manually or with AI assist)
│
│ 🧑 HUMAN: Admin deploys directly to PROD
│ - Updates bug status to deployed_prod manually
│ - Records fix details in ai_fix_diff field
▼
[deployed_prod] (manual)
│ 📲 Telegram: "Emergency hotfix deployed to PROD. [Bug title]"
│
│ 🧑 HUMAN: Validates PROD immediately
│
└─ If UAT is ahead → manually cherry-pick to UAT branch
If UAT is same version → update UAT as well
▼
✅ Emergency resolvedChecklist for Emergency Hotfix
- Severity confirmed as critical/high before bypassing pipeline
- At least one other team member notified before deploy
- Fix deployed and validated within agreed SLA (e.g. P1: 1 hour, P2: 4 hours)
- Post-deploy smoke test completed (login, core workflow, affected feature)
- Bug status updated manually in system
- Telegram/Slack notification sent to stakeholders
- Post-incident note added to bug record (root cause, fix summary)
- UAT updated (cherry-pick or re-sync if needed)
- Incident review scheduled (within 48h for P1)
Rollback Procedure
Scenario: A deploy (T1 or T2) introduces a regression or new failure.
Decision: When to Rollback
Issue detected after deploy
│
├─ Severity: minor UX glitch → Monitor, schedule fix in next pipeline
│
├─ Severity: functional regression → Rollback immediately
│
└─ Severity: data corruption risk → Rollback + escalate + engage DBARollback Process
Regression detected post-deploy
│
│ 🧑 HUMAN: Admin confirms rollback needed
│ - Record: what was deployed, when, what broke
▼
│ 🤖 SYSTEM or 🧑 HUMAN: Execute rollback
│ - Docker: docker compose down && git checkout <prev_tag> && docker compose up
│ - DB migration: apply down migration if schema changed
│ - Status of affected bugs → revert to previous status
▼
│ 📲 Telegram: "Rollback executed for [version]. Monitoring."
│
│ 🧑 HUMAN: Post-rollback validation (5–10 min smoke test)
│
└─ Stable → document in HISTORY + schedule proper fix
Unstable → escalateRollback Checklist
- Previous working commit/tag identified (git log)
- Rollback scope defined (frontend / backend / both / DB)
- Affected bug statuses reverted in system
- Smoke test completed after rollback
- Root cause of regression documented
- Team + stakeholders notified
- Fix plan for the reverted change recorded
Scheduled Deploy Times (Reference Only)
⚠️ These times are project-specific. Adapt per project SLA and business hours.
| Slot | Name | Phase | Typical Window |
|---|---|---|---|
| T1 | UAT/PROD-queue Deploy | Phase 1 | Off-peak evening (e.g. 20:00) |
| T2 | PROD/UAT-merge Deploy | Phase 2 | Late evening (e.g. 22:00) |
Principles for choosing T1/T2:
- T1 and T2 must have enough gap for human validation (minimum 1–2 hours)
- Both should be outside business hours unless urgency demands otherwise
- For 24/7 systems: choose lowest traffic window (check metrics)
- Emergency hotfix: no scheduled time — deploy ASAP after approval
Telegram Notification Templates
Use these as the standard message format for each pipeline node.
T1 Complete — Flow 1 (UAT deployed)
🔧 Bug Fix Pipeline — Flow 1 已部署 UAT
• #<id> [<severity>] <title>
• ...
📦 Release: <version>
✅ 請驗收 UAT：<UAT_URL>
確認後請點「批准推 PROD」。
下次 T2 時間：<T2_time>T2 Complete — Flow 1 (PROD deployed)
🚀 Bug Fix Pipeline — Flow 1 已部署 PROD
• #<id> [<severity>] <title>
✅ Flow 1 完成。UAT 與 PROD 版本已對齊。T1 Complete — Flow 2 (PROD queued)
🔧 Bug Fix Pipeline — Flow 2 已排隊部署 PROD
• #<id> [<severity>] <title>
⏳ 今晚 T2（<T2_time>）自動部署至 PROD。
部署後請驗收，確認後點「批准 Merge UAT」。T2 Complete — Flow 2 (PROD deployed, UAT pending)
🚀 Bug Fix Pipeline — Flow 2 已部署 PROD
• #<id> [<severity>] <title>
⚠️ 請登入 PROD 驗收。
確認正常後點「批准 Merge UAT」。
下次 T2 時間：<T2_time>T2 Complete — Flow 2 (UAT merged)
✅ Bug Fix Pipeline — Flow 2 完成
• #<id> [<severity>] <title>
🎉 Fix 已同步至 UAT。Flow 2 全流程完成。Emergency Hotfix
🚨 Emergency Hotfix — <PROD/UAT>
Bug: #<id> [<severity>] <title>
時間：<datetime>
部署人：<admin>
狀態：已部署，請立即驗收
需要跟進：<yes/no — UAT cherry-pick needed>Rollback
⚠️ Rollback 執行 — <environment>
原因：<brief reason>
回滾至：<version/commit>
時間：<datetime>
執行人：<admin>
狀態：已回滾，正在監控
下一步：<scheduled fix / investigation>Show full SKILL.md (604 more words)Show less
Adapting This Workflow to a New Project
When setting up a new project with this workflow:
- Define T1 and T2 — pick times based on traffic patterns and SLA
- Set severity policy — confirm which severities enter pipeline vs emergency hotfix
- Configure Telegram/notification channels — who receives which notifications
- Add DB columns —
fix_flow,found_in_env, and status enum (see Status Reference) - Implement Phase 1 + Phase 2 cron jobs — schedule at T1 and T2
- Add approval endpoints —
approve-prod,approve-uat-merge, batch variants - Add status badges + action buttons — frontend must reflect all statuses clearly
- Test the full cycle in UAT first — simulate a bug through both flows before going live
- Document rollback steps — specific to the project's tech stack and DB
Pre-Deploy Checklist (T1 / T2)
Run before every scheduled deploy window.
- DB backup confirmed — last backup < 24h, or trigger manual backup now
- Monitoring alerts active — error rate, response time, queue depth dashboards open
- On-call admin reachable — someone available to respond within 15 min post-deploy
- Change freeze check — not within a freeze window (see Change Freeze Policy)
- Rollback path clear — previous working commit/tag identified and noted
- Dependent services healthy — upstream/downstream APIs, DBs, message queues OK
- Disk + memory OK — server has headroom (>20% free disk, <80% memory)
Post-Deploy Monitoring
After each T1 or T2 deploy, monitor for a minimum of 10 minutes before standing down.
Metrics to Watch
| Metric | Healthy Threshold | Action if Breached |
|---|---|---|
| HTTP 5xx error rate | < 0.5% | Investigate immediately, consider rollback |
| API response time (p95) | < baseline + 20% | Check DB queries, cache hit rate |
| Memory usage | < 85% | Check for memory leaks in new code |
| CPU usage | < 80% sustained | Check for infinite loops or expensive queries |
| Login / auth success rate | > 99% | Auth regression — rollback candidate |
| Key business flow (e.g. task create) | Working end-to-end | Smoke test immediately post-deploy |
Smoke Test Sequence (2–3 min)
- Login with admin account
- Navigate to the affected feature
- Perform the action that triggered the bug
- Confirm fix is working
- Check 2–3 adjacent features for regression
- Check system logs for new errors
If any smoke test step fails → rollback immediately, do not wait.
Multi-Service Deploy (Cross-Service Fixes)
Scenario: A bug fix requires changes to more than one service (e.g. backend API + frontend, or service A + service B).
Deploy Order Principle
Always deploy in dependency order:
Backend (API) first → Frontend second
Shared library → Dependent services
DB migration → Application code
Never deploy in reverse order — it risks breaking in-flight requests.Coordination Steps
- Map dependencies — list all services affected and their dependency order
- Stage the deploys — do not deploy all services simultaneously
- Validate between services — after each service deploy, quick health check before next
- Single rollback plan — define the exact reverse order and what to check at each step
- Lock window — communicate to team that a multi-service deploy is in progress (no other deploys)
Status Tracking for Multi-Service
Tag the bug with affected services. Use release notes to list which service each fix applies to:
[backend] Fix: null pointer in task update handler
[frontend] Fix: error boundary not catching API timeoutChange Freeze Policy
Certain periods should have no scheduled pipeline deploys (T1/T2 suspended). Emergency hotfixes may still be approved by escalation.
Recommended Freeze Windows
| Period | Recommended Action |
|---|---|
| Public holidays | Suspend T1/T2. Emergency hotfix requires 2-person approval. |
| Lunar New Year (3 days) | Full freeze. P1 only with CTO sign-off. |
| Major client go-live week | Freeze for that client's system. Other systems normal. |
| End-of-month financial close | Freeze financial modules. Other modules normal. |
| Planned system maintenance | Coordinate freeze window in advance, notify stakeholders. |
Declaring a Freeze
- Update HEARTBEAT.md or project config with freeze start/end dates
- Notify team via Telegram/channel
- Pipeline cron jobs remain scheduled but agent checks freeze flag before executing
- Emergency hotfix during freeze: requires explicit approval from admin + one other senior (two-person rule)
Freeze Flag (implementation)
In pipeline config or environment variable:
DEPLOY_FREEZE=true # hard freeze, all deploys blocked
DEPLOY_FREEZE_MODULES=financial # module-specific freeze
DEPLOY_FREEZE_UNTIL=2026-02-05 # auto-lift dateQuick Reference Card
FLOW SELECTION:
Same version? → Flow 1
UAT ahead? → Flow 2
Critical/High? → Emergency Hotfix
Freeze window? → Block (escalate for emergency)
FLOW 1: confirmed → [T1] deployed_uat → [human] pending_prod → [T2] deployed_prod ✅
FLOW 2: confirmed → [T1] pending_prod → [T2] deployed_prod → [human] pending_uat_merge → [T2] uat_merged ✅
ROLLBACK: detect → confirm → execute → validate → document
SEVERITY:
low/medium → pipeline eligible
high/critical → emergency hotfix only
MULTI-SERVICE: backend first → validate → frontend → validate
PRE-DEPLOY: backup ✓ monitoring ✓ on-call ✓ freeze-check ✓ rollback-path ✓
POST-DEPLOY: monitor 10min → smoke test → stand down© LeoYeAI, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 1 other file in skills/tonic-system-deploy of LeoYeAI/openclaw-master-skills.
- SKILL.md
- _meta.json
Open the folder on GitHubat commit e5199b5
Compare with similar skills
Tonic System Deploy next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Tonic System Deploy this skillLeoYeAI/openclaw-master-skills | 2.2k | — | ~4.5k | Automated safety check: Pass | MIT | |
| Aspiremicrosoft/aspire.dev | 196 | 4 repos | ~1.1k | Automated safety check: Pass | MIT | |
| Operating Livekit Agentslivekit-examples/agent-starter-python | 264 | 1 repos | ~2.4k | Automated safety check: Pass | MIT | |
| Medusa Cloud Local Buildmedusajs/medusa-agent-skills | 228 | — | ~1k | Automated safety check: Notes | None | |
| Release Engineeringmagnus919/agent-skills | 116 | — | ~3.9k | Automated safety check: Pass | MIT | |
| Fastly Compute Deployment Debuggingdivinevideo/divine-mobile | 266 | — | ~1.3k | Automated safety check: Pass | MPL-2.0 |
Similar skills
- Official
Operating Livekit Agents
livekit-examples/agent-starter-python
Deploys and operates a LiveKit agent in production: shipping a version to LiveKit Cloud and rolling it back, secrets and configuration, the worker process model and prewarming, safe async inside…
Medusa Cloud Local Build
medusajs/medusa-agent-skills
Reproduces a Medusa Cloud build on your machine with mcloud local build, to debug build-failed deployments without pushing or waiting on Cloud.
Release Engineering
magnus919/agent-skills
Design, automate, and operate end-to-end software releases: release process models and pipelines (trunk-based development, CD stages, release trains), progressive delivery and feature flags…
Fastly Compute Deployment Debugging
divinevideo/divine-mobile
Debug Fastly Compute deployments that appear successful but return stale/wrong responses.
Frontend Forge Extension Operations
kubesphere/kubesphere
Runs the lifecycle of FrontendExtension resources in a Kubernetes cluster: create, rebuild, package, publish, unpublish, delete and debug stuck states.
More from LeoYeAI/openclaw-master-skills
All 1,235 skills in this repoDevOps Pipeline Management
LeoYeAI/openclaw-master-skills
Manages pipelines on a DevOps quality and efficiency platform through its OpenAPI: list workspaces and templates, create, update, run and cancel pipelines, and read run records.
Feishu Document Collaboration
LeoYeAI/openclaw-master-skills
Patches OpenClaw's Feishu extension so an edited document triggers an isolated agent session that reads the doc and replies inline, turning it into a live chat space.
Files Memory System
LeoYeAI/openclaw-master-skills
Multi-context memory management system for OpenClaw agents with group-isolated storage, global shared memory, workspace organization, and group-specific skills isolation.
GEO-Claw AI Visibility Agent
LeoYeAI/openclaw-master-skills
Runs a brand's AI-search visibility work end to end: diagnosing how AI platforms represent it, repositioning it, producing AI-optimized content and monitoring ongoing mentions.
Google Workspace CLI
LeoYeAI/openclaw-master-skills
Installs and authenticates the gws CLI, then automates Gmail, Drive, Sheets, Calendar, Docs, Chat and Tasks with ready-made recipes, persona bundles and security audits.
HealthFit Health Advisors
LeoYeAI/openclaw-master-skills
Runs four advisor roles, a fitness coach, nutritionist, data analyst and TCM practitioner, to build a health profile and track workouts, diet and wellness over time.
Related
Works with
Categories
Questions about Tonic System Deploy
What does Tonic System Deploy do?
Software deployment workflow for systems with separate UAT and PROD environments. Tonic System Deploy is an agent skill from LeoYeAI/openclaw-master-skills. Software deployment workflow for systems with separate UAT and PROD environments.
When should I use Tonic System Deploy?
Tonic System Deploy fits situations like: : planning a bug fix deployment; choosing between Flow 1 (UAT-first) and Flow 2 (PROD-first); handling emergency hotfixes; executing rollbacks.
How do I install Tonic System Deploy in Claude Code?
Run `npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a claude-code`. Or copy the skill folder (skills/tonic-system-deploy in LeoYeAI/openclaw-master-skills) into .claude/skills/tonic-system-deploy in your project. Claude Code loads it when a task matches its description.
How do I install Tonic System Deploy in Codex?
Run `npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a codex`. Or copy the skill folder (skills/tonic-system-deploy in LeoYeAI/openclaw-master-skills) into .agents/skills/tonic-system-deploy in your project. Codex loads it when a task matches its description.
Can I use Tonic System Deploy in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add LeoYeAI/openclaw-master-skills --skill tonic-system-deploy -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/tonic-system-deploy, .gemini/skills/tonic-system-deploy, .github/skills/tonic-system-deploy and .opencode/skills/tonic-system-deploy in your project.
What does Tonic System Deploy need to run?
Going by SKILL.md and its folder, Tonic System Deploy needs the command-line tools its instructions call (git and docker). Our summary lists: Docker.
Does Tonic System Deploy access the network?
SKILL.md contains no URLs. Its commands use git and docker, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Tonic System Deploy safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Tonic System Deploy use?
Tonic System Deploy is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Tonic System Deploy use?
About 4.5k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Tonic System Deploy?
Skills that share tags, products or a category with Tonic System Deploy: Aspire (microsoft/aspire.dev, 196 stars), Operating Livekit Agents (livekit-examples/agent-starter-python, 264 stars), Medusa Cloud Local Build (medusajs/medusa-agent-skills, 228 stars) and Release Engineering (magnus919/agent-skills, 116 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Tonic System Deploy?
LeoYeAI (a GitHub user) maintains it in LeoYeAI/openclaw-master-skills, which has 2,160 GitHub stars. The repository holds 1,235 skills in this directory. The repository was last updated on July 20, 2026.
Source: LeoYeAI/openclaw-master-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.