メニュー
Use when the system structure is known and the team must turn domain concepts and architectural boundaries into durable storage schemas, ownership rules, and migration-safe data flow decisions before implementation.
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-data-modeling |
| description | Use when the system structure is known and the team must turn domain concepts and architectural boundaries into durable storage schemas, ownership rules, and migration-safe data flow decisions before implementation. |
| metadata | {"phase":"02-architecture","inputs":["architecture-doc","domain-model","spec-doc"],"outputs":["data-schema"],"prerequisites":["pc-system-design"],"quality_gate":"Data schema matches domain and architecture boundaries, lifecycle rules are explicit, and migration-sensitive decisions are documented","roles":["architect","developer"],"methodologies":["all"],"effort":"medium"} |
Turn concepts and boundaries into durable data structures the system can evolve safely.
Data modeling decides what the system remembers, how it relates, and how change propagates through storage over time.
See context and anti-pattern notes.
I/O contract notes define required inputs and authority.
For each major entity or aggregate, decide:
Translate the domain into tables, collections, events, or documents based on access patterns and consistency needs. Keep read models and write models separate when the workload or boundary requires it.
Avoid schemas that blur service boundaries just because a join would be convenient.
Document:
Before finalizing, challenge the model with likely future operations:
If the data model makes routine change unsafe, revise it now.
Produce only declared outputs at their documented quality boundary.
