메뉴
Reason about systems as wholes — how components interact, where complexity hides, what scales, what fails, and whether stated requirements are technically feasible within real-world constraints. Applies wherever system-level trade-offs, interactions, or feasibility are considered.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Design clear, versioned, backward-compatible interfaces and contracts between units, services, and external consumers. Applies wherever interfaces/contracts are designed or reviewed.
Evaluate software architecture for sound boundaries, intentional coupling, explicit trade-offs, scalability, deployability, operability, and failure behaviour. Applies wherever architectural decisions are designed or reviewed.
Identify and define the core domain concepts of a system — components, entities, relationships, ownership boundaries, and the language the system speaks. Applies wherever domain structure, entity ownership, or business capability boundaries are designed or reviewed.
Apply disciplined implementation practices across backend, frontend, infrastructure, configuration, and tests: write-test-verify, repository convention matching, integration boundary control, and appropriate test strategy.
AI-DLC workspace kickoff. Handles the welcome banner and workspace setup — creating the intent directory, state file, and audit file. Read by the orchestrator at the start of every new intent.
AI-DLC workflow orchestrator. Activate whenever the user states a fresh development intent — building, creating, implementing, fixing, migrating, refactoring, or adding a feature to a codebase. Use this skill for any free-form development prompt such as "build X", "add feature Y", "migrate Z to W", "fix the bug in V", "refactor U", or "create a new service for T".
| name | aidlc-system-thinking |
| description | Reason about systems as wholes — how components interact, where complexity hides, what scales, what fails, and whether stated requirements are technically feasible within real-world constraints. Applies wherever system-level trade-offs, interactions, or feasibility are considered. |
The ability to reason about systems as wholes — understanding how components interact, where complexity hides, what scales and what doesn't, and whether stated requirements are technically feasible within real-world constraints.
When applied at requirements-analysis: validate that requirements are technically feasible, flag requirements that imply hidden complexity (e.g., "real-time sync across regions" implies distributed consensus), identify missing non-functional requirements that the functional requirements imply, and flag contradictions between requirements.
When applied at domain-design: reason about component boundaries, dependency directions, communication patterns, and whether the decomposition supports the stated NFRs.
When applied at infrastructure-design: validate that infrastructure choices can meet the stated performance, reliability, and scalability targets.
