Skip to main content

doc-maintainer

Maintain and expand DOCS.MD to cover the full Scribe codebase. Use when asked to update documentation, add missing modules/flows, improve coverage maps, or align docs with code changes in this repo.

Datos de origen

Repositorio
nibzard/scribe
Última actividad en el origen
29 de enero de 2026 a las 10:08
Idioma detectado de SKILL.md
inglés
Estrellas
9
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
doc-maintainer
description
Maintain and expand DOCS.MD to cover the full Scribe codebase. Use when asked to update documentation, add missing modules/flows, improve coverage maps, or align docs with code changes in this repo.
# Doc Maintainer ## Goal Keep `DOCS.MD` accurate, comprehensive, and aligned with the current codebase. ## Workflow 1. Scan the repo for new or changed areas (prefer `rg --files` + targeted file reads). 2. Compare code areas to `DOCS.MD` sections and the Table of Contents. 3. Add or update documentation so each major subsystem and user-facing flow is covered. 4. Keep changes concise, factual, and tied to the actual implementation. ## Coverage Rules - Ensure every top-level folder with code or assets is represented in `DOCS.MD`. - For each subsystem, list: - Responsibilities (1-3 bullets). - Key entry files (headers + sources). - If new developer sections are added, update the Table of Contents to include them. - Prefer a single “Codebase Map” section for breadth, and add focused sections only for complex features. ## DOCS.MD Style - Use short paragraphs and bullet lists; avoid long prose. - Keep headings numbered to match the Table of Contents. - Use inline code for file paths. - Mention specific files for claims; avoid vague wording like “some files.” ## When Updating After Code Changes - If a new service or screen is added, document it under the relevant subsystem. - If behavior changes (e.g., keybindings, UI flow), update both the behavior summary and key files. - If a file is deprecated or unused, note it briefly rather than deleting documentation. ## Do Not - Do not add unrelated documentation files; only update `DOCS.MD`. - Do not describe managed components in depth; note them at a high level.
Ver en GitHub