Land And DeployCAUTION
The most comprehensive Claude Code guide: agentic workflows, hooks, skills, MCP servers, quizzes, and production-ready templates. 430K+ lines.
Overview
The most comprehensive Claude Code guide: agentic workflows, hooks, skills, MCP servers, quizzes, and production-ready templates. 430K+ lines.
d90170da4369OBSERVED · 2026-10-07What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: land-and-deploy
description: Merge PR, wait for CI, verify deploy, run canary. The complete landing pipeline.
argument-hint: "[--skip-checks] [--env staging|production]"
effort: high
disable-model-invocation: true
---
# Land and deploy
Complete landing pipeline: merge the PR, wait for CI, verify the deployment, run a health check.
Picks up where `/ship` left off. `/ship` creates the PR. This command merges it and verifies production.
**Non-interactive by default.** The user said "land it", so land it. Stop only for the critical readiness gate and hard blockers.
## Instructions
### Step 1: Pre-flight
```bash
# Verify GitHub CLI is authenticated
gh auth status
# Detect PR from current branch (or use argument if provided)
gh pr view --json number,state,title,url,mergeStateStatus,mergeable,baseRefName,headRefName
```
**Stop conditions:**
- GitHub CLI not authenticated → "Run `gh auth login` first"
- No PR exists → "No PR found for this branch. Run `/ship` first."
- PR already merged → "PR is already merged."
- PR is closed → "PR is closed. Reopen it first."
---
### Step 2: CI status check
```bash
# Check current CI status
gh pr checks --json name,state,status,conclusion
# Check for merge conflicts
gh pr view --json mergeable -q .mergeable
```
**Stop conditions:**
- Required checks FAILING → show failing checks, stop
- `mergeable` is `CONFLICTING` → "PR has merge conflicts. Resolve them and push before landing."
- Required checks PENDING → proceed to Step 3 (wait for CI)
- All checks passing → skip to Step 3.5 (readiness gate)
---
### Step 3: Wait for CI (if pending)
```bash
# Watch CI checks with 15-minute timeout
gh pr checks --watch --fail-fast
```
- CI passes → continue to Step 3.5
- CI fails → stop, show failures
- Timeout (15 min) → "CI has been running for 15 minutes. Investigate manually."
Record CI wait duration for the deploy report.
---
### Step 3.5: Pre-Merge readiness gate
**This is the one critical confirmation before an irreversible merge.** Collect all evidence, then get explicit approval.
#### Review staleness check
```bash
# How many commits since the last review in this branch?
git log --oneline $(git merge-base HEAD origin/main)..HEAD | wc -l
# What changed after any review was done?
git log --oneline -10
```
Staleness thresholds:
- 0–3 commits since review → CURRENT (green)
- 4+ commits, touching code → STALE (yellow, review may not reflect current code)
- No review found → NOT RUN (yellow)
#### Test results
```bash
# Run tests now (fast tests only)
npm test 2>/dev/null || pnpm test 2>/dev/null || \
pytest --tb=short -q 2>/dev/null || \
go test ./... 2>/dev/null
# Check exit code
echo "Tests exit code: $?"
```
Failing tests = BLOCKER. Cannot merge with failing tests.
#### Documentation check
```bash
# Were CHANGELOG and docs updated on this branch?
git diff --name-only $(git merge-base HEAD origin/main)...HEAD -- \
README.md CHANGELOG.md ARCHITECTURE.md CONTRIBUTING.md CLAUDE.md VERSION
```
If CHANGELOG.md and VERSION were NOT modified and the diff includes new features → WARNING.
#### Readiness report
Present a summary and ask for explicit confirmation:
```
╔══════════════════════════════════════════════════════════╗
║ PRE-MERGE READINESS REPORT ║
╠══════════════════════════════════════════════════════════╣
║ PR: #NNN: [title] ║
║ Branch: feature-branch → main ║
║ ║
║ REVIEWS ║
║ Review: CURRENT / STALE (N commits) / NOT RUN ║
║ ║
║ TESTS ║
║ Fast tests: PASS / FAIL (blocker) ║
║ ║
║ DOCUMENTATION ║
║ CHANGELOG: Updated / NOT UPDATED (warning) ║
║ VERSION: Bumped / NOT BUMPED (warning) ║
║ ║
║ WARNINGS: N | BLOCKERS: N ║
╚══════════════════════════════════════════════════════════╝
Options:
A) Merge (all checks green)
B) Don't merge yet, address warnings first
C) Merge anyway (I understand the risks)
```
If the user chooses B, list exactly what needs to be done and stop.
---
### Step 4: Merge the PR
```bash
# Merge (auto-detect method from repo settings, delete branch after)
gh pr merge --auto --delete-branch
# Fallback if auto-merge is not enabled
# gh pr merge --squash --delete-branch
```
Record the merge commit SHA and timestamp.
If merge fails with permission error → "You don't have merge permissions. Ask a maintainer to merge."
If merge queue is active, poll until merged:
```bash
# Poll every 30 seconds, timeout after 30 minutes
gh pr view --json state -q .state
```
---
### Step 5: Platform detection
Detect how this project deploys so we know what to verify.
```bash
# Detect platform from config files
[ -f fly.toml ] && echo "PLATFORM: fly"
[ -f render.yaml ] && echo "PLATFORM: render"
[ -f vercel.json ] || [ -d .vercel ] && echo "PLATFORM: vercel"
[ -f netlify.toml ] && echo "PLATFORM: netlify"
[ -f Procfile ] && echo "PLATFORM: heroku"
[ -f railway.toml ] && echo "PLATFORM: railway"
# Detect GitHub Actions deploy workflows
for f in .github/workflows/*.yml .github/workflows/*.yaml; do
[ -f "$f" ] && grep -qiE "deploy|release|production|cd" "$f" 2>/dev/null && echo "DEPLOY_WORKFLOW: $f"
done
# Classify diff scope (frontend / backend / docs / config)
git diff --name-only $(git merge-base HEAD~1 origin/main)...HEAD | \
awk '{
if (/\.(css|scss|tsx|jsx|html|svg)$/ || /components|pages|public\//) f=1;
if (/api\/|server\/|backend\/|\.(go|py|rb|java)$/) b=1;
if (/README|CHANGELOG|docs\/|\.(md)$/) d=1;
Trust audit
CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | WARN |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (2)
whitepapers/recap-cards/en/_extensions
whitepapers/recap-cards/fr/_extensions
Gates applied: no_behavioural_pass.
d90170da4369full audit observations/trust-audit/skill/florianbruniaux__land-and-deploy.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-07 | d90170da4369 | CAUTION | B | 89 | first audit |
Questions
What does the Land And Deploy skill do?
The most comprehensive Claude Code guide: agentic workflows, hooks, skills, MCP servers, quizzes, and production-ready templates. 430K+ lines.
Is Land And Deploy safe to install?
With care. The audit graded it B (89/100) and found 2 things worth knowing before you trust this skill, listed below with the exact line each was found on.
What can Land And Deploy access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (d90170da4369), read on 2026-10-07. The repository is watched, and a new audit runs when it changes — this is the first audit.