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.

310 stars

Best use case

ln-521-test-researcher is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

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.

Teams using ln-521-test-researcher 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

$curl -o ~/.claude/skills/ln-521-test-researcher/SKILL.md --create-dirs "https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/main/skills-catalog/ln-521-test-researcher/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/ln-521-test-researcher/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How ln-521-test-researcher Compares

Feature / Agentln-521-test-researcherStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

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.

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

## Inputs

| Input | Required | Source | Description |
|-------|----------|--------|-------------|
| `storyId` | Yes | args, git branch, kanban, user | Story to process |

**Resolution:** Story Resolution Chain.
**Status filter:** To Review

# Test Researcher

**Type:** L3 Worker

Researches real-world problems and edge cases before test planning to ensure tests cover actual user pain points, not just AC.

## Purpose & Scope
- Research common problems for the feature domain using Web Search, MCP Ref, Context7.
- Analyze how competitors solve the same problem.
- Find customer complaints and pain points from forums, StackOverflow, Reddit.
- Post structured findings as Linear comment for downstream skills (ln-522, ln-523).
- No test creation or status changes.

## When to Use

This skill should be used when:
- Use at the start of a test-planning workflow when feature-domain evidence is needed
- Story has non-trivial functionality (external APIs, file formats, authentication)
- Need to discover edge cases beyond AC

**Skip research when:**
- Story is trivial (simple CRUD, no external dependencies)
- Research comment already exists on Story
- User explicitly requests to skip

## Workflow

### Phase 1: Discovery

**MANDATORY READ:** Load `shared/references/input_resolution_pattern.md`

1. **Resolve storyId:** Run Story Resolution Chain per guide (status filter: [To Review]).

2. Auto-discover Team ID from `docs/tasks/kanban_board.md`

### Phase 2: Extract Feature Domain

1) Fetch Story from Linear
2) Parse Story goal and AC to identify:
   - What technology/API/format is involved?
   - What is the user's goal? (e.g., "translate XLIFF files", "authenticate via OAuth")
3) Extract keywords for research queries

### Phase 3: Research Common Problems

Use available tools to find real-world problems:

1) **Web Search:**
   - "[feature] common problems"
   - "[format] edge cases"
   - "[API] gotchas"
   - "[technology] known issues"

2) **MCP Ref:**
   - `ref_search_documentation("[feature] error handling best practices")`
   - `ref_search_documentation("[format] validation rules")`

3) **Context7:**
   - Query relevant library docs for known issues
   - Check API documentation for limitations

### Phase 4: Research Competitor Solutions

1) **Web Search:**
   - "[competitor] [feature] how it works"
   - "[feature] comparison"
   - "[product type] best practices"

2) **Analysis:**
   - How do market leaders handle this functionality?
   - What UX patterns do they use?
   - What error handling approaches are common?

### Phase 5: Research Customer Complaints

1) **Web Search:**
   - "[feature] complaints"
   - "[product type] user problems"
   - "[format] issues reddit"
   - "[format] issues stackoverflow"

2) **Analysis:**
   - What do users actually struggle with?
   - What are common frustrations?
   - What gaps exist between user expectations and typical implementations?

### Phase 6: Compile and Post Findings

1) **Compile findings** into categories:
   - **Input validation issues** (malformed data, encoding, size limits)
   - **Edge cases** (empty input, special characters, Unicode)
   - **Error handling** (timeouts, rate limits, partial failures)
   - **Security concerns** (injection, authentication bypass)
   - **Competitor advantages** (features we should match or exceed)
   - **Customer pain points** (problems users actually complain about)

2) **Post Linear comment** on Story with research summary:

```markdown
## Test Research: {Feature}

### Sources Consulted
- [Source 1](url)
- [Source 2](url)

### Common Problems Found
1. **Problem 1:** Description + test case suggestion
2. **Problem 2:** Description + test case suggestion

### Competitor Analysis
- **Competitor A:** How they handle this + what we can learn
- **Competitor B:** Their approach + gaps we can exploit

### Customer Pain Points
- **Complaint 1:** What users struggle with + test to prevent
- **Complaint 2:** Common frustration + how to verify we solve it

### Recommended Test Coverage
- [ ] Test case for problem 1
- [ ] Test case for competitor parity
- [ ] Test case for customer pain point

---
_This research informs both manual tests (ln-522) and automated tests (ln-523)._
```

## Critical Rules

- **No test creation:** Only research and documentation.
- **No status changes:** Only Linear comment.
- **Source attribution:** Always include URLs for sources consulted.
- **Actionable findings:** Each problem should suggest a test case.
- **Skip trivial Stories:** Don't research "Add button to page".

## 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-521"`
- `status`
- `warnings`
- `research_comment_path`

Write the summary to the provided artifact path or return the same envelope in structured output.

**Standalone default (no coordinator):** Generate `run_id` = `standalone-ln-521-{YYYYMMDD}-{short_hash}`, write summary JSON to `.hex-skills/runtime-artifacts/runs/{run_id}/test-planning-worker/ln-521.json`. NEVER write artifacts to the project root directory.

## Definition of Done

- [ ] Feature domain extracted from Story (technology/API/format identified)
- [ ] Common problems researched (Web Search + MCP Ref + Context7)
- [ ] Competitor solutions analyzed (at least 1-2 competitors)
- [ ] Customer complaints found (forums, StackOverflow, Reddit)
- [ ] Findings compiled into categories
- [ ] Linear comment posted with "## Test Research: {Feature}" header
- [ ] At least 3 recommended test cases suggested

**Output:** Linear comment with research findings for ln-522 and ln-523 to use.

## Reference Files

- Research methodology: Web Search, MCP Ref, Context7 tools
- Comment format: Structured markdown with sources
- Downstream consumers: ln-522-manual-tester, ln-523-auto-test-planner
- **MANDATORY READ:** `shared/references/research_tool_fallback.md`

---

**Version:** 1.0.0
**Last Updated:** 2026-01-15

Related Skills

ln-812-optimization-researcher

310
from levnikolaevich/claude-code-skills

Researches competitive benchmarks and generates optimization hypotheses for identified bottlenecks. Use after profiling.

ln-782-test-runner

310
from levnikolaevich/claude-code-skills

Executes all test suites and reports results with coverage. Use when verifying that test infrastructure works after bootstrap.

ln-743-test-infrastructure

310
from levnikolaevich/claude-code-skills

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

310
from levnikolaevich/claude-code-skills

Checks test file organization, directory layout, test-to-source mapping, domain grouping, co-location. Use when auditing test structure.

ln-636-manual-test-auditor

310
from levnikolaevich/claude-code-skills

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

310
from levnikolaevich/claude-code-skills

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

310
from levnikolaevich/claude-code-skills

Identifies missing tests for critical paths (money, security, data integrity, core flows). Use when auditing test coverage gaps.

ln-633-test-value-auditor

310
from levnikolaevich/claude-code-skills

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

310
from levnikolaevich/claude-code-skills

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

310
from levnikolaevich/claude-code-skills

Detects tests validating framework/library behavior instead of project code. Use when auditing test business logic focus.

ln-630-test-auditor

310
from levnikolaevich/claude-code-skills

Coordinates test suite audit across business logic, E2E coverage, value, isolation, manual quality, and structure. Use when auditing entire test suite.

ln-523-auto-test-planner

310
from levnikolaevich/claude-code-skills

Plans automated tests (E2E/Integration/Unit) using Risk-Based Testing after manual testing. Use when Story needs a test task with prioritized scenarios.