ln-523-auto-test-planner
Plans automated tests (E2E/Integration/Unit) using Risk-Based Testing after manual testing. Use when Story needs a test task with prioritized scenarios.
Best use case
ln-523-auto-test-planner is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Plans automated tests (E2E/Integration/Unit) using Risk-Based Testing after manual testing. Use when Story needs a test task with prioritized scenarios.
Teams using ln-523-auto-test-planner should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ln-523-auto-test-planner/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ln-523-auto-test-planner Compares
| Feature / Agent | ln-523-auto-test-planner | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Plans automated tests (E2E/Integration/Unit) using Risk-Based Testing after manual testing. Use when Story needs a test task with prioritized scenarios.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
> **Paths:** File paths (`shared/`, `references/`, `../ln-*`) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If `shared/` is missing, fetch files via WebFetch from `https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}`.
# Automated Test Planner
**Type:** L3 Worker
Creates Story test task with comprehensive automated test coverage (E2E/Integration/Unit) based on Risk-Based Testing methodology and REAL manual testing results.
## Inputs
| Input | Required | Source | Description |
|-------|----------|--------|-------------|
| `storyId` | Yes | args, git branch, kanban, user | Story to process |
**Resolution:** Story Resolution Chain.
**Status filter:** To Review
## Purpose & Scope
- **Create** comprehensive test task for Story automation
- **Calculate** risk-based priorities (Impact x Probability)
- **Generate** 11-section test plan from manual test results
- **Delegate** to ln-301-task-creator (CREATE) or ln-302-task-replanner (REPLAN)
- **NOT** for: manual testing (ln-522), research (ln-521), orchestration (ln-520)
## When to Use
- Use when implementation work is done and automated test coverage must be planned
- All implementation Tasks in Story status = Done
- ln-521 research: uses if available, generates minimal inline research if missing
- ln-522 manual testing: uses if available, marks as 'skipped by policy' if missing
**Automation:** Supports `autoApprove: true` (default when invoked by ln-520) to skip manual confirmation.
## Workflow
### Phase 0: Tools Config
**MANDATORY READ:** Load `shared/references/tools_config_guide.md`, `shared/references/storage_mode_detection.md`, and `shared/references/input_resolution_pattern.md`
Extract: `task_provider` = Task Management → Provider (`linear` | `file`).
### Phase 1: Discovery (Automated)
1. **Resolve storyId:** Run Story Resolution Chain per guide (status filter: [To Review]).
2. Auto-discover Team ID from `docs/tasks/kanban_board.md` (see CLAUDE.md "Configuration Auto-Discovery")
### Phase 2: Story + Tasks Analysis (NO Dialog)
**Step 0: Study Project Test Files**
1. Scan for test-related files:
- tests/README.md (commands, setup, environment)
- Test configs (jest.config.js, vitest.config.ts, pytest.ini)
- Existing test structure (tests/, __tests__/ directories)
- Coverage config (.coveragerc, coverage.json)
2. Extract: test commands, framework, patterns, coverage thresholds
3. Ensures test planning aligns with project practices
**Step 1: Load Research and Manual Test Results**
1. Fetch Story (must have label "user-story"):
- IF `task_provider` = `linear`: `get_issue(storyId)` — extract Story.id (UUID, NOT short ID)
- IF `task_provider` = `file`: `Read story.md` — extract Story metadata
2. Load research comment (from ln-521): "## Test Research: {Feature}"
- IF `task_provider` = `linear`: `list_comments(issueId=storyId)` → find matching comment
- IF `task_provider` = `file`: `Glob("docs/tasks/epics/*/stories/*/comments/*.md")` → find matching comment
- IF research comment not found: generate 3-5 bullet points of key test areas based on Story AC and task descriptions (inline, no external research).
3. Load manual test results comment (from ln-522): "## Manual Testing Results"
- Same approach as research comment above
- IF manual test results not found: skip manual test coverage analysis. Note in output: 'Manual testing: skipped by policy (simplified mode).'
4. Parse sections: AC results (PASS/FAIL), Edge Cases, Error Handling, Integration flows
5. Map to test design: PASSED AC -> E2E, Edge cases -> Unit, Errors -> Error handling, Flows -> Integration
**Step 2: Analyze Story + Tasks**
1. Parse Story: Goal, Test Strategy, Technical Notes
2. Fetch all child Tasks (status = Done):
- IF `task_provider` = `linear`: `list_issues(parentId=Story.id, state="Done")`
- IF `task_provider` = `file`: `Glob("docs/tasks/epics/*/stories/*/tasks/*.md")` → filter by `**Status:** Done`
3. Analyze each Task:
- Components implemented
- Business logic added
- Integration points created
- Conditional branches (if/else/switch)
4. Identify what needs testing
### Phase 3: Parsing Strategy for Manual Test Results
**Process:** Locate Linear comment with "Manual Testing Results" header -> Verify Format Version 1.0 -> Extract structured sections (Acceptance Criteria, Test Results by AC, Edge Cases, Error Handling, Integration Testing) using regex -> Validate (at least 1 PASSED AC, AC count matches Story, completeness check) -> Map parsed data to test design structure
**Error Handling:** Missing comment -> use fallback (inline research or skip per Phase 2 logic), Missing format version -> WARNING (try legacy parsing), Required section missing -> use fallback, No PASSED AC -> ERROR (fix implementation)
### Phase 4: Risk-Based Test Planning (Automated)
**MANDATORY READ:** Load `shared/references/risk_based_testing_guide.md` for complete methodology.
**E2E-First Approach:** Prioritize by business risk (Priority = Impact x Probability), not coverage metrics.
**Workflow:**
**Step 1: Risk Assessment**
Calculate Priority for each scenario from manual testing:
```
Priority = Business Impact (1-5) x Probability (1-5)
```
**Decision Criteria:**
- Priority ≥15 -> **MUST test**
- Priority 9-14 -> **SHOULD test** if not covered
- Priority <=8 -> **SKIP** (manual testing sufficient)
**Step 2: E2E Test Selection (2-5):** Baseline 2 (positive + negative) ALWAYS + 0-3 additional (Priority ≥15 only)
**Step 3: Unit Test Selection (0-15):** DEFAULT 0. Add ONLY for complex business logic (Priority ≥15): financial, security, algorithms
**Step 4: Integration Test Selection:** DEFAULT 0. Add ONLY if E2E gaps AND Priority ≥15: rollback, concurrency, external API errors
**Step 5: Validation:** Each test passes Usefulness Criteria (Priority ≥15, Confidence ROI, Behavioral, Predictive, Specific, Non-Duplicative)
### Phase 5: Test Task Generation (Automated)
Generates complete test task per `test_task_template.md` (11 sections):
**Sections 1-7:** Context, Risk Matrix, E2E/Integration/Unit Tests (with Priority scores + justifications), Coverage, DoD
**Section 8:** Existing Tests to Fix (analysis of affected tests from implementation tasks)
**Section 9:** Infrastructure Changes (packages, Docker, configs - based on test dependencies)
**Section 10:** Documentation Updates (README, CHANGELOG, tests/README, config docs)
**Section 11:** Legacy Code Cleanup (deprecated patterns, backward compat, dead code)
Shows preview for review.
### Phase 6: Confirmation & Delegation
**Step 1:** Preview generated test plan (always displayed for transparency)
**Step 2:** Confirmation logic:
- **autoApprove: true** (default from ln-520) -> proceed automatically
- **Manual run** -> prompt user to type "confirm"
**Step 3:** Check for existing test task
- IF `task_provider` = `linear`: `list_issues(parentId=Story.id, label="tests")`
- IF `task_provider` = `file`: `Glob("docs/tasks/epics/*/stories/*/tasks/*.md")` → filter by `**Labels:**` containing `tests`
**Decision:**
- **Count = 0** -> **CREATE MODE** (Step 4a)
- **Count >= 1** -> **REPLAN MODE** (Step 4b)
**Step 4a: CREATE MODE** (if Count = 0)
Invoke ln-301-task-creator worker with taskType: "test"
**Pass to worker:**
- taskType, teamId, storyData (Story.id, title, AC, Technical Notes, Context)
- researchFindings (from ln-521 comment)
- manualTestResults (from ln-522 comment)
- testPlan (e2eTests, integrationTests, unitTests, riskPriorityMatrix)
- infrastructureChanges, documentationUpdates, legacyCleanup
**Worker returns:** Task URL + summary
**Step 4b: REPLAN MODE** (if Count >= 1)
Invoke ln-302-task-replanner worker with taskType: "test"
**Pass to worker:**
- Same data as CREATE MODE + existingTaskIds
**Worker returns:** Operations summary + warnings
**Step 5:** Return summary to orchestrator (ln-520)
---
## Runtime Summary Artifact
**MANDATORY READ:** Load `shared/references/test_planning_summary_contract.md`
Accept optional `summaryArtifactPath`.
Summary kind:
- `test-planning-worker`
Required payload semantics:
- `worker = "ln-523"`
- `status`
- `warnings`
- `test_task_id`
- `test_task_url`
- `coverage_summary`
- `planned_scenarios`
Write the summary to the provided artifact path or return the same envelope in structured output.
## Definition of Done
**Research and Manual Results Loaded:**
- [ ] Research comment "## Test Research: {Feature}" found (from ln-521)
- [ ] Manual test results "## Manual Testing Results" found (from ln-522)
- [ ] At least 1 AC marked as PASSED
**Risk-Based Test Plan Generated:**
- [ ] Risk Priority Matrix calculated for all scenarios
- [ ] E2E tests: Baseline positive + negative, additional only if Priority ≥15
- [ ] Integration tests: ONLY if E2E doesn't cover AND Priority ≥15
- [ ] Unit tests: ONLY complex business logic with Priority ≥15
- [ ] Each test passes all 6 Usefulness Criteria
- [ ] No framework/library testing: Each test validates OUR business logic only
**Test Task Description Complete (11 sections):**
- [ ] All 11 sections populated per template
- [ ] Risk Priority Matrix included
- [ ] Each test beyond baseline 2 justified
**Worker Delegation Executed:**
- [ ] CREATE MODE: Delegated to ln-301-task-creator
- [ ] REPLAN MODE: Delegated to ln-302-task-replanner
- [ ] Linear Issue URL returned
**Output:**
- **CREATE MODE:** Linear Issue URL + confirmation
- **REPLAN MODE:** Operations summary + URLs
## Reference Files
- **Tools config:** `shared/references/tools_config_guide.md`
- **Storage mode operations:** `shared/references/storage_mode_detection.md`
- **Risk-based testing methodology:** `shared/references/risk_based_testing_guide.md`
- **Auto-discovery patterns:** `shared/references/auto_discovery_pattern.md`
- **Test task template:** `shared/templates/test_task_template.md` (workers ln-301/ln-302 load via Template Loading)
- **Testing examples:** `references/risk_based_testing_examples.md`
- **MANDATORY READ:** `shared/references/research_tool_fallback.md`
## Critical Rules
- **Manual results preferred:** Use ln-522 manual testing results when available. When missing (simplified mode), generate minimal inline research and mark manual testing as skipped
- **E2E-first, not unit-first:** Baseline is always 2 E2E (positive + negative); unit/integration added only for Priority >= 15
- **No framework testing:** Every test must validate OUR business logic; never test library/framework behavior
- **Usefulness enforcement:** Every test beyond baseline must pass all 6 Usefulness Criteria (see risk_based_testing_guide.md)
- **Delegate, don't create:** Task creation goes through ln-301/ln-302 workers; this skill generates the plan only
## Best Practices
**Minimum Viable Testing:** Start with baseline E2E (positive + negative). Each additional test must pass all 6 Usefulness Criteria.
**Risk-Based Testing:** Prioritize by Business Impact x Probability. E2E-first from ACTUAL manual testing results. Priority ≥15 scenarios covered by tests.
**Expected-Based Testing:** For deterministic tests, compare actual vs expected using `diff`. **MANDATORY READ:** Load `../ln-522-manual-tester/SKILL.md` — section "Test Design Principles".
---
**Version:** 1.0.0
**Last Updated:** 2026-01-15Related Skills
ln-782-test-runner
Executes all test suites and reports results with coverage. Use when verifying that test infrastructure works after bootstrap.
ln-743-test-infrastructure
Sets up test infrastructure with Vitest, xUnit, and pytest. Use when adding testing frameworks and sample tests to a project.
ln-637-test-structure-auditor
Checks test file organization, directory layout, test-to-source mapping, domain grouping, co-location. Use when auditing test structure.
ln-636-manual-test-auditor
Checks manual test scripts for harness adoption, golden files, fail-fast, config sourcing, idempotency. Use when auditing manual test quality.
ln-635-test-isolation-auditor
Checks test isolation (API/DB/FS/Time/Network), determinism, flaky tests, order-dependency, anti-patterns. Use when auditing test isolation.
ln-634-test-coverage-auditor
Identifies missing tests for critical paths (money, security, data integrity, core flows). Use when auditing test coverage gaps.
ln-633-test-value-auditor
Scores each test by Impact x Probability, returns KEEP/REVIEW/REMOVE decisions. Use when auditing test value and pruning low-value tests.
ln-632-test-e2e-priority-auditor
Validates E2E coverage for critical paths (money, security, data integrity). Risk-based prioritization. Use when auditing E2E test coverage.
ln-631-test-business-logic-auditor
Detects tests validating framework/library behavior instead of project code. Use when auditing test business logic focus.
ln-630-test-auditor
Coordinates test suite audit across business logic, E2E coverage, value, isolation, manual quality, and structure. Use when auditing entire test suite.
ln-522-manual-tester
Performs manual testing of Story AC via executable bash scripts in tests/manual/. Use when Story implementation needs hands-on AC verification.
ln-521-test-researcher
Researches real-world problems, competitor solutions, and customer complaints for a feature domain. Use before test planning to ground tests in actual user pain points.