document-driven-development

Align code changes with existing project documentation to prevent drift.

Updated Mar 25, 2026
One-click install
npx skills add https://github.com/XingYu55555/mysql-db-practice --skill document-driven-development
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: document-driven-development
Source: https://github.com/XingYu55555/mysql-db-practice/tree/main/.trae/skills/document-driven-development
Command: npx skills add https://github.com/XingYu55555/mysql-db-practice --skill document-driven-development

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Ensures all code changes are grounded in the project's documentation, preventing drift and misinterpretation.

Core Features & Use Cases

  • Locate and read the relevant docs (docs/architecture/.md, docs/api/.yaml, docs/schema/*.sql, READMEs, config files) before making changes.

  • Verify that proposed changes conform to documented design intents, service boundaries, and constraints.

  • If documentation conflicts with implementation, do not modify code to match undocumented behavior; report discrepancies and decide whether to update docs or adjust code.

  • Cite documentation during changes with explicit references, e.g., "According to architecture.md section X" and "API spec dictates...".

  • Common Documentation Locations:

  • Architecture: docs/architecture/microservices.md

  • Data Flow: docs/architecture/data-flow.md

  • API Specs: docs/api/

  • Database Schema: configs/mysql/init.sql

  • Service READMEs: services/*/README.md

  • Red Flags:

  • Don't guess or improvise; verify against docs.

  • Do reference and confirm consistency with intent.

  • Output guidelines and expectations for compliance.

Quick Start

Before editing any code, locate the relevant documentation and verify all changes against it.

Frequently Asked Questions about document-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify code changes against project documentation?

Verifying code changes against project documentation involves locating relevant architecture or API specs, explicitly citing them in modifications, and ensuring conformance to design intent. This prevents undocumented drift before proceeding.

What is documentation-driven development for preventing code drift?

Documentation-driven development prevents code drift by requiring developers to ground all source code, configuration, and deployment changes in existing project docs. Discrepancies trigger reporting rather than silent undocumented modifications.

What should I do if implementation conflicts with documented architecture?

When implementation conflicts with documented architecture, do not modify code to match undocumented behavior. Report the discrepancy and explicitly decide whether to update the docs or adjust the code to restore compliance.

How do I align configuration file updates with API specs and database schemas?

To align configuration updates with API specs and database schemas, read relevant files in docs/api/ or configs/mysql/init.sql first. Cite these references during changes to verify service boundary compliance.

Where should I locate project documentation before modifying source code?

Locate project documentation before modifying source code in standard directories like docs/architecture/*.md, docs/api/*.yaml, configs/mysql/init.sql, and service READMEs. This ensures changes conform to documented design intents.