knowledge-curator
Use when repeated lessons, pitfalls, or decisions should move from temporary session context into durable project guidance — curate what to keep, what to discard, and where it belongs.
Best use case
knowledge-curator is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when repeated lessons, pitfalls, or decisions should move from temporary session context into durable project guidance — curate what to keep, what to discard, and where it belongs.
Teams using knowledge-curator should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/knowledge-curator/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How knowledge-curator Compares
| Feature / Agent | knowledge-curator | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when repeated lessons, pitfalls, or decisions should move from temporary session context into durable project guidance — curate what to keep, what to discard, and where it belongs.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Knowledge Curator Not every useful insight belongs in a one-off chat. Knowledge Curator turns repeated lessons from session history into maintainable project guidance so future sessions start from better defaults. ## Why This is Copilot-Exclusive Copilot CLI gives you three building blocks that work well together: - **Session artifacts** for saving structured notes during a task - **`/resume`** for continuing a past session with its artifacts and SQL state - **`session_store` search** for finding prior discussions and patterns later The key constraint matters: `session_store` is **read-only historical memory**, not a writable knowledge base. This skill is about deciding what should graduate from temporary session context into durable project docs such as `.github/copilot-instructions.md`, `CONTRIBUTING.md`, or reference guides. ## When to Use - The same repo-specific warning or pattern keeps appearing across sessions - A temporary workaround has become a stable team practice - You want to prune stale guidance instead of accumulating contradictory notes - A sprint or migration produced lessons worth promoting into project instructions ## When NOT to Use | Instead of knowledge-curator | Use | |------------------------------|-----| | You only need to find something from a past session | `copilot-exclusive/cross-session-memory` | | You need a first-pass backlog from external ecosystem research | `copilot-exclusive/ecosystem-intake` | | You are documenting a single hard-to-reverse technical decision | `documentation/architecture-decisions` | ## Prerequisites - A candidate insight worth keeping - A target destination for that insight - Enough evidence to tell whether it is stable, repeated, or obsolete ## Knowledge Layers | Layer | Medium | Best for | |-------|--------|----------| | **Session** | session artifacts, SQL notes, current plan | In-progress findings, experiments, temporary context | | **Historical** | `session_store` search + `/resume` | Looking up what happened in earlier sessions | | **Durable** | `.github/copilot-instructions.md`, `CONTRIBUTING.md`, reference docs | Stable project rules, patterns, and team-facing guidance | ## Workflow ### 1. Capture candidate lessons during the task When you notice a reusable pattern or pitfall, save it in the current session workspace instead of burying it in scrollback: ```text Save a short session note with: - the pattern or pitfall - where we saw it - whether it is provisional or stable ``` Keep these notes short and concrete. ### 2. Review historical evidence Search prior sessions before promoting anything: ```text Search prior sessions for notes about flaky setup, markdown lint failures, or validation order. Summarize the repeated findings before we decide what to keep. ``` Promotion is stronger when the same lesson shows up more than once. ### 3. Promote only durable guidance Move proven guidance into the right permanent home: - `.github/copilot-instructions.md` for broad repo-wide defaults - `CONTRIBUTING.md` for contributor workflow expectations - `guides/` or `references/` for richer explanations and examples Example prompt: ```text Promote the validated markdown workflow lessons into CONTRIBUTING.md. Keep the wording short, actionable, and repository-specific. ``` ### 4. Prune or rewrite stale guidance Do not only add. Review for drift: ```text Compare the current instructions against what recent sessions actually required. List any stale, duplicated, or contradictory guidance before editing. ``` If a note is no longer true, remove or rewrite it instead of layering on exceptions. ### 5. Export a compact handoff when needed At the end of a sprint or migration, create a concise handoff artifact: ```text Create a short project-knowledge summary for this sprint: - 5 lessons to keep - 3 pitfalls to avoid next time - 3 items that should remain temporary ``` Use that summary as review input before changing permanent instructions. ### 6. Sync durable artifacts across machines When work moves between personal machines or between planning and implementation sessions, sync the **durable output**, not the session database itself: ```text Export the artifacts worth keeping: - project instructions updates - architecture notes - migration checklists - retro summaries - reusable implementation review reports Store them in a private repository or internal docs location after removing secrets or machine-local details. ``` On the receiving machine: 1. pull the durable artifacts 2. load them as context for the new session 3. use `/resume` only for local session continuity, not as a cross-machine sync mechanism `session_store` remains a read-only local history layer. Cross-machine continuity should come from intentionally curated docs and artifacts, not from treating session memory as a shared database. ## Promotion Heuristics Promote an insight when it is: - repeated across multiple tasks or sessions - specific to this repository or workflow - likely to change future execution quality - stable enough that you want it applied by default Keep it as session-only context when it is still experimental, one-off, or weakly supported. ## Related Skills - [`cross-session-memory`](../cross-session-memory/SKILL.md) — search and resume prior sessions - [`context-prime`](../context-prime/SKILL.md) — load durable project guidance at session start - [`ecosystem-intake`](../ecosystem-intake/SKILL.md) — turn outside signals into adopt/adapt/reject candidates - [`architecture-decisions`](../../documentation/architecture-decisions/SKILL.md) — record major technical decisions explicitly
Related Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.