mcpField
E
executing-plans-preflight

executing-plans-preflight

github.com/shihyuhoDevelopment037 installsUpdated 6d ago
Repository

About executing-plans-preflight

Executing Plans Preflight is a semi-automatic git-state gate for developers preparing to implement a plan. It checks branch context, worktree cleanliness, and remote sync, proposing changes that require confirmation before execution.

Key features

  1. 01Detects default branch and branch context
  2. 02Checks staged, unstaged, and untracked files
  3. 03Fetches and checks remote synchronization
  4. 04Proposes branch creation or rebase with confirmation
  5. 05Allows dirty-worktree override

Use cases

  1. 01Prepare a repository before implementation
  2. 02Identify uncommitted work before switching context
  3. 03Check whether a branch is behind or diverged

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/shihyuho/skills --skill executing-plans-preflight

After installing, type/executing-plans-preflightin Claude Code to confirm it loaded.

Bundled filesREADME.md

Details

From the project README

Executing Plans Preflight

Semi-automatic git state gate. Detects issues, proposes fixes, executes on confirmation. Run this before any implementation work begins — it ensures git state is ready so you start from a clean, correct baseline.

Not in a git repo? Say Not a git repository — skipping preflight. and move on.

Checks

Run in order. Pass silently when nothing is wrong — only speak up when there is something to fix.

1. Branch Context

Detect default branch via origin/HEAD. Fallback: treat main/master as default if detection fails.

  • Detached HEAD → ask which branch to switch to (cannot infer).
  • On default branch → infer a branch name from the plan in conversation (title → kebab-case, prefix with conventional commit type: feat/, fix/, docs/, refactor/, perf/, test/, chore/, ci/, build/; default feat/). Propose it, let user confirm or rename, then git switch -c. No plan in conversation? Ask directly — don't guess from filesystem.
  • Otherwise → silent pass.
2. Worktree Clean

Run git status --porcelain. Everything counts as dirty (staged, unstaged, untracked).

  • Clean → silent pass.
  • Dirty → list paths, ask user to resolve or say "continue" to override. Record the override — Check 3 needs to know. Don't help with commit/stash; that's the user's call, because commit scope and message are conscious decisions that shouldn't be buried inside preflight.
3. Remote Sync

Run git fetch. If fetch fails, warn and continue with local info — don't claim remote state is fresh when it isn't.

  • No upstream / ahead / up-to-date → silent pass.
  • Upstream gone → ask: clear tracking or recreate?
  • Behind/diverged → propose git pull --rebase. If dirty files were overridden in Check 2, warn that pull may conflict and offer to skip sync.

New branches from Check 1 have no upstream — that's expected, don't push.

Report

One-line conclusion after all checks. Each fix gets its own line before it.

Switched to `feat/add-auth` (was on main)
Preflight passed. Ready to go.

If dirty files were overridden, end with Proceeding with uncommitted changes. instead of Ready to go.

Why these guardrails exist

  • Confirm before executing — git operations are hard to undo; one wrong switch -c or pull --rebase on the wrong branch can cost real work.
  • Allow dirty override — blocking unconditionally was v2's biggest friction point. The user knows their working state better than preflight does.
  • Never push — preflight manages local state only. Publishing is a separate, deliberate step.

Comments

Markdown supported