steady-flight
From the author
Appa's steady flight for executing a plan and for behavior-preserving refactors. Use when a plan, spec, or list of units already exists and needs faithful step-by-step implementation, or for a refactor (rename, extract, inline, dedupe, move) that must change structure and keep behavior. Pins the behavior first, executes each unit with its check, and stops rather than improvising when the plan stops matching reality.
Install
npx skills add tmcfarlane/team-avatar --skill steady-flight -a claude-code
Installs to .claude/skills/steady-flight/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 83
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- safe-landingtmcfarlane/team-avatarAppa's safe landing for shipping a green stack. Appa never sets down until he has seen the ground is solid. Use for "land it", "ship the stack", "merge when ready", "merge it", or landing PRs after `long-flight` reports merge-ready. Verifies each PR independently, lands only the contiguous verified run from the root bottom-up under a head guard, and reads back every landing. Needs the user's landing authority.Other★ 111
- plan-a-changetestdouble/hanPlans an architecture-driven change to code that already exists: module boundaries, type responsibilities, layering, coupling, and the public surface a revision moves. Produces a buildable change plan that names the types, modules, and methods involved and records the surface delta each change makes. Use when the user wants to plan, scope, or sequence a restructure, extraction, split, consolidation, responsibility shift, or API revision of existing code, including "these responsibilities are wrong, plan the fix". Does not assess an area and stop at findings — use architectural-analysis. Does not specify new behavior — use plan-a-feature. Does not diagnose a bug — use investigate. Does not write the code — use refactor to restructure it or tdd to build it.Planning★ 327
- plan-executionthiientv/godmodeExecutes an existing implementation plan task by task, preserving its interfaces and constraints, running focused checks after each slice, and stopping when the repository differs from the plan. Use when a written plan or approved checklist already exists. Not for inventing the plan, debugging an unexplained failure, or broad unscoped cleanup.Planning★ 99
- process-designcbrock84/headcountDesigns, documents, and fixes operational processes — mapping the current state, finding where work actually stalls, redesigning the flow, and building controls that hold. Use this when the same failure keeps recurring, when a handoff between teams is unreliable, when onboarding a repeated task, when work takes far longer than the work itself, or when deciding whether to automate, standardize, or eliminate a process.Design★ 2.2K
- autopilotOutlineDriven/outline-driven-developmentUse when a human has an approved delivery plan and wants the full chain run under phase gates. Not for planning, open-ended debugging, or single-step execution: use work directly.Planning★ 55
- planericrisco/rsc-harnessUse when an approved, clarified spec must become a technical blueprint before any code — the SDD phase between clarify and tasks: architecture, contracts, data flow, testing strategy, sequencing and risks, at structure altitude, never framework syntax. NOT the what/why spec (that is `specify`), NOT the ambiguity sweep (that is `clarify`), NOT the task breakdown (that is `tasks`), NOT the code (that is `implement`).Planning★ 350
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in