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.
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
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ln-521-test-researcher/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ln-521-test-researcher Compares
| Feature / Agent | ln-521-test-researcher | 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?
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
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
ChatGPT vs Claude for Agent Skills
Compare ChatGPT and Claude for AI agent skills across coding, writing, research, and reusable workflow execution.
AI Agents for Startups
Explore AI agent skills for startup validation, product research, growth experiments, documentation, and fast execution with small teams.
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-15Related Skills
ln-812-optimization-researcher
Researches competitive benchmarks and generates optimization hypotheses for identified bottlenecks. Use after profiling.
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-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.