add skills

.claude/skills/document-features/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: document-features
+description: Populate `<docs-dir>/features/<slug>.md` for one, several, or every undocumented feature area by dispatching up to 10 parallel subagents — one per feature. The agent docs directory is discovered from `AGENTS.md` — typically `agents-docs/` (the `setup-agentic-repository` default) but may be elsewhere if `--docs-dir` was used. Use whenever the user wants to document features, fill out feature docs, write up specific features (e.g. "document auth and billing"), document all undocumented features, or follow up on `find-features` discovery. This is the natural sequel to `find-features` — that skill identifies what is missing, this skill writes the docs in parallel.
+metadata:
+  author: Olof Brogeby
+  url: https://github.com/brogeby
+---
+
+# document-features
+
+Write feature documentation for the repository — one populated `<docs-dir>/features/<slug>.md` per requested feature — by dispatching subagents in parallel so an "all" run does not serialize. The agent docs directory (`<docs-dir>`) is discovered in Phase 1; it's typically `agents-docs/` but `setup-agentic-repository` may have written it somewhere else.
+
+This skill is the documentation counterpart to `find-features`. `find-features` discovers what is missing; `document-features` is the focused worker that actually fills the template, in parallel, for the features the user names.
+
+If the user asks "find and document everything", you can start with `find-features` to build the candidate list, then hand that list to this skill. If the user already knows which features they want (e.g. "document auth and billing"), come straight here.
+
+---
+
+## Phase 1 — Verify prerequisites and locate the docs directory
+
+Confirm the repo has been initialized with the Mimas template, and discover where its agent docs actually live. `setup-agentic-repository` writes the agent doc tree to **`agents-docs/`** by default (a sibling of any human-maintained `docs/`), but `--docs-dir <dir>` can override that (e.g. `docs/agents`). Don't assume the path; discover it.
+
+1. Read `AGENTS.md` at the repo root. Every Mimas-generated `AGENTS.md` lists its docs paths in the first block (`<docs-dir>/AGENT_WORKFLOW.md`, `<docs-dir>/AGENTS_FEATURES.md`, etc.) — the directory in those paths is the docs dir for this repo.
+2. If `AGENTS.md` doesn't exist or doesn't reference the contract files, fall back to searching for `AGENTS_FEATURES.md` directly (`find . -maxdepth 3 -name AGENTS_FEATURES.md`). The directory containing it is the docs dir.
+3. Confirm the files this skill needs are there:
+   - `<docs-dir>/AGENTS_FEATURES.md` — feature documentation contract
+   - `<docs-dir>/features/feature-template.md` — canonical template
+   - `<docs-dir>/FEATURES.md` — feature index
+
+If any are missing, tell the user this skill is designed to run after `setup-agentic-repository` and stop. Do not scaffold them yourself.
+
+For the rest of this skill, treat the discovered directory as `<docs-dir>` and use it wherever paths appear. **Critical:** the subagent prompt in Phase 3 is a template — substitute the actual discovered value into it before dispatching each subagent. The subagents do not run this Phase 1 themselves and will not discover the dir on their own.
+
+Read `<docs-dir>/AGENTS_FEATURES.md` and the root `AGENTS.md` (plus any subdomain `CONTEXT.md` files) so you know the contract — what counts as an area-level doc vs. a per-service doc, and which subdomains exist. These files are authoritative; if anything in this skill drifts from them, the files win.
+
+---
+
+## Phase 2 — Decide what to document
+
+The user's request usually contains the answer. Parse what they said:
+
+- **Named features** ("document auth and billing", "write up the search feature") → take that list of slugs
+- **A number** ("document 3 features", "write up the top 5") → take a numeric count of the most significant undocumented features
+- **"all" / "every" / "everything"** → every undocumented feature with meaningful implementation
+- **Ambiguous or empty** → use `AskUserQuestion` with the same options find-features uses (Top 5 / All / Number / Specific names) plus an "Other" free-text fallback
+
+If the user is continuing from a recent `find-features` session, prefer the candidate list that already exists in the conversation over re-asking.
+
+Then quickly inventory `<docs-dir>/features/`:
+
+- Top-level `.md` files (one per documented area, ignoring `feature-template.md`)
+- Subdirectories (areas with per-service docs)
+- Entries in `<docs-dir>/FEATURES.md`
+
+Filter the requested list against the inventory:
+
+- Drop slugs that already have `<docs-dir>/features/<slug>.md`. Tell the user which ones you skipped and why
+- For named features that you cannot locate in the codebase, surface them and ask whether to skip or scaffold a TODO doc. Do not invent feature areas
+
+If the user asked for a number or "all" and you need to identify candidates yourself, scan the subdomains declared in `AGENTS.md` looking for named concepts with dedicated logic — dedicated service layer, non-trivial handler, dedicated tables/migrations, multiple endpoints, real business rules. A single empty route stub is not enough. Rank by significance and trim to the requested count.
+
+---
+
+## Phase 3 — Dispatch one subagent per feature, in parallel
+
+This is the whole point of the skill. Documentation per feature is independent work — one subagent can read the code for `auth` while another reads the code for `billing`. Serializing them throws away the parallelism the harness gives you.
+
+**Cap concurrency at 10 subagents.** If the final list has more than 10 features, dispatch the first batch of 10 in one message, wait for it to complete, then dispatch the next batch. Do not exceed 10 concurrent agents — it overwhelms tooling and the user's review can't keep up.
+
+For each feature in the current batch, spawn one `Agent` call in the **same message** (this is what makes them run in parallel). Use the `general-purpose` subagent unless something more specific fits.
+
+Each subagent gets a self-contained prompt — it has not seen this conversation, so include everything it needs. **Before dispatching, substitute `<docs-dir>` with the value you discovered in Phase 1** (typically `agents-docs`). The subagents do not discover the dir on their own.
+
+```
+You are documenting a single feature area for this repository. The output is one populated markdown file at `<docs-dir>/features/<slug>.md` that follows the project's feature documentation contract.
+
+Feature slug: <slug>
+One-line concept (from discovery, may be rough): <concept>
+
+Authoritative reading order (read these first, in order):
+1. `<docs-dir>/AGENTS_FEATURES.md` — the contract that governs how feature docs are written
+2. `<docs-dir>/features/feature-template.md` — the canonical template. Mirror its section order and headings; do not invent your own structure
+3. `AGENTS.md` and any subdomain `CONTEXT.md` files — for vocabulary and where the code lives
+
+Your task:
+- Locate this feature in the codebase. Confirm it has meaningful implementation (service layer, handler, endpoints, tables, real business rules). If it is only a stub, stop and report that back — do not write a doc for a stub
+- Create `<docs-dir>/features/<slug>.md` from the template
+- Fill in what you can verify from the code: overview, responsibilities, key concepts, endpoint(s), service/handler/repository paths, key types, tests location, related features
+- Set `Area:` to the slug, `Status:` to `Active` for production code or `In Progress` for half-built features, and `Last updated:` to today's date in `YYYY-MM-DD`
+- For sections you cannot confidently fill (performance, security review, undocumented edge cases), keep the template's prompt and add a clear `TODO:` marker. Honest gaps beat invented content
+- If the feature has multiple distinct services or endpoints worth separating, also create `<docs-dir>/features/<slug>/<service>.md` files from the same template and link them from the area doc — but only when complexity actually warrants it. Do not duplicate large sections between area and per-service docs
+- Do not edit `<docs-dir>/FEATURES.md` — the dispatcher will update the index once all features are written, to avoid concurrent edits to the same file
+- Do not commit anything
+
+Report back when done with:
+- Path(s) of the file(s) you created
+- One-line description of the feature (this will be used for the FEATURES.md entry)
+- Which template sections you left as TODO
+- Anything you noticed that needs human judgment
+```
+
+Substitute `<slug>`, `<concept>`, and `<docs-dir>` per feature. Keep the rest verbatim — the subagent depends on having the contract in its own context.
+
+If features turn out to be unrelated to one another (different subdomains, different layers), there's no need to coordinate beyond avoiding the shared `<docs-dir>/FEATURES.md` file. The dispatcher updates the index after the batch returns.
+
+---
+
+## Phase 4 — Update the index and report back
+
+Once a batch completes, collect each subagent's reported one-liner and add entries to `<docs-dir>/FEATURES.md` in alphabetical order, in the form:
+
+```
+- [<slug>](./features/<slug>.md) — one-line description
+```
+
+If `<docs-dir>/FEATURES.md` still contains the placeholder `_No feature areas documented yet. Add entries as you build out the system._`, remove that line as you add the first real entry.
+
+Then, if more features remain (because the original list was >10), dispatch the next batch of up to 10 and repeat.
+
+When everything is written, tell the user:
+
+- Which feature docs were created (full paths), grouped by batch if there were multiple
+- Which requested features were skipped, and why ("already documented at `<docs-dir>/features/<slug>.md`", "could not locate in codebase", "implementation too thin to earn an entry yet")
+- Which sections in the new docs are TODOs that still need human judgment
+- That `<docs-dir>/FEATURES.md` was updated and how many entries were added
+- Any discrepancies you noticed between `<docs-dir>/FEATURES.md` and the filesystem
+
+Do not commit the changes. The user reviews before committing.
+
+---
+
+## Why this is structured around subagents
+
+Documenting one feature is read-heavy and largely independent of documenting another — different files, different services, different endpoints. The slow part is the reading, and parallelizing the reading is the entire reason this skill exists separately from `find-features`. Spawning ten subagents in one message and letting them work concurrently turns a 10-minute sequential run into something closer to a 1–2 minute parallel one, with each subagent producing a focused, faithful doc because its whole context is one feature.
+
+The 10-agent cap is pragmatic, not theoretical: more than that and you risk rate limits, output you can't usefully review at once, and the dispatcher running out of room to track which agent owns which slug. Two batches of ten is fine; ten batches of one is the failure mode this skill is designed to avoid.
+
+---
+
+## What makes a good output
+
+**Faithful to the code.** Endpoint paths, file locations, method names, table names must match what is actually in the repo. If a subagent can't find something, the right move is a `TODO:` marker, not a guess.
+
+**Concept-first for area docs.** The area-level doc explains what the feature is *for* — responsibilities, boundaries, vocabulary. Deep implementation detail belongs in per-service docs once they exist.
+
+**Honest about gaps.** A clear `TODO: describe rate limiting` is more useful than a fabricated rate limit policy. Future sessions can fill these in from real information.
+
+**Proportionate.** A small CRUD endpoint with one handler does not need every section of the template. Trim or skip sections that genuinely do not apply. The template is a checklist of what *might* be relevant, not a contract that every section must be populated.
+
+**Honors the contract.** The structure, headings, and rules in `<docs-dir>/AGENTS_FEATURES.md` and `<docs-dir>/features/feature-template.md` win every time. If this skill's instructions ever drift from those files, the files are authoritative — they live with the project and are what other agents read.

.claude/skills/document-features/evals/evals.json

@@ -0,0 +1,35 @@
+{
+  "skill_name": "document-features",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "find-features just listed auth, billing, and search as undocumented. Please go document all three.",
+      "expected_output": "Skill verifies prerequisites by discovering the agent docs directory (typically agents-docs/, but may be elsewhere — read from AGENTS.md), takes the three named features, inventories <docs-dir>/features/ to confirm none are already documented, dispatches one subagent per feature in a single message (so they run in parallel), substitutes the discovered <docs-dir> value into each subagent prompt before dispatching, then writes <docs-dir>/features/auth.md, <docs-dir>/features/billing.md, <docs-dir>/features/search.md from the template, and appends three entries to <docs-dir>/FEATURES.md (alphabetical). Leaves TODO markers where content cannot be derived from the code. Does not commit.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "document every undocumented feature in this repo",
+      "expected_output": "Skill discovers the docs dir, parses 'every' as 'all', identifies undocumented feature areas with meaningful implementation, dispatches subagents in parallel batches capped at 10 per batch (with the discovered <docs-dir> substituted into each subagent prompt), writes one doc per feature, and updates <docs-dir>/FEATURES.md. If there are more than 10 features, runs a second batch after the first finishes. Reports back which features were skipped and why.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "write the docs for billing",
+      "expected_output": "Skill discovers the docs dir, treats 'billing' as a single named feature, checks <docs-dir>/features/billing.md does not already exist, locates billing in the codebase, dispatches one subagent to document it (with <docs-dir> substituted into the prompt), writes <docs-dir>/features/billing.md from the template, and adds an entry to <docs-dir>/FEATURES.md. If billing already has a doc or cannot be located, the skill surfaces that instead of silently creating something.",
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "document the top 5 undocumented features",
+      "expected_output": "Skill discovers the docs dir, parses '5' as a numeric limit, identifies undocumented feature areas, ranks by significance, takes the top 5, dispatches 5 subagents in parallel in a single message (each with <docs-dir> substituted), writes 5 docs from the template, and updates <docs-dir>/FEATURES.md with 5 alphabetical entries. Other candidates are listed in the final report as 'not selected this round'.",
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "this repo uses --docs-dir docs/agents for its agent docs. document the auth feature.",
+      "expected_output": "Skill discovers the docs dir is docs/agents/ (from AGENTS.md path references), dispatches a single subagent with docs/agents substituted into the subagent prompt template, writes docs/agents/features/auth.md, and updates docs/agents/FEATURES.md. Does not hardcode agents-docs/ or docs/features/ — uses the discovered path everywhere.",
+      "files": []
+    }
+  ]
+}

.claude/skills/find-features/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: find-features
+description: Discover feature areas in the current repository that are not yet documented under the agent docs `features/` tree (scaffolded by `setup-agentic-repository` — `agents-docs/features/` by default, or wherever `--docs-dir` put it), then create populated feature docs from the canonical template. Use whenever the user wants to find undocumented features, fill out `features/`, catch up on missing feature documentation, document feature X/Y/Z, or mentions "find features". This is the natural follow-up to `setup-agentic-repository`, which scaffolds the empty `features/` tree this skill populates.
+metadata:
+  author: Olof Brogeby
+  url: https://github.com/brogeby
+---
+
+# find-features
+
+Discover feature areas in this repository that are missing from `<docs-dir>/features/`, then create a populated markdown file for each one — following the contract in `<docs-dir>/AGENTS_FEATURES.md` and the template at `<docs-dir>/features/feature-template.md`. The agent docs directory (`<docs-dir>`) is discovered in Phase 1 — it's typically `agents-docs/` but `setup-agentic-repository` may have written it somewhere else.
+
+The Mimas template (`setup-agentic-repository`) scaffolds an empty `<docs-dir>/features/` tree. This skill is the next step — it fills it in.
+
+---
+
+## Phase 1 — Verify prerequisites and locate the docs directory
+
+Confirm the repo has been initialized with the Mimas template, and discover where its agent docs actually live. `setup-agentic-repository` writes the agent doc tree to **`agents-docs/`** by default (a sibling of any human-maintained `docs/`), but `--docs-dir <dir>` can override that (e.g. `docs/agents`). Don't assume the path; discover it.
+
+1. Read `AGENTS.md` at the repo root. Every Mimas-generated `AGENTS.md` lists its docs paths in the first block (`<docs-dir>/AGENT_WORKFLOW.md`, `<docs-dir>/AGENTS_FEATURES.md`, etc.) — the directory in those paths is the docs dir for this repo.
+2. If `AGENTS.md` doesn't exist or doesn't reference the contract files, fall back to searching for `AGENTS_FEATURES.md` directly (`find . -maxdepth 3 -name AGENTS_FEATURES.md`). The directory containing it is the docs dir.
+3. Confirm the files this skill needs are there:
+   - `<docs-dir>/AGENTS_FEATURES.md` — feature documentation contract
+   - `<docs-dir>/features/feature-template.md` — the canonical template
+   - `<docs-dir>/FEATURES.md` — the feature index
+
+If any of those are missing, tell the user this skill is designed to run after `setup-agentic-repository` and stop. Don't try to scaffold them yourself — that is the other skill's job.
+
+For the rest of this skill, treat the discovered directory as `<docs-dir>` and use it wherever paths appear. Don't hardcode `docs/` or `agents-docs/` in your reasoning, prompts, or report.
+
+Read `<docs-dir>/AGENTS_FEATURES.md` and the root `AGENTS.md` (plus any subdomain `CONTEXT.md` files) so you know:
+
+- what counts as a feature area — a named concept with dedicated logic in the codebase, identified by naming and behavior, not folder structure alone
+- the split between area-level docs (`<docs-dir>/features/<area>.md`) and per-service docs (`<docs-dir>/features/<area>/<service>.md`)
+- which subdomains exist and where their code lives
+
+These files define the contract you must satisfy. The whole point of the skill is to produce docs that look like a senior engineer on this project wrote them, following the rules already agreed in `AGENTS_FEATURES.md`.
+
+---
+
+## Phase 2 — Inventory what is already documented
+
+List `<docs-dir>/features/` and capture, before asking the user anything:
+
+- Top-level `.md` files (one per documented area) — ignore `feature-template.md`, it is the template
+- Subdirectories under `<docs-dir>/features/` (areas with per-service docs)
+- The entries listed in `<docs-dir>/FEATURES.md`
+
+You will use this list to filter out features that already have an area doc. Discrepancies between the filesystem and `<docs-dir>/FEATURES.md` are worth flagging in your final report, but don't block on them.
+
+---
+
+## Phase 3 — Ask the user what to discover
+
+Use `AskUserQuestion` to ask how many features (or which ones) to discover. Phrase the question so it accepts a number, "all", or a free-text list of names. The tool always offers an "Other" free-text fallback, so give a few sensible presets and let the user type a specific answer when none fit.
+
+```
+questions:
+  - question: "How many features would you like to discover, or which ones specifically?"
+    header: "Scope"
+    multiSelect: false
+    options:
+      - label: "Top 5 (Recommended)"
+        description: "Discover up to 5 of the most significant undocumented feature areas."
+      - label: "All"
+        description: "Find every undocumented feature area in the codebase."
+      - label: "A specific number (1–10)"
+        description: "I'll tell you a number from 1 to 10."
+      - label: "Specific names"
+        description: "I'll list the feature names I want documented (e.g. 'auth, billing, search')."
+```
+
+Parse whatever they answer with — accept a bare number, the word "all" (any case), or a comma- or space-separated list. Phrases like "find feature x, y, z" or "auth and billing" should yield `["x", "y", "z"]` and `["auth", "billing"]` respectively. Don't be strict about format; pull out the names.
+
+If the user names features you can't locate in the codebase, surface that and ask whether to skip them or create scaffolded TODO docs for them. Do not silently invent them.
+
+---
+
+## Phase 4 — Discover undocumented feature areas
+
+Scan the codebase for feature areas using the definition from `<docs-dir>/AGENTS_FEATURES.md`. Start from the subdomains declared in the root `AGENTS.md` — if there are several large subdomains, **launch one subagent per subdomain in parallel** so discovery doesn't serialize.
+
+For each candidate feature, capture:
+
+- **Slug** — kebab-case, ideally matching how the area is referenced in code or routes (e.g. `auth`, `billing`, `recruitment-content`)
+- **One-sentence concept** — what the feature does, in user-facing terms
+- **Where the code lives** — routes, services, handlers, components, modules
+- **Significance signal** — at least one of: dedicated service layer, non-trivial handler, dedicated DB tables/migrations, multiple endpoints, real business rules. A single empty route stub is not enough
+- **Whether it is already documented** — does `<docs-dir>/features/<slug>.md` exist already?
+
+Then filter:
+
+- Drop anything that already has an area-level doc
+- Drop stubs and scaffolding — `<docs-dir>/AGENTS_FEATURES.md` says an entry must have meaningful implementation. Err on the side of leaving thin features out and noting them as "not yet earning an entry"
+
+Rank what is left by significance (surface area, number of endpoints, depth of business logic), then trim to what the user asked for:
+
+- **Number** → take the top N from the ranked list
+- **"all"** → take everything that survived the filter
+- **Named features** → take only those, matched by slug or close fuzzy match, warning about any that didn't match
+
+---
+
+## Phase 5 — Create the feature docs
+
+For each chosen feature:
+
+1. Read `<docs-dir>/features/feature-template.md` once and use it as the structural template — section order, headings, prompts. Do not invent your own structure.
+2. Create `<docs-dir>/features/<slug>.md` populated from the template:
+   - Fill in what you can verify from the code: overview, responsibilities, key concepts, API endpoint(s), service/handler/repository paths, key types, tests location, related features
+   - Set **`Area:`** to the slug, **`Status:`** to `Active` for production code or `In Progress` for half-built features, and **`Last updated:`** to today's date in `YYYY-MM-DD`
+   - For sections you cannot confidently fill (performance characteristics, security review, edge cases nobody has documented), keep the template's prompt and add a clear TODO marker. Leaving an honest gap is better than inventing content
+3. If the feature has multiple distinct services or endpoints worth separating, also create `<docs-dir>/features/<slug>/` and seed per-service docs (`<docs-dir>/features/<slug>/<service>.md`) from the same template, then link them from the area doc. Only do this when complexity actually warrants it — the contract says don't duplicate large sections between area and per-service docs
+
+After writing each file, add an entry to `<docs-dir>/FEATURES.md` in alphabetical order, in the form:
+
+```
+- [<slug>](./features/<slug>.md) — one-line description
+```
+
+If `<docs-dir>/FEATURES.md` still contains the placeholder `_No feature areas documented yet. Add entries as you build out the system._`, remove that line as you add the first real entry.
+
+---
+
+## Phase 6 — Report back
+
+Tell the user:
+
+- Which feature docs were created (full paths)
+- Which candidates were considered but rejected, and why ("too thin to earn an entry yet", "matches existing doc <name>", etc.)
+- Which sections in the new docs are TODOs that still need human judgment (performance, security, business rules, error scenarios)
+- Whether `<docs-dir>/FEATURES.md` was updated, and any discrepancies you noticed between it and the filesystem
+
+Do not commit the changes. The user reviews before committing.
+
+---
+
+## What makes a good output
+
+**Faithful to the code.** Endpoint paths, file locations, method names, table names must match what is actually in the repo. If you cannot find something, leave the template prompt in place with a TODO — do not guess.
+
+**Concept-first for area docs.** The area-level doc explains what the feature is *for* — responsibilities, boundaries, vocabulary. Implementation detail belongs in per-service docs once they exist.
+
+**Honest about gaps.** A clear `TODO: describe rate limiting` is more useful than a fabricated rate limit policy. Future sessions can fill these in from real information.
+
+**Proportionate.** A small CRUD endpoint with one handler does not need every section of the template. Trim or skip sections that genuinely do not apply (no auth, no caching, no migrations, no feature flags). The template is a checklist of what *might* be relevant, not a contract that every section must be populated.
+
+**Honors the contract.** The structure, headings, and rules in `<docs-dir>/AGENTS_FEATURES.md` and `<docs-dir>/features/feature-template.md` win every time. If this skill's instructions ever drift from those files, the files are authoritative — they live with the project and are what other agents read.

.claude/skills/find-features/evals/evals.json

@@ -0,0 +1,35 @@
+{
+  "skill_name": "find-features",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I just ran /setup-agentic-repository on this repo and the features folder is empty. Can you find the most important features and write up docs for them?",
+      "expected_output": "Skill verifies prerequisites by discovering the agent docs directory (reading AGENTS.md or searching for AGENTS_FEATURES.md — typically agents-docs/ but may be elsewhere), asks how many/which features (with Top 5 / All / Number / Names options), scans the codebase, creates <docs-dir>/features/<slug>.md files from the template for the chosen features, and appends entries to <docs-dir>/FEATURES.md (alphabetical). Honestly leaves TODO markers where it cannot derive content from the code.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "we have some feature docs already but I think auth and billing are missing — can you check and add what's missing?",
+      "expected_output": "Skill discovers the docs dir, inventories the existing <docs-dir>/features/, treats the user's free-text answer 'auth and billing' as the named list, verifies both exist in the codebase (skipping or flagging any that don't), and creates only the missing area docs while leaving already-documented features alone.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "find every undocumented feature in this repo and document them all",
+      "expected_output": "Skill interprets 'every' as 'all', discovers every feature area with meaningful implementation that lacks an area doc in the discovered <docs-dir>/features/, filters out stubs, ranks by significance, and creates one doc per area plus <docs-dir>/FEATURES.md entries. Reports back rejected candidates with reasons.",
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "find 3 features that aren't documented yet",
+      "expected_output": "Skill parses '3' as a numeric limit, discovers undocumented features in the discovered docs dir, takes the top 3 by significance, and creates docs and <docs-dir>/FEATURES.md entries for exactly those three. Other candidates are listed in the final report as 'not selected this round'.",
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "the docs are under agents-docs/ in this repo, find any feature areas we haven't written up yet",
+      "expected_output": "Skill reads AGENTS.md (or falls back to searching for AGENTS_FEATURES.md), confirms the docs dir is agents-docs/, uses agents-docs/AGENTS_FEATURES.md as the contract and agents-docs/features/feature-template.md as the template, and writes new docs into agents-docs/features/. Does not hardcode 'docs/' anywhere in the output.",
+      "files": []
+    }
+  ]
+}

skills-lock.json

@@ -5,6 +5,18 @@
       "source": "JuliusBrussee/caveman",
       "sourceType": "github",
       "computedHash": "4d486dd6f9fbb27ce1c51c972c9a5eb25a53236ae05eabf4d076ac1e293f4b7a"
+    },
+    "document-features": {
+      "source": "Grade-AI-Labs/Mimas",
+      "sourceType": "github",
+      "skillPath": "skills/document-features/SKILL.md",
+      "computedHash": "e4df8d900aab6698d2ae65c575ca006a05d13ff99a17d3a7273124858d57051d"
+    },
+    "find-features": {
+      "source": "Grade-AI-Labs/Mimas",
+      "sourceType": "github",
+      "skillPath": "skills/find-features/SKILL.md",
+      "computedHash": "2581a85c49fff668c838068c06611723e233890be7e3cdeaab6c7545ecd85e89"
     }
   }
 }