mis-documentation

Standardizes project documentation using Diataxis, ADRs, RFCs, C4 diagrams, runbooks, and postmortems.

Updated Oct 7, 2023
One-click install
npx skills add https://github.com/AhmedElbialy148/Portfolio --skill mis-documentation-ahmedelbialy148
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: mis-documentation
Source: https://github.com/AhmedElbialy148/Portfolio/tree/main/.cursor/skills/mis-documentation
Command: npx skills add https://github.com/AhmedElbialy148/Portfolio --skill mis-documentation-ahmedelbialy148

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve? Engineering teams produce inconsistent, scattered, or missing documentation — decisions get lost, runbooks fail at 3am, and onboarding takes weeks. This Skill provides one opinionated standard for every kind of doc that ships in a repo, so any engineer (human or AI) can find why decisions were made, how the system fits together, and what to do when alerts fire. ## Core Features & Use Cases - Complete doc taxonomy: Covers Diataxis quadrants (tutorials, how-tos, reference, explanation), ADRs for decisions made, RFCs for decisions in flight, C4 architecture diagrams (Context, Container, Component), runbooks, blameless postmortems, changelogs, READMEs, and onboarding docs. - Repo bootstrapping: Provides a canonical docs/ directory layout plus ready-to-copy Markdown templates for ADRs, RFCs, plans, C4 diagrams, runbooks, postmortems, changelogs, READMEs, and onboarding. - Review checklist and anti-patterns: Includes a PR review checklist for docs and explicit anti-patterns (e.g., mixed Diataxis quadrants, mutable ADRs, blameful postmortems). - Use Case: A team starting a new service uses the Skill to scaffold docs/ with a C4 context diagram, an ADR index, a changelog, and an onboarding guide — then later writes a blameless postmortem and runbook after their first sev2 incident. ## Quick Start Ask the AI to bootstrap the MIS documentation structure in your repository, including the docs folder layout, an ADR template, and a changelog.

Frequently Asked Questions about mis-documentation

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

FAQPage Schema
How do I write an Architecture Decision Record (ADR)?▼

Create a file at docs/decisions/<NNNN>-<short-name>.md with Status, Context, Decision, Consequences, and Alternatives considered sections. ADRs are immutable once accepted; to change a decision, write a new ADR that supersedes the old one.

What is the difference between an ADR and an RFC?▼

An RFC captures a decision in flight and is used to gather feedback before committing, while an ADR records a decision after it has been made. Accepted RFCs spawn one or more ADRs as the canonical decision record.

How do I choose between a tutorial, how-to, reference, and explanation doc?▼

Use the Diataxis quadrants: tutorials for readers learning by doing, how-tos for task-focused readers, reference for fact lookup, and explanation for readers seeking understanding. Never mix quadrants in a single document.

Does the C4 model require Structurizr for architecture diagrams?▼

No. Mermaid with C4 syntax is the default because it renders natively in GitHub. Structurizr DSL is optional and recommended only for repos with more than five containers or rapidly evolving diagrams.

What makes a postmortem blameless?▼

A blameless postmortem describes systems failing rather than people. Replace statements like "Alice deployed the bad change" with "the deploy pipeline allowed an unreviewed change to reach prod", and never name individuals as causes.

When should I not write an ADR?▼

Skip ADRs for stylistic preferences covered by lint rules, single-file refactors, and anything reversible in an afternoon by one engineer. ADRs are for decisions that constrain future code or would surprise a reader months later.