runkids/feature-radar/feature-radar-scan

Scan Opportunities

Discover new feature opportunities and add them to .feature-radar/opportunities/.

Deep Read

<HARD-GATE> Read and follow ../feature-radar/references/DEEP-READ.md — complete all 6 steps before proceeding. </HARD-GATE>

Behavioral Directives

<HARD-GATE> Read and follow ../feature-radar/references/DIRECTIVES.md.

Additional directive for this skill:

• Filter aggressively — Create an opportunity file only when you can cite concrete demand evidence or make a clear innovation case. Skip weak signals, such as a single issue with no engagement.

</HARD-GATE>

Brainstorm Intake

<HARD-GATE> Run Brainstorm Intake when the user brings an idea of their own ("I have an idea", "what if we...", "I was thinking about...", "brainstorm") or describes a problem without a clear feature shape.

When the user asked for a scan directly ("scan opportunities", "scan ecosystem", "find new features") and brought no idea of their own, jump directly to ## Workflow. </HARD-GATE>

Phase 1: Core Questions

Ask these one at a time. Prefer multiple-choice when possible.

1. Problem space — "What problem are you trying to solve, or what experience do you want to improve?"

• Cross-reference: search existing opportunities/ and archive/ for related themes.
• If a match is found, surface it: "Is this related to #{nn} {title}, or a completely different direction?"

1. Target user — "Who would benefit from this feature?"

• Offer choices derived from base.md Project Context if available.

1. Spark — "What triggered this idea?"

• (A) A pain point from my own usage
• (B) Saw a similar feature in another tool/project
• (C) New technical possibilities (new API, new library)
• (D) Community/user feedback
• (E) Pure creative exploration

Phase 2: Adaptive Depth

After Phase 1, assess idea maturity:

Mature (has clear problem + user + demand signal): → Ask 1 closing question to confirm scope, then proceed to Exit.

Emerging (has problem but fuzzy shape): → Ask up to 3 more questions to sharpen:

• "What does the usage look like in your mind?"
• "Have you seen an implementation you particularly liked?" (if yes, consider creating a references/ entry)
• "What's the minimum scope that would feel useful?" (MVP scoping)

Raw (pure exploration, no clear problem yet): → Switch to open-ended dialogue. Ask up to 5 more questions:

• Explore adjacent possibilities
• Challenge assumptions: "If we don't build this, what's the biggest loss?"
• Seek demand signals: "Has anyone (including yourself) run into this problem repeatedly?"
• Stop when: a clear feature shape emerges, OR user says "enough"

Exit: Output Options

Summarize the refined idea:

"Here's a summary of our discussion:

• Problem: {problem}
• Target user: {target user}
• Direction: {feature shape}
• Demand signal: {demand evidence or 'creative exploration'}
• Related items: {related opportunities/archive/specs, or 'none found'}"

Then ask:

"What would you like to do next?"

• (A) Proceed to scan — use this direction as focused context, search all 6 sources for supporting evidence and related opportunities
• (B) Save as opportunity draft — write to opportunities/{nn}-{slug}.md with Status: Open, decide later whether to scan

If (A): Pass the summary as context into ## Workflow Step 1, with a narrowed focus on the identified direction. If (B): Create the opportunity file following ../feature-radar/references/SPEC.md § 3.3, populate fields from the intake summary, then run the Annotation Checkpoint per ../feature-radar/references/WORKFLOW-PATTERNS.md. After approval, present Completion Summary and suggest "run a focused scan around this direction" as a next step.

Workflow

1. Identify sources — where to look for ideas:

• User signals: issues, discussions, forum posts, support requests
• Creative exploration: "what if we..." brainstorming, combining existing features in new ways
• Ecosystem evolution: adjacent tools, emerging standards, new capabilities in dependencies
• Technical possibilities: new APIs, libraries, or techniques that enable things previously impossible
• Cross-project research: interesting approaches from related projects (from base.md Inspiration Sources)
• Community conversations: Reddit, HN, Discord, blog posts
• If Brainstorm Intake was completed: use the intake summary as the primary focus direction. Prioritize sources most relevant to the identified problem space. Still scan all 6 source types, but weight results toward the intake direction.

1. Scan and collect — for each source, look for:

• Unmet user needs and recurring pain points
• Feature ideas with demand signals (upvotes, comments, multiple independent asks)
• Creative approaches that could enhance existing functionality
• Technical breakthroughs that unlock new possibilities
• Patterns emerging across multiple tools

1. Deduplicate — check against existing opportunities/ and archive/ files
2. Cross-reference codebase — for each candidate, search the project to check:

• Already partially implemented? → mark as "Partially Done"
• Does existing architecture support this? → note in "Design Notes"
• Related TODOs or FIXMEs in the code? → cite them

1. Evaluate each candidate against all 6 criteria before creating its opportunity file, addressing each criterion explicitly:

1. Create opportunity files — for each viable candidate, write .feature-radar/opportunities/{nn}-{slug}.md
2. Checkpoint — Review & Annotate per ../feature-radar/references/WORKFLOW-PATTERNS.md

Present scan results using this format:

Scan complete: {n} new opportunities
| # | Opportunity | Demand Signal | Impact | Effort | Source |
|---|------------|---------------|--------|--------|--------|
| {nn} | {title} | {evidence} | H/M/L | H/M/L | {where found} |

1. Update base.md — increment opportunities count, update Value & Innovation Landscape if needed

Opportunity File Format

Use the format defined in ../feature-radar/references/SPEC.md § 3.3 (opportunities/{nn}-{slug}.md).

Guidelines

• Don't create opportunities for every idea you find. Filter aggressively — weak signal wastes attention.
• 1 issue with no comments = weak signal. Multiple independent asks = strong signal.
• Creative ideas without existing demand can still be valid — evaluate innovation potential separately.
• Write an honest "Our Position" — it's OK to say "we don't want this" or "not yet."
• Number sequentially from the highest existing number in opportunities/ and archive/.
• If scanning reveals problems others have that we've already solved, add to references/ instead.

Example Output

→ Created opportunities/07-streaming-output.md (Impact: High, Effort: Medium)
→ Skipped: "hook system" already exists as opportunities/03-hook-system.md
→ Updated base.md: opportunities 6 → 7

Brainstorm Intake Example

User: "I was thinking... what if we could automatically detect when a feature is getting stale?"
 
Phase 1:
  Q1 (Problem): "What problem are you trying to solve?" → Feature opportunities sitting unreviewed
  Cross-ref: Found #05 role-assignment — user confirms: different direction
  Q2 (Target): "Who benefits?" → Project maintainers managing backlogs
  Q3 (Spark): (A) Pain point from own usage
 
Phase 2 (Emerging → 2 follow-ups):
  Q4: "What does usage look like?" → Periodic check, flag items older than N days with no activity
  Q5: "Minimum useful scope?" → Just a reminder in completion summary, no automation needed
 
Exit summary:
  Problem: Stale opportunities go unnoticed
  Target user: Project maintainers
  Direction: Staleness detection in completion summaries
  Demand signal: Personal pain point (single user)
  Related: None found
 
User chose: (B) Save as opportunity draft
→ Created opportunities/06-staleness-detection.md (Impact: Low, Effort: Low)
→ Suggested next step: "run a focused scan around staleness detection"

Completion Summary

Follow the template in ../feature-radar/references/DIRECTIVES.md, with skill name "Scan Complete".