本文へ移動
cccskills
無料GitHub で公開

feature-radar-scan

Discover new feature opportunities from creative brainstorming, user feedback, ecosystem trends, and cross-project research. Writes results to .feature-radar/opportunities/. MUST use this skill when the user wants to GENERATE new ideas — not evaluate existing ones — including casual or half-formed ones ("what if we...", "I have an idea"). Use when the user wants feature ideas or new directions, asks what the project is missing, wants to mine issues, community feedback, or adjacent tools for inspiration, or wants to refresh the opportunity backlog. Do NOT use for evaluating/prioritizing existing features — that's feature-radar's job.

日本語の概要は準備中です。原文の説明を表示しています。

runkids/feature-radarスター 14(GitHub 14 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(1)

  • SKILL.md9.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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?"
  2. Target user — "Who would benefit from this feature?"
    • Offer choices derived from base.md Project Context if available.
  3. 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.
  2. 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
  3. Deduplicate — check against existing opportunities/ and archive/ files
  4. 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
  5. Evaluate each candidate against all 6 criteria before creating its opportunity file, addressing each criterion explicitly:
CriterionQuestion
Real user demandAre users actually asking for this, or does it solve a latent need?
Value upliftDoes this meaningfully improve the user experience or unlock new possibilities?
Innovation potentialDoes this introduce a creative breakthrough or unique approach?
Effort / impact ratioIs the cost justified by the benefit?
Architectural fitDoes it align with our core philosophy?
Ecosystem timingIs the ecosystem ready?
  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".

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Full-cycle feature discovery, evaluation, and prioritization. Builds a persistent knowledge base at .feature-radar/ and runs a 6-phase workflow to recommend what to build next. Modes: full (all phases), quick (scan only), evaluate (prioritize), #N (deep-dive one). MUST use this skill whenever the user asks about feature priorities, roadmaps, what to build, or wants to evaluate/compare feature ideas — even if they don't say "feature radar" explicitly. Use when the user wants to decide what to build next, rank or compare features and backlog items, plan a roadmap or project direction, reassess deferred or open opportunities, or mentions the .feature-radar/ directory.

日本語の概要は準備中です。原文の説明を表示しています。

runkids/feature-radar142026年9月29日 更新

Archive a completed, rejected, or covered feature into .feature-radar/archive/ with mandatory learning extraction. MUST use this skill whenever a feature reaches a terminal state — done, rejected, covered, deferred, or N/A — including casual mentions like "we shipped X". The skill extracts learnings, derives new opportunities, and updates refs. Use when the user reports a feature shipped or finished, decides against building one, defers or postpones one, or asks to close or archive an opportunity. Do NOT use for discovering new features — that's feature-radar-scan's job.

日本語の概要は準備中です。原文の説明を表示しています。

runkids/feature-radar142026年9月29日 更新

Extract reusable patterns, architectural decisions, and pitfalls from completed work into .feature-radar/specs/. Captures the "why" behind choices so future sessions build on past experience. MUST use this skill when the user reflects on what worked or didn't, wants to record a decision or pattern for future use, or hit a dead end worth documenting. Use when the user asks to remember, document, or extract lessons from recent work. Do NOT use for recording external observations — that's feature-radar-ref's job. Do NOT use for archiving completed features — that's feature-radar-archive's job.

日本語の概要は準備中です。原文の説明を表示しています。

runkids/feature-radar142026年9月29日 更新

Record external observations, ecosystem trends, and creative inspiration into .feature-radar/references/. MUST use this skill when the user mentions something interesting from outside their project — other tools, articles, approaches, or trends — even casually ("I saw a cool thing in X"). Use when the user shares a URL, article, talk, or research finding, notes an ecosystem trend or a related project's notable feature, or asks to bookmark or track external inspiration. Do NOT use for internal learnings/patterns — that's feature-radar-learn's job. Do NOT use for prioritizing features — that's feature-radar's job.

日本語の概要は準備中です。原文の説明を表示しています。

runkids/feature-radar142026年9月29日 更新

Validate SKILL.md frontmatter and .feature-radar/ files against format rules. Runs validate.sh, reports errors/warnings, and auto-fixes issues. MUST use this skill after editing any SKILL.md or .feature-radar/ file, even if the user doesn't ask — catches format bugs like the Agent Skills spec's 1024-char description limit before they break the skill. Use when the user asks to validate, lint, or verify skills or .feature-radar/ files, after editing either, or before committing changes that touch skills/ or .feature-radar/.

日本語の概要は準備中です。原文の説明を表示しています。

runkids/feature-radar142026年9月29日 更新

runkids のスキルをすべて見る

このスキルの問題を報告する