James Cruce d2e2618474 fix(land-and-deploy): correct the --auto failure diagnosis in Step 4 ... Step 4 says `--auto` failing means "repo doesn't have auto-merge enabled". That is only one of two causes, and in practice it is the rarer one. `--auto` only QUEUES a merge behind pending required checks. When every required check has already settled -- or the repo declares no required status checks at all -- GitHub considers the PR immediately mergeable and rejects enablePullRequestAutoMerge with "Pull request is in clean status" or "Pull request is in unstable status". Auto-merge being enabled makes no difference. A repo with zero required status checks takes the direct path 100% of the time, and so does any repo whose CI finishes before Step 4 runs. The flow itself is fine -- the direct-merge fallback already handles both cases. The problem is the recorded reason: an operator reading MERGE_PATH=direct is told to go check whether auto-merge is enabled, which sends them to the wrong setting. I lost time to exactly that on a repo where auto-merge was enabled the whole time and the ruleset simply had no required checks. Also adds --squash to the --auto invocation. The fallback squashes, so without it the two paths merge with different strategies depending on which one happens to be taken. Docs-only. Regenerated with `bun run gen:skill-docs` (and verified clean for --host codex and --host factory); output is idempotent on re-run, so the Skill Docs Freshness gate stays green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-02 14:22:30 -04:00
..
SKILL.md	fix(land-and-deploy): correct the --auto failure diagnosis in Step 4	2026-08-02 14:22:30 -04:00
SKILL.md.tmpl	fix(land-and-deploy): correct the --auto failure diagnosis in Step 4	2026-08-02 14:22:30 -04:00