deploy-from-stale-worktree-silent-rollback SKILL.md skillA
deploy-from-stale-worktree-silent-rollback from wan-huiyan/agent-traffic-control is an agent skill: a SKILL.md folder an AI agent loads when a task calls for it.
mdr add wan-huiyan/agent-traffic-control/deploy-from-stale-worktree-silent-rollback@v1.2.0Pins v1.2.0 in mdr.lock. Pin the fingerprint instead.
- Audit grade
- A, 17 of 17 checks passed
- Kind
- SKILL.md skill
- Repository
- wan-huiyan/agent-traffic-control
- Path
plugins/agent-traffic-control/skills/deploy-from-stale-worktree-silent-rollback/SKILL.md- Versions recorded
- 4
- Latest version
- v1.2.0, committed Aug 11, 2026
- First version recorded
- May 29, 2026
- Size
- 21,709 bytes
- Repository stars
- 3
- License
- MIT
Diagnose "I deployed a new Cloud Run / Docker image but a bunch of recently merged fixes regressed in production." Use when: (1) the deploy script does `gcloud builds submit ... "${SCRIPT_DIR}"` or `docker build <dir>` (build context = local filesystem, NOT a git ref), (2) the user has many git worktrees / multiple checkouts of the same repo, (3) the user reports "redeployed but the fix from PR #X isn't live" or "lots of fixes regressed after my deploy", (4) the deployed revision created at…
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# Deploy from a stale worktree silently rolls back merged fixes
## Problem
The user merged a PR (or many PRs), redeployed the serving service, and
reports the fix isn't live — sometimes "a lot of fixes regressed". The
deployed image is brand new (recent timestamp, latest revision) and the
deploy succeeded green. The diff between code and what's deployed is
*not* a baking issue, *not* a browser cache issue — the **image itself
contains old code**.
This happens when the deploy script's build context is the local
filesystem (`gcloud builds submit ... "${LOCAL_DIR}"`,
`docker build <dir>`, `gcloud run deploy --source <dir>`, `kaniko
--context dir://...`) and the user runs it from a stale checkout. With
many git worktrees, it is easy to be sitting in `worktrees/foo/` 21
commits behind `main` and not notice — the deploy ships whatever is on
disk.
## Trigger conditions
All of these are typical:
1. The repo has a deploy script that uses one of:
- `gcloud builds submit --tag=... "${SCRIPT_DIR}"` (no commit SHA tag)
- `docker build -t ... <local-dir>` then push
- `gcloud run deploy --source <local-dir>`
2. The user has multiple checkouts of the same repo (worktrees,
…Read the whole file at its exact version.
How to install
mdr add wan-huiyan/agent-traffic-control/deploy-from-stale-worktree-silent-rollback@sha256:f987839313f96e10The line at the top of this page pins the label v1.2.0, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
[](https://markdownregistry.com/a/art_i6wah4z7xkh5be76)
3 badge image fetches in 30 days. What the badge shows.
Versions
The registry has recorded 4 versions of this file, between May 29, 2026 and Aug 11, 2026, about one every 25 days.
| version | committed | commit | size | audit | |
|---|---|---|---|---|---|
| v1.2.0 latest | 2026-08-11 | f274e4b | 21,709 B | A | view · diff |
| v1.2.0 | 2026-08-05 | e3930cf | 21,718 B | A | view · diff |
| v1.2.0 | 2026-07-08 | f1254dd | 22,077 B | A | view · diff |
| v1.2.0 | 2026-05-29 | 059688a | 22,046 B | A | view |
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (21709 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
wan-huiyan/agent-traffic-control · 3 stars · license MIT · pushed 2026-09-22 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_i6wah4z7xkh5be76 GET https://markdownregistry.com/api/v1/resolve?ref=wan-huiyan/agent-traffic-control/deploy-from-stale-worktree-silent-rollback GET https://markdownregistry.com/api/v1/blob/f987839313f96e101a88bda527711d233afe8fbf46be9f715a53d13f634500d9
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
Guides: the SKILL.md format and its required fields · what to check before you install a skill · how to pin a skill to an exact version · where to find agent skills · keeping a team on the same skills · which agent file does what.