When this skill is activated, always start your first response with the 🧢 emoji.

Internal Docs

Internal documentation is the connective tissue of engineering organizations. It captures decisions (RFCs, design docs), preserves operational knowledge (runbooks), extracts lessons from failure (post-mortems), and makes institutional knowledge discoverable (knowledge management). This skill gives an agent the ability to draft, review, and improve internal documents that are clear, actionable, and structured for their specific audience - from a 2-page RFC to a detailed incident post-mortem.

When to use this skill

Trigger this skill when the user:

• Wants to write or draft an RFC or design document
• Needs to create a post-mortem or incident review document
• Asks to build an operational runbook or playbook
• Wants to organize or structure a team knowledge base
• Needs to review an existing internal doc for completeness or clarity
• Asks about documentation templates, formats, or best practices
• Wants to write an ADR (Architecture Decision Record)
• Needs to create onboarding documentation or team guides

Do NOT trigger this skill for:

• Public-facing API documentation or developer docs (use api-design skill)
• README files or open-source project documentation (use code-level docs conventions)

Key principles

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

# RFC: <Title>

**Author:** <name>  **Status:** Draft | In Review | Approved | Rejected
**Created:** <date>  **Last updated:** <date>
**Reviewers:** <list>  **Decision deadline:** <date>

## TL;DR
<2-3 sentences: what you propose and why>

## Motivation
<What problem does this solve? Why now? What happens if we do nothing?>

## Proposal
<The detailed solution. Include diagrams, data models, API contracts as needed.>

## Alternatives considered
<At least 2 alternatives with honest pros/cons for each>

## Tradeoffs and risks
<What are we giving up? What could go wrong? How do we mitigate?>

## Rollout plan
<How will this be implemented incrementally? Feature flags? Migration?>

## Open questions
<Unresolved items that need input from reviewers>

Always include at least two genuine alternatives. A single-option RFC signals the decision was made before the review process started.

Write a post-mortem

Post-mortems extract organizational learning from incidents. Follow a blameless approach - focus on systems and processes, never on individuals.

# Post-Mortem: <Incident title>

**Date of incident:** <date>  **Severity:** SEV-1 | SEV-2 | SEV-3
**Author:** <name>  **Status:** Draft | Review | Final
**Time to detect:** <duration>  **Time to resolve:** <duration>

## Summary
<3-4 sentences: what happened, who was affected, and the impact>

## Timeline
| Time (UTC) | Event |
|---|---|
| HH:MM | <what happened> |

## Root cause
<The deepest "why" - use the 5 Whys technique to go beyond symptoms>

## Contributing factors
<Other conditions that made the incident possible or worse>

## What went well
<Things that worked during response - detection, communication, tooling>

## What went poorly
<Process or system gaps exposed by the incident>

## Action items
| Action | Owner | Priority | Due date | Status |
|---|---|---|---|---|
| <specific action> | <name> | P0/P1/P2 | <date> | Open |

Every action item must be specific, assigned, and dated. "Improve monitoring" is not an action item. "Add latency p99 alert on checkout service at 500ms threshold" is.

Create a runbook

Runbooks provide step-by-step procedures for operational tasks. Write them for the worst case: an engineer who has never seen this system, at 3 AM, under stress.

# Runbook: <Procedure name>

**Owner:** <team>  **Last verified:** <date>
**Estimated time:** <duration>  **Risk level:** Low | Medium | High

## When to use
<Trigger conditions - what alert, symptom, or request leads here>

## Prerequisites
- [ ] Access to <system>
- [ ] Permissions: <specific roles or credentials needed>

## Steps

### Step 1: <Action>
<Exact command or UI action. No ambiguity.>
```bash
kubectl get pods -n production -l app=checkout

Expected output: <what you should see if things are working> If this fails: <what to do - escalation path or alternative>

Step 2: <Action>

...

Rollback

Escalation

<Who to contact if the runbook doesn't resolve the issue>

> Test every runbook by having someone unfamiliar with the system follow it.
> If they get stuck, the runbook is incomplete.

### Write an Architecture Decision Record (ADR)

ADRs are lightweight, immutable records of a single architectural decision.

```markdown
# ADR-<NNN>: <Decision title>

**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-<NNN>
**Date:** <date>  **Deciders:** <names>

## Context
<What forces are at play? What constraint or opportunity triggered this decision?>

## Decision
<The change we are making. State it clearly in one paragraph.>

## Consequences
<What becomes easier? What becomes harder? What are the risks?>

ADRs are append-only. If a decision is reversed, write a new ADR that supersedes the old one. Never edit a finalized ADR.

Review an existing document for quality

Walk through the doc checking these dimensions in order:

1. Audience - Is it clear who this is for? Does the depth match their expertise?
2. Structure - Can a reader find what they need by skimming headers?
3. Completeness - Are there gaps that will generate questions?
4. Actionability - Does the reader know