unit-test-creating-test-plan
When to Apply This Skill
- A stakeholder or QA team needs a human-readable summary of the testing strategy
- A sprint or feature requires formal test documentation before work begins
- A compliance or audit process requires evidence of test planning
- A developer wants a Markdown test plan committed alongside their test file
Atomic Skills to Load First
Read these files before executing any step:
-
../unit-test-authoring-test-plans/SKILL.md— Full 10-section test plan structure, BDD/Gherkin scenario format, coverage target tables, entry/exit criteria, approval tables, and output format guidance for both Markdown and .docx -
../unit-test-analyzing-code-coverage/SKILL.md— Used to populate the Coverage Targets section (Section 6) with accurate current vs target metrics and gap commentary
Execution Steps
Read references/index.md before executing any step.
Step 1 — Gather Inputs
Collect as many of the following as are available:
- Generated test suite (for populating the test cases table in Section 5)
- Coverage report or gap analysis (for Section 6 — Coverage Targets)
- Requirements, user stories, or PRD (for scope, objectives, and BDD scenarios)
- Preferred output format: md (default) or docx
Step 2 — Author the Test Plan
Follow the full 10-section structure from ../unit-test-authoring-test-plans/SKILL.md:
- Cover Page / Header
- Scope (in scope, out of scope, target environments)
- Test Objectives (measurable goals)
- Test Strategy (framework, coverage tool, execution method, BDD flag)
- Test Cases Summary Table (ID, name, category, priority, status)
- Coverage Targets (current vs target per coverage type)
- Dependencies and Risks
- Entry and Exit Criteria
- Defect Management
- Approvals
Include BDD / Gherkin scenarios in Section 4 when requirements or user stories are provided as input.
Step 3 — Format Output
- md format: emit directly as Markdown, ready to commit to the repository
- docx format: apply the docx skill to convert the Markdown into a professionally formatted Word document with heading styles and page numbers
Output Deliverables
test_plan_<feature_or_module>.md <- always produced
test_plan_<feature_or_module>.docx <- produced only when --format docx is requested
More from wizeline/sdlc-agents
editing-pptx-files
Use this action any time a .pptx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates, layouts, speaker notes, or comments. Trigger whenever the user mentions \"deck,\" \"slides,\" \"presentation,\" or references a .pptx filename, regardless of what they plan to do with the content afterward. If a .pptx file needs to be opened, created, or touched, use this action.
25editing-docx-files
Use this action whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of \"Word doc\", \"word document\", \".docx\", or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a \"report\", \"memo\", \"letter\", \"template\", or similar deliverable as a Word or .docx file, use this action. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.
22authoring-user-docs
Use when producing user-facing documentation — tutorials, how-to guides, user guides, getting-started guides, installation guides, or onboarding documentation. Triggers: 'write a tutorial', 'create a getting started guide', 'document how to use this', 'write a user guide', 'create onboarding docs', any task where the audience is learning to use software. Always load authoring-technical-docs first.
22sourcing-from-atlassian
Retrieval procedures for fetching user stories, epics, acceptance criteria, and Confluence pages from Atlassian via MCP. Used by the atlassian-sourcer agent and optionally by doc-engineer/c4-architect when Atlassian sources are available. Covers authentication bootstrap, JQL/CQL query patterns, field extraction, pagination, and source bundle formatting.
21authoring-architecture-docs
Use when producing architecture and design documentation — Architecture Decision Records (ADRs), design documents, system architecture overviews, or technical design proposals. Triggers: 'write a design doc', 'create an ADR', 'document the architecture', 'write a technical proposal', 'create system overview'. Always load authoring-technical-docs first.
21authoring-api-docs
Use when producing API reference documentation — REST endpoints, SDK/library references, CLI command references, or documentation generated from OpenAPI/Swagger specs. Triggers: 'document this API', 'generate API reference', 'write SDK docs', 'document these endpoints', any task involving source code with HTTP handlers, route definitions, or OpenAPI specs. Always load authoring-technical-docs first.
20