repo-harness 0.4.3 → 0.5.1

package/README.es.md

@@ -1,17 +1,26 @@
 # repo-harness
 
-Repo-local agentic development harness CLI y skill runtime para workflows de
-Claude/Codex.
+`repo-harness` convierte las sesiones de programación con Claude/Codex en un
+workflow repo-local repetible. Incluye un CLI y hooks de skill/runtime que
+escriben contexto, planes, handoffs, checks y evidencias de review dentro del
+proyecto, para que la siguiente sesión de agente continúe desde archivos y no
+desde el historial de chat.
+
+Úsalo para:
+
+- adoptar un repositorio existente con un contrato de agente tasks-first
+- mantener Claude y Codex alineados sobre los mismos planes, checks, handoffs y
+  límites de contexto
+- gastar menos tokens redescubriendo estructura gracias a CodeGraph y la carga
+  progresiva de contexto
+
+Entrega al agente un PRD o Sprint completo; después, tu bucle es solo review and
+`next`, o iniciar `/goal` y quedar AFK.
 
 [English](README.md) | [简体中文](README.zh-CN.md) | [日本語](README.ja.md) | [Français](README.fr.md) | [Español](README.es.md)
 
 Dirección del repositorio: `https://github.com/Ancienttwo/repo-harness`
 
-`repo-harness` es un harness de workflow que aterriza el proceso de programación
-con IA en archivos del repositorio. Es a la vez el repositorio fuente de la CLI
-`repo-harness` y de su skill runtime, y el ejemplo autoalojado del workflow
-repo-local que él mismo genera para los proyectos downstream.
-
 ## Por qué usar repo-harness
 
 - **El estado de la sesión vive en archivos, no en el historial de chat.** Las
@@ -42,7 +51,7 @@ repo-local que él mismo genera para los proyectos downstream.
   opcionales según el tipo de proyecto y cuatro hook profiles (`standard`,
   `minimal`, `biome`, `biome-strict`). Ejecuta
   `npx -y repo-harness init`; no necesitas clonar el repositorio fuente.
-- **Comando de refresco del repo (`repo-harness update`).** La instalación y el
+- **Comando de adopción del repo (`repo-harness adopt`).** La instalación y el
   refresco de repos existentes tienen su propia superficie de comando, manteniendo
   la ruta de migración repo-local anterior mientras `init` queda dedicado al
   runtime global.
@@ -100,7 +109,7 @@ En conjunto hay tres capas:
 1. **Capa del paquete fuente**: este repositorio mantiene la CLI, los command
    skill facades, los templates, los hook assets, el workflow contract, los tests
    y el release gate.
-2. **Capa del contract del repositorio objetivo**: `repo-harness update` o la
+2. **Capa del contract del repositorio objetivo**: `repo-harness adopt` o la
    migración escribe `docs/spec.md`, `plans/`, `tasks/`, `.ai/context/`,
    `.ai/harness/`, helper scripts y `.ai/hooks/`.
 3. **Capa del host adapter**: el `~/.claude/settings.json` y el
@@ -200,15 +209,41 @@ retoma contra un sprint concreto en vez de reinterpretar el chat original.
 Esta es la ruta más rápida para evaluar si un repositorio real es apto para
 adoptar este workflow.
 
-### Instalar o refrescar el runtime local
+### Instalar el CLI
+
+La ruta por defecto no requiere Node.js: el instalador usa Bun como runtime. Si
+Bun no existe, instala Bun primero y después instala el CLI `repo-harness`.
+
+```bash
+# macOS / Linux
+curl -fsSL https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.sh | sh
+
+# Windows (PowerShell)
+irm https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.ps1 | iex
+```
+
+<details>
+<summary>¿Ya tienes Bun o Node? Usa gestores de paquetes</summary>
 
 ```bash
+# Bun
+bun add -g repo-harness
+repo-harness init
+
+# Node/npm, con Bun ya en PATH porque el CLI corre sobre Bun
 npx -y repo-harness init
 ```
 
-La npm package release line y el generated workflow stamp usan ahora la misma
-línea `0.4.x`. `repo-harness init` es el bootstrap
-global y `repo-harness update` es el refresco repo-local. `repo-harness init`
+</details>
+
+### Bootstrap del runtime del host
+
+```bash
+repo-harness init
+```
+
+`repo-harness init` es el bootstrap global, `repo-harness update` es el refresco
+user-level y `repo-harness adopt` es el refresco repo-local. `repo-harness init`
 configura el CLI, los hook adapters de nivel usuario, Waza, Mermaid, el brain
 root y CodeGraph MCP; el viejo camino Claude plugin `scripts/setup-plugins.sh`
 queda retirado.
@@ -245,17 +280,17 @@ elimina `scripts/sync-codex-installed-copies.sh`.
 En un repositorio existente, ejecuta desde el repo root:
 
 ```bash
-npx -y repo-harness update --dry-run
+npx -y repo-harness adopt --dry-run
 ```
 
 Aplica solo después de que el reporte del dry-run sea correcto:
 
 ```bash
-npx -y repo-harness update
+npx -y repo-harness adopt
 ```
 
 Para un proyecto o módulo nuevo, usa la branch command `repo-harness-scaffold`.
-Para un repositorio existente, usa `repo-harness update`; este instala o refresca
+Para un repositorio existente, usa `repo-harness adopt`; este instala o refresca
 el harness y no crea el stack tecnológico de la aplicación.
 
 ### Cómo se ve el éxito
@@ -345,8 +380,8 @@ Guards habituales:
 
 ## Release actual
 
-- npm package: `repo-harness@0.4.3`
-- Generated workflow stamp: `repo-harness@0.4.3+template@0.4.3`
+- npm package: `repo-harness@0.5.1`
+- Generated workflow stamp: `repo-harness@0.5.1+template@0.5.1`
 - GitHub repository: `Ancienttwo/repo-harness`
 - Release history: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -360,7 +395,7 @@ Guards habituales:
   - `assets/workflow-contract.v1.json`
 - Los generated repos usan por defecto el repo-local harness flow:
   - `docs/spec.md -> plans/ -> tasks/contracts/ -> tasks/reviews/ -> .ai/context/context-map.json -> .ai/harness/*`
-- `repo-harness update` refresca las runtime pieces:
+- `repo-harness update` refresca las runtime pieces de usuario:
   - los `repo-harness` skill aliases
   - los global Codex/Claude hook adapters
   - las Waza skills: `think`, `hunt`, `check`, `health`
@@ -390,10 +425,29 @@ Los command facades públicos están en `assets/skill-commands/`; preservan la
 compatibilidad de discovery por skills, mientras el CLI y los hooks ejecutan:
 
 - Planning / review: `repo-harness-plan`, `repo-harness-review`, `repo-harness-autoplan`
+- Product planning layer: `repo-harness-prd` (activa `$geju`, luego usa drafting Claude-first con `claude -p --model opus`; Codex queda solo como fallback)
+- Sprint program layer: `repo-harness-sprint` (convierte un PRD en un backlog ordenado bajo `plans/sprints/`)
+- Goal session layer: `repo-harness-goal` / `repo-harness:goal` (prepara prompts `/goal` de Codex/Claude desde un PRD o Sprint detallado; si falta el documento, lo pide primero)
 - Repo workflow actions: `repo-harness-ship`, `repo-harness-init`, `repo-harness-migrate`, `repo-harness-upgrade`, `repo-harness-capability`, `repo-harness-architecture`, `repo-harness-handoff`, `repo-harness-deploy`, `repo-harness-repair`, `repo-harness-check`
 - Branch project creation: `repo-harness-scaffold`
 
-`repo-harness update` se usa para repositorios existentes; `repo-harness-scaffold`
+La cadena de planning está separada por capas:
+
+```text
+idea -> repo-harness-prd -> repo-harness-sprint from-prd -> repo-harness-goal
+```
+
+Usa `repo-harness-prd` cuando la fuente todavía es una idea de producto: primero
+ejecuta un direction pass con `$geju`, luego pide a Claude vía `claude -p --model opus` que
+redacte el PRD, con Codex solo como fallback. Usa
+`repo-harness-sprint from-prd <plans/prds/*.prd.md>` para convertir un PRD
+aprobado en un Sprint backlog ordenado con acceptance lines verificables por
+máquina. Usa `repo-harness-goal` solo cuando ya exista un PRD o Sprint detallado;
+prepara un prompt `/goal` acotado para Codex/Claude y mantiene el PRD/Sprint como
+source of truth. Si falta ese documento, el goal command debe pedirlo antes de
+empezar implementación desde el chat.
+
+`repo-harness adopt` se usa para repositorios existentes; `repo-harness-scaffold`
 queda como branch command para crear proyectos o módulos nuevos. `hooks-init`, `docs-init` y
 `create-project-dirs` son pasos internos, no commands públicos.
 

package/README.fr.md

@@ -1,17 +1,26 @@
 # repo-harness
 
-Harness CLI de développement agentique repo-local et skill runtime pour les
-workflows Claude/Codex.
+`repo-harness` transforme les sessions de code Claude/Codex en workflow
+repo-local répétable. Il fournit un CLI et des hooks skill/runtime qui écrivent
+le contexte, les plans, les handoffs, les checks et les preuves de review dans le
+projet, afin que la session d'agent suivante reprenne depuis les fichiers plutôt
+que depuis l'historique de chat.
+
+Utilisez-le pour :
+
+- adopter un dépôt existant avec un contrat d'agent tasks-first
+- garder Claude et Codex alignés sur les mêmes plans, checks, handoffs et limites
+  de contexte
+- dépenser moins de tokens à redécouvrir la structure grâce à CodeGraph et au
+  chargement progressif du contexte
+
+Donnez à l'agent un PRD ou Sprint complet ; ensuite, votre boucle se limite à
+review and `next`, ou à lancer `/goal` puis passer AFK.
 
 [English](README.md) | [简体中文](README.zh-CN.md) | [日本語](README.ja.md) | [Français](README.fr.md) | [Español](README.es.md)
 
 Adresse du dépôt : `https://github.com/Ancienttwo/repo-harness`
 
-`repo-harness` est un harness de workflow qui matérialise le processus de
-programmation par IA dans les fichiers du dépôt. C'est à la fois le dépôt source
-du CLI `repo-harness` et de son skill runtime, et un exemple auto-hébergé du
-workflow repo-local qu'il génère lui-même pour les projets en aval.
-
 ## Pourquoi utiliser repo-harness
 
 - **L'état de session vit dans les fichiers, pas dans l'historique de chat.** Des
@@ -42,7 +51,7 @@ workflow repo-local qu'il génère lui-même pour les projets en aval.
   optionnels selon le type de projet, et quatre hook profiles (`standard`,
   `minimal`, `biome`, `biome-strict`). Exécutez
   `npx -y repo-harness init` ; aucun clone du dépôt source n'est nécessaire.
-- **Commande de rafraîchissement du dépôt (`repo-harness update`).** L'installation
+- **Commande d'adoption du dépôt (`repo-harness adopt`).** L'installation
   et le rafraîchissement des dépôts existants ont leur propre surface de commande,
   tout en conservant l'ancien chemin de migration repo-local et en gardant `init`
   dédié au runtime global.
@@ -102,7 +111,7 @@ L'ensemble se découpe en trois couches :
 1. **Couche package source** : ce dépôt maintient le CLI, les command skill
    facades, les templates, les hook assets, le workflow contract, les tests et le
    release gate.
-2. **Couche contrat du dépôt cible** : `repo-harness update` ou une migration écrit
+2. **Couche contrat du dépôt cible** : `repo-harness adopt` ou une migration écrit
    `docs/spec.md`, `plans/`, `tasks/`, `.ai/context/`, `.ai/harness/`, les helper
    scripts et `.ai/hooks/`.
 3. **Couche host adapter** : les `~/.claude/settings.json` et `~/.codex/hooks.json`
@@ -205,15 +214,42 @@ initial.
 C'est le chemin le plus rapide pour évaluer si un dépôt réel se prête à l'adoption
 de ce workflow.
 
-### Installer ou rafraîchir le runtime local
+### Installer le CLI
+
+Le chemin par défaut ne demande pas Node.js : l'installateur utilise Bun comme
+runtime. Si Bun est absent, il installe Bun d'abord, puis installe le CLI
+`repo-harness`.
+
+```bash
+# macOS / Linux
+curl -fsSL https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.sh | sh
+
+# Windows (PowerShell)
+irm https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.ps1 | iex
+```
+
+<details>
+<summary>Vous avez déjà Bun ou Node ? Utilisez les gestionnaires de packages</summary>
 
 ```bash
+# Bun
+bun add -g repo-harness
+repo-harness init
+
+# Node/npm, avec Bun déjà sur PATH car le CLI s'exécute sur Bun
 npx -y repo-harness init
 ```
 
-La release line du package npm et le generated workflow stamp utilisent
-désormais la même ligne `0.4.x`. `repo-harness init`
-sert au bootstrap global et `repo-harness update` sert au rafraîchissement
+</details>
+
+### Bootstrap du runtime hôte
+
+```bash
+repo-harness init
+```
+
+`repo-harness init` sert au bootstrap global, `repo-harness update` au
+rafraîchissement user-level, et `repo-harness adopt` au rafraîchissement
 repo-local. `repo-harness init` configure le CLI, les hook adapters de niveau
 utilisateur, Waza, Mermaid, le brain root et CodeGraph MCP ; l'ancien chemin
 Claude plugin `scripts/setup-plugins.sh` est retiré.
@@ -250,17 +286,17 @@ sont supprimés par `scripts/sync-codex-installed-copies.sh`.
 Pour un dépôt existant, exécutez depuis le repo root :
 
 ```bash
-npx -y repo-harness update --dry-run
+npx -y repo-harness adopt --dry-run
 ```
 
 Appliquez seulement une fois que le rapport du dry-run est correct :
 
 ```bash
-npx -y repo-harness update
+npx -y repo-harness adopt
 ```
 
 Pour un nouveau projet ou un nouveau module, utilisez la branch command
-`repo-harness-scaffold`. Pour un dépôt existant, utilisez `repo-harness update` ;
+`repo-harness-scaffold`. Pour un dépôt existant, utilisez `repo-harness adopt` ;
 il installe ou rafraîchit le harness sans créer de stack applicatif.
 
 ### À quoi ressemble le succès
@@ -350,8 +386,8 @@ Guards courants :
 
 ## Release actuelle
 
-- npm package : `repo-harness@0.4.3`
-- Generated workflow stamp : `repo-harness@0.4.3+template@0.4.3`
+- npm package : `repo-harness@0.5.1`
+- Generated workflow stamp : `repo-harness@0.5.1+template@0.5.1`
 - GitHub repository : `Ancienttwo/repo-harness`
 - Release history : [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -365,7 +401,7 @@ Guards courants :
   - `assets/workflow-contract.v1.json`
 - Les generated repos utilisent par défaut le repo-local harness flow :
   - `docs/spec.md -> plans/ -> tasks/contracts/ -> tasks/reviews/ -> .ai/context/context-map.json -> .ai/harness/*`
-- `repo-harness update` rafraîchit les runtime pieces :
+- `repo-harness update` rafraîchit les runtime pieces utilisateur :
   - les `repo-harness` skill aliases
   - les global Codex/Claude hook adapters
   - les Waza skills : `think`, `hunt`, `check`, `health`
@@ -396,10 +432,29 @@ préservent la découverte par skills, tandis que l'exécution appartient au CLI
 aux hooks :
 
 - Planning / review : `repo-harness-plan`, `repo-harness-review`, `repo-harness-autoplan`
+- Product planning layer : `repo-harness-prd` (active `$geju`, puis rédige en Claude-first avec `claude -p --model opus` ; Codex ne sert que de fallback)
+- Sprint program layer : `repo-harness-sprint` (transforme un PRD en backlog ordonné dans `plans/sprints/`)
+- Goal session layer : `repo-harness-goal` / `repo-harness:goal` (prépare des prompts `/goal` Codex/Claude depuis un PRD ou Sprint détaillé ; si le document manque, il le demande d'abord)
 - Repo workflow actions : `repo-harness-ship`, `repo-harness-init`, `repo-harness-migrate`, `repo-harness-upgrade`, `repo-harness-capability`, `repo-harness-architecture`, `repo-harness-handoff`, `repo-harness-deploy`, `repo-harness-repair`, `repo-harness-check`
 - Branch project creation : `repo-harness-scaffold`
 
-`repo-harness update` sert aux dépôts existants ; `repo-harness-scaffold` sert de
+La chaîne de planning est volontairement découpée en couches :
+
+```text
+idea -> repo-harness-prd -> repo-harness-sprint from-prd -> repo-harness-goal
+```
+
+Utilisez `repo-harness-prd` quand la source est encore une idée produit : il
+lance d'abord un direction pass `$geju`, puis demande à Claude via `claude -p --model opus`
+de rédiger le PRD, avec Codex seulement en fallback. Utilisez
+`repo-harness-sprint from-prd <plans/prds/*.prd.md>` pour transformer
+un PRD approuvé en Sprint backlog ordonné avec des lignes d'acceptance
+vérifiables par machine. Utilisez `repo-harness-goal` seulement lorsqu'un PRD ou
+Sprint détaillé existe déjà ; il prépare un prompt `/goal` borné pour
+Codex/Claude et garde le PRD/Sprint comme source of truth. Si ce document manque,
+le goal command doit le demander avant de lancer une implémentation depuis le chat.
+
+`repo-harness adopt` sert aux dépôts existants ; `repo-harness-scaffold` sert de
 branch command pour créer un nouveau projet ou module. `hooks-init`, `docs-init` et
 `create-project-dirs` sont des étapes internes, pas des commands publiques.
 

package/README.ja.md

@@ -1,16 +1,23 @@
 # repo-harness
 
-Claude/Codex の workflow 向けに、repo-local な agentic development harness の CLI と
-skill runtime を提供します。
+`repo-harness` は、Claude/Codex のコーディング session を、繰り返し使える
+repo-local workflow に変えます。CLI と skill/runtime hooks によって、context、plan、
+handoff、check、review evidence をプロジェクト内のファイルへ書き戻し、次の agent session が
+chat memory ではなくファイルから続きに入れるようにします。
+
+主な用途:
+
+- 既存リポジトリへ tasks-first agent contract を導入する
+- Claude と Codex を同じ plan、check、handoff、context boundary に揃える
+- CodeGraph と段階的な context loading により、構造を再発見するための token 消費を減らす
+
+Agent に完全な PRD または Sprint を渡せば、あとは review and `next` だけで進めるか、
+`/goal` を開始して AFK できます。
 
 [English](README.md) | [简体中文](README.zh-CN.md) | [日本語](README.ja.md) | [Français](README.fr.md) | [Español](README.es.md)
 
 リポジトリ：`https://github.com/Ancienttwo/repo-harness`
 
-`repo-harness` は、AI 開発フローをリポジトリ内のファイルへ落とし込む workflow harness です。
-`repo-harness` CLI と skill runtime のソースリポジトリであると同時に、下流プロジェクト向けに
-自身が生成する repo-local workflow を、自分自身に適用したセルフホスト例でもあります。
-
 ## なぜ repo-harness を使うのか
 
 - **セッションの状態はファイルに残り、チャット履歴には残らない。** 別々の agent
@@ -34,7 +41,7 @@ skill runtime を提供します。
   commit/pending）、プロジェクト種別ごとのオプション LSP plugins、そして 4 段階の hook profile
   （`standard`、`minimal`、`biome`、`biome-strict`）を扱います。
   実行は `npx -y repo-harness init`。source checkout は不要です。
-- **Repo refresh コマンド（`repo-harness update`）。** 既存 repo の install / refresh は
+- **Repo adoption コマンド（`repo-harness adopt`）。** 既存 repo の install / refresh は
   独立した command surface になり、従来の repo-local migration path を保ちながら
   `init` は global runtime setup に集中します。
 - **CodeGraph index の自己修復。** prompt hook が構造的な code-navigation intent を検出し、
@@ -79,7 +86,7 @@ product boundary は意図的に地味です。対象リポジトリを検査し
 
 1. **ソースパッケージ層**：本リポジトリが CLI、CLI-backed command facades、templates、hook assets、
    workflow contract、tests、release gate を所有します。
-2. **対象リポジトリ contract 層**：`repo-harness update` または migration が、`docs/spec.md`、
+2. **対象リポジトリ contract 層**：`repo-harness adopt` または migration が、`docs/spec.md`、
    `plans/`、`tasks/`、`.ai/context/`、`.ai/harness/`、helper scripts、`.ai/hooks/` といった
    repo-local ファイルを書き込みます。
 3. **Host adapter 層**：user-level の `~/.claude/settings.json` と `~/.codex/hooks.json` が
@@ -172,15 +179,41 @@ PRD Sprint が durable source of truth となり、Codex Goal mode は元の cha
 
 実際のリポジトリがこの workflow を導入するのに適しているかを評価する、最速の経路です。
 
-### ローカル runtime をインストールまたはリフレッシュする
+### CLI をインストールする
+
+既定の経路では Node.js は不要です。installer は Bun を runtime として使います。
+Bun が見つからない場合は、先に Bun をインストールしてから `repo-harness` CLI をインストールします。
+
+```bash
+# macOS / Linux
+curl -fsSL https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.sh | sh
+
+# Windows (PowerShell)
+irm https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.ps1 | iex
+```
+
+<details>
+<summary>Bun または Node がすでにある場合は package manager も使えます</summary>
 
 ```bash
+# Bun
+bun add -g repo-harness
+repo-harness init
+
+# Node/npm。CLI runtime は Bun なので、Bun が PATH 上に必要です。
 npx -y repo-harness init
 ```
 
-npm package と generated workflow stamp は現在同じ `0.4.x` release line を使います。
+</details>
+
+### host runtime を bootstrap する
+
+```bash
+repo-harness init
+```
+
 `repo-harness init` は global bootstrap、`repo-harness update` は
-repo-local refresh です。`repo-harness init` は CLI、user-level hook adapters、Waza、Mermaid、
+user-level refresh、`repo-harness adopt` は repo-local refresh です。`repo-harness init` は CLI、user-level hook adapters、Waza、Mermaid、
 brain root、CodeGraph MCP を設定し、退役した `scripts/setup-plugins.sh` の Claude plugin path は使いません。
 
 ソースの checkout から作業する場合：
@@ -214,17 +247,17 @@ symlink に裏打ちされた runtime entrypoint です。退役した `repo-har
 既存リポジトリでは repo root から実行します。
 
 ```bash
-npx -y repo-harness update --dry-run
+npx -y repo-harness adopt --dry-run
 ```
 
 dry-run のレポートが正しいことを確認してから適用します。
 
 ```bash
-npx -y repo-harness update
+npx -y repo-harness adopt
 ```
 
 新しいプロジェクトやモジュールには支線 command `repo-harness-scaffold` を使います。既存リポジトリには
-`repo-harness update` を使います。これは harness をインストールまたはリフレッシュするもので、アプリケーション
+`repo-harness adopt` を使います。これは harness をインストールまたはリフレッシュするもので、アプリケーション
 スタックは作成しません。
 
 ### 成功した状態
@@ -312,8 +345,8 @@ hook がブロックしたときは、まず terminal の構造化された出
 
 ## 現在の Release
 
-- npm package：`repo-harness@0.4.3`
-- Generated workflow stamp：`repo-harness@0.4.3+template@0.4.3`
+- npm package：`repo-harness@0.5.1`
+- Generated workflow stamp：`repo-harness@0.5.1+template@0.5.1`
 - GitHub repository：`Ancienttwo/repo-harness`
 - Release history：[`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -327,7 +360,7 @@ hook がブロックしたときは、まず terminal の構造化された出
   - `assets/workflow-contract.v1.json`
 - Generated repos はデフォルトで repo-local harness flow を使います：
   - `docs/spec.md -> plans/ -> tasks/contracts/ -> tasks/reviews/ -> .ai/context/context-map.json -> .ai/harness/*`
-- `repo-harness update` は runtime pieces をリフレッシュします：
+- `repo-harness update` は user-level runtime pieces をリフレッシュします：
   - `repo-harness` skill aliases
   - global Codex/Claude hook adapters
   - Waza skills：`think`、`hunt`、`check`、`health`
@@ -355,10 +388,29 @@ knowledge sync、handoff retrieval の workflow 設計に影響を与えてい
 公開 command facades は `assets/skill-commands/` にあります。host skill discovery との互換性を残しつつ、実行は CLI と hooks が担います。
 
 - Planning / review：`repo-harness-plan`、`repo-harness-review`、`repo-harness-autoplan`
+- Product planning layer：`repo-harness-prd`（先に `$geju` を有効化し、Claude-first の `claude -p --model opus` で PRD を起草する。Codex は fallback のみ）
+- Sprint program layer：`repo-harness-sprint`（PRD を `plans/sprints/` の順序付き backlog に分解する）
+- Goal session layer：`repo-harness-goal` / `repo-harness:goal`（詳細な PRD または Sprint artifact から Codex/Claude の `/goal` prompt を準備する。文書がなければ先に要求する）
 - Repo workflow actions：`repo-harness-ship`、`repo-harness-init`、`repo-harness-migrate`、`repo-harness-upgrade`、`repo-harness-capability`、`repo-harness-architecture`、`repo-harness-handoff`、`repo-harness-deploy`、`repo-harness-repair`、`repo-harness-check`
 - Branch project creation：`repo-harness-scaffold`
 
-`repo-harness update` は既存リポジトリ向け、`repo-harness-scaffold` は支線 command として新しいプロジェクトやモジュールを作成します。
+planning chain は意図的に層を分けています。
+
+```text
+idea -> repo-harness-prd -> repo-harness-sprint from-prd -> repo-harness-goal
+```
+
+入力がまだプロダクトアイデアなら `repo-harness-prd` を使います。まず `$geju` の
+direction pass を行い、その後 Claude に `claude -p --model opus` で PRD を起草させます。Codex は
+Claude が使えない、または失敗した場合だけ fallback です。承認済み PRD を
+machine-checkable acceptance line 付きの順序付き Sprint backlog にするには
+`repo-harness-sprint from-prd <plans/prds/*.prd.md>` を使います。
+`repo-harness-goal` は詳細な PRD または Sprint artifact がある場合だけ使い、
+Codex/Claude 向けの bounded `/goal` prompt を準備し、PRD/Sprint を source of truth
+として維持します。その文書がない場合、goal command はチャット文脈から実装を始めず、
+先に文書を要求しなければなりません。
+
+`repo-harness adopt` は既存リポジトリ向け、`repo-harness-scaffold` は支線 command として新しいプロジェクトやモジュールを作成します。
 `hooks-init`、`docs-init`、`create-project-dirs` は内部ステップであり、公開 commands ではありません。
 
 ## Maintainer Reference