skills/wsf-research-phase/SKILL.md
Research how to implement a phase (standalone - usually use /wsf-plan-phase instead)
npx skillsauth add sampx/agent-tools wsf-research-phaseInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Note: This is a standalone research command. For most workflows, use /wsf-plan-phase which integrates research automatically.
Use this command when:
Orchestrator role: Parse phase, validate against roadmap, check existing research, gather context, spawn researcher agent, present results.
Why subagent: Research burns context fast (WebSearch, Context7 queries, source verification). Fresh 200k context for investigation. Main context stays lean for user interaction. </objective>
<available_agent_types> Valid WSF subagent types (use exact names — do not fall back to 'general-purpose'):
Normalize phase input in step 1 before any directory lookups. </context>
<process>INIT=$(node "/Users/sam/coding/wopal/wopal-workspace/.wopal/wsf/bin/wsf-tools.cjs" init phase-op "$ARGUMENTS")
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
Extract from init JSON: phase_dir, phase_number, phase_name, phase_found, commit_docs, has_research, state_path, requirements_path, context_path, research_path.
Resolve researcher model:
RESEARCHER_MODEL=$(node "/Users/sam/coding/wopal/wopal-workspace/.wopal/wsf/bin/wsf-tools.cjs" resolve-model wsf-phase-researcher --raw)
PHASE_INFO=$(node "/Users/sam/coding/wopal/wopal-workspace/.wopal/wsf/bin/wsf-tools.cjs" roadmap get-phase "${phase_number}")
If found is false: Error and exit. If found is true: Extract phase_number, phase_name, goal from JSON.
ls .planning/phases/${PHASE}-*/RESEARCH.md 2>/dev/null
If exists: Offer: 1) Update research, 2) View existing, 3) Skip. Wait for response.
If doesn't exist: Continue.
Use paths from INIT (do not inline file contents in orchestrator context):
requirements_pathcontext_pathstate_pathPresent summary with phase description and what files the researcher will load.
Research modes: ecosystem (default), feasibility, implementation, comparison.
<research_type>
Phase Research — investigating HOW to implement a specific phase well.
</research_type>
<key_insight>
The question is NOT "which library should I use?"
The question is: "What do I not know that I don't know?"
For this phase, discover:
- What's the established architecture pattern?
- What libraries form the standard stack?
- What problems do people commonly hit?
- What's SOTA vs what the agent's training thinks is SOTA?
- What should NOT be hand-rolled?
</key_insight>
<objective>
Research implementation approach for Phase {phase_number}: {phase_name}
Mode: ecosystem
</objective>
<files_to_read>
- {requirements_path} (Requirements)
- {context_path} (Phase context from discuss-phase, if exists)
- {state_path} (Prior project decisions and blockers)
</files_to_read>
<additional_context>
**Phase description:** {phase_description}
</additional_context>
<downstream_consumer>
Your RESEARCH.md will be loaded by `/wsf-plan-phase` which uses specific sections:
- `## Standard Stack` → Plans use these libraries
- `## Architecture Patterns` → Task structure follows these
- `## Don't Hand-Roll` → Tasks NEVER build custom solutions for listed problems
- `## Common Pitfalls` → Verification steps check for these
- `## Code Examples` → Task actions reference these patterns
Be prescriptive, not exploratory. "Use X" not "Consider X or Y."
</downstream_consumer>
<quality_gate>
Before declaring complete, verify:
- [ ] All domains investigated (not just some)
- [ ] Negative claims verified with official docs
- [ ] Multiple sources for critical claims
- [ ] Confidence levels assigned honestly
- [ ] Section names match what plan-phase expects
</quality_gate>
<output>
Write to: .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md
</output>
Task(
prompt=filled_prompt,
subagent_type="wsf-phase-researcher",
model="{researcher_model}",
description="Research Phase {phase}"
)
## RESEARCH COMPLETE: Display summary, offer: Plan phase, Dig deeper, Review full, Done.
## CHECKPOINT REACHED: Present to user, get response, spawn continuation.
## RESEARCH INCONCLUSIVE: Show what was attempted, offer: Add context, Try different mode, Manual.
<objective>
Continue research for Phase {phase_number}: {phase_name}
</objective>
<prior_state>
<files_to_read>
- .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md (Existing research)
</files_to_read>
</prior_state>
<checkpoint_response>
**Type:** {checkpoint_type}
**Response:** {user_response}
</checkpoint_response>
Task(
prompt=continuation_prompt,
subagent_type="wsf-phase-researcher",
model="{researcher_model}",
description="Continue research Phase {phase}"
)
</process>
<success_criteria>
tools
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
development
Workspace-level Git worktree management — create, list, remove, and prune isolated development environments. Use this skill whenever the user needs to create a worktree, set up an isolated workspace, work on multiple features in parallel, list existing worktrees, check what worktrees exist, remove or delete a worktree, clean up stale worktrees, or manage git working trees in any way. Triggers include "create worktree", "new worktree", "list worktrees", "show worktrees", "remove worktree", "delete worktree", "clean up worktree", "prune worktree", "isolated environment", "parallel development", "worktree for <project>", or any request involving git worktree operations.
development
Issue/Plan-driven development workflow. Tasks must be backed by a GitHub Issue or Plan. Trigger: issue references like #14, creating issues, creating plans, implementing plans, executing plans, checking plans, verifying plans, Plan lifecycle transitions (approve/complete/verify/archive), decomposing PRDs into Issues. Skip: spec-driven workflows, research/discussion/explanation only, small ad-hoc changes that don't need an Issue or Plan.
testing
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.