メニュー
Use when the architecture is known and the team must choose concrete languages, frameworks, data stores, or infrastructure tools with explicit trade-offs instead of letting implementation drift into ad hoc stack decisions.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when a bug, failing test, regression, or unexpected behavior needs a root-cause-first debugging loop before code changes, especially when brownfield seams, recent releases, or historical defect matches make guesswork unsafe.
Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).
Use when discovery has narrowed an idea enough that the team must make a go/no-go, pivot, or scope-down decision based on technical, economic, operational, or timeline viability before requirements, architecture, or major implementation.
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
Use when discovery needs evidence about market demand, competitors, pricing pressure, or underserved segments for a new product or expansion idea before feasibility, user research, or requirements are finalized.
Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly
| name | pc-tech-selection |
| description | Use when the architecture is known and the team must choose concrete languages, frameworks, data stores, or infrastructure tools with explicit trade-offs instead of letting implementation drift into ad hoc stack decisions. |
| metadata | {"phase":"02-architecture","inputs":["requirements-doc","architecture-doc"],"outputs":["tech-decision-record"],"prerequisites":["pc-system-design"],"quality_gate":"Key technology choices are explicit, justified against the architecture drivers, and recorded with adoption consequences","roles":["architect","tech-lead","devops-engineer"],"methodologies":["all"],"effort":"medium"} |
Choose technologies by architectural fit and operational consequence, not by habit or trend.
Tech selection turns a structural design into a concrete stack.
See context and anti-pattern notes.
I/O contract notes define required inputs and authority.
List the categories that actually require a choice now:
Do not pretend every category is open if upstream constraints already settled it.
Evaluate each meaningful option against:
Use a small decision matrix when useful, but prefer clear narrative reasoning over spreadsheet theater.
Favor the simplest stack that satisfies the drivers. Extra tools add integration cost, cognitive load, and future upgrade work. "Because it is popular" is not a valid criterion.
Document why the option won, what trade-offs were accepted, and what future condition would justify revisiting the decision.
Produce only declared outputs at their documented quality boundary.
