documentation-and-adrs

Record architectural decisions and project documentation with ADR templates and verification checklists.

Updated Apr 8, 2026
One-click install
npx skills add https://github.com/harishgovardhandamodar/adversarialStudy --skill documentation-and-adrs-harishgovardhandamodar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/harishgovardhandamodar/adversarialStudy/tree/main/Distributionally-Adversarial-Attack/.agents/skills/documentation-and-adrs
Command: npx skills add https://github.com/harishgovardhandamodar/adversarialStudy --skill documentation-and-adrs-harishgovardhandamodar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Helps teams and agents record the reasoning behind technical and architectural choices so future engineers can understand why decisions were made and avoid repeated debates or regressions.

Core Features & Use Cases

  • ADRs and Templates: Provides a template and lifecycle guidance for Architecture Decision Records to track proposed, accepted, and superseded decisions.
  • Inline Documentation Guidance: Explains when to comment code, what to document, and how to surface known gotchas for maintainers and agents.
  • Repository Docs Structure: Recommends README layout, changelog maintenance, and verification checklists for shipping features and onboarding.
  • Use Case: When choosing a new database or changing a public API, use the ADR template to record context, alternatives, decision, and consequences so reviewers and future maintainers understand the trade-offs.

Quick Start

Create an ADR in docs/decisions/ that names the decision, states the status and date, describes context, lists alternatives, records the decision, and notes consequences.

Frequently Asked Questions about documentation-and-adrs

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

FAQPage Schema
What is an architecture decision record and when should I create one?

An architecture decision record (ADR) captures the context, alternatives, decision, and consequences of a technical choice. You should create an ADR during architecture changes, API updates, or feature shipping to ensure future engineers understand the trade-offs.

How do I structure an ADR for a new database or public API change?

To structure an ADR, create a document in your repository that names the decision, states the status and date, describes the context, lists alternatives, records the decision, and notes the consequences for reviewers and future maintainers.

What should be included in a repository README for developer onboarding?

A repository README for onboarding should follow a recommended layout that explains the project, setup instructions, and maintenance guidelines. It should be paired with a regularly updated changelog to track feature shipping and API updates.

When should I write inline code comments and what should they document?

Inline code comments should be written to document known gotchas, complex logic, and important context for maintainers. Use inline documentation guidance to determine when to comment and how to surface critical information effectively within the codebase.

How do I verify documentation completeness before shipping a new feature?

You verify documentation completeness by applying a verification checklist during feature shipping. This ensures ADR templates, README files, API documentation, and changelogs are properly updated and maintained before deployment.