$npx -y skills add derailed-dash/dazbo-agent-skills --skill maintaining-core-documentationCreates, maintains, and synchronizes core project documentation (README, TODO, DESIGN, Architecture, Testing, Deployment). Use when the user needs to write, update, or structure project documentation based on codebase changes, or whenever the user asks to perform any documentatio
| 1 | # Maintaining Core Documentation |
| 2 | |
| 3 | This skill provides a comprehensive framework for the creation and maintenance of high-quality, professional technical documentation for any software project or repository. |
| 4 | |
| 5 | ## Table of Contents |
| 6 | |
| 7 | - [Triggers](#triggers) |
| 8 | - [Mandatory Initialization](#mandatory-initialization) |
| 9 | - [Core Principles](#core-principles) |
| 10 | - [Technical Writer Skill Synergy](#technical-writer-skill-synergy) |
| 11 | - [Document Maintenance Guide](#document-maintenance-guide) |
| 12 | - [Formatting Rules](#formatting-rules) |
| 13 | - [Documentation Review Process](#documentation-review-process) |
| 14 | |
| 15 | ## Triggers |
| 16 | |
| 17 | This skill should be triggered whenever: |
| 18 | |
| 19 | - The user requests to create or review documentation. |
| 20 | - The user adds / changes / deletes functionality, or makes significant changes to the codebase. |
| 21 | - The user makes any changes to testing. |
| 22 | - The user makes any changes to deployment. |
| 23 | |
| 24 | ## Mandatory Initialization |
| 25 | |
| 26 | Before performing ANY documentation task, you MUST check for the presence of the `technical-writer` skill, by following the guidance in the `Technical Writer Skill Synergy` section below. |
| 27 | |
| 28 | ## Core Principles |
| 29 | |
| 30 | 1. **Persona & Style**: Maintain a tone that is professional ("Expert Architect"), technical but welcoming. Use a high-level architectural perspective when explaining the "Why" behind design decisions. |
| 31 | 2. **Cross-Document Synchronisation**: Changes to a core property (like a project ID, a URL, or a file path) must be propagated to *all* applicable documentation files immediately. |
| 32 | 3. **Read Existing Documentation**: Always read the existing documentation files to understand the current state and intent of the project. |
| 33 | 4. **Tech Stack**: If the file `conductor/tech-stack.md` is present, read it to understand the intended tech stack. |
| 34 | 5. **Technical Accuracy**: Do not assume that the existing documentation is accurate or up-to-date. Verify the codebase, configuration settings (e.g. `config.py`, `Makefile`, `*.tfvars`, `pyproject.toml`), environment variable names, and command flags, before updating documentation. |
| 35 | 6. **Ask About Unknowns**: |
| 36 | - Ask questions to help establish design choices and technology selection. |
| 37 | - Ask questions to help establish the rationale for any design decisions that are missing rationale. |
| 38 | 7. **Technical Writer Synergy**: When performing documentation maintenance, you MUST make use of the `technical-writer` skill IF (and only IF) the `technical-writer` skill is present. If it is not found, follow the **Technical Writer Skill Synergy** section below. |
| 39 | |
| 40 | ## Technical Writer Skill Synergy |
| 41 | |
| 42 | The `technical-writer` skill improves the quality of your documentation review and creation. |
| 43 | |
| 44 | 1. Determine `technical-writer` skill availability: |
| 45 | **Skill exists?** → Load the skill and collaborate on formatting. |
| 46 | **Skill missing?** → Follow the "Installation workflow" below. |
| 47 | |
| 48 | 2. Installation workflow: |
| 49 | - Check availability using `npx skills ls -g`. |
| 50 | - Recommend the skill to the user. |
| 51 | - If approved, install via: `npx skills add https://github.com/shubhamsaboo/awesome-llm-apps --skill technical-writer -g -y` |
| 52 | |
| 53 | ## Document Maintenance Guide |
| 54 | |
| 55 | Here are the core documents that should be maintained by this skill. You MUST review EACH of these core documents and update them as needed. |
| 56 | |
| 57 | ### 1. `README.md` (The "Storefront") |
| 58 | |
| 59 | * **Focus**: Rapid onboarding and high-level project purpose. |
| 60 | * **Template**: [README.md.template](./references/README.md.template) |
| 61 | * **Sample**: [README.md](./references/samples/README.md) |
| 62 | * **Key Sections**: Overview, Key Links (Blogs/Live Demo), Project Structure (folder tree), Setup (One-time vs Per-session), Useful Commands (use Markdown tables). |
| 63 | * **Triggers** include, but are not limited to: |
| 64 | - Adding a new top-level directory. |
| 65 | - Adding a core feature. |
| 66 | - Adding a `make` target. |
| 67 | - Changing the local development setup workflow. |
| 68 | |
| 69 | ### 2. `TODO.md` (Project Plan) |
| 70 | |
| 71 | * **Focus**: Overall project roadmap and task tracking. |
| 72 | * **Template**: [TODO.md.template](./references/TODO.md.template) |
| 73 | * **Maintenance Condition**: Only maintain if this file already exists. You may offer to create it, for example, if tasks have been achieved and/or future tasks are being discussed. |
| 74 | * **Triggers** include, but are not limited to: |
| 75 | - Completing a step or updating the project timeline. |
| 76 | - If asked to create a new TODO entry. |
| 77 | - Offer to mark steps as closed when done. |
| 78 | |
| 79 | ### 3. `docs/DESIGN.md` (Visual & UX) |
| 80 | |
| 81 | * **Focus**: Visual identity, UX components, and design tokens. Can be used by UI design integrations, e.g. Google Stitch. |
| 82 | * **Template**: [des |