القائمة
System design, architecture decisions, dependency analysis for coding projects.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | architect |
| description | System design, architecture decisions, dependency analysis for coding projects. |
| version | 1.0.0 |
| author | Hermes Coder (adapted from Squad flight/fido/gnc) |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["architecture","design","planning","dependencies","system-design"],"related_skills":["implementer","quality","reviewer"]}} |
Apply this lens when making system design decisions, evaluating architecture, or analyzing dependencies.
Identity: Senior software architect responsible for system-level design decisions.
Expertise:
Responsibilities:
When reviewing work through the Architect lens:
When designing cloud-backed services (e.g., Firestore, DynamoDB, MongoDB):
sync.RWMutex) in-memory mock repository alongside the live cloud client. Ensure mock methods copy items dereferenced to preserve memory safety.main.go), attempt connection to the live cloud database. If connection fails (credentials, permissions, offline), log a warning and fallback to the Mock repository so the application can run offline.USE_MOCK_DB=true) to let developers explicitly force mock execution for rapid local styling, testing, or offline development.(default) database in a GCP project is configured in Datastore Mode, native Firestore queries will return a FailedPrecondition error.restres) and instantiating the Go client using NewClientWithDatabase(ctx, projectID, databaseID) instead of the default constructor.FIRESTORE_DATABASE) to route queries dynamically across environments.When designing web applications where users must submit data (like rosters, picks, or preferences) before their first login, or when they encounter onboarding hurdles prior to a hard game-day or transaction deadline (e.g. fantasy pools, sports leagues, gated enterprise portals):
User table with their email and display_name (leaving their OAuth google_sub or login provider identifier as None/null).User record now exists with a unique ID, the system allows the commissioner or background processes to create, validate, and persist user-owned data (e.g. Pick rows, rosters, profiles) on their behalf before they have registered an account.get_or_create_user(db, email, google_sub, ...)) to support email-matching fallbacks:
google_sub, perform a case-insensitive lookup on email.email (with a null/placeholder google_sub), bind the authenticating google_sub to their Google ID, normalize their data, and complete the sign-in.When designing systems that must transition between distinct calendar phases (such as regular season vs postseason bowl games, or qualifying rounds vs main tournaments) where pick constraints, validation rules, and scoring formulas differ:
season_phase): Add a simple phase column to your parent scheduler table (such as Week.season_phase = "regular" or "bowl"). This avoids polluting child tables with separate flags or creating completely separate relational schemas.pick_validator.py): Rather than writing multiple validator classes that duplicate code, inject the season_phase directly into your validation context and conditionally bypass phase-inapplicable checks:
scoring_orchestrator.py): Route scoring to distinct, phase-specific calculation functions (e.g. compute_base_score vs compute_bowl_score) on-the-fly depending on the target week's season_phase:
standings.py): By default, exclude postseason phases from your main standings and streak queries (e.g., query WHERE Week.season_phase == 'regular') to prevent postseason scores from polluting or skewing your canonical regular season total tables. Expose optional season_phase query parameters to allow dedicated postseason standings dashboards to be rendered independently.When requested to conduct a codebase-wide architectural review, security audit, or generate technical recommendations for a project:
Always evaluate each discovered architectural item, security gap, technical debt, or recommended enhancement using these three explicit dimensions:
Never create fragmented diagnostic or report files unless explicitly requested. Always consolidate findings directly into existing, single-source-of-truth backlog files (such as BACKLOG.md or NEXT_STEPS.md) at the root of the repository to maintain strict workspace hygiene and prevent document sprawl.
When dispatching architecture-related tasks:
Analyze the architecture of <project-dir>. Focus on:
1. Module structure and dependencies
2. Interface boundaries between components
3. Design patterns in use
4. Areas of coupling or complexity
Provide a concise architecture summary with recommendations.
Branch, commit, push, and open PRs with humanized messages, then monitor GitHub Actions CI. Per-project autonomy gating; blocks direct pushes to the default branch and pushes with a dirty tree. Never auto-merges.
Dispatch patterns for Claude Code as the coding engine. Default harness. Implementation dispatches go through dispatch_coder.py (writes the dispatch receipt the commit gate requires).
Testing strategy, TDD enforcement, spec compliance, and regression checks.
Write implementation plans: bite-sized tasks for coding engine dispatch.
Automated fix loop for failed Quality/Reviewer checks. Parses failures, builds escalating prompts, dispatches through the active harness up to 3 times.
Run independent, file-disjoint plan tasks concurrently, each isolated in its own git worktree + branch. Collects per-task results; never auto-merges.