documentation-and-adrs

Produce decision records and documentation verified against source behavior.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/vTRKA/supervibe --skill documentation-and-adrs-vtrka
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/vTRKA/supervibe/tree/main/skills/documentation-and-adrs
Command: npx skills add https://github.com/vTRKA/supervibe --skill documentation-and-adrs-vtrka

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents future agents and maintainers from rediscovering the why behind changes by ensuring durable, evidence-backed documentation stays aligned with real behavior.

Core Features & Use Cases

  • Decision records for lasting constraints: Capture context, chosen options, rejected alternatives, consequences, and review triggers when architecture, API, workflow, migrations, or operational behaviors change.
  • Public docs that don’t drift: Keep README/setup/runbooks/migration guides accurate by verifying commands, paths, versions, and counts against source and tests.
  • Evidence-first verification: Produce documentation outputs only after reading source-of-truth artifacts and running the relevant grep/tests/link validators.

Quick Start

Use the documentation-and-adrs Skill to verify a proposed change against the existing docs and then produce a decision record or updated user-facing documentation with evidence and alternatives.

Frequently Asked Questions about documentation-and-adrs

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

FAQPage Schema
How do I write architecture decision records that capture rejected alternatives and consequences?▼

Architecture decision records document context, chosen options, rejected alternatives, and consequences to explain why a change exists. This prevents future maintainers from rediscovering the reasoning behind architecture, API, workflow, and migration decisions.

How do I prevent documentation drift in READMEs and runbooks against actual source behavior?▼

Preventing documentation drift requires verifying commands, paths, versions, and counts against source code and tests before authoring. Evidence-first documentation reads source-of-truth artifacts and runs validators to keep READMEs, runbooks, and migration guides accurate.

What's the best way to document migration guides with evidence-first verification?▼

The best way to document migration guides is producing documentation only after reading source-of-truth artifacts and running relevant grep, tests, or link validators. This evidence-first approach verifies proposed changes against existing behavior and records verification commands for reliable discovery.

When do I need decision records for API changes and operational behaviors?▼

Decision records are needed when changes to architecture, APIs, workflows, migrations, or operational behaviors create future constraints or operational requirements. They capture the why-so decisions and review triggers required for reliable future maintenance and discovery.

Can I use this approach to verify proposed changes against existing documentation before updating?▼

Yes, you can verify a proposed change against existing docs and then produce a decision record or updated user-facing documentation with evidence and alternatives. This ensures durable, evidence-backed documentation stays aligned with real source behavior.

What are the limitations of relying on manual documentation without verification commands?▼

Manual documentation without verification commands risks doc drift, where READMEs, setup guides, and runbooks become inaccurate. Without evidence-first authoring and source-of-truth validation, future agents and maintainers lose reliable discovery of why changes exist.