{
  "schema_version": 2,
  "kind": "shortening-method",
  "format": "agent-skill",
  "id": "architecture-decision",
  "name": "Architecture decision",
  "category": "Technical",
  "summary": "Shorten a design decision while retaining its rationale and tradeoffs.",
  "use_cases": [
    "Architecture decision records",
    "Technical design reviews"
  ],
  "word_count": 147,
  "url": "https://sho.rten.it/methods/architecture-decision/",
  "instructions_url": "https://sho.rten.it/methods/architecture-decision/SKILL.md",
  "skill_url": "https://sho.rten.it/methods/architecture-decision/SKILL.md",
  "json_url": "https://sho.rten.it/methods/architecture-decision/llms.txt",
  "plain_text_url": "https://sho.rten.it/methods/architecture-decision/prompt.txt",
  "license": "MIT",
  "sources_url": "https://sho.rten.it/sources/#architecture-decision",
  "skill_name": "architecture-decision",
  "skill_description": "Shorten a design decision while retaining its rationale and tradeoffs. Use for Architecture decision records, Technical design reviews.",
  "agents_md_url": "https://sho.rten.it/methods/architecture-decision/AGENTS.md",
  "sources": [],
  "instructions": "Condense a supplied architecture decision record for someone who will maintain or revisit the choice. Select this for a durable technical decision, not a general executive recommendation.\n\nState the decision and its status first: proposed, accepted, or superseded, as supplied. Keep the problem, constraints, and alternatives that explain the choice. Reduce each alternative to the decisive benefit or cost. Preserve consequences, reversibility, and conditions that would justify reconsideration.\n\nRemove meeting chronology, repeated background, and implementation detail that does not affect the decision. Separate agreed facts from estimates and untested assumptions. Do not turn an accepted tradeoff into a solved problem or a proposed design into an approved one.\n\nOutput brief sections for Status and decision, Why, Tradeoffs, and Revisit when supported. Keep system names and numeric constraints exact. Do not create new acceptance criteria, select a different design, or add actions that the record does not authorize.",
  "example": {
    "context": "Search architecture record",
    "before": "This decision is accepted. We will keep search in PostgreSQL using full-text indexes for the first release. The corpus is currently 80,000 documents, and the team has two engineers. We considered a separate search service because it offers typo tolerance, but operating another service would exceed our current on-call capacity. PostgreSQL avoids that operational burden, though the first release will not support typo tolerance. The latency target is 300 ms at the 95th percentile; it has not been validated under production load. We will revisit this choice if tests miss that target or the corpus grows beyond 500,000 documents.",
    "after": "Status and decision: Accepted — use PostgreSQL full-text indexes for release 1.\nWhy: 80,000 documents and two engineers. A separate search service offers typo tolerance but exceeds current on-call capacity.\nTradeoffs: No typo tolerance in release 1. The 300 ms p95 latency target is unvalidated under production load.\nRevisit: Tests miss the target or the corpus exceeds 500,000 documents.",
    "must_preserve": [
      "Accepted PostgreSQL full-text indexes for first release",
      "80,000 documents; two engineers; on-call capacity constraint",
      "Separate search offers typo tolerance but exceeds capacity",
      "First release lacks typo tolerance",
      "300 ms p95 target unvalidated in production load",
      "Revisit on failed target tests or more than 500,000 documents"
    ],
    "kind": "illustrative",
    "omitted": [
      "The repeated statement that PostgreSQL avoids the burden of operating another service."
    ]
  }
}