القائمة
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.
