ralph-tui-create-beads-rust
Convert PRDs to beads for ralph-tui execution using beads-rust (br CLI). Creates an epic with child beads for each user story. Use when you have a PRD and want to use ralph-tui with beads-rust as the task source. Triggers on: create beads, convert prd to beads, beads for ralph, ralph beads, br beads.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o ralph-tui-create-beads-rust.zip https://jpskill.com/download/20877.zip && unzip -o ralph-tui-create-beads-rust.zip && rm ralph-tui-create-beads-rust.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/20877.zip -OutFile "$d\ralph-tui-create-beads-rust.zip"; Expand-Archive "$d\ralph-tui-create-beads-rust.zip" -DestinationPath $d -Force; ri "$d\ralph-tui-create-beads-rust.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
ralph-tui-create-beads-rust.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
ralph-tui-create-beads-rustフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[スキル名] ralph-tui-create-beads-rust
Ralph TUI - ビーズの作成 (beads-rust)
beads-rust (br CLI) を使用して、PRD をビーズ (エピック + 子タスク) に変換し、ralph-tui の自律実行に備えます。
注: このスキルは beads-rust の
brコマンドを使用します。代わりにオリジナルの beads (bd) がインストールされている場合は、ralph-tui-create-beadsスキルを使用してください。
ジョブ
PRD (Markdown ファイルまたはテキスト) を受け取り、br コマンドを使用してビーズを作成します。
- PRD の「Quality Gates」セクションから品質ゲートを抽出します。
- 機能のエピックビーズを作成します。
- 各ユーザーストーリーの子ビーズを作成します (品質ゲートを付加します)。
- ビーズ間の依存関係を設定します (スキーマ → バックエンド → UI)。
ralph-tui run --tracker beads-rustで実行できる形式で出力します。
ステップ 1: 品質ゲートの抽出
PRD の「Quality Gates」セクションを探します。
## Quality Gates
These commands must pass for every user story:
- `pnpm typecheck` - Type checking
- `pnpm lint` - Linting
For UI stories, also include:
- Verify in browser using dev-browser skill
以下を抽出します。
- ユニバーサルゲート: すべてのストーリーに適用されるコマンド (例:
pnpm typecheck) - UIゲート: UI ストーリーにのみ適用されるコマンド (例: ブラウザでの検証)
「Quality Gates」セクションが存在しない場合: ユーザーにどのコマンドが合格すべきか尋ねるか、npm run typecheck のような適切なデフォルトを使用します。
出力形式
ビーズは、特殊文字を安全に処理するために HEREDOC 構文で br create コマンドを使用します。
# Create epic (link back to source PRD)
br create --type=epic \
--title="[Feature Name]" \
--description="$(cat <<'EOF'
[Feature description from PRD]
EOF
)" \
--external-ref="prd:./tasks/feature-name-prd.md"
# Create child bead (with quality gates in acceptance criteria)
br create \
--parent=EPIC_ID \
--title="[Story Title]" \
--description="$(cat <<'EOF'
[Story description with acceptance criteria INCLUDING quality gates]
EOF
)" \
--priority=[1-4]
重要: HEREDOC デリミタには常に
<<'EOF'(シングルクォート) を使用してください。これにより、説明内のバッククォート、$variables、および()のシェル解釈が防止されます。
ストーリーのサイズ: 最重要ルール
各ストーリーは、1 回の ralph-tui イテレーション (約 1 つのエージェントコンテキストウィンドウ) で完了できる必要があります。
ralph-tui は、以前の作業の記憶を持たない新しいエージェントインスタンスをイテレーションごとに生成します。ストーリーが大きすぎると、エージェントは完了する前にコンテキストを使い果たしてしまいます。
適切なサイズのストーリー:
- データベース列とマイグレーションの追加
- 既存のページへの UI コンポーネントの追加
- 新しいロジックによるサーバーアクションの更新
- リストへのフィルタードロップダウンの追加
大きすぎるストーリー (分割してください):
- 「ダッシュボード全体を構築する」→ スキーマ、クエリ、UI コンポーネント、フィルターに分割
- 「認証を追加する」→ スキーマ、ミドルウェア、ログイン UI、セッション処理に分割
- 「API をリファクタリングする」→ エンドポイントまたはパターンごとに 1 つのストーリーに分割
経験則: 変更を 2〜3 文で説明できない場合は、大きすぎます。
ストーリーの順序: 依存関係が最初
ストーリーは依存関係の順序で実行されます。前のストーリーが後のストーリーに依存してはいけません。
正しい順序:
- スキーマ/データベースの変更 (マイグレーション)
- サーバーアクション / バックエンドロジック
- バックエンドを使用する UI コンポーネント
- データを集計するダッシュボード/概要ビュー
間違った順序:
- ❌ UI コンポーネント (まだ存在しないスキーマに依存)
- ❌ スキーマの変更
br dep add による依存関係
br dep add コマンドを使用して、どのビーズが最初に完了する必要があるかを指定します。
# Create the beads first
br create --parent=epic-123 --title="US-001: Add schema" ...
br create --parent=epic-123 --title="US-002: Create API" ...
br create --parent=epic-123 --title="US-003: Build UI" ...
# Then add dependencies (issue depends-on blocker)
br dep add ralph-tui-002 ralph-tui-001 # US-002 depends on US-001
br dep add ralph-tui-003 ralph-tui-002 # US-003 depends on US-002
構文: br dep add <issue> <depends-on> — issue は depends-on に依存します (depends-on によってブロックされます)。
ralph-tui は以下を行います。
- 依存関係が完了するまで、ブロックされたビーズを「ブロック済み」として表示します。
- 依存関係が未解決の間は、実行のためにビーズを選択しません。
- ビーズに取り組む際に、プロンプトに依存関係のコンテキストを含めます。
正しい依存関係の順序:
- スキーマ/データベースの変更 (依存関係なし)
- バックエンドロジック (スキーマに依存)
- UI コンポーネント (バックエンドに依存)
- 統合/洗練 (UI に依存)
受け入れ基準: 品質ゲート + ストーリー固有
各ビーズの説明には、以下の受け入れ基準を含める必要があります。
- PRD からのストーリー固有の基準 (このストーリーが達成すること)
- PRD の品質ゲートセクションからの品質ゲート (最後に付加されます)
良い基準 (検証可能):
- 「
investorType列を investor テーブルに追加し、デフォルトを 'cold' にする」 - 「フィルタードロップダウンにオプション: All, Cold, Friend がある」
- 「トグルをクリックすると確認ダイアログが表示される」
悪い基準 (曖昧):
- ❌ 「正しく動作する」
- ❌ 「ユーザーは簡単に X を実行できる」
- ❌ 「優れた UX」
- ❌ 「エッジケースを処理する」
変換ルール
- 最初に PRD から品質ゲートを抽出します。
- 各ユーザーストーリー → 1 つのビーズ
- 最初のストーリー: 依存関係なし (基盤を作成します)
- 後続のストーリー: 前のストーリーに依存します (UI はバックエンドに依存するなど)
- 優先度: 依存関係の順序、次にドキュメントの順序に基づきます (0=クリティカル、2=中、4=バックログ)
- すべてのストーリー:
status: "open" - 受け入れ基準: ストーリーの基準 + 品質ゲートを付加
- UI ストーリー: UI 固有のゲート (ブラウザ検証) も付加
大規模な PRD の分割
PRD に大きな機能がある場合は、それらを分割します。
オリジナル:
「異なるメッセージングで友達へのアウトリーチトラックを追加する」
分割後:
- US-001: investor テーブルに investorType フィールドを追加する
- US-002: investor リスト UI にタイプトグルを追加する
- US-003: 友達固有のフェーズ進行ロジックを作成する
- US-004: 友達メッセージテンプレートを作成する
- US-005: 友達のタスク生成を接続する
- US-006: タイプでフィルターを追加する
- US-007: 新しい投資家フォームを更新する
- US-008: ダッシュボードのカウントを更新する
それぞれが、完了できる焦点を絞った変更です。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Ralph TUI - Create Beads (beads-rust)
Converts PRDs to beads (epic + child tasks) for ralph-tui autonomous execution using beads-rust (br CLI).
Note: This skill uses the
brcommand from beads-rust. If you have the original beads (bd) installed instead, use theralph-tui-create-beadsskill.
The Job
Take a PRD (markdown file or text) and create beads using br commands:
- Extract Quality Gates from the PRD's "Quality Gates" section
- Create an epic bead for the feature
- Create child beads for each user story (with quality gates appended)
- Set up dependencies between beads (schema → backend → UI)
- Output ready for
ralph-tui run --tracker beads-rust
Step 1: Extract Quality Gates
Look for the "Quality Gates" section in the PRD:
## Quality Gates
These commands must pass for every user story:
- `pnpm typecheck` - Type checking
- `pnpm lint` - Linting
For UI stories, also include:
- Verify in browser using dev-browser skill
Extract:
- Universal gates: Commands that apply to ALL stories (e.g.,
pnpm typecheck) - UI gates: Commands that apply only to UI stories (e.g., browser verification)
If no Quality Gates section exists: Ask the user what commands should pass, or use a sensible default like npm run typecheck.
Output Format
Beads use br create command with HEREDOC syntax to safely handle special characters:
# Create epic (link back to source PRD)
br create --type=epic \
--title="[Feature Name]" \
--description="$(cat <<'EOF'
[Feature description from PRD]
EOF
)" \
--external-ref="prd:./tasks/feature-name-prd.md"
# Create child bead (with quality gates in acceptance criteria)
br create \
--parent=EPIC_ID \
--title="[Story Title]" \
--description="$(cat <<'EOF'
[Story description with acceptance criteria INCLUDING quality gates]
EOF
)" \
--priority=[1-4]
CRITICAL: Always use
<<'EOF'(single-quoted) for the HEREDOC delimiter. This prevents shell interpretation of backticks,$variables, and()in descriptions.
Story Size: The #1 Rule
Each story must be completable in ONE ralph-tui iteration (~one agent context window).
ralph-tui spawns a fresh agent instance per iteration with no memory of previous work. If a story is too big, the agent runs out of context before finishing.
Right-sized stories:
- Add a database column + migration
- Add a UI component to an existing page
- Update a server action with new logic
- Add a filter dropdown to a list
Too big (split these):
- "Build the entire dashboard" → Split into: schema, queries, UI components, filters
- "Add authentication" → Split into: schema, middleware, login UI, session handling
- "Refactor the API" → Split into one story per endpoint or pattern
Rule of thumb: If you can't describe the change in 2-3 sentences, it's too big.
Story Ordering: Dependencies First
Stories execute in dependency order. Earlier stories must not depend on later ones.
Correct order:
- Schema/database changes (migrations)
- Server actions / backend logic
- UI components that use the backend
- Dashboard/summary views that aggregate data
Wrong order:
- ❌ UI component (depends on schema that doesn't exist yet)
- ❌ Schema change
Dependencies with br dep add
Use the br dep add command to specify which beads must complete first:
# Create the beads first
br create --parent=epic-123 --title="US-001: Add schema" ...
br create --parent=epic-123 --title="US-002: Create API" ...
br create --parent=epic-123 --title="US-003: Build UI" ...
# Then add dependencies (issue depends-on blocker)
br dep add ralph-tui-002 ralph-tui-001 # US-002 depends on US-001
br dep add ralph-tui-003 ralph-tui-002 # US-003 depends on US-002
Syntax: br dep add <issue> <depends-on> — the issue depends on (is blocked by) depends-on.
ralph-tui will:
- Show blocked beads as "blocked" until dependencies complete
- Never select a bead for execution while its dependencies are open
- Include dependency context in the prompt when working on a bead
Correct dependency order:
- Schema/database changes (no dependencies)
- Backend logic (depends on schema)
- UI components (depends on backend)
- Integration/polish (depends on UI)
Acceptance Criteria: Quality Gates + Story-Specific
Each bead's description should include acceptance criteria with:
- Story-specific criteria from the PRD (what this story accomplishes)
- Quality gates from the PRD's Quality Gates section (appended at the end)
Good criteria (verifiable):
- "Add
investorTypecolumn to investor table with default 'cold'" - "Filter dropdown has options: All, Cold, Friend"
- "Clicking toggle shows confirmation dialog"
Bad criteria (vague):
- ❌ "Works correctly"
- ❌ "User can do X easily"
- ❌ "Good UX"
- ❌ "Handles edge cases"
Conversion Rules
- Extract Quality Gates from PRD first
- Each user story → one bead
- First story: No dependencies (creates foundation)
- Subsequent stories: Depend on their predecessors (UI depends on backend, etc.)
- Priority: Based on dependency order, then document order (0=critical, 2=medium, 4=backlog)
- All stories:
status: "open" - Acceptance criteria: Story criteria + quality gates appended
- UI stories: Also append UI-specific gates (browser verification)
Splitting Large PRDs
If a PRD has big features, split them:
Original:
"Add friends outreach track with different messaging"
Split into:
- US-001: Add investorType field to database
- US-002: Add type toggle to investor list UI
- US-003: Create friend-specific phase progression logic
- US-004: Create friend message templates
- US-005: Wire up task generation for friends
- US-006: Add filter by type
- US-007: Update new investor form
- US-008: Update dashboard counts
Each is one focused change that can be completed and verified independently.
Example
Input PRD:
# PRD: Friends Outreach
Add ability to mark investors as "friends" for warm outreach.
## Quality Gates
These commands must pass for every user story:
- `pnpm typecheck` - Type checking
- `pnpm lint` - Linting
For UI stories, also include:
- Verify in browser using dev-browser skill
## User Stories
### US-001: Add investorType field to investor table
**Description:** As a developer, I need to categorize investors as 'cold' or 'friend'.
**Acceptance Criteria:**
- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
- [ ] Generate and run migration successfully
### US-002: Add type toggle to investor list rows
**Description:** As Ryan, I want to toggle investor type directly from the list.
**Acceptance Criteria:**
- [ ] Each row has Cold | Friend toggle
- [ ] Switching shows confirmation dialog
- [ ] On confirm: updates type in database
### US-003: Filter investors by type
**Description:** As Ryan, I want to filter the list to see just friends or cold.
**Acceptance Criteria:**
- [ ] Filter dropdown: All | Cold | Friend
- [ ] Filter persists in URL params
Output beads:
# Create epic (link back to source PRD)
br create --type=epic \
--title="Friends Outreach Track" \
--description="$(cat <<'EOF'
Warm outreach for deck feedback
EOF
)" \
--external-ref="prd:./tasks/friends-outreach-prd.md"
# US-001: No deps (first - creates schema)
br create --parent=ralph-tui-abc \
--title="US-001: Add investorType field to investor table" \
--description="$(cat <<'EOF'
As a developer, I need to categorize investors as 'cold' or 'friend'.
## Acceptance Criteria
- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
- [ ] Generate and run migration successfully
- [ ] pnpm typecheck passes
- [ ] pnpm lint passes
EOF
)" \
--priority=1
# US-002: UI story (gets browser verification too)
br create --parent=ralph-tui-abc \
--title="US-002: Add type toggle to investor list rows" \
--description="$(cat <<'EOF'
As Ryan, I want to toggle investor type directly from the list.
## Acceptance Criteria
- [ ] Each row has Cold | Friend toggle
- [ ] Switching shows confirmation dialog
- [ ] On confirm: updates type in database
- [ ] pnpm typecheck passes
- [ ] pnpm lint passes
- [ ] Verify in browser using dev-browser skill
EOF
)" \
--priority=2
# Add dependency: US-002 depends on US-001
br dep add ralph-tui-002 ralph-tui-001
# US-003: UI story
br create --parent=ralph-tui-abc \
--title="US-003: Filter investors by type" \
--description="$(cat <<'EOF'
As Ryan, I want to filter the list to see just friends or cold.
## Acceptance Criteria
- [ ] Filter dropdown: All | Cold | Friend
- [ ] Filter persists in URL params
- [ ] pnpm typecheck passes
- [ ] pnpm lint passes
- [ ] Verify in browser using dev-browser skill
EOF
)" \
--priority=3
# Add dependency: US-003 depends on US-002
br dep add ralph-tui-003 ralph-tui-002
Syncing Changes
After creating beads, sync to export to JSONL (for git tracking):
br sync --flush-only
This exports the SQLite database to .beads/issues.jsonl for version control.
Output Location
Beads are stored in: .beads/ directory (SQLite DB + JSONL export)
After creation, run ralph-tui:
# Work on a specific epic
ralph-tui run --tracker beads-rust --epic ralph-tui-abc
# Or let it pick the best task automatically
ralph-tui run --tracker beads-rust
ralph-tui will:
- Work on beads within the specified epic (or select the best available task)
- Close each bead when complete
- Close the epic when all children are done
- Output
<promise>COMPLETE</promise>when epic is done
Checklist Before Creating Beads
- [ ] Extracted Quality Gates from PRD (or asked user if missing)
- [ ] Each story is completable in one iteration (small enough)
- [ ] Stories are ordered by dependency (schema → backend → UI)
- [ ] Quality gates appended to every bead's acceptance criteria
- [ ] UI stories have browser verification (if specified in Quality Gates)
- [ ] Acceptance criteria are verifiable (not vague)
- [ ] No story depends on a later story (only earlier stories)
- [ ] Dependencies added with
br dep addafter creating beads - [ ] Ran
br sync --flush-onlyto export for git tracking
Differences from beads (Go version)
| Command | beads (bd) |
beads-rust (br) |
|---|---|---|
| Create | bd create |
br create |
| Dependencies | bd dep add |
br dep add |
| Sync | bd sync |
br sync --flush-only |
| Close | bd close |
br close |
| Storage | .beads/beads.jsonl |
.beads/*.db + JSONL export |