無料GitHub で公開

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 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-radarスター 14(GitHub 14 + cccskills 0)

実行スコア未検証

インストール方法を見る

含まれるファイル（1）

SKILL.md2.8 KB

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

Identify the source — ask the user what was just completed (feature, bug fix, refactor, investigation)
Analyze the work — review recent commits, changed files, and implementation decisions
Extract knowledge — classify each reusable piece into exactly one category, and state the classification in your output:
- Pattern: recurring solution worth replicating (e.g., "three-tier config merge")
- Decision: architectural choice with rationale (e.g., "YAML over JSON because...")
- Pitfall: mistake or dead end to avoid
- Technique: implementation approach that worked well
Write to specs — create or append to .feature-radar/specs/{topic}.md
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.
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".

レビュー

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

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

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

同じリポジトリのスキル

feature-radar

無料

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.

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