{"id":"099116d1-3670-48f1-af59-007d41ccec66","shortId":"bbmtBe","kind":"skill","title":"architect","tagline":"Use when designing a new feature or system, making architecture decisions, writing technical design docs, or structuring project documentation. Triggers on \"design\", \"architecture\", \"technical design\", \"ADR\", \"system decomposition\", \"how should I structure this\", \"设计方案\", \"架构设计\", ","description":"# Architect\n\nArchitect Skill — drives design decisions through Socratic questioning and produces a complete technical documentation system.\n\nThe architect's deliverables are the documentation system itself. Writing `overview.md` is the act of system decomposition; writing `domain-model.md` is the act of establishing ubiquitous language. Documentation is not a by-product of design — documentation IS the design.\n\n## Core Principles\n\n1. **Documentation before code**: Each step's documentation output serves as input for the next step — no skipping, no reordering\n2. **Socratic questioning drives design**: Do not propose solutions directly — first identify architectural concerns from User Stories, then converge design decisions through questioning\n3. **User Stories are purely user-perspective**: User Stories should contain only user experience and acceptance criteria — never mix in technical details\n4. **Single file ≤ 400 lines**: If exceeded, use overview.md as the entry point and split downward with layered navigation\n5. **Terminology unification**: `domain-model.md` implements DDD Ubiquitous Language — the single source of truth (SSOT) for business term <-> technical term mapping\n6. **Superpowers outputs must be consolidated**: Plans generated during a session must be written into `docs/` before coding begins\n7. **Design-first approach**: Documentation may describe the target state (design ahead of code is normal); however, implemented features must have corresponding documentation\n\n---\n\n## Overall Workflow (must be executed in order)\n\n```\n1. User Story          → Define user experience flows and acceptance criteria (no technical details)\n2. Architecture Design → User Story pattern recognition → Socratic questioning → brainstorming divergence\n                         → Converge using methodology references → Output overview.md + domain-model.md + ADR\n3. Dev/Test Env Design → Build feedback loops for AI Agent TDD\n4. Module Detail Design→ Module-level pattern recognition → questioning → output ≤400 line module docs\n5. Layered Test Plan   → Generate L2-L4 plans based on User Stories + tech design + env design\n   (L2-L4)\n6. Parallel TDD Dev    → Implement in parallel using agent teams + superpowers\n```\n\n---\n\n## Documentation Directory Structure\n\n> **All documentation must reside under `docs/` in the project root.** In the tree below, `docs/` is the root, and all subdirectories (`product/`, `architecture/`, etc.) are children of `docs/`. Absolute paths look like `<project-root>/docs/product/prd.md`. Do not create standalone `product/` or `architecture/` directories at the project root.\n\n```\ndocs/                                # <-- The single root directory for all documentation\n├── TODO.md                          # Documentation review tracking checklist (SSOT)\n├── product/                         # docs/product/ — Product layer: user perspective\n│   ├── prd.md                       # docs/product/prd.md\n│   └── user-stories/\n│       ├── README.md                # docs/product/user-stories/README.md\n│       └── {service-or-module}.md   # docs/product/user-stories/{service}.md\n├── architecture/                    # docs/architecture/ — Architecture layer: system design decisions\n│   ├── overview.md                  # docs/architecture/overview.md (≤400 lines)\n│   ├── domain-model.md              # docs/architecture/domain-model.md — Ubiquitous Language SSOT\n│   ├── tech-stack.md                # docs/architecture/tech-stack.md\n│   └── {service}/                   # docs/architecture/{service}/\n│       ├── overview.md              # docs/architecture/{service}/overview.md (≤400 lines)\n│       └── {topic}.md               # docs/architecture/{service}/{topic}.md (≤400 lines)\n├── testing/                         # docs/testing/ — Testing layer: strategy and test cases\n│   ├── strategy.md                  # docs/testing/strategy.md\n│   └── services/{service}/          # docs/testing/services/{service}/\n└── deployment/                      # docs/deployment/ — Deployment layer: environment operations manual\n    ├── local-dev.md\n    ├── ci.md\n    └── cd.md\n```\n\n---\n\n## Rules\n\n### Step 1 — User Stories (`docs/product/user-stories/{service}.md`)\n\n**What to write**: User experience flows, Epic breakdown, verifiable acceptance criteria (AC). May include NFRs (non-functional requirements).\n\n**Strictly forbidden**: Technical implementation details (no class names, API paths, database fields, or protocol details). User Stories are the user's perspective, not a technical specification.\n\n**Document structure**:\n- Split files by **service or module** (e.g., `gateway.md`, `sandbox.md`) — one file per service domain\n- Organize each file by **Epic** — an Epic is a business-meaningful feature cluster\n- ID format: `US-{module-abbreviation}-{number}` (e.g., `US-FI-01`)\n- Each User Story: Background (Why) + User Story (Who/What/Goal) + AC (Given/When/Then format)\n- NFRs in a separate section with quantifiable metrics (e.g., \"p95 response < 2s\") — no implementation approach\n- Progress markers: `✅ Implemented` / `⚙️ In Progress` / `Not Started`\n- After adding new User Story, update the index table in `user-stories/README.md`\n\n**Companion Skill**: `story-craftsman` (guided interviews to uncover context + standard template generation)\n\n---\n\n### Step 2 — Architecture Design (`docs/architecture/`)\n\nStep 2 is the architect's core work. **Do not jump straight to drawing architecture diagrams after reading the User Stories** — first identify the architectural concerns implied in the User Stories, converge design decisions through questioning, then commit them to documentation.\n\n#### 2a. User Story Pattern Recognition\n\nAfter reading Step 1's User Stories, identify the implicit architectural concerns. Common User Story patterns and their architectural signals:\n\n| Appears in User Stories... | Architecture Signal | Questioning Direction |\n|-------------|---------|-------------|\n| Multiple tenants / OEM customers / white-label | Multi-tenancy isolation | Data isolation level, configuration variance, failure blast radius |\n| Real-time / push / streaming / online status | Real-time communication | Latency tolerance, push failure strategy, concurrent connection scale |\n| Scheduled / periodic / auto-execution | Scheduling system | Failure compensation vs skip, concurrent trigger mutual exclusion, timezone handling |\n| Distributed update / remote management / software upgrade | Offline + eventual consistency | Offline node catch-up, interrupted upgrade recovery, canary + rollback |\n| Third-party payment / external API integration | External integration | Failure isolation, retry idempotency, reconciliation mechanism |\n| Audit / compliance / operation records | Audit trail | Immutability, retention period, access control |\n| Orders / tickets / entity lifecycle | State machine | State definitions, transition rules, concurrent transitions, invalid transition handling |\n| Cross-service coordination / multi-step process | Distributed transactions | Eventual vs strong consistency, compensation mechanism, timeout handling |\n| Search / reports / data analytics | Read-write separation | Query model vs write model, data sync latency tolerance |\n| Any new feature / user behavior change | **Observability** | How to measure success? What metrics are needed? Event tracking needed? A/B experiment validation needed? |\n\n**Not all User Stories will trigger every signal.** A simple CRUD feature does not need to be questioned about distributed consistency. Only question what is relevant to the current User Story.\n\n#### 2b. Socratic Questioning\n\nFor each identified architectural concern, converge design decisions through questioning rather than giving direct answers. The goal is to have the user (or yourself) explicitly answer the following:\n\n**Boundary definition** (corresponding to DDD Bounded Context):\n- Do these two pieces of logic change at different frequencies?\n- Do their failures need to be isolated? (A going down should not affect B)\n- Do they have clear data ownership? (Who is the source of truth?)\n\n**Integration patterns**:\n- Does the caller need the result immediately? → Sync vs async\n- If the downstream is down, should the upstream fail or continue? → Coupling level\n- Does this operation need to be idempotent? (What happens on repeat calls?)\n\n**Observability** (must question for every feature):\n- After this feature launches, how do we know it's successful? → Define core metrics (conversion rate, retention, p95 latency, etc.)\n- Are new tracking events needed? → User behavior events (impression/click/conversion funnel)\n- Is A/B experiment validation needed? → When the approach is uncertain, use experiment data instead of guessing\n- What are the SLA targets? → Quantified targets for availability, response time, error rate\n- How do we detect problems? → Alert rules, dashboards, log keywords\n\n**Design constraints**:\n- What is the most critical non-functional requirement? (Latency? Throughput? Consistency? Availability?)\n- Which are hard constraints (non-negotiable) and which are soft constraints (trade-offable)?\n- What technologies is the team most experienced with? (Tech selection should consider team capability)\n\n#### 2c. Architecture Quality Principles\n\nDesigns must be checked against the following principles. These are also the criteria used by `code-review` to evaluate design quality.\n\n**Structural principles**:\n- **High cohesion, low coupling**: Clear module boundaries, each module does one thing, changes do not propagate\n- **Dependency direction**: Stable modules do not depend on unstable modules, dependencies flow in one direction\n- **Vertical slicing**: Organized by business domain rather than technical stack layers\n- **Core module separation**: Core business logic is independent of frameworks and infrastructure, reusable across environments\n- **Ports & Adapters**: Business logic is strictly isolated from external dependencies; all I/O is defined through Port interfaces, no direct dependency on concrete implementations\n\n**Robustness principles**:\n- **Failure isolation**: External dependencies going down have degradation/circuit-breaker/timeout strategies\n- **Idempotency**: Write operations are safe for repeated calls\n- **Data consistency**: Transaction boundaries for cross-table/cross-service operations are correct\n- **Input validation**: User input is validated at system boundaries\n- **Built-in stubs**: Every external dependency has a corresponding Stub/Mock; test environments do not require external services to be online\n\n**Evolvability principles**:\n- **Extension points**: Interfaces are pre-designed for known future changes\n- **Interface minimization**: APIs expose only necessary information without leaking internal implementation\n- **Naming is design**: Variable, function, and interface names must accurately convey intent; naming is not just about readability — it determines whether an AI Agent can correctly understand semantics\n- **Every rule has a Why**: Documentation, comments, and commit messages explain \"why,\" not just \"what\"; ADR, AC, and config items all need rationale\n\n#### 2d. Solution Divergence and Convergence\n\nAfter gathering sufficient information through questioning:\n\n1. **Invoke `superpowers:brainstorming`** to diverge and explore possible approaches\n2. **Reference methodology decision cards in `references/`** to evaluate approaches (see this skill's references/ directory)\n3. **Converge**: Select an approach, record it as an ADR\n\n**ADR reasoning chain** (must be included — conclusions alone are insufficient):\n- **Context**: What problem is being faced + what constraints exist\n- **Options**: What approaches were considered (at least 2)\n- **Trade-off**: Pros and cons of each approach (not just the pros)\n- **Decision**: What was chosen (or **Pending** — see below)\n- **Consequences**: What costs were accepted\n\n**Pending ADR**: When questions remain unanswered or information is insufficient for a decision, a **Pending ADR must be created** (Decision marked as `Pending`) rather than skipping it. A Pending ADR records the known Context and Options, and explicitly states \"which questions must be answered before a decision can be made.\" This ensures uncertain decision points are explicitly tracked and not forgotten during subsequent design.\n\n#### 2e. Documentation Output\n\n**Output files**:\n- `overview.md` — Architecture overview (design goals table → Mermaid architecture diagram → component responsibilities table → sub-document navigation table)\n- `domain-model.md` — Ubiquitous Language SSOT (business term <-> technical term mapping, essentially implementing DDD Ubiquitous Language)\n- ADR records in overview.md or separate files\n\n**Documentation standards**:\n- **Single file ≤ 400 lines** — when exceeded, split into sub-documents; overview.md retains only the overview and sub-document navigation table\n- Record review time using `|Document Status` at the beginning of the file\n- **All terminology must align with `domain-model.md`** — consult it before writing; do not invent new concepts\n- Use relative paths for cross-document references; add a three-column navigation table at the top of subsystem documents (submodule | document | description)\n- Use `<br/>` for line breaks in Mermaid diagram nodes — **`\\n` is prohibited**\n\n**Companion Skills**: `doc-writing` (HWPR to mark human design decisions, AWOR for expanded detail), `superpowers:brainstorming` (solution divergence)\n\n---\n\n### Step 3 — Dev/Test Environment Design (`docs/deployment/local-dev.md`)\n\n**What to write**: L1/L2/L3 layered environment architecture, multi-worktree port isolation strategy, shared channel switching mechanism, hot-reload configuration. The goal is to build a fast-feedback TDD loop for AI Agents.\n\n**Documentation standards**:\n- `local-dev.md` has two sections: **User Guide** (commands and results, for developers) + **Implementation Details** (design rationale, for maintainers)\n- Use `make` targets as the entry point for operations; bare commands are prohibited in documentation\n\n**Companion Skills**:\n- `multi-worktree-dev` (L1/L2/L3 layered design, port hash offset, shared channel exclusive switching, health probing)\n- `mock-engine` (Mock infrastructure: start/stop mock services, load test data, create test scenarios)\n\n---\n\n### Step 4 — Module Detail Design (`docs/architecture/{service}/*.md`)\n\n**What to write**: Internal design of a single service/module — interface contracts, data flows, state machines, key algorithms.\n\nLike Step 2, Step 4 also requires first identifying module-level design concerns, then converging through questioning.\n\n#### 4a. Module-Level Pattern Recognition\n\n| Module Characteristic | Questioning Direction |\n|---------|-------------|\n| Exposes external APIs | Error classification (which are retryable / which are not), idempotency, versioning strategy |\n| Entities with lifecycles | State definitions, transition guard conditions, concurrent transitions, invalid transition handling |\n| Depends on external services | Timeout strategy, circuit-breaker thresholds, degradation plan, anti-corruption layer design |\n| High-concurrency reads/writes | Lock granularity, optimistic vs pessimistic, cache consistency |\n| Complex business rules | Will rules change? Configuration-driven vs hard-coded? How to handle rule conflicts? |\n| User-behavior-related features | What tracking events are needed? How is the funnel defined? Is A/B experimentation needed? |\n\n#### 4b. Output After Questioning\n\nAfter converging through questioning, produce a module design document that must include:\n\n- **Interface contract**: Not just API path + request/response, but also error classification and idempotency description\n- **State machine** (if applicable): State diagram + guard conditions + concurrency handling strategy\n- **Dependency direction**: Who this module depends on, who depends on it, and whether the direction is correct (stable modules should not depend on unstable modules)\n- **Data flow**: Source → transform → sink, including error/retry paths\n- **Observability design**: Core metric definitions (SLA), new tracking events needed (event tracking), A/B experiment plan (if applicable), alert rules, dashboards\n\n**Documentation standards**:\n- **Each file strictly ≤ 400 lines** — this is a hard limit, not a suggestion\n- When exceeding 400 lines, split: keep the overview in `{service}/overview.md`, move details to `{service}/{topic}.md`\n- Layered nesting: system overview → service overview → module details; each layer is responsible only for its own granularity\n- Each detail document references its parent service overview at the top, forming a navigable document tree\n\n**Companion Skill**: `doc-writing` (HWPR/AWOR framework)\n\n---\n\n### Step 5 — Layered Test Plan (`docs/testing/`)\n\n**What to write**: A layered testing strategy generated from Step 1 (User Story acceptance criteria) + Step 2 (technical design) + Step 3 (environment design).\n\n**Document structure**:\n```\ndocs/testing/\n├── strategy.md                 # Overview (≤400 lines): layer table, layering logic, mock architecture, traceability matrix, CI/CD\n└── scenarios/                  # AC-level scenario matrices (strategy.md should not contain individual test cases)\n    ├── ep1-<epic>.md           # By Epic (product/QA perspective)\n    ├── tech-<module>.md        # By technical module (developer perspective)\n    └── tech-nfr.md             # NFR degradation/fault tolerance\n```\n\n**strategy.md must include**:\n1. **10-column test layer overview table** (layer / case count / test goal / real dependencies / mock dependencies / real infra / mock infra / execution timing / duration / code location)\n2. **Layering logic table** (what problem each layer solves + why the layer above is insufficient)\n3. **Mock infrastructure SSOT** (directory structure + mock/real switching strategy per layer)\n4. **Requirements traceability matrix** (User Story → test case IDs per layer)\n5. **Quality gate table** (gate / checkpoint / criteria)\n\n**Scenario file AC-level traceability table**: Fixed 8-column format `AC Scenario | Smoke | L1 | L2-1 | L2-2 | L3-1 | L3-2 | L4`, each cell filled with specific test case IDs.\n\n**Key principles**:\n- L3/L4 are **black-box tests** — test clients interact directly with the user interface; **intercepting or mocking internal components at intermediate layers is prohibited**\n- Test scenario data is switched via `make mock-scenario` for controlled, repeatable execution\n\n**Quality standards** (also the criteria used by `code-review` for evaluating tests; see `testing-strategy` skill for detailed layered strategy):\n- **Code without E2E tests must not merge to trunk** — treated as a defect, not a \"to-do\"\n- Each implemented User Story AC must have L3 E2E test coverage (AC describes user behavior and must be verified end-to-end; **L3 uses real dependencies**, not stubs)\n- Each implemented API handler must have at least L2 integration tests (verifying interface contracts and data correctness)\n- State changes, deletions, corrections, and other core flows must have boundary scenario coverage\n- Test scenarios must cover all ACs in the User Stories (verified via traceability matrix: AC → L2 case ID + L3 scenario ID)\n- **Built-in stubs are a shift-left strategy**: Every external dependency has a corresponding stub; L1/L2 do not require external services to be online. However, L3 E2E must use real dependencies to verify the complete chain\n\n**Companion Skills**:\n- `testing-strategy` (generate complete layered strategy by project type, includes `references/engagement-example.md` real-world example)\n- `mock-engine` (mock infrastructure management: L1/L2 stub/mock service startup, test scenario data loading)\n- `multi-worktree-dev` (test parallel safety design — multiple worktrees do not contend for shared channels)\n\n---\n\n### Step 6 — CI/CD Deployment Documentation (`docs/deployment/ci.md` + `cd.md`)\n\n**What to write**: CI pipeline quality gates, CD deployment strategy, K8s resource configuration, Ingress routing, secrets management.\n\n**Companion Skills**:\n\n| Task | Skill |\n|------|-------|\n| Write/review `.gitlab-ci.yml` | `gitlab-ci` |\n| Full deployment workflow for new apps (CI + K8s + Ingress + Vault + Crossplane) | `cicd-developer` |\n| ArgoCD GitOps sync/rollback/troubleshooting | `argocd` |\n| Set up CICD component stack for new clusters | `argocd-deploy` |\n| View/troubleshoot K8s cluster resources | `k8s-ops` |\n| Image registry Robot Account | `harbor` |\n| Vault secrets management | `vault-kv-manager` |\n| Runner selection and troubleshooting | `gitlab-instance-runners` |\n| Embedded repo CI Pipeline | `embed-ci-setup` |\n| Jenkins pipeline management | `jenkins` |\n\n---\n\n## Cross-Document Maintenance Rules\n\n| Operation | Must Also Update |\n|------|------------------|\n| Add/delete/rename document | `docs/TODO.md` |\n| Add User Story | `user-stories/README.md` index table |\n| Change architecture component responsibilities | `architecture/overview.md` mapping table |\n| Add domain terminology | `architecture/domain-model.md` |\n| Document + code changed together | Put in the same MR (use `gitlab-mr` skill) |\n\n### Superpowers Output Consolidation Rules\n\n`superpowers:writing-plans`, `superpowers:brainstorming`, and other skills generate design documents or plans during a session. These documents **must be consolidated into the `docs/` system** — they cannot exist only in session context or temporary files:\n\n| Superpowers Output | Consolidation Target |\n|----------------|---------|\n| Feature plan / brainstorm conclusions | Corresponding Epic in `docs/product/user-stories/{service}.md` |\n| Overall technical plan / writing-plans output | `docs/architecture/overview.md` or corresponding service overview |\n| Module implementation plan | `docs/architecture/{service}/{topic}.md` |\n| Test plan | `docs/testing/strategy.md` or `services/{service}/` |\n| Dev environment design | `docs/deployment/local-dev.md` |\n\n**Consolidation timing**: After superpowers plan is confirmed and before coding starts — consolidate documents first, then begin coding.\n\n---\n\n## Documentation Review (`docs/TODO.md`)\n\n`TODO.md` tracks all items pending review using three states: `[ ]` To Do / `[/]` In Progress / `[x]` Done\n\nReview focus areas:\n- Whether any file exceeds 400 lines (split if so)\n- Whether terminology is consistent with `domain-model.md` (business term <-> technical term mapping)\n- Whether User Stories contain technical details\n- Whether cross-document reference paths are correct\n- Whether User Story status is synchronized with code implementation\n- Whether Product / Architecture interpretations of Phase breakdown are aligned\n- **Whether ADR includes a complete reasoning chain** (Context → Options → Trade-off → Decision → Consequences)\n\n---\n\n## Skill Toolchain Quick Reference\n\n| Step | Task | Skill to Use |\n|------|------|-----------|\n| Step 1 | Write User Stories | `story-craftsman` |\n| Step 2 | Architecture design: solution divergence | `superpowers:brainstorming` |\n| Step 2 | Architecture design: write documentation | `doc-writing` |\n| Step 3 | Design dev/test environment layering | `multi-worktree-dev` |\n| Step 4 | Module detail design | `doc-writing` |\n| Step 5 | Generate layered test plan | `testing-strategy` + `multi-worktree-dev` |\n| Step 6 | CI Pipeline configuration | `gitlab-ci` / `embed-ci-setup` / `jenkins` |\n| Step 6 | CD full deployment workflow | `cicd-developer`   |\n| Step 6 | K8s / images / secrets | `k8s-ops` +  `vault-kv-manager` |\n| Throughout | Event tracking definition and management | event tracking platform |\n| Throughout | A/B experiments / Feature Flags | A/B experiment platform |\n| Throughout | SLA metric configuration | `sla-metric` |\n| Throughout | Monitoring dashboards / alerts | `grafana` + `prometheus` |\n| Throughout | Error monitoring | `sentry` + `sentry-onboarding` |\n| Throughout | Submit documentation + code together as MR | `gitlab-mr` |\n| Throughout | R&D process orchestration | `dev-workflow` |\n| Throughout | Create or update the Skill itself | `superpowers:writing-skills` |\n\n---\n\n## Methodology References (`references/`)\n\nThe questioning and solution evaluation in Steps 2/4 can reference the following methodology decision cards. Each card answers only three questions: when to use it, core concepts quick reference, and when NOT to use it.\n\n**The AI agent already has sufficient knowledge of these methodologies — the value of the decision cards is helping determine \"should I use this for the current scenario.\"**\n\n| Decision Card | Applicable Signals |\n|-------|---------|\n| `references/ddd.md` | Confused business terminology, unclear service boundaries, multi-team collaboration |\n| `references/event-driven.md` | Async processing, cross-service coordination, state change notifications |\n| `references/hexagonal.md` | Multiple external integrations, need for testability, preventing framework lock-in |\n| `references/state-machine.md` | Entities with lifecycles, complex state transition rules |\n| `references/integration-patterns.md` | Third-party API integration, unreliable external systems |\n| `references/multi-tenant.md` | OEM / white-label / multi-tenant scenarios |\n\n---\n\n## Example Comparisons\n\n### Bad — Jumping to architecture diagram immediately after reading User Stories\n\n```\nRead User Stories → Directly write overview.md and draw Mermaid diagrams\n→ No questioning, service boundaries drawn by intuition, ADR has no reasoning chain\n```\n\n### Good — Pattern recognition → questioning → brainstorming → convergence\n\n```\nRead User Story → Identify \"multi-tenant + distributed update\" signals\n→ Question: What level of data isolation between tenants? What's the catch-up strategy for offline nodes?\n→ Brainstorm 3 approaches\n→ Reference DDD + multi-tenant decision cards to evaluate\n→ Select approach, write ADR (with complete reasoning chain)\n→ Output overview.md + domain-model.md\n```\n\n---\n\n### Bad — User Story contains technical details\n\n```markdown\n## US-GW-01 Message Routing\nAfter a user sends a message, the Gateway calls the `resolve_intent()` method through\nIntentResolveMiddleware, queries the PostgreSQL workspace table to get the agent_id,\nthen distributes it to the corresponding Sandbox Pod via Redis Pub/Sub.\n```\n\nProblem: AC should describe the results the user sees, not class names, databases, or middleware.\n\n### Good — User Story from purely user perspective\n\n```markdown\n## US-GW-01 Message Routing\n**Background**: Users need to maintain independent Agent context across different group chats.\n\n**User Story**: As a team member, I want each group chat to have its own Agent context\nso that the Agent remembers each group's context independently without cross-contamination.\n\n**AC**:\n- Given the user has had conversations in both Group A and Group B\n- When the user asks a question in Group A\n- Then the Agent responds based only on Group A's history, without mixing in Group B's content\n```\n\n---\n\n### Bad — Single file exceeds 400 lines with no splitting\n\n```\ndocs/architecture/gateway.md  (800 lines, containing all subsystem details)\n```\n\n### Good — Overview with navigation + layered sub-documents\n\n```\ndocs/architecture/gateway/\n├── overview.md          (≤400 lines, architecture diagram + sub-document navigation table)\n├── intent-resolve.md    (≤400 lines)\n├── thread-lane.md       (≤400 lines)\n└── feishu-card.md       (≤400 lines)\n```\n\n---\n\n### Bad — Superpowers output stays in the session\n\n```\nAfter brainstorming is complete, directly say \"ok, let's start coding\"\n→ Plan exists only in session context, lost in next session, cannot serve as test baseline\n```\n\n### Good — Consolidate plan into docs/ before coding\n\n```\nBrainstorming complete → Write into docs/architecture/overview.md → commit → start coding\n```","tags":["architect","enterprise","harness","engineering","addxai","agent-skills","ai-agent","ai-engineering","claude-code","code-review","cursor","devops"],"capabilities":["skill","source-addxai","skill-architect","topic-agent-skills","topic-ai-agent","topic-ai-engineering","topic-claude-code","topic-code-review","topic-cursor","topic-devops","topic-enterprise","topic-sre","topic-windsurf"],"categories":["enterprise-harness-engineering"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/addxai/enterprise-harness-engineering/architect","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add addxai/enterprise-harness-engineering","source_repo":"https://github.com/addxai/enterprise-harness-engineering","install_from":"skills.sh"}},"qualityScore":"0.458","qualityRationale":"deterministic score 0.46 from registry signals: · indexed on github topic:agent-skills · 16 github stars · SKILL.md body (27,807 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-04-22T01:02:10.993Z","embedding":null,"createdAt":"2026-04-21T19:04:00.300Z","updatedAt":"2026-04-22T01:02:10.993Z","lastSeenAt":"2026-04-22T01:02:10.993Z","tsv":"'-1':2284,2288 '-2':2286,2290 '/cross-service':1282 '/docs/product/prd.md':373 '/overview.md':445,2074 '/readme.md':621,2665 '01':574,3274,3339 '1':94,249,482,689,1402,2137,2199,2890 '10':2200 '2':114,262,636,641,1412,1464,1837,2143,2224,2898,2906 '2/4':3055 '2a':681 '2b':917 '2c':1147 '2d':1391 '2e':1555 '2s':597 '3':137,281,1428,1704,2147,2239,2915,3242 '4':160,292,1811,1839,2250,2925 '400':163,303,430,446,454,1602,2054,2066,2155,2818,3430,3452,3462,3465,3468 '4a':1853 '4b':1955 '5':179,307,2122,2261,2933 '6':199,327,2547,2946,2959,2968 '7':218 '8':2276 '800':3436 'a/b':882,1065,1952,2041,2989,2993 'abbrevi':568 'absolut':369 'ac':499,583,1384,2168,2271,2279,2384,2391,2444,2453,3314,3385 'ac-level':2167,2270 'accept':153,257,497,1490,2140 'access':812 'account':2618 'accur':1349 'across':1230,3350 'act':66,74 'ad':609 'adapt':1233 'add':1657,2659,2675 'add/delete/rename':2656 'adr':27,280,1383,1437,1438,1492,1506,1520,1591,2867,3202,3256 'affect':977 'agent':290,335,1363,1743,3085,3300,3348,3369,3374,3410 'ahead':230 'ai':289,1362,1742,3084 'alert':1098,2046,3006 'algorithm':1834 'align':1637,2865 'alon':1445 'alreadi':3086 'also':1161,1840,1979,2342,2654 'analyt':850 'answer':934,945,1534,3065 'anti':1903 'anti-corrupt':1902 'api':515,793,1331,1865,1975,2411,3159 'app':2584 'appear':706 'applic':1988,2045,3112 'approach':222,600,1071,1411,1421,1432,1459,1473,3243,3254 'architect':1,37,38,54,644 'architectur':11,24,126,263,363,380,421,423,637,654,664,696,704,710,923,1148,1561,1567,1715,2162,2669,2859,2899,2907,3178,3454 'architecture/domain-model.md':2678 'architecture/overview.md':2672 'area':2813 'argocd':2593,2596,2606 'argocd-deploy':2605 'ask':3402 'async':1002,3126 'audit':803,807 'auto':755 'auto-execut':754 'avail':1088,1117 'awor':1695 'b':978,3398,3423 'background':578,3342 'bad':3175,3264,3426,3470 'bare':1772 'base':316,3412 'baselin':3502 'begin':217,1630,2791 'behavior':868,1060,1938,2394 'black':2305 'black-box':2304 'blast':731 'bound':953 'boundari':948,1181,1277,1294,2436,3120,3198 'box':2306 'brainstorm':271,1405,1700,2702,2739,2904,3211,3241,3478,3510 'break':1676 'breakdown':495,2863 'breaker':1898 'build':285,1734 'built':1296,2461 'built-in':1295,2460 'busi':194,559,1210,1221,1234,1581,1919,2829,3116 'business-meaning':558 'by-product':83 'cach':1916 'call':1027,1273,3285 'caller':995 'canari':786 'cannot':2724,3498 'capabl':1146 'card':1416,3062,3064,3098,3111,3250 'case':463,2178,2207,2257,2298,2455 'catch':781,3235 'catch-up':780,3234 'cd':2560,2960 'cd.md':479,2552 'cell':2293 'chain':1440,2497,2872,3206,3260 'chang':869,961,1187,1328,1923,2427,2668,2681,3133 'channel':1723,1791,2545 'characterist':1860 'chat':3353,3364 'check':1154 'checklist':398 'checkpoint':2266 'children':366 'chosen':1481 'ci':2556,2578,2585,2637,2641,2947,2952,2955 'ci.md':478 'ci/cd':2165,2548 'cicd':2591,2599,2965 'cicd-develop':2590,2964 'circuit':1897 'circuit-break':1896 'class':513,3323 'classif':1867,1981 'clear':982,1179 'client':2309 'cluster':562,2604,2610 'code':97,216,232,1167,1930,2222,2348,2362,2680,2785,2792,2855,3019,3487,3509,3517 'code-review':1166,2347 'cohes':1176 'collabor':3124 'column':1661,2201,2277 'command':1752,1773 'comment':1374 'commit':677,1376,3515 'common':698 'communic':743 'companion':622,1684,1778,2114,2498,2570 'comparison':3174 'compens':760,843 'complet':49,2496,2504,2870,3258,3480,3511 'complex':1918,3151 'complianc':804 'compon':1569,2320,2600,2670 'con':1470 'concept':1648,3074 'concern':127,665,697,924,1848 'conclus':1444,2740 'concret':1253 'concurr':749,763,824,1885,1909,1993 'condit':1884,1992 'config':1386 'configur':728,1729,1925,2565,2949,2999 'configuration-driven':1924 'confirm':2782 'conflict':1935 'confus':3115 'connect':750 'consequ':1486,2879 'consid':1144,1461 'consist':777,842,906,1116,1275,1917,2826 'consolid':204,2695,2718,2735,2776,2787,3504 'constraint':1104,1121,1129,1455 'consult':1640 'contain':148,2175,2837,3267,3438 'contamin':3384 'contend':2542 'content':3425 'context':631,954,1448,1524,2729,2873,3349,3370,3379,3493 'continu':1013 'contract':1828,1972,2422 'control':813,2337 'converg':132,273,671,925,1395,1429,1850,1960,3212 'convers':1048,3391 'convey':1350 'coordin':832,3131 'core':92,646,1046,1217,1220,2031,2432,3073 'correct':1285,1365,2012,2425,2429,2847 'correspond':240,950,1304,2475,2741,2756,3307 'corrupt':1904 'cost':1488 'count':2208 'coupl':1014,1178 'cover':2442 'coverag':2390,2438 'craftsman':626,2896 'creat':376,1509,1807,3035 'criteria':154,258,498,1163,2141,2267,2344 'critic':1109 'cross':830,1280,1654,2648,2842,3129,3383 'cross-contamin':3382 'cross-docu':1653,2647,2841 'cross-servic':829,3128 'cross-tabl':1279 'crossplan':2589 'crud':896 'current':914,3108 'custom':717 'd':3028 'dashboard':1100,2048,3005 'data':725,849,860,983,1076,1274,1806,1829,2021,2328,2424,2528,3227 'databas':517,3325 'ddd':184,952,1588,3245 'decis':12,42,134,427,673,927,1415,1478,1503,1510,1537,1544,1694,2878,3061,3097,3110,3249 'decomposit':29,69 'defect':2374 'defin':252,1045,1245,1950 'definit':821,949,1881,2033,2982 'degrad':1900 'degradation/circuit-breaker/timeout':1264 'degradation/fault':2194 'delet':2428 'deliver':56 'depend':1191,1197,1201,1241,1251,1260,1301,1890,1996,2001,2004,2017,2212,2214,2406,2472,2492 'deploy':470,472,2549,2561,2580,2607,2962 'describ':225,2392,3316 'descript':1672,1984 'design':4,15,23,26,41,87,91,118,133,220,229,264,284,295,321,323,426,638,672,926,1103,1151,1171,1324,1342,1554,1563,1693,1707,1759,1786,1814,1822,1847,1906,1966,2030,2145,2149,2537,2707,2774,2900,2908,2916,2928 'design-first':219 'detail':159,261,294,511,521,1698,1758,1813,2076,2088,2099,2359,2839,2927,3269,3441 'detect':1096 'determin':1359,3101 'dev':330,1783,2533,2772,2923,2944,3032 'dev-workflow':3031 'dev/test':282,1705,2917 'develop':1756,2190,2592,2966 'diagram':655,1568,1679,1990,3179,3194,3455 'differ':963,3351 'direct':123,713,933,1192,1205,1250,1862,1997,2010,2311,3188,3481 'directori':339,381,390,1427,2243 'distribut':769,837,905,3220,3303 'diverg':272,1393,1407,1702,2902 'doc':16,214,306,346,355,368,386,1687,2117,2721,2912,2930,3507 'doc-writ':1686,2116,2911,2929 'docs/architecture':422,440,443,450,639,1815,2762 'docs/architecture/domain-model.md':433 'docs/architecture/gateway':3450 'docs/architecture/gateway.md':3435 'docs/architecture/overview.md':429,2754,3514 'docs/architecture/tech-stack.md':438 'docs/deployment':471 'docs/deployment/ci.md':2551 'docs/deployment/local-dev.md':1708,2775 'docs/product':401 'docs/product/prd.md':407 'docs/product/user-stories':418,485,2744 'docs/product/user-stories/readme.md':412 'docs/testing':457,2126,2152 'docs/testing/services':468 'docs/testing/strategy.md':465,2768 'docs/todo.md':2658,2795 'document':20,51,59,79,88,95,101,223,241,338,342,393,395,533,680,1373,1556,1574,1598,1610,1619,1626,1655,1669,1671,1744,1777,1967,2049,2100,2112,2150,2550,2649,2657,2679,2708,2715,2788,2793,2843,2910,3018,3449,3458 'domain':548,1211,2676 'domain-model.md':71,182,279,432,1577,1639,2828,3263 'done':2810 'downstream':1005 'downward':175 'draw':653,3192 'drawn':3199 'drive':40,117 'driven':1926 'durat':2221 'e.g':541,570,594 'e2e':2364,2388,2488 'emb':2640,2954 'embed':2635 'embed-ci-setup':2639,2953 'end':2400,2402 'end-to-end':2399 'engin':1798,2518 'ensur':1542 'entiti':816,1877,3148 'entri':171,1768 'env':283,322 'environ':474,1231,1307,1706,1714,2148,2773,2918 'ep1':2179 'epic':494,553,555,2182,2742 'error':1091,1866,1980,3010 'error/retry':2027 'essenti':1586 'establish':76 'etc':364,1053 'evalu':1170,1420,2351,3052,3252 'event':879,1057,1061,1943,2037,2039,2980,2985 'eventu':776,839 'everi':892,1032,1299,1368,2470 'evolv':1316 'exampl':2515,3173 'exceed':166,1605,2065,2817,3429 'exclus':766,1792 'execut':246,756,2219,2339 'exist':1456,2725,3489 'expand':1697 'experi':151,254,492,883,1066,1075,2042,2990,2994 'experienc':1139 'experiment':1953 'explain':1378 'explicit':944,1528,1547 'explor':1409 'expos':1332,1863 'extens':1318 'extern':792,795,1240,1259,1300,1311,1864,1892,2471,2481,3137,3162 'face':1453 'fail':1011 'failur':730,747,759,797,967,1257 'fast':1737 'fast-feedback':1736 'featur':7,237,561,866,897,1033,1036,1940,2737,2991 'feedback':286,1738 'feishu-card.md':3467 'fi':573 'field':518 'file':162,536,545,551,1559,1597,1601,1633,2052,2269,2732,2816,3428 'fill':2294 'first':124,221,661,1842,2789 'fix':2275 'flag':2992 'flow':255,493,1202,1830,2022,2433 'focus':2812 'follow':947,1157,3059 'forbidden':508 'forgotten':1551 'form':2109 'format':564,585,2278 'framework':1226,2120,3143 'frequenc':964 'full':2579,2961 'function':505,1112,1344 'funnel':1063,1949 'futur':1327 'gate':2263,2265,2559 'gateway':3284 'gateway.md':542 'gather':1397 'generat':206,311,634,2134,2503,2706,2934 'get':3298 'gitlab':2577,2632,2690,2951,3024 'gitlab-ci':2576,2950 'gitlab-ci.yml':2575 'gitlab-instance-runn':2631 'gitlab-mr':2689,3023 'gitop':2594 'give':932 'given':3386 'given/when/then':584 'go':973,1261 'goal':936,1564,1731,2210 'good':3207,3328,3442,3503 'grafana':3007 'granular':1912,2097 'group':3352,3363,3377,3394,3397,3406,3415,3422 'guard':1883,1991 'guess':1079 'guid':627,1751 'gw':3273,3338 'handl':768,828,846,1889,1933,1994 'handler':2412 'happen':1024 'harbor':2619 'hard':1120,1929,2059 'hard-cod':1928 'hash':1788 'health':1794 'help':3100 'high':1175,1908 'high-concurr':1907 'histori':3418 'hot':1727 'hot-reload':1726 'howev':235,2486 'human':1692 'hwpr':1689 'hwpr/awor':2119 'i/o':1243 'id':563,2258,2299,2456,2459,3301 'idempot':800,1022,1266,1874,1983 'identifi':125,662,693,922,1843,3216 'imag':2615,2970 'immedi':999,3180 'immut':809 'implement':183,236,331,510,599,603,1254,1339,1587,1757,2381,2410,2760,2856 'impli':666 'implicit':695 'impression/click/conversion':1062 'includ':501,1443,1970,2026,2198,2510,2868 'independ':1224,3347,3380 'index':615,2666 'individu':2176 'inform':1335,1399,1498 'infra':2216,2218 'infrastructur':1228,1800,2241,2520 'ingress':2566,2587 'input':105,1286,1289 'instanc':2633 'instead':1077 'insuffici':1447,1500,2238 'integr':794,796,991,2418,3138,3160 'intent':1351,3288 'intent-resolve.md':3461 'intentresolvemiddlewar':3291 'interact':2310 'intercept':2316 'interfac':1248,1320,1329,1346,1827,1971,2315,2421 'intermedi':2322 'intern':1338,1821,2319 'interpret':2860 'interrupt':783 'interview':628 'intuit':3201 'invalid':826,1887 'invent':1646 'invok':1403 'isol':724,726,798,971,1238,1258,1720,3228 'item':1387,2799 'jenkin':2643,2646,2957 'jump':650,3176 'k8s':2563,2586,2609,2613,2969,2973 'k8s-ops':2612,2972 'keep':2069 'key':1833,2300 'keyword':1102 'know':1041 'knowledg':3089 'known':1326,1523 'kv':2625,2977 'l1':2282 'l1/l2':2477,2522 'l1/l2/l3':1712,1784 'l2':313,325,2283,2285,2417,2454 'l2-l4':312,324 'l3':2287,2289,2387,2403,2457,2487 'l3/l4':2302 'l4':314,326,2291 'label':720,3168 'languag':78,186,435,1579,1590 'latenc':744,862,1052,1114 'launch':1037 'layer':177,308,403,424,459,473,1216,1713,1785,1905,2081,2090,2123,2131,2157,2159,2203,2206,2225,2231,2235,2249,2260,2323,2360,2505,2919,2935,3446 'leak':1337 'least':1463,2416 'left':2468 'let':3484 'level':298,727,1015,1846,1856,2169,2272,3225 'lifecycl':817,1879,3150 'like':372,1835 'limit':2060 'line':164,304,431,447,455,1603,1675,2055,2067,2156,2819,3431,3437,3453,3463,3466,3469 'load':1804,2529 'local-dev.md':477,1746 'locat':2223 'lock':1911,3145 'lock-in':3144 'log':1101 'logic':960,1222,1235,2160,2226 'look':371 'loop':287,1740 'lost':3494 'low':1177 'machin':819,1832,1986 'made':1540 'maintain':1762,3346 'mainten':2650 'make':10,1764,2332 'manag':772,2521,2569,2622,2626,2645,2978,2984 'manual':476 'map':198,1585,2673,2833 'mark':1511,1691 'markdown':3270,3335 'marker':602 'matric':2171 'matrix':2164,2253,2452 'may':224,500 'md':417,420,449,453,487,1817,2080,2180,2186,2746,2765 'meaning':560 'measur':873 'mechan':802,844,1725 'member':3359 'merg':2368 'mermaid':1566,1678,3193 'messag':1377,3275,3282,3340 'method':3289 'methodolog':275,1414,3045,3060,3092 'metric':593,876,1047,2032,2998,3002 'middlewar':3327 'minim':1330 'mix':156,3420 'mock':1797,1799,1802,2161,2213,2217,2240,2318,2334,2517,2519 'mock-engin':1796,2516 'mock-scenario':2333 'mock/real':2245 'model':856,859 'modul':293,297,305,416,540,567,1180,1183,1194,1200,1218,1812,1845,1855,1859,1965,2000,2014,2020,2087,2189,2759,2926 'module-abbrevi':566 'module-level':296,1844,1854 'monitor':3004,3011 'move':2075 'mr':2687,2691,3022,3025 'multi':722,834,1717,1781,2531,2921,2942,3122,3170,3218,3247 'multi-step':833 'multi-team':3121 'multi-ten':721,3169,3217,3246 'multi-worktre':1716 'multi-worktree-dev':1780,2530,2920,2941 'multipl':714,2538,3136 'must':202,210,238,244,343,1029,1152,1348,1441,1507,1532,1636,1969,2197,2366,2385,2396,2413,2434,2441,2489,2653,2716 'mutual':765 'n':1681 'name':514,1340,1347,1352,3324 'navig':178,1575,1620,1662,2111,3445,3459 'necessari':1334 'need':878,881,885,900,968,996,1019,1058,1068,1389,1945,1954,2038,3139,3344 'negoti':1124 'nest':2082 'never':155 'new':6,610,865,1055,1647,2035,2583,2603 'next':108,3496 'nfr':2193 'nfrs':502,586 'node':779,1680,3240 'non':504,1111,1123 'non-funct':503,1110 'non-negoti':1122 'normal':234 'notif':3134 'number':569 'observ':870,1028,2029 'oem':716,3165 'offabl':1132 'offlin':775,778,3239 'offset':1789 'ok':3483 'onboard':3015 'one':544,1185,1204 'onlin':738,1315,2485 'op':2614,2974 'oper':475,805,1018,1268,1283,1771,2652 'optimist':1913 'option':1457,1526,2874 'orchestr':3030 'order':248,814 'organ':549,1208 'output':102,201,277,302,1557,1558,1956,2694,2734,2753,3261,3472 'overal':242,2747 'overview':1562,1615,2071,2084,2086,2105,2154,2204,2758,3443 'overview.md':63,168,278,428,442,1560,1594,1611,3190,3262,3451 'ownership':984 'p95':595,1051 'parallel':328,333,2535 'parent':2103 'parti':790,3158 'path':370,516,1651,1976,2028,2845 'pattern':267,299,684,701,992,1857,3208 'payment':791 'pend':1483,1491,1505,1513,1519,2800 'per':546,2248,2259 'period':753,811 'perspect':144,405,528,2184,2191,3334 'pessimist':1915 'phase':2862 'piec':958 'pipelin':2557,2638,2644,2948 'plan':205,310,315,1901,2043,2125,2700,2710,2738,2749,2752,2761,2767,2780,2937,3488,3505 'platform':2987,2995 'pod':3309 'point':172,1319,1545,1769 'port':1232,1247,1719,1787 'possibl':1410 'postgresql':3294 'prd.md':406 'pre':1323 'pre-design':1322 'prevent':3142 'principl':93,1150,1158,1174,1256,1317,2301 'probe':1795 'problem':1097,1450,2229,3313 'process':836,3029,3127 'produc':47,1963 'product':85,362,378,400,402,2858 'product/qa':2183 'progress':601,605,2808 'prohibit':1683,1775,2325 'project':19,349,384,2508 'prometheus':3008 'propag':1190 'propos':121 'pros':1468,1477 'protocol':520 'pub/sub':3312 'pure':141,3332 'push':736,746 'put':2683 'qualiti':1149,1172,2262,2340,2558 'quantifi':592,1085 'queri':855,3292 'question':45,116,136,270,301,675,712,903,908,919,929,1030,1401,1494,1531,1852,1861,1958,1962,3049,3068,3196,3210,3223,3404 'quick':2882,3075 'r':3027 'radius':732 'rate':1049,1092 'rather':930,1212,1514 'rational':1390,1760 'read':657,687,852,3182,3185,3213 'read-writ':851 'readabl':1357 'readme.md':411 'reads/writes':1910 'real':734,741,2211,2215,2405,2491,2513 'real-tim':733,740 'real-world':2512 'reason':1439,2871,3205,3259 'recognit':268,300,685,1858,3209 'reconcili':801 'record':806,1433,1521,1592,1622 'recoveri':785 'redi':3311 'refer':276,1413,1418,1426,1656,2101,2844,2883,3046,3047,3057,3076,3244 'references/ddd.md':3114 'references/engagement-example.md':2511 'references/event-driven.md':3125 'references/hexagonal.md':3135 'references/integration-patterns.md':3155 'references/multi-tenant.md':3164 'references/state-machine.md':3147 'registri':2616 'relat':1650,1939 'relev':911 'reload':1728 'remain':1495 'rememb':3375 'remot':771 'reorder':113 'repeat':1026,1272,2338 'repo':2636 'report':848 'request/response':1977 'requir':506,1113,1310,1841,2251,2480 'resid':344 'resolv':3287 'resourc':2564,2611 'respond':3411 'respons':596,1089,1570,2092,2671 'result':998,1754,3318 'retain':1612 'retent':810,1050 'retri':799 'retryabl':1870 'reusabl':1229 'review':396,1168,1623,2349,2794,2801,2811 'robot':2617 'robust':1255 'rollback':787 'root':350,358,385,389 'rout':2567,3276,3341 'rule':480,823,1099,1369,1920,1922,1934,2047,2651,2696,3154 'runner':2627,2634 'safe':1270 'safeti':2536 'sandbox':3308 'sandbox.md':543 'say':3482 'scale':751 'scenario':1809,2166,2170,2268,2280,2327,2335,2437,2440,2458,2527,3109,3172 'schedul':752,757 'search':847 'secret':2568,2621,2971 'section':590,1749 'see':1422,1484,2353,3321 'select':1142,1430,2628,3253 'semant':1367 'send':3280 'sentri':3012,3014 'sentry-onboard':3013 'separ':589,854,1219,1596 'serv':103,3499 'servic':414,419,439,441,444,451,466,467,469,486,538,547,831,1312,1803,1816,1893,2073,2078,2085,2104,2482,2524,2745,2757,2763,2770,2771,3119,3130,3197 'service-or-modul':413 'service/module':1826 'session':209,2713,2728,3476,3492,3497 'set':2597 'setup':2642,2956 'share':1722,1790,2544 'shift':2467 'shift-left':2466 'signal':705,711,893,3113,3222 'simpl':895 'singl':161,188,388,1600,1825,3427 'sink':2025 'skill':39,623,1424,1685,1779,2115,2357,2499,2571,2573,2692,2705,2880,2886,3039,3044 'skill-architect' 'skip':111,762,1516 'sla':1083,2034,2997,3001 'sla-metr':3000 'slice':1207 'smoke':2281 'socrat':44,115,269,918 'soft':1128 'softwar':773 'solut':122,1392,1701,2901,3051 'solv':2232 'sourc':189,988,2023 'source-addxai' 'specif':532,2296 'split':174,535,1606,2068,2820,3434 'ssot':192,399,436,1580,2242 'stabl':1193,2013 'stack':1215,2601 'standalon':377 'standard':632,1599,1745,2050,2341 'start':607,2786,3486,3516 'start/stop':1801 'startup':2525 'state':228,818,820,1529,1831,1880,1985,1989,2426,2804,3132,3152 'status':739,1627,2851 'stay':3473 'step':99,109,481,635,640,688,835,1703,1810,1836,1838,2121,2136,2142,2146,2546,2884,2889,2897,2905,2914,2924,2932,2945,2958,2967,3054 'stori':130,139,146,251,266,319,410,484,523,577,581,612,620,625,660,670,683,692,700,709,889,916,2139,2255,2383,2448,2661,2664,2836,2850,2893,2895,3184,3187,3215,3266,3330,3355 'story-craftsman':624,2894 'straight':651 'strategi':460,748,1265,1721,1876,1895,1995,2133,2247,2356,2361,2469,2502,2506,2562,2940,3237 'strategy.md':464,2153,2172,2196 'stream':737 'strict':507,1237,2053 'strong':841 'structur':18,33,340,534,1173,2151,2244 'stub':1298,2408,2463,2476 'stub/mock':1305,2523 'sub':1573,1609,1618,3448,3457 'sub-docu':1572,1608,1617,3447,3456 'subdirectori':361 'submit':3017 'submodul':1670 'subsequ':1553 'subsystem':1668,3440 'success':874,1044 'suffici':1398,3088 'suggest':2063 'superpow':200,337,1404,1699,2693,2697,2701,2733,2779,2903,3041,3471 'switch':1724,1793,2246,2330 'sync':861,1000 'sync/rollback/troubleshooting':2595 'synchron':2853 'system':9,28,52,60,68,425,758,1293,2083,2722,3163 'tabl':616,1281,1565,1571,1576,1621,1663,2158,2205,2227,2264,2274,2667,2674,3296,3460 'target':227,1084,1086,1765,2736 'task':2572,2885 'tdd':291,329,1739 'team':336,1137,1145,3123,3358 'tech':320,1141,2185 'tech-nfr.md':2192 'tech-stack.md':437 'technic':14,25,50,158,196,260,509,531,1214,1583,2144,2188,2748,2831,2838,3268 'technolog':1134 'templat':633 'temporari':2731 'tenanc':723 'tenant':715,3171,3219,3230,3248 'term':195,197,1582,1584,2830,2832 'terminolog':180,1635,2677,2824,3117 'test':309,456,458,462,1306,1805,1808,2124,2132,2177,2202,2209,2256,2297,2307,2308,2326,2352,2355,2365,2389,2419,2439,2501,2526,2534,2766,2936,2939,3501 'testabl':3141 'testing-strategi':2354,2500,2938 'thing':1186 'third':789,3157 'third-parti':788,3156 'thread-lane.md':3464 'three':1660,2803,3067 'three-column':1659 'threshold':1899 'throughout':2979,2988,2996,3003,3009,3016,3026,3034 'throughput':1115 'ticket':815 'time':735,742,1090,1624,2220,2777 'timeout':845,1894 'timezon':767 'to-do':2377 'todo.md':394,2796 'togeth':2682,3020 'toler':745,863,2195 'toolchain':2881 'top':1666,2108 'topic':448,452,2079,2764 'topic-agent-skills' 'topic-ai-agent' 'topic-ai-engineering' 'topic-claude-code' 'topic-code-review' 'topic-cursor' 'topic-devops' 'topic-enterprise' 'topic-sre' 'topic-windsurf' 'traceabl':2163,2252,2273,2451 'track':397,880,1056,1548,1942,2036,2040,2797,2981,2986 'trade':1131,1466,2876 'trade-off':1130,1465,2875 'trail':808 'transact':838,1276 'transform':2024 'transit':822,825,827,1882,1886,1888,3153 'treat':2371 'tree':353,2113 'trigger':21,764,891 'troubleshoot':2630 'trunk':2370 'truth':191,990 'two':957,1748 'type':2509 'ubiquit':77,185,434,1578,1589 'unansw':1496 'uncertain':1073,1543 'unclear':3118 'uncov':630 'understand':1366 'unif':181 'unreli':3161 'unstabl':1199,2019 'updat':613,770,2655,3037,3221 'upgrad':774,784 'upstream':1010 'us':565,572,3272,3337 'us-fi':571 'us-gw':3271,3336 'use':2,167,274,334,1074,1164,1625,1649,1673,1763,2345,2404,2490,2688,2802,2888,3071,3081,3104 'user':129,138,143,145,150,250,253,265,318,404,409,483,491,522,526,576,580,611,619,659,669,682,691,699,708,867,888,915,941,1059,1288,1750,1937,2138,2254,2314,2382,2393,2447,2660,2663,2835,2849,2892,3183,3186,3214,3265,3279,3320,3329,3333,3343,3354,3388,3401 'user-behavior-rel':1936 'user-perspect':142 'user-stori':408,618,2662 'valid':884,1067,1287,1291 'valu':3094 'variabl':1343 'varianc':729 'vault':2588,2620,2624,2976 'vault-kv-manag':2623,2975 'verifi':496,2398,2420,2449,2494 'version':1875 'vertic':1206 'via':2331,2450,3310 'view/troubleshoot':2608 'vs':761,840,857,1001,1914,1927 'want':3361 'whether':1360,2008,2814,2823,2834,2840,2848,2857,2866 'white':719,3167 'white-label':718,3166 'who/what/goal':582 'without':1336,2363,3381,3419 'work':647 'workflow':243,2581,2963,3033 'workspac':3295 'worktre':1718,1782,2532,2539,2922,2943 'world':2514 'write':13,62,70,490,853,858,1267,1643,1688,1711,1820,2118,2129,2555,2699,2751,2891,2909,2913,2931,3043,3189,3255,3512 'write/review':2574 'writing-plan':2698,2750 'writing-skil':3042 'written':212 'x':2809 '架构设计':36 '设计方案':35","prices":[{"id":"f8709908-3d40-40ec-833f-4c5a1050e17a","listingId":"099116d1-3670-48f1-af59-007d41ccec66","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"addxai","category":"enterprise-harness-engineering","install_from":"skills.sh"},"createdAt":"2026-04-21T19:04:00.300Z"}],"sources":[{"listingId":"099116d1-3670-48f1-af59-007d41ccec66","source":"github","sourceId":"addxai/enterprise-harness-engineering/architect","sourceUrl":"https://github.com/addxai/enterprise-harness-engineering/tree/main/skills/architect","isPrimary":false,"firstSeenAt":"2026-04-21T19:04:00.300Z","lastSeenAt":"2026-04-22T01:02:10.993Z"}],"details":{"listingId":"099116d1-3670-48f1-af59-007d41ccec66","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"addxai","slug":"architect","github":{"repo":"addxai/enterprise-harness-engineering","stars":16,"topics":["agent-skills","ai-agent","ai-engineering","claude-code","code-review","cursor","devops","enterprise","sre","windsurf"],"license":"apache-2.0","html_url":"https://github.com/addxai/enterprise-harness-engineering","pushed_at":"2026-04-17T08:57:37Z","description":"Enterprise-grade AI Agent Skills for software development, DevOps, SRE, security, and product teams. Compatible with Claude Code, Cursor, Windsurf, Gemini CLI, GitHub Copilot, and 30+ AI coding agents.","skill_md_sha":"b8477c73555c02d94f795b77fca1a7d49a0a8f06","skill_md_path":"skills/architect/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/addxai/enterprise-harness-engineering/tree/main/skills/architect"},"layout":"multi","source":"github","category":"enterprise-harness-engineering","frontmatter":{"name":"architect","description":"Use when designing a new feature or system, making architecture decisions, writing technical design docs, or structuring project documentation. Triggers on \"design\", \"architecture\", \"technical design\", \"ADR\", \"system decomposition\", \"how should I structure this\", \"设计方案\", \"架构设计\", \"技术方案\", \"文档体系\", \"写 User Story\", \"写文档\". Also use when reviewing existing architecture docs or asking \"where should I put this doc?\""},"skills_sh_url":"https://skills.sh/addxai/enterprise-harness-engineering/architect"},"updatedAt":"2026-04-22T01:02:10.993Z"}}