# Lc Curate Context > Create optimized llm-context rules for specific tasks by analyzing codebase content and generating minimal file selection patterns Use when this capability is needed. - Skill: `tomevault-io/lc-curate-context` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/lc-curate-context` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/lc-curate-context/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/lc-curate-context --- # Context Descriptor Creation Create rules that define the minimal sufficient context for a task. The job is not to gather a lot of relevant code. The job is to produce the smallest full-file and excerpted-file set that is still enough to complete the task. ## Use This Workflow 1. Understand the task in concrete file terms. 2. Start from the narrowest sensible filter baseline. 3. Put files to edit in `full-files`. 4. Put callers, dependencies, and large reference files in `excerpted-files`. 5. Run `lc-preview`. 6. Read the exact `Full files` and `Excerpted files` lists. 7. Tighten until the selection is minimal and sufficient. ## Pick the Baseline First Start narrow unless you have a good reason not to. **Use `lc/flt-no-files` when:** - the task is surgical - you already know the likely files - you want exact control over membership **Use `flt-repo-base` or `lc/flt-base` when:** - you need a broad project slice - the task spans a subsystem - the project already has a disciplined repo-level filter If `lc-preview` shows many unexpected full files, your baseline is too broad. ## Full vs Excerpted **Full files** - files you expect to edit - small configs or templates that directly control the behavior - compact integration points where exact code matters **Excerpted files** - callers and dependencies - large modules where structure is enough - reference implementations and surrounding architecture Move a file from excerpted to full only when the exact body matters. ## Verify with `lc-preview` `lc-preview` is the main verification step. Read it in this order: 1. `Summary` 2. `Full files` 3. `Excerpted files` Ask: - Are all expected edit targets in `Full files`? - Did any unrelated files leak into `Full files`? - Are context files in `Excerpted files` instead of `Full files`? - Is the total selection small enough for the task? Do not trust a rule until the exact file lists look right. ## Grounded Example 1: Improve `lc-preview` Task: change preview formatting so it lists all selected full and excerpted files. This is a narrow task. Start from `lc/flt-no-files`. ```yaml --- description: Improve lc-preview verification output compose: filters: [lc/flt-no-files] excerpters: [lc/exc-base] also-include: full-files: - "/src/llm_context/context_preview.py" - "/src/llm_context/cli.py" - "/src/llm_context/commands.py" - "/src/llm_context/lc_resources/templates/lc/preview.j2" excerpted-files: - "/src/llm_context/context_generator.py" - "/src/llm_context/context_spec.py" - "/src/llm_context/file_selector.py" - "/src/llm_context/rule.py" --- Make lc-preview show exact full and excerpted file membership for rule verification. ``` Why this shape: - full: the command path and template being edited - excerpted: supporting selection and rendering code for orientation - narrow baseline: prevents accidental inclusion of most of the repo What to look for in `lc-preview`: - only those four edit targets in `Full files` - supporting internals in `Excerpted files` - no tests, docs, or unrelated resources unless intentionally added ## Grounded Example 2: Tighten Primitive Rules and Skill Guidance Task: improve primitive rule composition and the skill docs that teach it. This task is broader, but still needs discipline. Start from a repo filter only if it already excludes enough noise. ```yaml --- description: Improve primitive rules and skill guidance compose: filters: [flt-repo-base, flt-no-excerpters] excerpters: [lc/exc-base] also-include: full-files: - "/src/llm_context/lc_resources/skills/lc-curate-context/*.md" - "/src/llm_context/lc_resources/rules/lc/*.md" - "/.llm-context/rules/*.md" - "/src/llm_context/rule.py" - "/src/llm_context/rule_parser.py" excerpted-files: - "/src/llm_context/context_spec.py" - "/src/llm_context/file_selector.py" - "/src/llm_context/commands.py" --- Improve the primitive rule vocabulary and the skill instructions that teach agents how to compose and verify task rules. ``` What to look for in `lc-preview`: - all rule and skill docs appear in `Full files` - supporting mechanics stay excerpted unless they are being changed - repo-level defaults do not drag in unrelated source files If preview expands too far, drop the repo baseline and switch to `lc/flt-no-files`. ## CLI and MCP Equivalents | Step | CLI | MCP | |------|-----|-----| | Explore | `lc-outlines` | `lc_outlines` | | Validate | `lc-preview ` | `lc_preview` | | Get context | `lc-context ` | `lc_outlines` + `lc_missing` | | Check drift | `lc-changed` | `lc_changed` | | Fetch exact files | `lc-missing -f '[paths]' -t ` | `lc_missing` | ## Path Rules In rule patterns, paths start with `/`, relative to project root. ```yaml - "/src/llm_context/rule.py" - "/tests/test_outliner.py" ``` Preview and generated context show namespaced paths like `/{project-name}/src/...`. ## File Naming - `tmp-prm-.md`: temporary task rule - `prm-.md`: reusable prompt rule - `flt-.md`: reusable filter primitive ## Feedback This skill is young — actively log friction whenever something is awkward, surprising, ambiguous, missing, or led you down the wrong path. Don't filter; patterns only emerge from honest individual observations. **Where to log** (try in order): 1. **If the user has a local `llm-context.py` checkout** (sibling repo, editable install, or anywhere else on disk) — append to `/field-notes.md`. That's the lowest-friction path to the maintainer, since the entry lands directly in the upstream working tree. - Probe common locations before asking: `../llm-context.py`, `~/GitHub/llm-context.py`, `~/src/llm-context.py`. If the user has mentioned the checkout elsewhere in the conversation, use that path. - If `field-notes.md` doesn't exist yet, create it with the header below. 2. **Otherwise** — append to `.llm-context/SKILL-FEEDBACK.md` in the current project (created on first entry, git-ignored by default). The user can copy entries upstream later. 3. **For items that clearly generalize beyond this project** — also paste the entry as an issue at https://github.com/cyberchitta/llm-context.py/issues so the maintainer can triage it. **Entry format** (newest at the top): - **Date** — `YYYY-MM-DD`, absolute (resolve "today"/"Tuesday" before writing). - **Task** — one line describing what the user was trying to accomplish. - **Observation** — 1–3 sentences: what surfaced, what worked around it (if anything), and whether it reads as a one-off or hints at a pattern. - **Suggested home** — one of `Skill.md` / `PATTERNS.md` / `SYNTAX.md` / `EXAMPLES.md` / `TROUBLESHOOTING.md` / upstream code / `still-unsure`. `still-unsure` is a valid answer. **First-time header** to drop at the top of a new feedback file (either `/field-notes.md` or `.llm-context/SKILL-FEEDBACK.md`): ```markdown # llm-context skill feedback (uncommitted) Informal log of friction with the `lc-curate-context` skill — anything awkward, buggy, missing, or surprising. Newest at the top. ``` Log first; decide later whether the observation generalizes. ## References - `PATTERNS.md` for reusable shapes - `EXAMPLES.md` for worked examples - `SYNTAX.md` for rule syntax - `TROUBLESHOOTING.md` for failure cases --- > Source: [cyberchitta/llm-context.py](https://github.com/cyberchitta/llm-context.py) — distributed by [TomeVault](https://tomevault.io).