{
  "schema_version": 2,
  "kind": "shortening-method",
  "format": "agent-skill",
  "id": "query-plan",
  "name": "Query plan",
  "category": "Technical",
  "summary": "Summarize a database plan around its costly operators and evidence.",
  "use_cases": [
    "EXPLAIN analysis",
    "Database performance notes"
  ],
  "word_count": 148,
  "url": "https://sho.rten.it/methods/query-plan/",
  "instructions_url": "https://sho.rten.it/methods/query-plan/SKILL.md",
  "skill_url": "https://sho.rten.it/methods/query-plan/SKILL.md",
  "json_url": "https://sho.rten.it/methods/query-plan/llms.txt",
  "plain_text_url": "https://sho.rten.it/methods/query-plan/prompt.txt",
  "license": "MIT",
  "sources_url": "https://sho.rten.it/sources/#query-plan",
  "skill_name": "query-plan",
  "skill_description": "Summarize a database plan around its costly operators and evidence. Use for EXPLAIN analysis, Database performance notes.",
  "agents_md_url": "https://sho.rten.it/methods/query-plan/AGENTS.md",
  "sources": [],
  "instructions": "Condense a supplied database execution-plan discussion into a short evidence-based reading. Select this for query operators and row flow, not general benchmark reporting.\n\nIdentify the query or supplied label, database version, and whether the plan is estimated or executed. Keep operators that explain cost, actual timing, row-estimate errors, repeated loops, sorting, spills, and filtering. Retain exact table, index, and predicate names. Distinguish planner cost units from elapsed time and per-loop values from totals.\n\nCollapse uninformative plan scaffolding and repeated commentary. Preserve cache state, parameter values, and measurement conditions that limit the result. State a suspected bottleneck as a suspicion unless the evidence establishes it. Keep proposed changes separate from measured outcomes.\n\nOutput Query, Evidence, and Interpretation lines, with a proposed next check only if supplied. Do not execute SQL, recommend a destructive change, invent an index, or claim that a suggested rewrite improved performance without a measured comparison.",
  "example": {
    "context": "Filtered order lookup",
    "before": "For query Q7 on PostgreSQL 16, EXPLAIN ANALYZE was run once with a warm cache and customer_id = 42. The plan used a sequential scan on orders. The scan estimated 100 matching rows but returned 18,000 actual rows and removed 982,000 rows by the filter customer_id = 42. Total execution time was 186 ms. The result then used an in-memory quicksort, so there was no disk spill. The scan appears to be the main cost, but this is only one parameter value and one warm-cache run. We proposed testing an index on orders(customer_id); that index has not been created or measured.",
    "after": "Query: Q7, PostgreSQL 16; one warm-cache EXPLAIN ANALYZE run; customer_id = 42.\nEvidence: orders sequential scan estimated 100 matches; actual 18,000, with 982,000 rows filtered out. Execution: 186 ms. In-memory quicksort; no spill.\nInterpretation: Scan appears dominant; one parameter and run limit the finding.\nNext check: Proposed orders(customer_id) index; not created or measured.",
    "must_preserve": [
      "Q7; PostgreSQL 16; EXPLAIN ANALYZE; one warm-cache run; customer_id = 42",
      "orders sequential scan; 100 estimated vs 18,000 actual matches; 982,000 filtered out",
      "186 ms execution; quicksort in memory; no disk spill",
      "Scan appears main cost, not conclusive broad claim",
      "orders(customer_id) index only proposed; not created or measured"
    ],
    "kind": "illustrative",
    "omitted": [
      "First-person framing of the proposed index test and repeated descriptions of the single run."
    ]
  }
}