agentleFS
Cogni-AI-OUCogni-AI-OU/cogni-ai-agent-skills/docs-writer/SKILL.md

docs-writer

Skill4 starsChanged 6 months agoMITView on GitHub

Create, update, and maintain documentation including Architectural Decision Records (ADRs), runbooks, READMEs, and code-level documentation. You MUST load this skill when asked to write, document, or generate new documentation.

28 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use docs-planner, docs-reviewer and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • strands-agentsSkill

    docs-planner

    Find the gaps in the Box documentation and produce a prioritized backlog for docs/user/ and docs/design/. Use when planning documentation work, after a feature or a binary ships without a page, for a periodic health check of the docs, or when asked "what docs need writing", "plan the docs work", "prioritize the docs backlog", or "what should we document next".

    Also in 3 projects that use this

  • strands-agentsSkill

    docs-reviewer

    Review Box drafts in docs/user/ or docs/design/, and wording-only rewrites in docs/dev/. Use after docs-writer, before a docs pull request, or for a requested doc review. Check style and preservation of meaning, then give a Ship it, Tighten, or Rethink verdict. Read-only.

    Also in 3 projects that use this

  • hiroppySkill

    docs-audit

    Audit docs/ design documents, specs, and implementation plans against current source code for drift. Outputs a drift report and updates documents. Triggers on "check if docs are up to date", "diff docs vs code", "update design docs", "docs consistency check", "verify specs match source", "check plan completion status". Most effective after code or documentation changes.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 13 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 26 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When writing the actual application source code or fixing a software bug.

    line 25
  2. Distinctive:

    When tasked with creating specific Agentic Workflow or Copilot CLI configurations (use specialized skills for those).

    line 27
  3. Distinctive:

    Document the WHY, not the WHAT:

    line 50
  4. Distinctive:

    Document non-obvious algorithmic choices.

    line 53
  5. Distinctive:

    Document external constraints (rate limits, API quirks, platform limitations).

    line 54
  6. Distinctive:

    Remove comments that state the obvious — they add noise.

    line 55
  7. Distinctive:

    When is this runbook used?

    line 60
  8. Distinctive:

    Ensure README reflects current state (not v1 state).

    line 69
  9. Distinctive:

    Ensure setup instructions work on a fresh machine.

    line 70
  10. Distinctive:

    Update architecture diagrams after significant changes.

    line 71
  11. Distinctive:

    When a subdirectory contains specific functionality, workflows, or architectural patterns that require clarification, create a dedicated …

    line 75
  12. Distinctive:

    Use this file to provide targeted instructions, constraints, and context for autonomous agents operating in that specific folder.

    line 76
  13. Distinctive:

    Ensure the local AGENTS.md aligns with the global repository invariants.

    line 77

“Common” is measured: kept by at least 6 in 10 of the 26 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- markdownlint-disable MD013 MD023 MD031 MD032 -->

Docs Writer

Guidance for writing core architecture, documentation, and constraint files. Use this skill when creating or updating repository documentation.

When to Use

  • Writing or generating Architectural Decision Records (ADRs).
  • Documenting non-obvious code or complex algorithms.
  • Creating or updating runbooks for production processes.
  • Updating README files to reflect current state or instructions.
  • Creating local AGENTS.md files for subdirectories.

When Not to Use

  • When writing the actual application source code or fixing a software bug.
  • For generating automated API references where dedicated tools (like JSDoc or Swagger) should be used instead.
  • When tasked with creating specific Agentic Workflow or Copilot CLI configurations (use specialized skills for those).

Common Pitfalls

  • Stating the Obvious: Writing comments like // increments the counter instead of explaining the business logic or edge cases behind the operation.
  • Orphaned ADRs: Writing an Architectural Decision Record but forgetting to link it in the main README or index, making it undiscoverable.
  • Outdated Runbooks: Copy-pasting old CLI commands into a new runbook without verifying that they still work on the current infrastructure.

Architectural Decision Records (ADRs)

Code explains what. Documentation explains why. The most valuable documentation records decisions that aren't obvious from reading the code: why this architecture, why this tradeoff, why not the obvious alternative.

For every significant architectural decision, write an ADR with:

  • Context: What was the situation requiring a decision?
  • Decision: What was decided?
  • Alternatives considered: What else was evaluated and why rejected?
  • Consequences: What are the positive and negative consequences?
  • Status: Proposed | Accepted | Deprecated | Superseded

(typically stored in docs/decisions/).

Code-Level Documentation

  • Document the WHY, not the WHAT:
    • ✅ // Using exponential backoff here — the payment API has strict rate limits (3 req/sec)
    • ❌ // Retry the request
  • Document non-obvious algorithmic choices.
  • Document external constraints (rate limits, API quirks, platform limitations).
  • Remove comments that state the obvious — they add noise.

Runbooks

For every production process that humans execute, write a runbook:

  • When is this runbook used?
  • What steps to execute?
  • What does "done" look like?
  • What could go wrong and how to recover?

(typically stored in docs/runbooks/).

README Currency

  • Ensure README reflects current state (not v1 state).
  • Ensure setup instructions work on a fresh machine.
  • Update architecture diagrams after significant changes.

Subdirectory Agents (AGENTS.md)

When a subdirectory contains specific functionality, workflows, or architectural patterns that require clarification, create a dedicated AGENTS.md file within that folder.

  • Use this file to provide targeted instructions, constraints, and context for autonomous agents operating in that specific folder.
  • Ensure the local AGENTS.md aligns with the global repository invariants.

Related Skills

  • critical-thinking: You MUST load this skill when deconstructing complex requirements into clear, architectural documentation.
  • agents-md-writer: You MUST load this skill when creating or updating AGENTS.md files.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.