Test Plan Create

If no arguments are provided and a strategy file was just generated by /strat.create or /strat.refine in this session, use it automatically — proceed directly to Step 1.

Interactive fallback

If no arguments are provided and no strategy file is available from the current session, ask the user for:

Required

1. Strategy Jira key: A RHAISTRAT Jira key (e.g., RHAISTRAT-400)

Optional

2. ADR file path: Local path to an exported ADR document (markdown, text, or PDF) for additional technical detail (API specs, data models, etc.)
3. ADR link: Google Doc URL (stored as reference in metadata, not fetched)
4. Feature directory name: snake_case name for the feature directory (e.g., mcp_catalog). If not provided, derive from the feature name.

Process

Step 0: Pre-flight Checks

0.1 Python dependencies

Run uv run python scripts/frontmatter.py schema test-plan via Bash. If it fails with a PyYAML import error, ask the user to install dependencies:

uv pip install -r requirements.txt

Do NOT proceed until this succeeds.

0.2 MCP Integration

Verify that the Atlassian MCP integration is available by attempting to use the mcp__atlassian__getJiraIssue tool.

If the MCP tool is not available:

1. Inform the user that Jira MCP integration is required to fetch strategy details
2. Ask the user to set up the official Atlassian MCP server (see https://support.atlassian.com/atlassian-rovo-mcp-server/docs/getting-started-with-the-atlassian-remote-mcp-server/)
3. Do NOT proceed until MCP is available or the user provides a local strategy file from artifacts/strat-tasks/ as an alternative

If the MCP tool is available, proceed to Step 1.

Step 1: Gather Information

1. Strategy: If a Jira key was provided, fetch it using mcp__atlassian__getJiraIssue. The strategy contains both the technical approach (HOW) and the business need (WHAT/WHY). If auto-detected, read the local file from artifacts/strat-tasks/.
2. ADR (if provided): Read the ADR file for additional technical detail (API endpoints, data models, implementation specifics).

Step 2: Analyze (Parallel Sub-Agents)

Invoke these three forked analyzer skills in parallel using the Skill tool. Each runs in its own isolated context with the strategy and ADR content.

Pass the full strategy content (and ADR content if available) inline in the skill arguments so each sub-agent has the source material.

• test-plan.analyze.endpoints: Extracts feature scope (in-scope, out-of-scope, test objectives) and identifies API endpoints/methods under test. Produces findings for Sections 1 and 4.
• test-plan.analyze.risks: Determines test levels, test types, priority definitions, risks with mitigations, and non-functional requirement assessments. Produces findings for Sections 2, 7, and 8.
• test-plan.analyze.infra: Identifies test environment configuration, test data, test users, infrastructure, and tooling requirements. Produces findings for Sections 3 and 9.

Once all three sub-agents return:

1. Merge their structured findings into the test plan template (Step 3)
2. Collect their ## Gaps sections for Step 3.5

• Do NOT add information that was not present in any sub-agent's output

Step 3: Generate Files

1. Create the feature directory using Bash: mkdir -p <feature_name>/test_cases
2. Read the template from ${CLAUDE_SKILL_DIR}/test-plan-template.md using the Read tool
3. Generate <feature_name>/TestPlan.md by filling in the template with the gathered information. Follow the template structure exactly — do not add, remove, or reorder sections. Do NOT write frontmatter manually — Step 3.1 handles it.
4. For Section 10.2 ({Endpoint/Method} Coverage): fill in the Endpoint column using the endpoints identified in Section 4. Leave the Test Cases and Coverage columns empty — they will be filled later in the process.
5. Generate <feature_name>/README.md with:
   • Feature name and one-line description
   • Links to Jira strategy, ADR (if provided)
   • Link to TestPlan.md
   • Brief mention of where automated tests will be implemented

Step 3.1: Set Frontmatter

After generating TestPlan.md, set its frontmatter using the frontmatter.py script via Bash. This validates the metadata against the schema before writing.

uv run python scripts/frontmatter.py set <feature_name>/TestPlan.md \
    feature="<feature_name>" \
    strat_key=<RHAISTRAT_KEY> \
    version=1.0.0 \
    status=Draft \
    author="<team_name>" \
    additional_docs="<comma-separated list of doc links, or []>"

• additional_docs: include ADR link and any other document links provided by the user. Use [] if none.
• last_updated is auto-set to today's date by the script.
• reviewers defaults to [].

If the script exits with an error, fix the field values and retry — do not write frontmatter by hand.

Step 3.5: Collect Gaps and Prompt for Additional Documents

After generating the test plan, collect all gaps reported by the three sub-agents from Step 2.

1. Extract gaps from each sub-agent's ## Gaps output section

2. Write <feature_name>/TestPlanGaps.md with all gaps organized by source sub-agent:

   # Gaps — <Feature Name>
   
   ## Scope & Endpoints
   {gaps from test-plan.analyze.endpoints, or "No gaps identified."}
   
   ## Test Strategy & Risks
   {gaps from test-plan.analyze.risks, or "No gaps identified."}
   
   ## Environment & Infrastructure
   {gaps from test-plan.analyze.infra, or "No gaps identified."}
   

3. Set frontmatter on TestPlanGaps.md using the frontmatter.py script:

   uv run python scripts/frontmatter.py set <feature_name>/TestPlanGaps.md \
       feature="<feature_name>" \
       strat_key=<RHAISTRAT_KEY> \
       status=Open \
       gap_count=<number_of_gaps>
   

   • gap_count: total number of individual gaps across all three sections
   • If no gaps were identified, set status=Resolved and gap_count=0
   • last_updated is auto-set by the script

4. If gaps exist, present the user with a structured action menu via AskUserQuestion. List the gaps first, then offer numbered options. Example:

   The following gaps were identified in the test plan:

   • Endpoint paths for the catalog API are not specified — an API spec or ADR would resolve this
   • RBAC roles are unclear — a feature refinement doc would help
   • KServe CSI configuration details are missing — a design doc would resolve this

   What would you like to do?

   1. Provide documents — paste file paths (ADR, API spec, design doc) to resolve gaps
   2. Proceed to review — continue with the test plan as-is (gaps will be noted in TestPlanGaps.md)
   3. Proceed to review + generate test cases — continue and automatically run /test-plan.create-cases after review

5. If the user chooses option 1: Read the provided documents, re-run only the relevant sub-agents from Step 2 with the new material, update the test plan, update TestPlanGaps.md (removing resolved gaps, adding any new ones), update the gaps frontmatter (gap_count, status), then present the menu again with remaining gaps (if any).

6. If the user chooses option 2 or no gaps exist: Proceed to Step 4.

7. If the user chooses option 3: Proceed to Step 4, and after the review is complete, automatically invoke /test-plan.create-cases with the feature directory.

Step 4: Review, Score, and Improve

After the gaps flow is complete, invoke the internal test-plan.review skill with the feature directory.

The reviewer runs the quality rubric (5 criteria, 0-2 each, 10-point scale):

• Specificity — feature-specific vs boilerplate
• Grounding — traceable to source material vs fabricated
• Scope Fidelity — matches strategy scope
• Actionability — a QE engineer could start testing
• Consistency — sections agree with each other

The reviewer handles auto-revision internally (up to 2 cycles) and writes <feature_name>/TestPlanReview.md with scores and feedback.

Handle the review output:

1. Read the verdict from <feature_name>/TestPlanReview.md frontmatter
2. Auto-fix (if any): Apply clearly correct improvements suggested by the reviewer (e.g., consistency fixes, missing entries in Section 10.2, generic priority definitions that should be feature-specific). Edit the TestPlan.md directly using the Edit tool.
3. Present summary: Show the user:
   • Final score and verdict from TestPlanReview.md
   • Any auto-fixes applied
   • Any remaining gaps from TestPlanGaps.md
   • Full visibility into the test plan's quality before proceeding to test case generation
4. If verdict is Rework: Advise the user to provide additional source documents (ADR, API spec, design doc) to resolve quality issues before generating test cases

What this skill does NOT do

• Does NOT generate individual test case files
• Does NOT fetch child stories under the epic
• Does NOT fetch the Google Doc ADR — it reads a local file only
• Does NOT resolve GitHub PR review comments (use /test-plan.resolve-feedback <PR_URL> after publishing)
• Section 5 (Test Cases): left as placeholder — to be filled later in the process
• Section 6 (E2E Test Scenarios): left as placeholder — to be filled by /test-plan.create-cases
• Section 7 (Non-Functional Requirements): filled by test-plan.analyze.risks — each category must be addressed or marked Not Applicable
• Section 10.1 (Test Case Summary): left as placeholder — to be filled later in the process
• Section 10.2 Test Cases column: left empty — to be filled by /test-plan.create-cases
• Section 10.2 Coverage column: left empty — to be filled by /coverage-assessment

$ARGUMENTS