Testing & Debugging Skills

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

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

Use when working with Terraform (.tf, .tfvars), Ansible (playbooks, roles, inventory), Docker (Dockerfile, docker-compose.yml), CloudFormation, or any infrastructure-as-code files — provides validation workflows, tool chains, and common mistake…

You MUST use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design through Socratic dialogue before implementation. Also use when the user says "I want to add", "let's design", "what if we", "I have an idea", or when a design discussion is happening. Invoked by /shipyard:brainstorm for requirements gathering.

Use when running any multi-step Shipyard workflow under Codex — build, audit, plan, ship, review, research, or map. Explains how Shipyard's parallel-agent workflows degrade to inline sequential execution in Codex, and routes intent to the right workflow skill. Trigger when the user says "build the plan", "audit this", "ship it", "review the code", "run the shipyard build", or asks how Shipyard works in Codex.

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 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.

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

Use when performing brownfield analysis on an existing codebase under Codex — onboarding to a new project, generating codebase documentation, or understanding legacy code. Trigger when the user says "map this codebase", "help me understand this code", "document this project", "I just inherited this repo", or runs shipyard init on existing code. This is the Codex inline-sequential form of the mapper agent.

Use when conducting domain research, evaluating technology options, investigating ecosystem choices, or gathering knowledge for a development phase under Codex. Trigger when the user says "research X", "what are our options for", "evaluate these libraries", "what's the best approach to", or before planning a phase. This is the Codex inline-sequential form of the researcher agent.

Use when reviewing code under Codex — verifying spec compliance, conducting quality review after a build, or checking that an implementation matches its plan. Trigger when the user says "review this", "review the implementation", "does this match the plan", "check the code quality", or after a Shipyard build completes. This is the Codex inline-sequential form of the reviewer agent.

Use when delivering or releasing a completed Shipyard phase under Codex — final verification, pre-ship security audit, documentation, and release. Trigger when the user says "ship it", "ship this phase", "release this", "we're done — finalize", or "run the shipyard ship workflow". This is the Codex inline-sequential form of the /shipyard:ship orchestration.

Use to inspect or manage Shipyard project state under Codex — show status, resume a previous session, cancel/pause in-progress work, or roll back to a checkpoint. Trigger when the user says "shipyard status", "what's the status", "resume", "continue where we left off", "cancel", "pause this", "roll back", or "restore the checkpoint". Codex has no SessionStart hook, so this skill loads state on demand.

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.

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 pyramid.

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 creating, editing, or improving skills, or when a skill isn't triggering correctly. Also use when editing any SKILL.md file, writing skill descriptions, or debugging why a skill doesn't activate. Triggers on "create a skill", "write a skill", "new skill", "improve this skill", "skill isn't triggering", or when reviewing skill quality and effectiveness.

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.