openspec-onboard

ユーザーが初めて OpenSpec のワークフローを一通り完了できるように案内します。これは学習体験です。各ステップを説明しながら、ユーザーのコードベースで実際の作業を行います。

ストアの選択： ユーザーがストア（ストアとは、このマシンに登録されている独立した OpenSpec リポジトリです）を指定した場合、または作業対象がストア内にある場合は、openspec store list --json を実行して登録済みのストア ID を確認し、仕様や変更を読み書きするコマンド（new change、status、instructions、list、show、validate、archive、doctor、context、schemas、view）に --store <id> を渡します。いったん選択したら、以降のワークフローでは --store <id> を常に付けてください。以下に示す、ストアを指定していないコマンドの例はすべて省略形です。実行する前にフラグを追加してください。たとえば、以下に示すストアを指定していない形式ではなく、openspec status --change "<name>" --json --store "<id>" を実行します。ほかのコマンドではこのフラグは不要です。コマンドが出力するヒントにはすでにフラグが含まれているため、後続のコマンドにも付けたままにしてください。ストアを選択していない場合、コマンドは最も近いローカルの openspec/ ルートを対象にします。

プロジェクトの確認： これらの手順は、すでに OpenSpec を使用しているプロジェクトを想定しています。最初に何かを書き込む手順（new change、archive、sync specs、またはアーティファクトファイルの作成）に進む前に、プロジェクトにルートがあることを確認します。openspec list --json を実行し（ストアを選択している場合は、そのストアがルートとなるため --store <id> を付けます）、root を読み取ります。root オブジェクトがあれば、プロジェクトはセットアップ済みです。"root": null は未セットアップであり、ここに openspec/ ディレクトリがないことを意味します。この状態で openspec new change などを書き込むと、副作用としてディレクトリが作成されます。このコマンドはゼロ以外の終了コードを返しますが、これは CLI の不具合ではなく、その状態を示しています。再試行したり回避策を講じたりせず、JSON を読み取ってください。

status のエラーメッセージが Declared in または Invalid store declaration in で始まり、このプロジェクトの openspec/config.yaml（または config.yml）を示している場合、"root": null はセットアップされていないことを意味するわけではありません。このプロジェクトは、マシン側で解決できないストア（未登録のストア、または不正な store: 行）を宣言して OpenSpec を使用しています。未初期化として扱って以下の分岐に進んではいけません。書き込みを行う前に停止し、そのエラーの message と fix をユーザーに示してください。

それ以外で、ルートがない場合の次の対応は、このワークフローが開始された経緯によって異なります。

• 自動選択： ユーザーが OpenSpec に言及せず、このスキルにも言及せず、スラッシュコマンドも実行していない状況で、あなた自身がこのワークフローを選択した場合です。OpenSpec の使用を中止し、OpenSpec がインストールされていない場合と同じように、通常どおりリクエストに対応してください。セットアップを促したり、OpenSpec のセットアップについて言及したりしないでください。
• 明示的な OpenSpec のリクエスト： ユーザーが OpenSpec に言及した、このスキルに言及した、またはそのスラッシュコマンドを実行した場合です。書き込みの前に停止し、プロジェクトをセットアップする（openspec init）、既存のストアを対象にする（--store <id>）、またはこのリクエストでは OpenSpec を使わずに続行する、のいずれかをユーザーに尋ねてください。回答を待ちます。

どちらの分岐でも、副作用としてルートを作成してはいけません。ユーザーが求めるまで openspec init を実行せず、openspec/ ファイルを手作業で作成せず、コマンドによってルートを作成させないでください。

---

事前確認

開始前に、OpenSpec CLI がインストールされているか確認します。

# Unix/macOS
openspec --version 2>&1 || echo "CLI_NOT_INSTALLED"
# Windows (PowerShell)
# if (Get-Command openspec -ErrorAction SilentlyContinue) { openspec --version } else { echo "CLI_NOT_INSTALLED" }

CLI がインストールされていない場合：

OpenSpec CLI がインストールされていません。先にインストールしてから、/openspec-onboard に戻ってください。

ここで停止します。

---

フェーズ 1：ようこそ

次を表示します。

## Welcome to OpenSpec!

I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.

**What we'll do:**
1. Pick a small, real task in your codebase
2. Explore the problem briefly
3. Create a change (the container for our work)
4. Build the artifacts: proposal → specs → design → tasks
5. Implement the tasks
6. Archive the completed change

**Time:** ~15-20 minutes

Let's start by finding something to work on.

---

フェーズ 2：タスクの選択

コードベースの分析

コードベースをスキャンし、小規模な改善の機会を探します。以下を確認してください。

1. TODO/FIXME コメント - コードファイル内の TODO、FIXME、HACK、XXX を検索します
2. エラーハンドリングの不足 - エラーを握りつぶす catch ブロック、try-catch を使わずに行われるリスクの高い処理
3. テストのない関数 - src/ とテストディレクトリを照合します
4. 型の問題 - TypeScript ファイル内の any 型（: any、as any）
5. デバッグ用コードの残存 - デバッグ用ではないコード内の console.log、console.debug、debugger 文
6. バリデーションの不足 - バリデーションを行わないユーザー入力ハンドラー

最近の Git のアクティビティも確認してください。

# Unix/macOS
git log --oneline -10 2>/dev/null || echo "No git history"
# Windows (PowerShell)
# git log --oneline -10 2>$null; if ($LASTEXITCODE -ne 0) { echo "No git history" }

提案を提示する

分析に基づき、具体的な提案を3～4件提示します。

## Task Suggestions

Based on scanning your codebase, here are some good starter tasks:

**1. [Most promising task]**
   Location: `src/path/to/file.ts:42`
   Scope: ~1-2 files, ~20-30 lines
   Why it's good: [brief reason]

**2. [Second task]**
   Location: `src/another/file.ts`
   Scope: ~1 file, ~15 lines
   Why it's good: [brief reason]

**3. [Third task]**
   Location: [location]
   Scope: [estimate]
   Why it's good: [brief reason]

**4. Something else?**
   Tell me what you'd like to work on.

Which task interests you? (Pick a number or describe your own)

何も見つからなかった場合： ユーザーが何を作りたいか尋ねます。

コードベース内に、すぐに取り組める明らかな改善点は見つかりませんでした。追加または修正したいと思っている小さなことはありますか？

スコープのガードレール

ユーザーが選んだ内容や説明した内容が大きすぎる場合（大規模な機能、数日かかる作業）：

That's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.

For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.

**Options:**
1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?
2. **Pick something else** - One of the other suggestions, or a different small task?
3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.

What would you prefer?

ユーザーが希望する場合は、ガードレールを無視できるようにします。これは厳密な制限ではありません。

---

フェーズ 3：探索のデモ

タスクが選ばれたら、探索モードを手短に実演します。

Before we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.

関連するコードを1～2分かけて調査します。

• 関連するファイルを読む
• 役立つ場合は、簡単な ASCII 図を描く
• 考慮事項を挙げる

## Quick Exploration

[Your brief analysis—what you found, any considerations]

┌─────────────────────────────────────────┐
│   [Optional: ASCII diagram if helpful]  │
└─────────────────────────────────────────┘

Explore mode (`/openspec-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.

Now let's create a change to hold our work.

一時停止 - 続行する前に、ユーザーの了承を待ちます。

---

フェーズ 4：変更の作成

説明：

## Creating a Change

A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives at the `changeRoot` reported by `openspec status --change "<name>" --json` and holds your artifacts—proposal, specs, design, tasks.

Let me create one for our task.

実行： 導出した kebab-case の名前を使って変更を作成します。

openspec new change "<derived-name>"

表示：

Created: <changeRoot from status JSON>

The folder structure:

/ ├── proposal.md ← 変更の理由（空の状態で作成し、後で内容を記入します） ├── design.md ← 実装方法（空の状態で作成します） ├── specs/ ← 詳細な要件（空の状態で作成します） └── tasks.md ← 実装チェックリスト（空の状態で作成します）

Now let's fill in the first artifact—the proposal.

---

フェーズ 5：提案

説明：

## The Proposal

The proposal captures **why** we're making this change and **what** it involves at a high level. It's the "elevator pitch" for the work.

I'll draft one based on our task.

実行： 提案の内容を下書きします（まだ保存しません）。

<capability-path> は specs/ を基準とした仕様ディレクトリです（例： user-auth または identity/user-auth）。変更する機能には既存のパスを そのまま使用します。新しい機能には、プロジェクトで確立された仕様の 構成に従います。

Here's a draft proposal:

---

# Proposal

## Why

[1-2 sentences explaining the problem/opportunity]

## What Changes

[Bullet points of what will be different]

## Capabilities

### New Capabilities
- `<capability-path>`: [brief description]

### Modified Capabilities

- `<existing-capability-path>`: [brief description]

## Impact

- `src/path/to/file.ts`: [what changes]
- [other files if applicable]

---

Does this capture the intent? I can adjust before we save it.

一時停止 - ユーザーの承認またはフィードバックを待ちます。

承認後、提案を保存します。

openspec instructions proposal --change "<name>" --json

次に、openspec instructions proposal --change "<name>" --json で得られる resolvedOutputPath に内容を書き込みます。

Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.

Next up: specs.

---

フェーズ 6：仕様

説明：

## Specs

Specs define **what** we're building in precise, testable terms. They use a requirement/scenario format that makes expected behavior crystal clear.

For a small task like this, we might only need one spec file.

実行： 仕様ファイルを作成する場所を解決します。

openspec instructions specs --change "<name>" --json
# Use resolvedOutputPath from the JSON. If it is a glob, choose the concrete file path using the schema instruction and the change's context.

仕様の内容を下書きします。

Here's the spec:

---

# Spec Delta

## ADDED Requirements

### Requirement: <Name>

<Description of what the system should do>

#### Scenario: <Scenario name>

- **WHEN** <trigger condition>
- **THEN** <expected outcome>
- **AND** <additional outcome if needed>

---

This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.

resolvedOutputPath から選んだ具体的なファイルパスに保存します。

---

フェーズ 7：設計

説明：

## Design

The design captures **how** we'll build it—technical decisions, tradeoffs, approach.

For small changes, this might be brief. That's fine—not every change needs deep design discussion.

実行： design.md の内容を下書きします。

Here's the design:

---

# Design

## Context

[Brief context about the current state]

## Goals / Non-Goals

**Goals:**
- [What we're trying to achieve]

**Non-Goals:**
- [What's explicitly out of scope]

## Decisions

### Decision 1: [Key decision]

[Explanation of approach and rationale]

---

For a small task, this captures the key decisions without over-engineering.

openspec instructions design --change "<name>" --json で得られる resolvedOutputPath に保存します。

---

フェーズ 8：タスク

説明：

## Tasks

Finally, we break the work into implementation tasks—checkboxes that drive the apply phase.

These should be small, clear, and in logical order. Each group carries the tests and documentation for its own work - the last group is only for integration checks.

実行： 仕様と設計に基づいてタスクを作成します。

Here are the implementation tasks:

---

# Tasks

## 1. [Category or file]

- [ ] 1.1 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]
- [ ] 1.2 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]

## 2. Integration Verification

- [ ] 2.1 Verify [broader integration or system behavior] with [end-to-end test or observable result]

---

Each checkbox becomes a unit of work in the apply phase. Does this task breakdown look right?

一時停止 - ユーザーの承認またはフィードバックを待ちます。

承認後、openspec instructions tasks --change "<name>" --json で得られる resolvedOutputPath に保存します。

次に、以下を尋ねます。

「タスクを保存しました。実装を始めてもよいですか？」

一時停止 - 実装を始める前に、ユーザーの確認を待ちます。

---

フェーズ 9：適用（実装）

説明：

## Implementation

Now we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs/design informed the approach.

実行： 各タスクについて、以下を行います。

1. 「タスク N に取り組んでいます：[説明]」と伝える
2. コードベースに変更を実装する
3. 仕様や設計を自然に参照する：「仕様には X とあるため、Y のように実装します」
4. tasks.md で完了にする：- [ ] → - [x]
5. 簡潔に状況を伝える：「✓ タスク N が完了しました」

説明は簡潔にし、コードの一行一行を過剰に説明しないでください。

すべてのタスクが完了したら：

## Implementation Complete

All tasks done:
- [x] Task 1
- [x] Task 2
- [x] ...

The change is implemented! One more step—let's archive it.

---

フェーズ 10：アーカイブ

説明：

## Archiving

When a change is complete, we archive it. The archive path is derived from `planningHome.changesDir` and the date.

Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.

実行： 変更をアーカイブします（ツール呼び出しからは確認プロンプトに回答できないため、--yes で確認に回答します）。

openspec archive "<name>" --yes

表示：

Archived to: `<planningHome.changesDir>/archive/<target-name>/` (the target name prepends today's date, unless the name already starts with a `YYYY-MM-DD-` prefix — then it is kept as-is, no second date)

The change is now part of your project's history. The code is in your codebase, the decision record is preserved.

---

フェーズ 11：振り返りと次のステップ

## Congratulations!

You just completed a full OpenSpec cycle:

1. **Explore** - Thought through the problem
2. **New** - Created a change container
3. **Proposal** - Captured WHY
4. **Specs** - Defined WHAT in detail
5. **Design** - Decided HOW
6. **Tasks** - Broke it into steps
7. **Apply** - Implemented the work
8. **Archive** - Preserved the record

This same rhythm works for any size change—a small fix or a major feature.

---

## Command Reference

**The commands you have installed:**

 | Command          | What it does                               |
 |------------------|--------------------------------------------|
 | `/openspec-propose` | Create a change and generate all artifacts |
 | `/openspec-explore` | Think through problems before/during work  |
 | `/openspec-apply-change`   | Implement tasks from a change              |
 | `/openspec-archive-change` | Archive a completed change                 |
 | `/openspec-new-change`     | Start a new change, one artifact at a time |
 | `/openspec-continue-change` | Continue working on an existing change    |
 | `/openspec-ff-change`      | Fast-forward: create all artifacts at once |
 | `/openspec-verify-change`  | Verify implementation matches artifacts    |

---

## What's Next?

Try `/openspec-propose` on something you actually want to build. You've got the rhythm now!

---

スムーズな終了処理

ユーザーが途中で止めたい場合

ユーザーが止める必要がある、休憩したいと言った場合、または関心が薄れているように見える場合：

No problem! Your change is saved at the `changeRoot` reported by `openspec status --change "<name>" --json`.

To pick up where we left off later, `openspec status --change "<name>" --json` shows exactly where the change stands.
- `/openspec-continue-change <name>` - Resume artifact creation
- `/openspec-apply-change <name>` - Jump to implementation (if tasks exist)

The work won't be lost. Come back whenever you're ready.

無理に引き止めず、丁寧に終了します。

ユーザーがコマンドの一覧だけを見たい場合

ユーザーがコマンドだけを見たい、またはチュートリアルをスキップしたいと言った場合：

## OpenSpec Quick Reference

**The commands you have installed:**

 | Command                  | What it does                               |
 |--------------------------|--------------------------------------------|
 | `/openspec-propose <name>`  | Create a change and generate all artifacts |
 | `/openspec-explore`         | Think through problems (no code changes)   |
 | `/openspec-apply-change <name>`    | Implement tasks                            |
 | `/openspec-archive-change <name>`  | Archive when done                          |
 | `/openspec-new-change <name>`      | Start a new change, step by step           |
 | `/openspec-continue-change <name>` | Continue an existing change                |
 | `/openspec-ff-change <name>`       | Fast-forward: all artifacts at once        |
 | `/openspec-verify-change <name>`   | Verify implementation                      |

Try `/openspec-propose` to start your first change.

丁寧に終了します。

---

ガードレール

• 重要な移行点（調査の後、提案の下書きの後、タスクの後、アーカイブの後）では、EXPLAIN → DO → SHOW → PAUSE のパターンに従います
• 実装中の説明は簡潔に保ちます。講義のようにならないようにします
• 変更が小さくてもフェーズを省略しません。目的はワークフローを教えることです
• 指定された箇所で確認を待ちますが、待ちすぎないようにします
• 終了する場合は丁寧に対応し、ユーザーに続行を強要しません
• 実際のコードベースのタスクを使います。シミュレーションや架空の例は使いません
• スコープは控えめに調整し、より小さなタスクへ導きますが、ユーザーの選択を尊重します