agentsclimarketplace

Feature radar

Skill runkids/feature-radar/skills/feature-radar

πŸ“‘ AI skill that helps your coding agent discover, track, and prioritize what to build next.

Install
npx -y skills add runkids/feature-radar --skill feature-radar

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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: - Asks "what should we build next?", "what's most impactful?", or similar - Wants to prioritize, rank, or compare features or backlog items - Needs roadmap planning, project direction, or strategic feature decisions - Says "help me prioritize", "review our backlog", "what are we missing" - Mentions .feature-radar/ directory or feature tracking - Wants periodic reassessment of deferred or open opportunities

SKILL.md

9.5 KB, as published. Nobody here has run it

Feature Discovery & Prioritization

Mode Routing

<HARD-GATE> Parse the user argument BEFORE any other logic. Determine the mode:
ArgumentModePhases
(none) or fullfull1-6 (all)
quickquick1-3 only
evaluateevaluatereconciliation β†’ 5-6 (skip 1-3)
#N (e.g. #2)focusRead opportunity N β†’ Phase 5 (single item) β†’ Phase 6

Route rules:

  • full: Follow normal workflow (Phase 1-6).
  • quick: Execute Phase 1-3, then skip to Completion Summary.
  • evaluate: Run "Subsequent Runs" reconciliation (steps 1-2), then jump directly to Phase 5-6.
  • focus (#N): Read .feature-radar/opportunities/{N}-*.md. If not found, list available opportunities and ask user to pick. Then run Phase 5 for that single opportunity, followed by Phase 6.

State the detected mode before proceeding: "Mode: {mode}" </HARD-GATE>

Bootstrap (First Run)

If .feature-radar/ does not exist at the project root, create it:

.feature-radar/
β”œβ”€β”€ base.md
β”œβ”€β”€ archive/
β”œβ”€β”€ opportunities/
β”œβ”€β”€ specs/
└── references/

Then generate base.md by completing the following:

<HARD-GATE> Complete ALL steps before presenting base.md to the user:
  1. Detect stack β€” read go.mod, package.json, Cargo.toml, pyproject.toml. Follow imports to understand the dependency graph. Don't just read the config β€” understand the architecture.
  2. Map structure β€” list top-level directories. For each, read at least one file to understand its purpose. Identify: entry points, core logic, tests, docs, configuration.
  3. Extract features β€” scan exports, commands, API routes, or public functions. Read the implementations, not just the names. Understand what each feature actually does.
  4. Find inspiration sources β€” read README, CONTRIBUTING, docs/ for related projects and communities
  5. Verify with user β€” present the generated base.md and ask: "Does this accurately describe your project?" </HARD-GATE>

After presenting base.md, support iterative refinement per references/WORKFLOW-PATTERNS.md.

<HARD-GATE> Do NOT proceed to the Workflow until the user approves base.md. </HARD-GATE>

base.md Template

Generate base.md following the structure defined in references/SPEC.md (sections 2-5). Read references/SPEC.md first, then fill {placeholders} with project-specific analysis.

Key sections to generate:

  • Project Context β€” detected language, architecture, key feature areas, core philosophy, inspiration sources
  • Feature Inventory β€” implemented features table + value & innovation landscape table
  • Tracking Summary β€” counts per category (start at 0)
  • Directory Layout β€” tree view
  • Classification Rules β€” per references/SPEC.md Β§3.2-3.5
  • Maintenance Workflow β€” feature flow between directories
  • Archive Extraction Checklist β€” per references/SPEC.md Β§4.3

After creating the directory, ask the user: "Should I add .feature-radar/ to .gitignore?" (Recommended if the tracking data is internal and shouldn't be committed.)

Subsequent Runs

On subsequent runs (.feature-radar/ already exists):

  1. Read existing base.md β€” do NOT overwrite
  2. Run reconciliation per references/DEEP-READ.md steps 2-6
  3. Proceed to Mode Routing

Behavioral Directives

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

Additional directives for this skill:

  • Do not skip phases outside mode rules β€” follow the Mode Routing and Phase execution HARD-GATEs. For conditional phases, state the skip condition check result before deciding to skip.
  • Reconcile on subsequent runs β€” see "Subsequent Runs" section above. </HARD-GATE>

Workflow

Execute phases in order.

<HARD-GATE> Phase execution rules (mode-dependent):

full mode (default):

  • Phase 1-3: ALWAYS execute.
  • Phase 4: Skip ONLY if no documentation directory exists.
  • Phase 5-6: Skip ONLY if no open opportunities exist.

quick mode:

  • Phase 1-3: Execute. Stop after Phase 3 β†’ Completion Summary.

evaluate mode:

  • Phase 1-4: Skip (reconciliation already done in Subsequent Runs).
  • Phase 5-6: Execute. Skip ONLY if no open opportunities exist.

focus mode (#N):

  • Phase 1-4: Skip.
  • Phase 5: Evaluate the single targeted opportunity only.
  • Phase 6: Propose for that opportunity only.

For each phase completed, state what was produced before moving to the next phase. </HARD-GATE>

Phase 1: Scan & Classify

  1. Read source files (feature ideas, user feedback, ecosystem observations, creative proposals, issue trackers)
  2. Cross-reference each entry against the codebase
  3. Classify:
    • Done / Covered / Rejected / N/A β†’ archive
    • Open / Partially Done β†’ opportunity
    • Cross-cutting pattern β†’ specs
    • External observation β†’ references

Checkpoint: Present classification results using this format, then ask "Continue to Phase 2?"

Phase 1 complete:
| Classification | Count | Items |
|---------------|-------|-------|
| Archive       | {n}   | {list} |
| Opportunity   | {n}   | {list} |
| Spec          | {n}   | {list} |
| Reference     | {n}   | {list} |

Phase 2: Archive Completed Features

For each archive candidate:

  1. Create archive/{nn}-{slug}.md
  2. Run the Archive Extraction Checklist (mandatory):
    • Extract learnings β†’ specs/
    • Derive new opportunities β†’ opportunities/
    • Update references β†’ references/
    • Update ecosystem trends β†’ specs/ecosystem-trends.md
  3. Mark the entry as processed in the source (strikethrough + status)

Phase 3: Organize Open Opportunities

  1. Create opportunities/{nn}-{slug}.md
  2. Assess Impact and Effort realistically
  3. Write an honest "Our Position" β€” do we actually want this?

Checkpoint: Present opportunities using this format, then ask "Continue to Phase 4?"

Phase 3 complete: {n} opportunities organized
| # | Opportunity | Impact | Effort | Our Position |
|---|------------|--------|--------|-------------|
| {nn} | {title} | High/Med/Low | High/Med/Low | {1-line stance} |

Phase 4: Gap Analysis

Find implemented features that docs don't mention:

  1. Scan documentation for coverage of implemented features
  2. For each gap: which feature, which page should cover it, standalone guide or section

Phase 5: Evaluate & Prioritize

CriterionQuestion
Real user demandAre users actually asking for this?
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?

Rank into tiers:

  • Build next: High value + strong demand or innovation potential + reasonable effort
  • Build soon: Good value + moderate demand
  • Monitor: Low demand or premature
  • Skip: Conflicts with philosophy or negligible value

Checkpoint: Present tier ranking using this format, then ask "Continue to Phase 6 (Propose)?"

Phase 5 complete:
| Tier | # | Opportunity | Demand | Value | Innovation | Effort/Impact | Fit | Timing |
|------|---|------------|--------|-------|------------|--------------|-----|--------|
| Build next | {nn} | {title} | {H/M/L} | {H/M/L} | {H/M/L} | {H/M/L} | {H/M/L} | {H/M/L} |
| Build soon | ... | | | | | | |
| Monitor    | ... | | | | | | |
| Skip       | ... | | | | | | |

Phase 6: Propose & Decide

For each "Build next" feature (top 1-3), present a proposal card:

### {nn}. {Title}
**Pitch**: {One paragraph β€” what value does this create?}
**Effort**: {N days} β€” {brief justification}
**Key decisions**:
- {decision 1}
- {decision 2}

After all cards, ask: "Should we enter plan mode for [feature]?"

Completion Summary

Follow the template in references/DIRECTIVES.md, with skill name "Complete" and an additional line: Top recommendation: {feature name} β€” {one-line pitch}

Guardrails

  • Don't copy blindly. Evaluate fit with YOUR architecture and users, not someone else's.
  • Don't overcount. 1 issue with no comments = weak signal.
  • Don't undercount. Multiple independent asks = strong signal.
  • Chase value, not features. Ask "what problem does this solve?" before "what does this do?"
  • Be honest about effort. Low < 1 day. Medium 1-3 days. High 1+ week.
  • Challenge deferred items. "Deferred" β‰  "forever" β€” re-evaluate each session.
  • Think creatively. The best features aren't always the obvious ones β€” look for novel angles.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.