lgbarn

Use when about to claim work is complete, fixed, or passing — before committing, creating PRs, or moving to the next task. Also use when you catch yourself using words like "should", "probably", or "seems to" about work state, or when expressing satisfaction ("Great!", "Done!") before running verification commands. Evidence before assertions, always.

Use when shipping features with public interfaces that lack docs, generating documentation, updating README files, writing API docs, creating architecture documentation, or when documentation is incomplete or outdated. Also use when adding breaking changes, implementing complex algorithms, or before shipping any phase — if a public function lacks a docstring, this skill applies.

Captures session context into .shipyard/HANDOFF.md so the next session can resume without losing progress.

Use when encountering any bug, test failure, unexpected behavior, or error message — before proposing any fixes. Also use when you see tracebacks, exceptions, "not working" complaints, build failures, performance problems, or integration issues. If you're tempted to "just try changing X and see if it works", this skill applies. Systematic root cause investigation always comes before fix attempts.

Use when writing tests, structuring test suites, choosing test boundaries, or debugging test quality issues like flakiness, over-mocking, or brittle tests. Also use when deciding between unit/integration/E2E tests, when tests break during refactoring (sign of testing implementation details), or when test setup exceeds 20 lines. Covers AAA structure, DAMP naming, mock boundaries, and the testing py

Import a spec-kit feature spec into Shipyard, replacing brainstorming. Use when a spec-kit feature directory exists with spec.md.

Use when starting any conversation, when the user asks "what should I do", "help me", "how do I use shipyard", or "where do I start". Establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions. Also use when unsure which skill or command applies to the current situation.

Import a handwritten spec document into Shipyard, replacing brainstorming. Use when a freeform spec, requirements, or design document exists.

Use when you have a written implementation plan to execute, either in the current session with builder/reviewer agents or in a separate session with review checkpoints. Also use when the user says "build this", "implement this", "execute the plan", "run the plan", or when a plan file has been loaded with independent tasks suitable for agent dispatch.

Use when a phase or milestone is complete and you need to extract reusable knowledge, before shipping, or when reflecting on completed work. Also use when the user says "what did we learn", "capture lessons", "retrospective", "wrap up", "ship this phase", or "done with this phase". If a phase is about to ship without lesson capture, this skill must activate.

Use when you have a spec, requirements, or design for a multi-step task — before touching code. Also triggers on "plan this", "break this down", "create tasks", "decompose this feature", or when a task clearly needs more than 2-3 steps to implement. If you're about to start building without a plan, or writing vague tasks like "implement feature X" without file paths and verification commands, this

Use when implementing any feature or bugfix, before writing implementation code. Also use when touching test files (*.test.*, *.spec.*, *_test.go), when plan tasks have tdd="true", or when the user says "test first", "write tests", "TDD", or "red green refactor". If you're about to write production code without a failing test, this skill applies.