kb-write
Skill15 starsChanged 24 days agoMITView on GitHub
Write to the Pointframe knowledge base - add new knowledge or update stale knowledge in docs/knowledge-base/knowledge-base.md (cross-cutting) or docs/knowledge-base/features/<area>.md (one area, with F-NN feature rows). Use when asked to document, write down, or update architecture, a feature, a subsystem, a decision, an invariant, a how-to, or a reference fact; or when a finished feature, refactor, fix, rename, or move changed how an area works.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Slava-code/college-kbtheir own version, first seen Oct 15, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Slava-code/college-kb★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 11
Read docs/knowledge-base/maintenance.md once per session (the core's "How to maintain this file" points to it).
- Distinctive: line 31
Not knowledge: test counts, PR numbers, "verified on my machine", what was tried and abandoned, anything derivable from git log.
- Very specific: line 35
Look first: pwsh scripts/kb.ps1 read <topic or file>.
- Distinctive: line 36
Read the code before writing.
- Distinctive: line 37
Write it in the file from "Where it goes":
- Distinctive: line 42
Keep the maps true in the same change:
- Distinctive: line 47
If you compared every section against the code, move "Last full review" at the top of the main file to today.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/kb-write: add or update knowledge
/kb-write <topic> writes about one topic. /kb-write with no topic sweeps the current change: run pwsh scripts/kb.ps1 changed (against HEAD; add -Base master for a whole branch) and handle every section and feature it lists whose subject actually changed.
Read docs/knowledge-base/maintenance.md once per session (the core's "How to maintain this file" points to it); it holds the templates, conventions, and budgets.
Where it goes
| The fact is... | Goes to |
| A user-facing feature: how it is triggered, its entry point, telemetry, and tests | A row in its area file's ## Features table, with the next free F-NN across all files |
| How one area works: flow, entry points, key types, its lessons | A ## section in features/<area>.md |
| A rule or recipe that only one area needs | A ## section in that area file |
| Which sections to read before editing a folder or file pattern | A row in docs/knowledge-base/file-map.md, linking the narrowest section that owns the files |
| How the app is composed (host, DI, messaging) | ## Subsystems in composition.md |
| A choice with lasting impact and a reason | A ## D-NNN Title section with the next number across all files: in the area file if only one area needs it, otherwise in decisions.md |
| A rule every area must keep, with why and what breaks | ## Invariants in composition.md |
| A short rule every change must keep | ## Architecture rules in the main file |
| A recipe any area uses | ## How-tos in how-tos.md |
| A stable table of paths, binaries, or configuration keys | docs/knowledge-base/references.md |
| CI, CD, versioning, release and merge scripts, installer and packaging rules | docs/knowledge-base/tooling.md |
| A bug, its root cause, and the fix | lessons.md (Problem, Root cause, What fixed it, Takeaway), then a - Lesson: <heading> line in the owning section |
| A task, plan, status, or roadmap item | plan/ (local-only, not in git), not the knowledge base |
Not knowledge: test counts, PR numbers, "verified on my machine", what was tried and abandoned, anything derivable from git log.
Steps
- Look first:
pwsh scripts/kb.ps1 read <topic or file>. If a section already covers it, update that section instead of adding a near-duplicate. - Read the code before writing. Every path you name must exist; every claim about behavior comes from the code, not from memory. Say why, not only what.
- Write it in the file from "Where it goes":
- Main file: a
### <Title>section at the end of the right##group. - Area file: a
## <Title>section, or a row in## Features. A new area is a newfeatures/<area>.mdwith# <Area>, a one-line scope, and## Features. - Updating: rewrite stale sentences in place; never append "Update:" or "Correction:" paragraphs.
- Main file: a
- End a section with a
**Files.**line,See [...](...)links (another file's section isother.md#anchoror../knowledge-base.md#anchor), and- Lesson:lines with exactlessons.mdheadings. - Keep the maps true in the same change:
- A new, removed, or rewired feature, telemetry event, or smoke test: update its
F-NNrow. IDs are never renumbered or reused; a removed feature's ID stays retired. - A new, renamed, or moved folder or project: add or rewrite its File map row; link new sections from the rows whose files they describe.
- A reversed decision: a new
## D-NNN, and "Superseded by D-NNN" as the first line of the old one.
- A new, removed, or rewired feature, telemetry event, or smoke test: update its
- Stay inside the budgets: a section under 8192 bytes (a
###section counts its parent##preamble), the main file under 12288, an area file under 40 KB.checkfails on a new or grown violation and lists the existing ones indocs/knowledge-base/kb-baseline.json, so write into a section that fits or split a topic into###sections; never grow a listed section. Prefer tables and short lists. Dates are absolute; no status badges, and no changelog phrasing ("since 2026-...", "added ...", "As of ..."): state the current fact. - If you compared every section against the code, move "Last full review" at the top of the main file to today.
- Finish with
/kb-check. Report what was added, what was updated, and anything you saw but left alone.
CLAUDE.md gets at most one line per topic; detail lives in the knowledge base. Nothing is committed; the user reviews and commits.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.