Stats
Actions
Tags
From rite
Automates the complete Issue-to-PR lifecycle: create new Issues, start working on Issues, create branches, implement changes, run quality checks, and manage PRs — all through a single workflow. Essential for any /rite: command, workflow questions, or when working with Issues, branches, commits, or PRs. Activates on "create issue", "new issue", "起票", "Issue を作成", "タスクを登録", "Issue 化", "新規 Issue", "start issue", "create PR", "next steps", "workflow", "rite", "Issue作業", "ブランチ", "コミット規約", "PR作成", "作業開始", "ワークフロー", "次のステップ". Use for workflow state detection, phase transitions, and command suggestions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rite:rite-workflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill provides context for rite workflow operations.
This skill provides context for rite workflow operations.
When activated, this skill provides:
Workflow Awareness
Command Guidance
Best Practices
Coding Principles
Common Principles
Comment Best Practices
rite workflow の identity は「定義された step を全て実行し、生成物の品質を担保する」ことである。時間的制約や context 残量を理由にした step の省略は禁止。残量の推論も禁止。context が実際に枯渇した場合の正規経路は /clear + /rite:resume の組合せであり、LLM が自己判断でワークフローを短縮する経路は存在しない。
さらに、workflow は途中で止まらない。そして最後のわけのわからない出力で終わらない。 sub-skill の return tag ([lint:*] / [pr:created:N] / [review:*] / [fix:*] / [ready:returned-to-caller]) は turn 境界ではなく継続トリガ である。ユーザー介入 (continue 入力) を要求せずに、同 turn 内で次 phase へ進む。
create.md の flat workflow 終端で出力される [create:returned-to-caller:{N}] HTML コメント marker は、他 sub-skill の return tag と異なり create.md 内で完結する terminal sentinel である (create は orchestrator から sub-skill として呼ばれず、継続すべき caller skill を持たない)。:returned-to-caller という命名は terminal vocabulary (:completed) が LLM の turn-boundary heuristic を誤発火させるのを避けるための全 producer 統一形式であり、create に caller skill が存在することを意味しない (hook / grep 契約のため必須)。ワークフロー完了時の user-visible な最終行は sentinel marker ではなく「✅ Issue #{N} を作成しました: {url}」のような人間可読な完了メッセージとし、sentinel は HTML コメント化等で user-visible な末端に孤立させない。
Sentinel naming policy: skill return signal の literal は
:returned-to-caller形式で統一する。旧:completed形式は LLM の turn-boundary heuristic と衝突し、caller skill の次 step を skip して turn が暗黙終了する事象を構造的に誘発する (実測ベース)。新形式は「caller に return した = caller の次 step に進む」という semantic に置換することで terminal vocabulary を構造的に排除する。各 emit site では sentinel 直前に<!-- skill return signal: caller must continue next step -->を併記して active disambiguation を提供する。
| 禁止事項 | 正規経路 |
|---|---|
| 「時間が足りないので X を省略します」 | 手順どおり実行 |
| 「context が圧迫しているので要約します」 | 手順どおり実行 |
| 「残量が不安なので review を切り上げます」 | /clear + /rite:resume をユーザーに案内 |
| return tag 直後に turn を閉じる | 同 turn 内で次 phase に継続。途中で止まった場合の正規復帰経路は /rite:resume (commands/resume.md Phase 5.3 (Phase enum → Step mapping (SoT)) の phase→step 表に従う) |
sentinel marker [create:returned-to-caller:{N}] を user-visible な最終行として残す | HTML コメント <!-- [create:returned-to-caller:{N}] --> として末尾に配置し、user-visible な最終行は ✅ ... 完了メッセージにする |
詳細と Anti-pattern / Correct Pattern は references/workflow-identity.md を参照。各 command (start / review / fix / ready / lint / cleanup / create / resume 等) からも同 reference を引いている。
3 step 以上の sequential workflow を実行する際は、以下の手順で TaskCreate / TaskUpdate / TaskList を使って進捗を能動追跡する。ここで「最外側 skill」とは TaskCreate を発行する skill (= ユーザーが invoke した最上位の skill) を指し、それ以外の skill (最外側から Skill ツール経由で呼ばれた skill) を「nested sub-skill」と呼ぶ。閾値を「3 step 以上」とするのは、2 step 以下の skill は単一 turn 内で逐次実行する想定で TaskList 管理の overhead が利点を上回らないため。代表例: pr:cleanup, pr:iterate, pr:open, pr:review, pr:fix, wiki:ingest, wiki:lint (列挙は例示で完全網羅ではない)。
TaskCreate でステップ列を全件登録する。nested sub-skill は既存 TaskList に対し下記 各 step 完了時 ルールと nested sub-skill の return 時点 ルールのみ適用する (二重 TaskCreate 禁止)。TaskUpdate で当該 step の status を completed に更新する。TaskList で未完了タスクの有無を確認する。未完了タスクが残っている場合は、未実行の最初の step に戻って実行を継続する (turn を終了しない)。全タスクが completed の場合のみ turn を終了する。wiki:ingest から呼ばれた wiki:lint) の return 時点: TaskUpdate のみ行い、turn 終了の判断は最外側 skill に委ねる。これにより skill ネスト時 (例: pr:cleanup → wiki:ingest → wiki:lint) の最内側 sentinel を turn 終了と誤認する事故を防ぐ。
Detect current state from:
{type}/issue-{number}-*
{type} values: feat, fix, docs, refactor, chore, style, teststyle is used for code style/formatting changes (no logic changes)| State | Suggestion |
|---|---|
| On main/develop, no Issue | /rite:issue:create or /rite:issue:list |
| Have an Issue, want to start work | /rite:pr:open <issue> (Issue → branch → 実装 → lint → draft PR を一気通貫) |
| On feature branch, PR open / draft, review-fix cycle | /rite:pr:iterate <pr> (mergeable まで review ⇄ fix を無限ループ) |
| Review mergeable, want to mark Ready | /rite:pr:ready <pr> then /rite:pr:merge <pr> |
| Merge 完了、branch 削除 / Wiki ingest / Projects Status Done 後処理が必要 | /rite:pr:cleanup <pr> |
| 複数 Issue を draft PR まで一括自律実行したい | /rite:pr:run <issue>... (各 Issue に open→iterate を順次実行し draft 止まり、失敗で即停止)。merge→cleanup まで完走するなら /rite:pr:run --merge <issue>... |
| Long session (30+ minutes elapsed) | /rite:issue:update |
Key Principle: Always apply
question_self_check(see references/common-principles.md) before asking questions. Most questions can be avoided through context inference and using sensible defaults.
Ask immediately (do not defer) when:
If questions arise during work, record them in the work memory comment under "要確認事項" (Items to Confirm):
### 要確認事項
1. [ ] {confirmation_item_1}
2. [ ] {confirmation_item_2}
Target: Minimize questions through context inference and sensible defaults. Issue Start: 0-1 (score C/D only), Implementation: 0, PR Review: 0-1 (critical decisions only). Record non-blocking questions in work memory.
See references/common-principles.md for detailed frequency table by phase.
Automatically detect work state at session start and notify if interrupted work exists.
See references/session-detection.md for details.
{type}/issue-{number}-* pattern)See references/phase-mapping.md for phase list.
See references/work-memory-format.md for work memory format.
/rite:issue:start は廃止され、4 つの単機能コマンド に分解されている (詳細は CHANGELOG 参照):
| コマンド | 責務 | 区分 |
|---|---|---|
/rite:pr:open <issue> | Issue → branch → 実装 → lint → draft PR (Step 0 Resume Dispatch 含む) | orchestrator |
/rite:pr:iterate <pr> | review ↔ fix を [review:mergeable] まで無限ループ (cycle counter なし、abort は Ctrl+C のみ) | orchestrator |
/rite:pr:ready <pr> | Ready 化 + Projects Status + 親判定 + 完了レポート | self-contained command |
/rite:pr:merge <pr> | gh pr merge --squash を叩くだけ (cleanup は分離) | self-contained command |
/rite:issue:create は引き続き flat single-file workflow を維持。マージ後の cleanup は /rite:pr:cleanup (既存) を別途実行する。
複数 Issue をまとめて回す場合は /rite:pr:run <issue>... が各 Issue に対し デフォルトでは pr:open → pr:iterate を順次・完全自律で実行して draft PR を残し (merge せずレビュー待ち)、--merge 指定時のみ pr:ready → pr:merge → pr:cleanup まで完走する (meta-orchestrator。成功する限り無確認、失敗で即停止、残りキューとモードは .rite/state/run-queue.json に永続化)。flow-state の handoff は使わず、継続は flat step 構造に委ねる。
LLM が途中で停止した場合の正規復帰経路は /rite:resume で、commands/resume.md Phase 5.3 (Phase enum → Step mapping (SoT)) の phase→新 4 コマンド routing 表に従う。implicit-stop 対策の hook 群 (auto-fire-step0.sh / stop-create-interview-block.sh / verify-terminal-output.sh) は撤去済み。
| sub-skill | emit する sentinel | invoke 元 |
|---|---|---|
rite:issue:implement | (現状 sentinel 未発火 — 完了は work memory / flow-state 側で確認する設計) | pr:open Step 4 |
rite:lint | [lint:success] / [lint:skipped] / [lint:error] / [lint:aborted] | implement 内で autonomous invoke、pr:open Step 5 が結果を読む |
rite:pr:create | [pr:created:N] / [pr:create-failed] | pr:open Step 6 |
rite:pr:review | [review:mergeable] / [review:fix-needed:N] / [review:error] | pr:iterate 内ループ |
rite:pr:fix | [fix:pushed] / [fix:pushed-wm-stale] / [fix:replied-only] / [fix:cancelled-by-user] / [fix:error] | pr:iterate 内ループ |
rite:pr:ready | [ready:returned-to-caller] / [ready:error] | ユーザー直接 / pr:run orchestrator |
rite:pr:merge | [merge:returned-to-caller] / [merge:not-ready] / [merge:error] | ユーザー直接 / pr:run orchestrator |
rite:pr:cleanup | [cleanup:returned-to-caller] | ユーザー直接 / pr:run orchestrator |
orchestrator (pr:open / pr:iterate) が sub-skill 出力の sentinel を grep で routing する。pr:ready / pr:merge / pr:cleanup は self-contained だが、pr:run (meta-orchestrator) が各 Issue に対しデフォルトでは pr:open → pr:iterate を、--merge 指定時のみ続けて pr:ready → pr:merge → pr:cleanup を順に invoke し、それぞれの sentinel を grep して次段へ進む (失敗で即停止)。pr:run は flow-state の handoff を使わず、継続は flat step 構造に委ねる。
現行の continuation enforcement は Layer 3 caller-continuation hints + Layer 4a/4b orchestrator-side reinforcements + flat sequential structure による (旧 Layer 1 prompt contract は cleanup.md flat 化と同時に物理排除済)。
Avoid common AI coding failure patterns: surface assumptions, manage confusion, push back when warranted, enforce simplicity, maintain scope discipline, clean dead code, plan inline, address all discovered issues, and keep documentation in sync with specification changes (documentation_consistency) — when the implementation changes user-visible behavior, update related README / docs / CLAUDE.md / plugin .md files in the same PR rather than deferring to a follow-up Issue. Route each kind of knowledge to its durable medium (knowledge_routing): How → code, What → tests, Why → commit log, Why not → code comments.
See references/coding-principles.md for the full principle list and details.
Canon TDD in the implementation phase: When tdd.enabled: true (default, opt-out) in rite-config.yml, rite:issue:implement drives a Canon TDD cycle — build a test list (seeded from the Issue's Section 6 Test Specification), then for each behavior: write a test → confirm it fails (Red) → minimal implementation (Green) → Refactor → repeat until the list is empty. The cycle is defined in ../../commands/issue/implement.md § 5.0.T. It degrades to test-list discipline only (Red/Green runs skipped) when commands.test is unset, and is skipped entirely when tdd.enabled: false. Config schema: docs/CONFIGURATION.md ### tdd.
plugins/rite/ 配下のファイルを編集する LLM・メンテナ、および rite workflow が生成する commit message / Issue body / PR description / review 指摘は、自己生成的に肥大化しないよう Simplification Charter に従う。runtime に効かない経緯記述は書かない / git log で代替できるものはコードに書かない / Issue # / PR # / cycle # の本文引用は禁止 / 重複 confirmation 禁止。
特に commands/pr/cleanup.md および commands/pr/references/ 配下のファイル群（pr/cleanup 系）は本 charter の主要適用対象であり、各ファイル冒頭に charter SoT 参照行を持つ。
See references/simplification-charter.md for the 5 self-questions (5 つの自問) / prohibited patterns (禁止パターン) / recommended patterns (推奨パターン).
Reduce excessive questions: self-check necessity, use defaults when available, infer from context.
See references/common-principles.md for details.
Before executing any /rite:* command, run the preflight guard. Resolve {plugin_root} per references/plugin-path-resolution.md.
bash {plugin_root}/hooks/preflight-check.sh --command-id "{current_command_id}" --cwd "$(pwd)"
Replace {current_command_id} with the slash command being executed (e.g., /rite:lint, /rite:pr:review).
If exit code is 1 (blocked), stop execution and display the preflight output. Do NOT proceed.
All gh commands that accept --body or --comment parameters MUST use safe patterns to avoid shell injection:
--body-file with mktemp for multi-line contentreferences/gh-cli-patterns.md for detailed safe patternsNever pass user-generated content directly via --body or --comment flags.
When a step of /rite:pr:open / /rite:pr:iterate / /rite:pr:ready / /rite:pr:merge fails or is skipped (Skill load failure, hook abnormal exit, Wiki ingest skip/failure, etc.), the affected skill or hook emits a plain WARNING / ERROR line to stderr. The orchestrator surfaces it in the conversation context, and the user re-runs the affected step via /rite:resume. Failures are visible but not auto-registered as Issues; the user decides whether to file one.
The earlier auto-registration mechanism (
workflow-incident-emit.shsentinel +/rite:issue:startdetection +workflow_incident:config key) was removed in favor of this single-layer plain-stderr design. Seedocs/SPEC.md"Workflow Failure Surfacing" for details.
This skill works with:
/rite:* commandsnpx claudepluginhub asakaguchi/cc-rite-workflow --plugin riteGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.