| name | internal-docs |
| version | 0.1.0 |
| description | Use this skill when writing, reviewing, or improving internal engineering documents - RFCs, design docs, post-mortems, runbooks, and knowledge base articles. Triggers on drafting a design proposal, writing an RFC, creating a post-mortem after an incident, building an operational runbook, organizing team knowledge, or improving existing documentation for clarity and completeness.
|
| tags | ["rfc","design-docs","post-mortem","runbook","knowledge-management","documentation","experimental-design","writing","grants"] |
| category | writing |
| recommended_skills | ["technical-writing","knowledge-base","remote-collaboration","second-brain"] |
| platforms | ["claude-code","gemini-cli","openai-codex","mcp"] |
| license | MIT |
| maintainers | [{"github":"maddhruv"}] |
Key principles
-
Write for the reader, not the writer - Every document exists to transfer
knowledge to someone else. Identify who will read it (decision-makers, on-call
engineers, new hires) and structure for their needs, not your thought process.
-
Decisions over descriptions - The most valuable internal docs capture the
"why" behind choices. A design doc that only describes the solution without
explaining alternatives considered and tradeoffs made is incomplete.
-
Actionability is everything - A runbook that says "investigate the issue"
is worthless. A post-mortem without concrete action items is theater. Every
document should leave the reader knowing exactly what to do next.
-
Living documents decay - Docs that aren't maintained become dangerous.
Every document needs an owner and a review cadence, or it should be marked
with an explicit expiration date.
-
Structure enables skimming - Engineers don't read docs linearly. Use
headers, TL;DRs, tables, and callouts so readers can find what they need
in under 30 seconds.
Core concepts
Internal docs fall into four categories, each with a distinct lifecycle and audience:
Decision documents (RFCs, design docs, ADRs) propose a change, gather feedback,
and record the final decision. They flow through draft, review, approved/rejected
states. The audience is peers and stakeholders who need to evaluate the proposal.
See references/rfcs-and-design-docs.md.
Incident documents (post-mortems, incident reviews) are written after something
goes wrong. They reconstruct the timeline, identify root causes, and produce action
items. The audience is the broader engineering org learning from failure. Blamelessness
is non-negotiable. See references/post-mortems.md.
Operational documents (runbooks, playbooks, SOPs) provide step-by-step procedures
for recurring tasks or incident response. The audience is the on-call engineer at
3 AM who needs to fix something fast. See references/runbooks.md.
Knowledge documents (wikis, guides, onboarding docs, team pages) preserve
institutional knowledge. The audience varies but typically includes new team members
and cross-team collaborators. See references/knowledge-management.md.
Common tasks
Draft an RFC
An RFC proposes a significant technical change and invites structured feedback.
Use this template structure:
Draft | In Review | Approved | Rejected
<2-3 sentences: what you propose and why>
