---
title: export-backlog
description: Skill that creates Epics, Sub-Epics, and Issues from the contents of reports/
seo:
  image: /ogp.png
---
**Input**: All documents in the `reports/` directory. Works with output from either the product or architect pipeline.

**Output**: The following three artifacts.

1. `reports/backlog/backlog-plan.md`: A human-readable plan document
2. `backlog-manifest.json`: Machine-readable data
3. The GitLab/GitHub Issues that are actually created

## Command and Key Options

```
/architect:export-backlog [--provider=gitlab|github] [--project=<path>] [--dry-run] [--yes] [--lang=en|ja]
```

| Option | Description |
|---|---|
| `--provider` | The tracker to use. If omitted, auto-detected from the repository's remote URL |
| `--project` | The target project. For GitLab: `group/subgroup/project`; for GitHub: `owner/repo` |
| `--dry-run` | Outputs only the plan document (`backlog-plan.md`) without creating any Issues |
| `--yes` | Skips plan document approval and proceeds directly to creation |
| `--lang` | Output language for Issue bodies and reports |

On the first run, it is safer to use `--dry-run` to review the plan document first, then run again without the flag once you are satisfied with the content.

## Mapping Model

Work is organized into a clear three-level hierarchy of Epics, Sub-Epics, and Issues.

- **Epic (large-scale work) — "what" and "why"**: Typically one per product. Describes why and for what purpose the product is being built.
- **Sub-Epic (mid-level work) — "what" to build, KRs (measurable numeric targets)**: Divided by feature area or ownership domain. Write measurable KRs based on <Tooltip tip="サービスがどれだけ安定して動くべきかという目標。SLI(測り方)とSLA(顧客への約束)と組で使います。" headline="SLO" cta="用語集で見る" href="/glossary">SLO</Tooltip> and <Tooltip tip="非機能要件。性能・信頼性・セキュリティなど、「何ができるか」以外の要件。" headline="NFR(非機能要件)" cta="用語集で見る" href="/glossary">NFR</Tooltip>. If numbers are not yet decided, mark them explicitly as "TBD".
- **Issue (smallest actionable unit of work) — "how"**: Broken down to the smallest individually actionable unit. Split by one feature, one API endpoint, or one schema change. Do not write more than five acceptance criteria per Issue or mix multiple aggregates into a single Issue.

### Example Issue Breakdown (Deal Management)

```
SE1.1: Deal Management (Core, Strong)
├── I1.1.1 案件を新規作成する
├── I1.1.2 自分の担当案件一覧を表示する
├── I1.1.3 案件詳細を開く
├── I1.1.4 案件の進捗ステータスを更新する ★critical path
├── I1.1.5 案件の次アクションを編集する
└── I1.1.6 案件にメモを追加する(Should)
```

:::note[Plan first, then create — idempotent on every run]
Before creating any Issues, the skill always writes a `backlog-plan.md` plan document and uses the `AskUserQuestion` mechanism to require human review and approval. On subsequent runs, items that already have a `remote.url` (a link to a previously created Issue) are skipped, preventing duplicate Issues from being created.
:::

:::warning[Use --unlabel to remove labels]
Prefixing a label name with `-` (a minus sign), as in `-l "-status::todo"`, does not remove the label. Instead, a new label named `-status::todo` is created.
See [Troubleshooting](/troubleshooting) for the fix.
:::