Update to Headcount: Technology

{
  "description": "Explores the problem and the range of possible approaches before any code is written — clarifying what is actually being asked, surfacing options with their tradeoffs, and converging on one. Use this at the start of any feature, component, or behavior change, when a request is ambiguous, when the first idea is the only idea on the table, or when a design decision needs pressure-testing before commitment.",
  "included_files": [],
  "name": "solution-exploration",
  "skill_md_contents": "---\nname: solution-exploration\ndescription: Explores the problem and the range of possible approaches before any code is written — clarifying what is actually being asked, surfacing options with their tradeoffs, and converging on one. Use this at the start of any feature, component, or behavior change, when a request is ambiguous, when the first idea is the only idea on the table, or when a design decision needs pressure-testing before commitment.\n---\n\n# Solution exploration\n\nThe most expensive bugs are decisions, not defects. This runs before implementation, not instead of\nit.\n\n## Establish what is actually wanted\n\nThe stated request is a proposed solution wearing the clothes of a requirement. Get underneath it:\n\n- What outcome does the person want? What breaks today without it?\n- Who else touches this, and what do they assume about it now?\n- What is explicitly **not** being asked for?\n- How will we know it worked — the observable difference.\n\nIf the answers conflict, stop and resolve that first. Building the average of two requirements\nsatisfies neither.\n\n## Generate genuinely different options\n\nTwo variations of the same idea are one option. Force real range:\n\n- The smallest thing that could work.\n- The version that assumes this doubles in scope next quarter.\n- The version that requires no new moving parts.\n- Buy, borrow, or do nothing.\n\nFor each: what it costs, what it forecloses, and what has to be true for it to be right.\n\n## Converge\n\nRecommend one and say why the others lost. A comparison that ends without a recommendation has\nmoved the work, not done it.\n\nName the assumption the recommendation rests on most heavily — that is where the plan will break if\nit breaks.\n\n## Never\n\n- Present options you would not accept as padding around the one you want.\n- Skip this because the task \"is simple.\" Simple tasks take five minutes here.\n- Let a preference stand in for a reason.\n"
}