Update to incident.io

{
  "description": "Write and maintain architecture docs — the documents that say what each system is, where it runs, what it depends on, and the real names of things (cloud projects, clusters, namespaces, hostnames, buckets). The heart of it is an interview that pins down what each system name actually means before anything is written. Use when asked to write, extend or improve architecture documentation, to document a system, or to fill a gap the `architecture` skill could not answer.\n",
  "included_files": [
    {
      "relative_path": "references/concerns.md",
      "size_in_bytes": 6310
    },
    {
      "relative_path": "references/examples/README.md",
      "size_in_bytes": 2687
    },
    {
      "relative_path": "references/examples/atlas/README.md",
      "size_in_bytes": 2175
    },
    {
      "relative_path": "references/examples/atlas/database.md",
      "size_in_bytes": 2208
    },
    {
      "relative_path": "references/examples/atlas/deployment.md",
      "size_in_bytes": 2478
    },
    {
      "relative_path": "references/examples/atlas/events.md",
      "size_in_bytes": 2030
    },
    {
      "relative_path": "references/examples/atlas/observability.md",
      "size_in_bytes": 1482
    },
    {
      "relative_path": "references/examples/environments.md",
      "size_in_bytes": 2037
    },
    {
      "relative_path": "references/examples/observability/README.md",
      "size_in_bytes": 1439
    },
    {
      "relative_path": "references/examples/routing.md",
      "size_in_bytes": 1922
    },
    {
      "relative_path": "references/examples/storefront/README.md",
      "size_in_bytes": 1226
    },
    {
      "relative_path": "references/format.md",
      "size_in_bytes": 8441
    },
    {
      "relative_path": "references/homes.md",
      "size_in_bytes": 1308
    },
    {
      "relative_path": "references/write.md",
      "size_in_bytes": 5838
    }
  ],
  "name": "architecture-author",
  "skill_md_contents": "---\nname: architecture-author\ndescription: >\n  Write and maintain architecture docs — the documents that say what each system is,\n  where it runs, what it depends on, and the real names of things (cloud projects,\n  clusters, namespaces, hostnames, buckets). The heart of it is an interview that pins\n  down what each system name actually means before anything is written. Use when asked\n  to write, extend or improve architecture documentation, to document a system, or to\n  fill a gap the `architecture` skill could not answer.\nargument-hint: \"<the system or systems to document>\"\n---\n\n# Architecture author\n\nArchitecture docs describe what systems *are*: where they run, what they depend on, and\nthe real names of things. They pair with runbooks — runbooks own *procedures* (how to\ndiagnose and fix a failure), architecture owns *facts* (what the component is in the\nfirst place) — and each side chains to the other rather than absorbing it. This skill\nwrites and maintains those docs. Answering questions from them is the `architecture`\nskill's job, and every write starts there: you search what already exists before\nwriting anything.\n\n## Before you start\n\nDo both of these before anything else here:\n\n1. **Load the `extensions` skill and have it map the estate**: which plugins are\n   registered, where each lives, and their sync state.\n2. **Load the `architecture` skill and follow it through its search** for each system\n   name in scope. It searches every place architecture docs can live. What it finds\n   shapes the whole job: an existing doc means extending it, not writing a sibling.\n\nSkipping them doesn't fail loudly. It just means you wrote a second copy of a doc that\nalready existed, somewhere nobody looked.\n\n## The job\n\nAuthor or extend architecture docs. The heart of it is an interview that resolves what\nsystem names actually mean before anything is written: the names people use are\nambiguous, and boundaries are decisions the owner makes, not facts an agent infers.\n→ [references/write.md](references/write.md)\n\nWhere the new docs go, and how to check they will be found, is\n[references/homes.md](references/homes.md).\n\n## The taxonomy\n\nArchitecture docs work when they follow a small structural spec — systems are\ndirectories (one per thing responders reason about separately, regardless of repo\nlayout), views are root files answering one cross-system question, estate services\n(observability, the data platform, CI) are directories whose README routes across\ntheir tools, the README is the map, and churny values are pointed at rather than\ncopied. The spec lives in [references/format.md](references/format.md); a corpus may\ncarry its own FORMAT.md, which takes precedence.\n[references/concerns.md](references/concerns.md) catalogs the recurring concerns\n(deployment, database, events, …) and the questions each file answers, and\n[references/examples/](references/examples/README.md) is a complete worked example\ncorpus to calibrate depth against.\n\n## What this skill is not for\n\nAnswering questions from existing docs (that's the `architecture` skill), diagnosis and\nfixes (the runbook that owns the failure), current runtime state (replica counts, flag\nvalues — the docs point at where those live), and product or code-level documentation\n(API references, user guides).\n"
}