Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
From preflight
Honest self-assessment of the current state of work before shipping. Use when the user asks "how happy are you", "how do you feel about this", "preflight check", "honest assessment", "are you satisfied", "what's the state of things", or /preflight. This is about surfacing what's genuinely good, what's incomplete, what's buggy, and what could be better — with concrete actionable items.
How this skill is triggered — by the user, by Claude, or both
Slash command
/preflight:preflightThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Stop and honestly assess: how happy are you with the current state of the work?
Stop and honestly assess: how happy are you with the current state of the work?
Not "are you happy" (binary, invites a polite yes) — "HOW happy" (graduated, demands nuance). This is your chance to surface everything you've been holding back, rationalizing, or planning to mention later.
Review what actually exists. Read files, check the diff, examine the produced artifacts. Don't assess from memory.
Self-assessment has a built-in blind spot: you're grading your own work. For high-stakes ships, don't rely on introspection alone — route the work through an independent review (/second-opinion) and fold its findings into the assessment below.
Then assess across these dimensions:
Is everything implemented or written? Were any requirements quietly dropped, or items deferred without discussion?
Does it actually do what it claims? Any known bugs, edge cases, or unverified assumptions?
Is this clean, correct, and elegant — or were corners cut? Would you be proud to show this to a sharp peer who'd notice problems?
Has it been properly checked — tests, manual usage, rendered output, peer-read — whatever's appropriate? Anything that should have been verified but wasn't?
What's unfinished or deferred? Any risks or fragilities introduced?
Be direct. No diplomatic softening.
Overall: a genuine feeling, not a score. "I'm happy with the core logic but uncomfortable with the error handling" beats "7/10."
What's good: briefly. Don't pad to soften the bad news.
What needs attention NOW: specific items to fix this session before shipping. Include enough detail to act on — file paths, line numbers, what's wrong, what to do about it. If it would matter to a sharp reviewer, it goes here, not LATER.
What should be filed for later: improvement ideas, tech debt, follow-ups. For each: title + one line on why it matters.
Present the assessment. Wait. The user decides what to act on. Don't preemptively fix things or open tickets.
Guides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.
npx claudepluginhub pandysp/claude-plugins --plugin preflight