Receber por email
← Voltar para o catálogo

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

12estrelas
Atualizado há 7 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add runkids/feature-radar

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/feature-radar-learn/svg)](https://www.skillteca.com.br/skills/feature-radar-learn)
#ai

Skills relacionadas

Ver todas de Documentos →

Alerta por categoria

Receba novas skills de Documentos toda segunda

1 email curto, só com as skills novas de Documentos. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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:
  4. Patterns: recurring solutions worth replicating (e.g., "three-tier config merge")
  5. Decisions: architectural choices with rationale (e.g., "YAML over JSON because...")
  6. Pitfalls: mistakes or dead ends others should avoid
  7. 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".

Compartilhar X LinkedIn