scribe-kb-tidy

Solid

Clean up a scribe knowledge base — split bloated articles, expand or merge thin stubs, archive overgrown rolling files, and merge KB-self-named directories. Use when `scribe lint` reports content-quality warnings (bloated article, thin article, rolling file overgrown, directory named after the KB), or when the user asks to tidy, prune, split, archive, or de-clutter their KB / scriptorium.

Data & Documents 61 stars 4 forks Updated 2 days ago MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
60
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# scribe KB tidy — agent skill `scribe lint` flags four content-quality problems it **cannot** fix mechanically because each needs judgment: **bloated** articles (split), **thin** stubs (expand or merge), **overgrown rolling files** (archive), and **directories named after the KB** (merge). This skill is the procedure for working that queue — the fixes `scribe lint --fix` deliberately never attempts. This is destructive-adjacent work: you rewrite, split, and move real curated knowledge. The golden rules below are not optional. **Trust map (see `references/FIELD_NOTES.md` for the evidence).** Two of these classes have a battle-tested procedure from real KB cleanups — reuse it. The other two have never actually been hand-executed; this skill is their *first* written procedure, grounded in the KB's stated principles. | Class | Status | How to move | |---|---|---| | Rolling archive | **Proven** — done on ~12 real projects | Reuse the recipe below | | Self-named dir | **Proven triage**, but merge is propose-only | Warn, distinguish, propose | | Bloated split | **Greenfield** — never hand-done | Propose split points first | | Thin expand/merge | **Greenfield** — never hand-done | Propose the target first | ## Golden rules (read before touching anything) 1. **Mechanical = safe; judgment = propose first.** Deterministic edits (moving whole rolling entries, backfilling frontmatter) you can just make — git is the safety net. Anything that decides *which page wins* or *which...

Details

Author
oliver-kriska
Repository
oliver-kriska/scribe
Created
4 months ago
Last Updated
2 days ago
Language
Go
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Solid

scribe-kb

Read, write, and search a scribe-managed knowledge base (markdown vault with frontmatter conventions, wikilinks, and qmd hybrid search). Use when the user's project has a scribe.yaml (KB root) or a .claude/<kb_name>/ drop-file directory (consumer side), or when they mention scribe, scriptorium, qmd, drop files, or "my KB". Covers frontmatter schema, wikilink syntax, drop-file pattern, search via qmd, and directory taxonomy.

61 Updated 2 days ago
oliver-kriska
AI & Automation Solid

scribe-cli

Set up and operate the scribe CLI — install/init personal or team KBs, diagnose with doctor/status, run sync/extraction, manage cron and Full Disk Access, and pick the right command for a maintenance goal. Use when the user wants to install or run scribe, asks which scribe command or init/team flags to use, says their KB is stale/empty or extraction/sync stopped, or is reading `scribe doctor`/`scribe status` output. For authoring KB content use scribe-kb; for the `scribe lint` content-quality queue use scribe-kb-tidy.

61 Updated 2 days ago
oliver-kriska
Web & Frontend Listed

scribekit-docs

Write, rewrite, reorganize, or deep-verify documentation for the current project's docs site (MDX), sourced entirely from the project's own code so every documented fact, option, default, and code sample is true. Use when the user wants to create/write/draft/document a new docs/reference/guide page; rewrite/audit/fact-check/update an existing one against the current code; reorganize/restructure/reshuffle the docs as a whole - fix the sidebar, the nav, the tabs, the groups, the ordering, or the information architecture when the structure is a mess, pages sit in the wrong section, or the reading order makes no sense; or deep-verify the WHOLE corpus before a release - verify/validate that every page is still true and up to date against the code and that the docs are ready to ship/release/deploy, fanning out one subagent per page and reporting every issue for the user to pick from (add --scan to only report, without changing anything). Each page's on-brand hero is generated by the companion /scribekit-hero skill

2 Updated 1 months ago
daanvandenbergh