scribe-kb-tidy
SolidClean 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.
Install
Quality Score: 81/100
Skill Content
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
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.
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.
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