القائمة
Use when writing, reviewing, or refactoring code that involves structural decisions. Provides SOLID principles, composition patterns, module organization, and side-effect boundary guidelines.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Activate at session start when using Agent Teams for complex multi-agent work. Establishes team lead role with delegation protocols, teammate spawning, model selection, and beads integration. You coordinate the team; teammates implement.
Initialize a new repository with standard scaffolding - git, gitignore, AGENTS.md, justfile, mise, beads, and timbers. Use when starting a new project or setting up an existing repo for Claude Code workflows.
Use when designing any player-facing feature, evaluating a game for accessibility, responding to accessibility feedback, designing difficulty or assist options, adding subtitle/caption systems, implementing input remapping, or when a player reports they can't play. Covers the four accessibility pillars (visual, auditory, motor, cognitive), implementation tiers, colorblind design, subtitle standards, input accessibility, and testing methodology. Accessibility is a design discipline, not a post-launch checklist.
Engagement loop design, pacing frameworks, the Experience Triangle (mechanics + dynamics + aesthetics), emotion layering across a session, and evaluating whether choices feel meaningful. Use when designing the core loop, structuring an emotional arc across 5-30 min sessions, debugging 'feels flat' or 'feels samey' play, evaluating whether decisions matter, planning peaks and valleys of intensity, or when playtesters describe sessions as 'fine but forgettable.' Sits one level above game-design (mechanic-level) and one below game-vision (north-star-level).
Numeric balance across game objects with stats — cost curves, transitive vs intransitive systems, dominant strategy detection, sandbagging signals, and anti-degenerate-strategy levers. Use when designing item or weapon stats, pricing storefronts, combat damage/HP/range numbers, upgrade trees, character classes, faction asymmetry, or anywhere two objects have numeric attributes that should relate fairly. Apply when playtesters say 'X is just better,' 'one path always wins,' or 'I never use Y.' Pairs with economy-design (currency flow) and progression-systems (curves over time).
The mechanic-level evaluation toolkit — apply the 5-Component Framework (Clarity, Motivation, Response, Satisfaction, Fit) to any individual mechanic. Use when designing or evaluating a single mechanic, reviewing whether a feature pulls its weight, debugging why a specific action feels off, comparing alternative implementations of the same mechanic, or doing a first-pass critique on a player-facing feature. For session-level pacing or emotional arcs see experience-design; for moment-to-moment juice see game-feel; for system-of-systems interactions see systems-design. This skill is the per-mechanic lens.
| name | solid-architecture |
| description | Use when writing, reviewing, or refactoring code that involves structural decisions. Provides SOLID principles, composition patterns, module organization, and side-effect boundary guidelines. |
Apply these principles when writing or modifying code. Use them as tie-breakers when design decisions conflict.
Favor small, focused types composed together rather than deep inheritance trees. When tempted to extend a class, first ask: "Can this be achieved through composition instead?"
Each module/type/function has one reason to change.
Violation signals:
Action: Split into focused modules with clear, singular purposes.
Extend via new implementations, not constant modification.
Violation signals:
Action: Add behavior through new modules and composition, not conditionals.
Subtypes must work anywhere their base type is expected.
Violation signals:
Action: Prefer interfaces over deep hierarchies. Ensure substitutability.
Depend only on the minimal surface needed.
Violation signals:
Action: Create small, specific interfaces. Split large ones.
Depend on abstractions, not concretions.
Violation signals:
Action: Inject dependencies. Use explicit context/environment objects passed to systems.
Establish clear dependency directions:
core → domain → application → UI
Rules:
Separate pure computation from side effects.
Pure (no side effects):
Impure (side effects):
Systems receive these via injection for deterministic testing:
Push I/O and external integrations to small, well-named boundary modules at system edges.
When refactoring: Bias toward making core logic purer and pushing side effects outward.
Before committing code changes: