alexion/skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove consume and wiki skills

Browse Source
This commit is contained in:
alexion
2026-07-31 18:45:55 -04:00
parent 942d32dcba
commit d0c9f94713
3 changed files with 0 additions and 212 deletions
Download Patch File Download Diff File Expand all files Collapse all files

131
skills/consume/SKILL.md
View File

@@ -1,131 +0,0 @@
---
name: consume
description: "Consume a project (or, later, another source) into the agent's AI-managed wiki — distil generalized, transferable knowledge into the artifact store, then clear the consumed scaffolding. Deliberate: run as /skill:consume [target], never automatically."
disable-model-invocation: true
---
# consume
Mine a source for its knowledge, routing each fact to the agent's AI-managed wiki or the target's always-loaded docs, then clear the consumed scaffolding once the knowledge is safely captured.
`/consume [target]` ingests one target — a filesystem path, defaulting to the current directory — and distils what it mines into two channels.
It is the write side of a pair with the read-only `/wiki`, which it invokes to read the rest of the AI-managed wiki.
The **pull channel** is the wiki — reusable knowledge a future agent retrieves on demand — and a fact earns a note there only if it both **generalizes** past the target it came from and is **trigger-able**, meaning some symptom, error, or task would send that agent looking for it.
The **push channel** is the target's own always-loaded documentation, its `AGENTS.md`, which carries what is useful but not wiki-shaped: a concrete repo-specific answer, or a proactive rule whose value is firing unprompted.
A single fact mined from the source usually splits across both — the transferable general lesson to the pull channel, the specific residue it leaves behind to the push channel.
Nothing is written and nothing is deleted until the user approves the plan.
## The write surfaces
Consume writes to two channels and nowhere else.
The AI-managed wiki lives at `$(xdg-user-dir DOCUMENTS)/ai-artifacts/wiki`.
Resolve it, and if it does not exist report that the wiki is unreachable and stop.
Write pull-channel notes only directly under that flat directory.
Outside the wiki, the sanctioned content write is the target's own always-loaded documentation, its `AGENTS.md` — the push channel of step 6.
Everything else in the target is read-only.
All reading of the wider AI-managed wiki goes through `/wiki` (step 3).
## 1. Select the branch
Resolve the artifact project directory as `$(xdg-user-dir DOCUMENTS)/ai-artifacts/projects/<project>`, where `<project>` is the lowercase basename of the target directory.
Route the target through this ladder, first match wins:
- An artifact project directory containing flat `*-spec.md` or `*-task.md` artifacts → a project: follow [`project.md`](project.md).
- No rung matches → report that the target is not something consume knows how to read, write nothing, and stop.
Done when a branch file is selected, or consume has stopped on an unsupported target.
## 2. Read the target and establish ground truth
Follow the selected branch file to understand the target's *current* state.
The branch file names its source of truth and what within the target is merely stale intent; ground your understanding in the former, never the latter.
Done when you understand what the target actually is now, from its branch's source of truth.
## 3. Read what the wiki already knows
Two reads with different jobs:
- Invoke `/wiki` on the concepts the target raised, to learn what the whole AI-managed wiki already holds — so new notes link to existing notes and hubs, and you do not re-capture knowledge the wiki already has.
- Scan the AI-managed wiki directly for the concept notes you may need to enrich.
Done when you know which existing notes bear on what you are about to write.
## 4. Plan the notes
Route every fact you mined through two acceptance axes.
- **Generalizes** — it teaches something that holds on a *different* target, not a fact true only of this one.
- **Trigger-able** — a recognizable symptom, error, or task would send a future agent to retrieve it.
Two premises stand behind trigger-ability.
The wiki is retrieval-on-demand, so knowledge whose only value is firing *unprompted* does not belong there however well it generalizes.
And the reader is an amnesiac agent, so "the reader will internalize it" is never a reason to keep a note — trigger-ability, not memorability, is the axis.
A fact earns a **pull-channel note** only when it passes *both* axes.
A fact that fails either axis but is still useful to the target goes to the **push channel**, the target's `AGENTS.md`: a **specific residue** that fails *generalizes* (the concrete repo-specific answer), or a **proactive rule** that generalizes but is not trigger-able (a verification-discipline or design-stance rule whose value is firing unprompted).
A fact that fails both axes and is useful to no one is dropped.
Most source lines split rather than route whole: the transferable **general lesson** goes to the pull channel, the **specific residue** it leaves behind goes to the push channel — recorded in the target's `AGENTS.md` when that file does not already hold it.
So plan both destinations together, deciding for each pull-channel note whether it is new or an update to an existing note whose knowledge is now stale or thinner than what you have learned.
Keep each pull-channel note atomic — one transferable idea per note.
When a note carries two independent lessons, split it.
Write as many notes as the knowledge warrants; the count follows from atomicity, not from a target number.
Then build the contribution map: for every file you consumed, the notes it feeds and the exact sections that contributed — including any file that fed no note, recorded as feeding nothing.
The mapping is many-to-many — one file may feed several notes, and one note may draw on several files.
Done when every mined fact has a decided destination — pull note, push item, or explicit drop — every pull-channel note passes both axes and is atomic, and every consumed file, including those feeding no note, is mapped with its contributing sections named.
## 5. Present the plan and wait for approval
Write the plan as a self-contained HTML file to the session's scratchpad directory and give the user its path.
The report is a complete ledger of every mined fact's disposition, not only of what gets written, so the selection bar itself can be reviewed:
1. **Wiki write-set (pull)** — each note to write or update, with its **trigger line**: one sentence naming the symptom, error, or task that would send a reader to retrieve it, and the `[[hub]]` wikilinks it belongs under.
2. **Contribution map** — for every consumed file, the notes it feeds and the exact contributing sections, including any file that fed nothing.
3. **Push write-set (target `AGENTS.md`)** — each proactive rule and each specific residue to add, each existing entry to trim to its residue, and each pure-general entry to remove, with the exact text and where it lands.
4. **Ref-fixes** — each file holding a reference to a spec or task file about to be deleted, and how the reference is fixed or removed. These accompany the scaffolding deletion of step 7, not the target write-set.
5. **Flagged, not authored** — any `[[hub]]` a note links that does not yet exist under `tags/`, and any push knowledge whose home is a hook or checklist rather than `AGENTS.md` — surfaced for the user to act on by hand.
6. **Drops** — every mined fact considered and cut, one line of why each.
The wiki write-set and the target-`AGENTS.md` write-set are approved independently: the user may accept one and decline the other.
A declined target write-set degrades to flagged suggestions — reported for the user to apply by hand, written nowhere.
The ref-fixes and the scaffolding deletion are not a write-set to accept or decline — they follow from proceeding with the run and execute in step 7, gated only behind the wiki writes.
Stop and wait for the user's explicit approval.
Write nothing and delete nothing until they approve.
Done when the user has ruled on each write-set.
## 6. Write the notes and reconcile the push channel
Write the approved wiki write-set first.
Write each new note directly under the output area the branch declares as distilled markdown.
When updating an existing note, preserve its format.
Link a hub whether or not its note exists yet — a dangling `[[hub]]` is a valid link and still feeds `/wiki` recall.
Then, if the target write-set was approved, reconcile the target's `AGENTS.md`: add the proactive rules and any specific residue the file does not already hold, trim mixed entries to their specific residue, and remove the pure-general entries.
Removal is gated on capture — trim or remove an entry only when its general part is present in the wiki, written just now in this run or confirmed already there via `/wiki`, never on the intention to write a note.
If the target write-set was declined, write nothing to the target and leave its items as the flagged suggestions of step 5.
Done when the approved wiki notes are written and, if approved, the target's `AGENTS.md` is reconciled.
## 7. Clear the consumed scaffolding
With the notes written, perform the branch's cleanup — the branch file names exactly what to remove and what references to repair.
Deletion never precedes the writes of step 6.
Done when the branch's cleanup has run.
## 8. Report
Tell the user what you created, updated, and left untouched across both channels — wiki notes written or updated, and the target's `AGENTS.md` reconciliation applied or, if declined, left as flagged suggestions.
Repeat the suggested new hubs and any hook-or-checklist items from the report, so the wiki's `tags/` and the target's other channels can be filled in by hand.
Done when the summary names every note written or updated, every target edit applied or flagged, and every suggested hub.

32
skills/consume/project.md
View File

@@ -1,32 +0,0 @@
# project branch
How consume reads a project target, and what it clears afterward.
Reached from step 1 of [`SKILL.md`](SKILL.md) when the target's flat artifact project directory contains `*-spec.md` or `*-task.md` artifacts.
## Read the source, mine the specs
The source code is the truth for *what* the project is and does now.
Read it thoroughly enough to understand its current state and to surface the reusable ideas it embodies — techniques, patterns, decisions, gotchas.
A gotcha usually carries two separable things — a transferable principle and a concrete repo-specific answer — so surface both.
Step 4 of SKILL.md routes the principle to the pull channel and the residue to the target's push channel.
The artifact project's `*-spec.md` and `*-task.md` artifacts are the canonical record of *why* — the reasoning, trade-offs, and intent behind what the code became.
They are the richest source of the generalizable lessons, and cleanup destroys them, so mine their reasoning now or lose it.
But they are not current fact: where a spec or task disagrees with the source, the source wins, and where one describes work later abandoned or changed, the source is what actually happened.
Together these are the raw material the writing logic generalizes; extracting the generalized notes themselves is step 4 of SKILL.md, not this branch's job.
Done when you understand the project's current state from its source and have mined its specs and tasks for the reasoning behind it.
## Output location
Project notes land flat under `$(xdg-user-dir DOCUMENTS)/ai-artifacts/wiki/`.
Do not create subdirectories there.
## Cleanup
After the notes are written (step 6 of SKILL.md), delete the `*-spec.md` and `*-task.md` artifacts that were present in the flat artifact project directory when you read the project in step 2 — the scaffolding this run consumed.
A file added after that read is not swept up.
Deleting those files can strand references to them.
Scan the target and its artifact project directory for pointers to each file about to be deleted — in `AGENTS.md`, context artifacts, ADRs, and sibling specs — and fix or remove each one, following the pointer wherever it lands rather than checking the push channel alone.

49
skills/wiki/SKILL.md
View File

@@ -1,49 +0,0 @@
---
name: wiki
description: Answer from the user's AI-managed wiki — read-only. Fires when a question plausibly concerns the user's recorded project knowledge, setup, config, decisions, preferences, or how-to notes rather than general world facts, or on "check my notes/vault/wiki", "what do my notes say about…", "do I have anything on…". Returns a synthesized answer with the source note paths, or states plainly that the wiki has nothing relevant.
---
# wiki
Answer a question from the user's AI-managed wiki, read-only.
The wiki is a knowledge base the user maintains, and this skill only ever reads it.
It searches the wiki and nothing else — not the web, not general knowledge — and the caller decides whether to combine the result with other sources.
The caller may be the user directly, a subagent, or another skill such as `/consume`, and the process below is the same for all three.
## 1. Resolve the wiki
The artifact root lives at `$(xdg-user-dir DOCUMENTS)/ai-artifacts`.
Its notes live under `wiki/` and its topic hubs live under `tags/`.
If either directory does not resolve or does not exist, report that the wiki is unreachable and stop.
Done when you have the wiki and tag paths.
## 2. Gather candidate notes
Expand the question into several search terms — synonyms, related concepts, and named entities — so a note worded differently than the question is still found.
Search with ripgrep over the Markdown files directly, not obsidian-cli, so retrieval works whether or not Obsidian is running: `rg -l -i` each term over `*.md` under `wiki/`.
Then widen for recall through the topic hubs under `tags/`.
Each note in `tags/` names a topic, and every note on that topic links to it with a bare `[[topic]]` wikilink, so for any hub matching the question, add its members — the notes containing `[[<hub-name>]]` — to the candidates.
Done when you have a candidate set of note paths.
## 3. Read to saturation, following links
Read every candidate note.
Within each, follow every `[[wikilink]]` that bears on the question to its note and read that one too, then repeat on those notes' links.
Continue until a full pass surfaces no note you have not already read — saturation.
There is no cap on how many notes you read, and a broad question legitimately pulls in many.
Read only Markdown — attachments and other binaries are not sources.
Done when every note bearing on the question has been read and a further pass finds nothing new.
## 4. Answer with provenance, or report nothing
If the notes answer the question, synthesize the answer, then list the notes whose content you drew on by path, each with its key excerpt, and cite that path for every claim taken from the wiki.
A note that only led you to others, such as an empty topic hub, is a discovery aid rather than a source, so leave it out of the list.
If nothing relevant was found, say plainly that the wiki has nothing on the question.
Do not pad the answer with wiki-flavored prose that no note supports, and do not create a note to fill the gap.
Done when the answer cites its source notes, or explicitly reports that the wiki has nothing relevant.