runkids/feature-radar · Archived

feature-radar-learn

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/didn't, wants to document a decision, or mentions remembering a pattern for future use. Use when the user: - Says "remember this approach", "document this decision", "save this pattern" - Reflects: "that worked well", "lessons learned", "what did we…

First seen Mar 9, 2026

Installation

$ npx skills add runkids/feature-radar --skill feature-radar-learn

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from runkids/feature-radar.

npx skills add runkids/feature-radar

Browse all from runkids/feature-radar

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 13
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,476 B
  • docs SUMMARY.md 952 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 17 installs

SKILL.md

Extract Learnings

Capture reusable knowledge from completed work into .feature-radar/specs/.

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. </HARD-GATE>

Workflow

  1. Identify the source — ask the user what was just completed (feature, bug fix, refactor, investigation)
  2. Analyze the work — review recent commits, changed files, and implementation decisions
  3. Extract knowledge — identify what's reusable:

- Patterns: recurring solutions worth replicating (e.g., "three-tier config merge") - Decisions: architectural choices with rationale (e.g., "YAML over JSON because...") - Pitfalls: mistakes or dead ends others should avoid - Techniques: implementation approaches that worked well <HARD-GATE> Before writing to specs/, classify each piece of knowledge into exactly one category:

  • Pattern: recurring solution worth replicating
  • Decision: architectural choice with rationale
  • Pitfall: mistake or dead end to avoid
  • Technique: implementation approach that worked well

State the classification explicitly in your output. </HARD-GATE>

  1. Write to specs — create or append to .feature-radar/specs/{topic}.md
  2. Checkpoint — State what was written and ask: "I've written to specs/{topic}.md ({classification type}). Does this look correct, or should I adjust anything?" Wait for user confirmation before proceeding.
  3. Update base.md — increment the specs count in Tracking Summary

File Format

Use the format defined in ../feature-radar/references/SPEC.md § 3.4 (specs/{topic}.md).

Guidelines

  • One topic per file. If the learning spans multiple topics, create multiple files.
  • Name files by the pattern, not by the feature that produced it.

- Good: yaml-config-merge.md, symlink-vs-copy-tradeoffs.md - Bad: audit-feature-learnings.md, v2-refactor-notes.md

  • Append to existing files when the new learning extends a known topic.
  • Keep it concise — future readers need the insight, not the full story.

Example Output

→ Created specs/symlink-vs-copy-tradeoffs.md (Decision)
→ Updated base.md: specs 2 → 3

Completion Summary

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