---
title: Architect Pipeline
description: >-
  The two approaches for /architect:* — greenfield (new development) and legacy
  (existing system rework) — plus a reference list of quality-check and review
  skills
seo:
  image: /ogp.png
---
The Architect pipeline has two paths: one for new development (the greenfield path) and one for reworking an existing system (the legacy path).

**Greenfield path**

Use this path when building a brand-new product or system from scratch.

```mermaid
flowchart LR
  A[define-requirements] --> B[map-domains] --> C[design-api] --> D[design-implementation]
  D --> E[generate-scalardb-code]
  D --> F["generate-infra-code etc."]
```

<Accordion>
  <AccordionItem title="/architect:define-requirements — Requirements Definition (opus)">
    Outputs four documents: the requirements definition, data & transaction requirements, a ScalarDB applicability assessment, and Open Questions (three documents when `--no-scalardb` is specified). This is the entry point of the greenfield path, and in the legacy path it can also be run after `investigate`.

    1. **Read the input materials and identify gaps**

        Reads input materials such as RFPs, meeting notes, and existing design documents along with the existing codebase, then sorts each template item into "answered by the materials" or "unanswered" (the gap list). If artifacts from the product pipeline exist, they are ingested automatically and treated as a product→architect handoff.

    2. **Ask only about the gaps**

        Asks only about the items on the gap list, each with 2–4 candidate choices. Answers are recorded as "TBD" only when deferred — requirements are never filled in by guesswork.

    3. **Classify as FR/NFR**

        Assigns `FR-xxx`/`NFR-xxx` IDs and priorities, and determines the data consistency requirement (strong consistency, eventual consistency, or local transaction) for each business process.

    4. **Assess ScalarDB applicability**

        Follows a decision tree to determine whether ScalarDB or ScalarDB Saga is a good fit (can be skipped with `--no-scalardb`). The final decision is left to `select-scalardb-edition`.
  </AccordionItem>

  <AccordionItem title="/architect:map-domains — Domain Mapping (opus)">
    Based on the analysis results from `analyze`, classifies domains into three types — Core, Supporting, and Generic — and identifies the business structural pattern (Pipeline/Blackboard/Dialogue/Hybrid) and the microservice boundary type (Process/Master/Integration/Supporting).

    Each bounded context is written as a nine-part Bounded Context Canvas, so it can be compared part by part against the same-format Canvas produced by the product side's `map-domains`.

    The product pipeline has a skill with the same name, but that one extracts bounded contexts from business capabilities — its input and purpose differ from this one.
  </AccordionItem>

  <AccordionItem title="/architect:design-api — API Design (opus)">
    Outputs a set of OpenAPI/GraphQL/gRPC/AsyncAPI specification files. The specification written here **is the contract itself** — downstream code cannot implement anything beyond this contract.

    | Decision | Content |
    |---|---|
    | Protocol selection | Choose REST/GraphQL/gRPC/AsyncAPI based on consumer diversity and the shape of operations (not on service name or DB product alone) |
    | Transaction placement | Specifies whether each operation belongs inside an ACID transaction, is a Saga step, or is local |
    | Authorization rules | Specifies the required role/scope for each operation and the criteria for determining object ownership (leaving this undefined and passing it downstream causes the operation to be treated as callable by anyone) |
    | Error format | Standardizes on RFC 9457 (Problem Details) format, keeping a single error format across the entire project |

    Before completing, verifies that every operation has an `operationId`, named schemas, all status codes, authorization rules, and (where needed) an Idempotency-Key (an identifier that makes resending the same request safe).
  </AccordionItem>

  <AccordionItem title="/architect:design-implementation — Implementation Design (opus)">
    Outputs implementation specifications at coding-ready granularity (API layer, domain services, repository interfaces, value objects, exception mapping).

    - The API layer specification maps each operation (operationId) from `design-api` one-to-one to which class receives it, which DTO it's received as, how it's validated, and where the transaction is opened. Request DTOs are never the same as domain objects or persistence entities (to prevent mass-assignment vulnerabilities).
    - Exception mapping is defined separately for two categories: internal (infrastructure exception → domain exception) and external (domain exception → RFC 9457 response).
    - `--layering=ddd|clean` selects the implementation-layer vocabulary. `clean` places one Use Case (input boundary) + Interactor per operationId, with a Presenter (output boundary) under `api/presenter/` — a Clean Architecture shape. The choice is written once as `layering_style` in the frontmatter of `api-layer-spec.md`, and every downstream generation skill reads it from there. Repositories keep their DDD name and domain ownership under either style, since the aggregate manifest, the Fakes, and the coverage thresholds are keyed on them.
  </AccordionItem>

  <AccordionItem title="/architect:generate-scalardb-code — ScalarDB Code Generation (opus)">
    Outputs Spring Boot + ScalarDB Java code (entities, repository implementations, domain services, Spring Boot configuration, build.gradle, Dockerfile), generated from the `design-implementation` and `design-scalardb` specifications.

    - Covers only the **domain/infrastructure** packages. The `api/` package (controllers, DTOs) is handled by `generate-api-code` — running both is what completes a single service.
    - Before writing code, resolves the knowledge bundle for the target ScalarDB version/edition, and verifies deprecation status against the actual jars and release notes rather than taking template documentation at face value.
  </AccordionItem>

  <AccordionItem title="/architect:generate-infra-code — Infrastructure Code Generation (sonnet)">
    Outputs Kubernetes manifests (Kustomize), Terraform modules, Helm values, and **a CI workflow that runs quality gates**, all under `generated/infrastructure/`.

    As one step in this pipeline, it generates **scaffolding code** from the design — this is what distinguishes it from `/infra:implement` (writing merge-ready code into the actual infrastructure repository). See the [infra plugin](/skills/infra) for details.

    The generated CI workflow has seven jobs — build/unit/contract/integration/sast/dependency-scan/image-scan (plus two model-driven stages) — and disabling gates via things like `continue-on-error` is prohibited.
  </AccordionItem>

  <AccordionItem title="/architect:generate-docs — Documentation Generation (sonnet)">
    Runs after `generate-scalardb-code`, `generate-infra-code`, and `generate-frontend`, or as the documentation step of `implement-backlog`, and creates READMEs and pages under `docs/` for the generated and implemented code.

    - To make reruns safe, the generated scope is delimited with **ownership markers** like `<!-- nexus:begin:... -->`. Only the content inside the markers is regenerated, leaving human-written text untouched. For existing READMEs without markers, new content is appended as a new section after confirmation (hand-written text is never overwritten).
    - When code and design documents disagree, the discrepancy is reported as a finding rather than papered over.
  </AccordionItem>
</Accordion>

**Legacy path**

Use this path when re-examining an existing system to rework or redesign it.

```mermaid
flowchart LR
  A[investigate] --> B[analyze]
  B --> C[evaluate-mmi]
  B --> D[evaluate-ddd]
  C --> E[integrate-evaluations]
  D --> E
  E --> F[redesign] --> G[design-microservices]
```

<Accordion>
  <AccordionItem title="/architect:investigate — Existing System Investigation (sonnet)">
    The first step in the legacy path. Produces four documents: a technology stack analysis, codebase structure, issues and technical debt (classified by severity as CRITICAL/High/Medium/Low), and readiness for applying DDD (domain-driven design).
  </AccordionItem>

  <AccordionItem title="/architect:analyze — Domain Analysis (opus)">
    Based on the results of `investigate`, produces a business glossary (the ubiquitous language — a mapping that unifies what each term means across the whole team), an actor/role/permission matrix, and a domain-to-code mapping.
  </AccordionItem>

  <AccordionItem title="/architect:evaluate-mmi — MMI Evaluation (sonnet)">
    Runs after `analyze` and can run in parallel with `evaluate-ddd`. Scores each module on four axes — Cohesion, Coupling, Independence, and Reusability — on a 5-point scale, then computes the MMI (Modularity Maturity Index, a measure of how readily a module can be split out) from the weighted average (Cohesion 30%, Coupling 30%, Independence 20%, Reusability 20%).

    | MMI score | Maturity |
    |---|---|
    | 80–100 | Ready (migratable) |
    | 60–80 | Moderate |
    | 40–60 | Needs Improvement |
    | 0–40 | Immature |
  </AccordionItem>

  <AccordionItem title="/architect:evaluate-ddd — DDD Fitness Evaluation (sonnet)">
    Can run in parallel with `evaluate-mmi`. Scores fitness for DDD across three layers and 12 criteria: strategic design (30% — ubiquitous language, bounded contexts, subdomain classification), tactical design (45% — value objects, entities, aggregates, repositories, domain services, domain events), and architecture (25% — layering, dependency direction, ports & adapters).
  </AccordionItem>

  <AccordionItem title="/architect:integrate-evaluations — Evaluation Integration (sonnet)">
    Consolidates the results of `evaluate-mmi` and `evaluate-ddd` into a single improvement plan aimed at moving toward microservices.
  </AccordionItem>

  <AccordionItem title="/architect:redesign — Bounded Context Redesign (opus)">
    Based on the evaluation results, produces proposed new bounded contexts (each context's responsibilities, included aggregates, and public interfaces) along with the relationships between contexts (DDD context map patterns such as ACL, OHS, and Conformist) as Mermaid diagrams.

    This is also where the Architecture Decision Records (ADR) log is opened and the `ADR-` ID scheme is registered. `design-microservices`, `design-scalardb`/`design-data-layer`, and `design-api` all append to the same log afterward (never rewriting another skill's record — retracting one means superseding it with a new record).
  </AccordionItem>

  <AccordionItem title="/architect:design-microservices — Microservices Design (opus)">
    Produces a service catalog (four categories: Process/Master/Integration/Supporting) and a phased migration roadmap.

    Rather than defaulting to "Saga/2PC" for cross-service transactions, this explicitly specifies which of the following mechanisms to use and passes that on to `design-scalardb`.

    | Mechanism | Configuration |
    |---|---|
    | One-phase commit | Configuration where all services share the same ScalarDB Cluster instance (recommended whenever possible) |
    | Global Transaction API (3.19+) | Clusters are separated, but a Transaction Coordinator node handles 2PC behind the scenes |
    | Application-driven 2PC | For splitting clusters without a Coordinator node. Keep this to 2–3 services at most |
    | ScalarDB Saga | Eventual consistency via compensation. See @rules/scalardb-saga-patterns.md for design guidance when using Saga |
  </AccordionItem>
</Accordion>

## Domain modeling detail (optional)

Once bounded contexts are settled, these optional phases nail down aggregates and their lifecycles before moving on to implementation — writing the tactical side of DDD (domain-driven design) as reviewable JSON artifacts. Because `design-state-machine` needs an aggregate list, run `design-aggregate` first.

<Accordion>
  <AccordionItem title="/architect:design-aggregate — Aggregate Design (opus)">
    Outputs `reports/03_design/aggregates/aggregate-manifest.json` (`AGG-` IDs). For each aggregate, defines the root, interior entities, value objects, invariants (with concrete examples on both the satisfied and violated branches), commands (actor, consistency class, emitted event), factories, specifications, and exactly one repository per root.

    `rules/aggregate-design.md` states the seven well-formedness rules — including the one-command / one-aggregate / one-transaction contract — and `tools/lib/aggregate_manifest.py` enforces them. This aggregate list becomes the candidate list for the following `design-state-machine` phase, and is consumed by `design-scalardb`/`design-data-layer`, `design-api`, `design-implementation`, `generate-test-specs`, `review-consistency`, and `report`.

    Events an aggregate publishes are also written out as the Domain Event Catalog (`reports/03_design/domain-event-catalog.json`/`.md`) — the context map's Published Language itself, recording each event's publisher, the contexts that consume it, and its delivery contract (guarantee level, idempotency key, version). `design-microservices` completes the consumer side once the service split is known, and `design-api`'s `asyncapi/` is generated from this catalog.
  </AccordionItem>

  <AccordionItem title="/architect:design-state-machine — State Transition Design (opus)">
    Outputs `reports/03_design/state-machines/state-machine-manifest.json`. For each aggregate with a lifecycle, defines states, events, and transitions (`(from, event) [guard] → to`, each with an actor, a consistency class, and an idempotency verdict), and decides **every cell of the state × event matrix** as `reject`, `ignore`, or `defer` — leaving no blank cell for the runtime to interpret.

    - Events that create an aggregate (`place`, `open`, `register`, etc.) are treated as a special column with no `from` state, and their idempotency verdict is derived mechanically from the API's idempotency contract.
    - It also builds a "contention table" — one row per pair of actors that can race against the same aggregate (an orchestrator vs. a recovery worker, the request path vs. a sweeper, etc.), naming who wins and what the loser does. A pair with no row is a race nobody designed.
    - `tools/lib/state_machine_manifest.py` (29 checks) enforces well-formedness rules — exactly one initial state, every state reachable, no undeclared dead end, and so on. `design-scalardb`/`design-data-layer`, `design-api`, `generate-test-specs`, `review-consistency`, and `report` all read this model.
  </AccordionItem>
</Accordion>

## Test generation

Two skills that put TDD (test-driven development) ahead of implementation. `implement-backlog` and `generate-scalardb-code` practice the structure `rules/tdd-workflow.md` defines — Red → Green → Refactor commit units, the ATDD (acceptance-test-driven development) outer loop, and one in-memory Fake per repository — and the quality gate (Stage 2) measures coverage (JaCoCo), mutation score (PIT), and whether test-first was actually followed.

<Accordion>
  <AccordionItem title="/architect:generate-characterization-tests — Characterization Test Generation (legacy path, sonnet)">
    Outputs golden-master tests recorded from the *running* legacy system — a seam inventory per module, fixtures whose every value the code actually produced, `@KnownDefect(DEBT-xx)` markers that pin a known bug without blessing it — plus `reports/07_test-specs/characterization-test-coverage.md`.

    `design-microservices`'s migration plan now requires every transformation-plan step to be tied to this characterization-test gate — a safety net for transforming behavior without breaking it.
  </AccordionItem>

  <AccordionItem title="/architect:generate-acceptance-tests — Acceptance Test Generation (sonnet)">
    Outputs Cucumber-JVM step definitions for the Gherkin scenarios in `reports/07_test-specs/` (tied to `RULE-`/`EX-`), plus `reports/07_test-specs/acceptance-test-coverage.md`. Runs over an API/application-layer driver built on the Fakes, with a fixed `Clock`.

    Scenarios whose implementation hasn't landed yet get a `@wip` tag — excluded from the pass/fail verdict but still counted. This is what makes the ATDD outer loop in `rules/tdd-workflow.md` executable.
  </AccordionItem>
</Accordion>

## Quality and operations

A set of skills for designing security, observability, disaster recovery, and cost with production operations in mind.

| Skill | What it designs |
|---|---|
| `design-security` | Authentication, authorization, secret management, networking, and tenant isolation. Also covers OWASP API Security Top 10 compliance |
| `design-observability` | Monitoring, distributed tracing (tracking requests that span multiple services), log aggregation, and alerting |
| `design-disaster-recovery` | RTO/RPO (recovery time objective and recovery point objective), backup, failover, and recovery procedures |
| `estimate-cost` | Estimates for cloud infrastructure, ScalarDB licensing, and operational costs, including sizing (determining the required scale) |

<Accordion>
  <AccordionItem title="/architect:design-security — Security Design (sonnet)">
    Outputs: authentication infrastructure (OAuth2/OIDC, service-to-service mTLS); an authorization model (RBAC/ABAC, including **object-level** authorization, not just role-level); a tenant isolation model; secret management (Vault/KMS, rotation strategy); network security (zero trust, segmentation); data classification (which fields are sensitive, and whether they may appear in API responses/logs/error details); audit logging; and a compliance checklist. Also covers OWASP API Security Top 10 compliance.
  </AccordionItem>

  <AccordionItem title="/architect:design-observability — Observability Design (sonnet)">
    Outputs: SLI/SLO definitions (per service, tied to business KPIs); distributed tracing (OpenTelemetry, tracking requests that span multiple services via correlation IDs); log aggregation; metrics (RED/USE methods); alert design; and ScalarDB-specific metrics (transaction success rate, OCC conflict rate). When using ScalarDB Saga, also adds Saga state counts and compensation failure rates.
  </AccordionItem>

  <AccordionItem title="/architect:design-disaster-recovery — Disaster Recovery Design (sonnet)">
    Outputs: RTO/RPO per service tier (recovery time objective and the amount of data loss that's acceptable); a backup strategy (frequency, retention, restore-test plan); failover design (cross-region, cross-AZ); data recovery procedures (including ScalarDB's Coordinator table); runbooks per failure scenario; and a recovery test plan that includes chaos engineering (deliberately inducing failures to verify resilience).
  </AccordionItem>

  <AccordionItem title="/architect:estimate-cost — Cost Estimation (sonnet)">
    Provides multi-faceted estimates covering: cloud infrastructure costs (AWS/Azure/GCP compute, storage, and network); ScalarDB licensing costs (by edition, whether contracted directly or via AWS Marketplace); operational costs (monitoring tools, support, staffing); and ScalarDB sizing (pod count, cluster configuration, DB capacity).
  </AccordionItem>

  <AccordionItem title="/architect:design-infrastructure — Infrastructure Logical Design (opus)">
    Outputs: Kubernetes cluster configuration (node pools, resource quotas, namespace strategy); container orchestration (deployment strategy, HPA, PDB); network design (mTLS, NetworkPolicy, Ingress/Gateway); IaC configuration (Terraform modules, state management); and a multi-environment strategy (dev/staging/prod, Kustomize overlays). When using ScalarDB Cluster, also designs the Helm chart configuration and Coordinator placement.

    The output is strictly a **logical design** — `/infra:design` in the [infra plugin](/skills/infra) takes the same area further into a concrete, multi-cloud-ready design (see the panel below).
  </AccordionItem>
</Accordion>

<Panel title="When actually building cloud infrastructure">
`design-infrastructure`, `generate-infra-code`, and `review-operations` handle logical design and scaffolding.
Implementing and reviewing Terraform/Kubernetes/CI in the actual infrastructure repository is the responsibility of the separate [infra](/skills/infra) plugin.
</Panel>

## Review skills (parallelizable perspectives)

A set of skills for checking a design or implementation from multiple perspectives. Each skill runs independently (in parallel), and `review-synthesizer` aggregates all results at the end to produce a Go/No-Go decision.

```mermaid
flowchart LR
  A[review-consistency] --> F[review-synthesizer]
  B["review-scalardb / review-data-integrity"] --> F
  C[review-operations] --> F
  D[review-risk] --> F
  E[review-business] --> F
  F --> G["Go/No-Go decision"]
```

| Skill | Perspective |
|---|---|
| `review-consistency` | Structural consistency, traceability, and terminology uniformity |
| `review-operations` | Monitoring, disaster recovery, security posture, and deployment safety |
| `review-risk` | Distributed system risks, failure modes, and validity of Saga design (a pattern for achieving distributed transactions through compensation). Intentionally adversarial — digs the deepest |
| `review-business` | Traceability to business requirements, whether NFRs are expressed as measurable values, and stakeholder alignment |
| `review-scalardb` | For ScalarDB use cases. 2PC (two-phase commit) scope, OCC (optimistic concurrency control) contention, and schema compatibility |
| `review-data-integrity` | For non-ScalarDB use cases. Data consistency, transaction safety, and schema quality |
| `review-synthesizer` | Consolidates results from 2–6 perspectives, deduplicates and prioritizes findings, and determines whether the quality gate passes or fails |

<Accordion>
  <AccordionItem title="/architect:review-consistency — Consistency Review (sonnet)">
    Scores three perspectives on a 5-point scale: structural consistency (35%), traceability (35%), and terminology consistency (30%). Outputs findings in JSON format covering things like orphaned sections, places where the requirements→design→implementation trace can't be followed, and cases where the same concept has been given different names.
  </AccordionItem>

  <AccordionItem title="/architect:review-operations — Operations Review (sonnet)">
    Evaluates operational readiness across four perspectives: monitoring/observability (30%), disaster recovery (30%), security posture (20%), and deployment safety (20%).
  </AccordionItem>

  <AccordionItem title="/architect:review-risk — Risk Review (opus)">
    Evaluates four perspectives — distributed system risk (30%), failure mode analysis (30%), Saga design validity (25%), and data integrity risk (15%) — deliberately from an adversarial standpoint. The goal is to surface risks the designer is unlikely to notice themselves, and it digs the deepest of the six perspectives.
  </AccordionItem>

  <AccordionItem title="/architect:review-business — Business Review (sonnet)">
    Evaluates the validity of the design from a business-requirements standpoint across four perspectives: requirements traceability (35%), NFRs expressed as measurable values (30%), stakeholder alignment (20%), and ROI/feasibility (15%).
  </AccordionItem>

  <AccordionItem title="/architect:review-scalardb — ScalarDB Review (sonnet)">
    Specific to projects that use ScalarDB. Evaluates three perspectives: the cross-service transaction mechanism (40%), OCC conflict analysis (35%), and schema/API compatibility (25%).
  </AccordionItem>

  <AccordionItem title="/architect:review-data-integrity — Data Integrity Review (sonnet)">
    Specific to projects that don't use ScalarDB. Evaluates three perspectives: transaction safety (40%), data integrity (35%), and schema design quality (25%). Mutually exclusive with `review-scalardb` — only one of the two runs.
  </AccordionItem>

  <AccordionItem title="/architect:review-synthesizer — Review Synthesis (sonnet)">
    Takes in results from 2–6 perspectives and consolidates them in the following order.

    1. **Merge duplicates**

        Findings that share the same location and root cause are merged into one, recording which perspectives surfaced it (e.g., "CON-003, BIZ-007"). When merging, the highest severity is adopted.

    2. **Classify priority**

        Classifies findings into four levels, from P0 (critical — leads to data loss, security breach, or system failure) to P3 (informational). Findings marked "important" by two or more perspectives, or marked "important" from the risk/scalardb perspective, are escalated to P1.

    3. **Determine the quality gate**

        Based on the thresholds in `review-registry.json`, determines PASS (e.g., average of 3.5 or higher and zero critical findings), CONDITIONAL PASS (average of 2.5 or higher and up to two critical findings), or FAIL.

    4. **Check fix propagation**

        Checks whether a finding that a design-document fix was supposed to resolve **still survives elsewhere** — for example, in OpenAPI descriptions. Because downstream code generation reads those descriptions as instructions, a supposedly-retracted statement left in place lets the same defect reappear in a different form.
  </AccordionItem>
</Accordion>

## ScalarDB migration

A set of skills for migrating an existing database to ScalarDB. `migrate-database` acts as the entry point (router) and dispatches to a dedicated skill based on the source database type.

```mermaid
flowchart LR
  A["migrate-database(router)"] --> B[migrate-oracle]
  A --> C[migrate-mysql]
  A --> D[migrate-postgresql]
```

| Skill | Scope |
|---|---|
| `migrate-database` | Identifies the source database type and routes to the appropriate dedicated skill below |
| `migrate-oracle` | Schema extraction, migration analysis, Advanced Queuing integration, and Java conversion of stored procedures and triggers |
| `migrate-mysql` | Schema extraction, migration analysis, and Java conversion of stored procedures and triggers |
| `migrate-postgresql` | Schema extraction, migration analysis, and Java conversion of stored procedures and triggers |

<Accordion>
  <AccordionItem title="/architect:migrate-database — Migration Entry Point (sonnet)">
    Has the user select which source database (Oracle/MySQL/PostgreSQL) is involved, and routes to the corresponding dedicated skill. It doesn't perform any schema extraction or conversion itself.
  </AccordionItem>

  <AccordionItem title="/architect:migrate-oracle — Oracle Migration (sonnet)">
    Uses six subagents — three sequential stages followed by three parallel runs — to handle everything from schema extraction to Java code generation.

    1. **Connection check and schema extraction (sequential)**

        Runs three steps in order: connection check via SQL*Plus → schema extraction via extraction scripts → report generation.

    2. **Migration analysis, AQ integration, and code conversion (parallel)**

        Runs three tasks concurrently: "migration analysis and complexity scoring," "generating Advanced Queuing (Oracle's message queue feature) setup SQL and Java consumers," and "converting PL/SQL stored procedures/triggers to Java." This cuts time by roughly 33–55% compared to running sequentially.
  </AccordionItem>

  <AccordionItem title="/architect:migrate-mysql — MySQL Migration (sonnet)">
    Follows the same approach as `migrate-oracle` (sequential extraction → parallel analysis/conversion) to perform schema extraction, migration analysis, and Java conversion of stored procedures/triggers. Advanced Queuing integration is out of scope, since it's an Oracle-specific feature.
  </AccordionItem>

  <AccordionItem title="/architect:migrate-postgresql — PostgreSQL Migration (sonnet)">
    Follows the same approach as `migrate-oracle` to perform schema extraction, migration analysis, and Java conversion of stored procedures/triggers. Advanced Queuing integration is out of scope, since it's an Oracle-specific feature.
  </AccordionItem>
</Accordion>

---

Among all the skills, the four **backlog management** skills are the most commonly used in real projects. They are used in sequence: `export-backlog` → `implement-backlog` → `review-issue` → `merge-issue`. The following pages cover each of these four skills in order.

<CardGroup cols={2}>
  <Card title="export-backlog" icon="clipboard-list" href="/skills/backlog/export">
    Creates Epics (large feature groupings), Sub-Epics, and Issues (concrete work items) based on the contents of the reports/ folder
  </Card>
  <Card title="implement-backlog" icon="code" href="/skills/backlog/implement">
    Drives implementation using sub-agents (AI running in a supporting role) arranged in a hierarchy
  </Card>
  <Card title="review-issue" icon="search-check" href="/skills/backlog/review">
    Reviews not only the individual Issue but also the entire Epic it belongs to
  </Card>
  <Card title="merge-issue" icon="git-merge" href="/skills/backlog/merge">
    Merges after a preflight check and reflects completion status up to the parent Epic
  </Card>
</CardGroup>