shinpr · shinpr · Aug 27, 2026 · Aug 27, 2026
diff --git a/README.es.md b/README.es.md
@@ -29,7 +29,7 @@ codex-workflows evita que el alcance crezca sin control durante toda la ejecuci
 | Alcance | El flujo contrasta la petición con el resultado deseado, las exclusiones expresas, el código existente y el coste aproximado. Lo que no justifica su coste se descarta antes de convertirse en arquitectura. |
 | Controles entre fases | Los requisitos, el diseño y el plan se revisan antes de autorizar la siguiente fase. Los agentes nuevos leen las decisiones aprobadas y la evidencia que necesitan, en vez de reconstruir la intención a partir de una conversación larga. |
 | Ejecución | Una vez aprobado el alcance de implementación, Codex ejecuta el conjunto de tareas de forma autónoma. Cada tarea supera su verificación específica y las comprobaciones aplicables del repositorio antes del commit de implementación. |
-| Finalización | Revisiones independientes de código y seguridad inspeccionan el cambio completo. Las correcciones obligatorias vuelven al mismo ciclo de implementación y calidad; las mejoras opcionales pueden descartarse si hay argumentos para hacerlo. |
+| Finalización | Las revisiones independientes de código y seguridad comprueban que el cambio terminado se ajuste al alcance aprobado y no contenga fallos importantes. Las correcciones obligatorias vuelven al mismo ciclo de implementación y calidad. |
 
 Este flujo requiere más llamadas a agentes y más tokens que una ejecución directa. Úsalo cuando proteger el resultado acordado compense ese coste.
 
@@ -71,6 +71,7 @@ El prefijo `$` invoca una skill de forma explícita. Escribe `$recipe-` para ver
 | Diseñar y construir un frontend web con React / TypeScript | `$recipe-front-design` → `$recipe-front-plan` → `$recipe-front-build` |
 | Entregar juntos un cambio de backend y otro de frontend React | `$recipe-fullstack-implement` |
 | Revisar una implementación frente a su diseño | `$recipe-review` o `$recipe-front-review` |
+| Definir o actualizar reglas de revisión propias del repositorio | `$recipe-quality-profile` |
 | Investigar un problema sin tocar el código | `$recipe-diagnose` |
 | Hacer un experimento desechable o un script puntual | Usa Codex directamente |
 
@@ -88,7 +89,7 @@ flowchart LR
     D --> E[Planificar el trabajo dependiente]
     E --> F[Aprobar el alcance de implementación]
     F --> H[Por tarea: implementar, verificar, comprobar calidad y hacer commit]
-    H --> K[Verificación independiente de código y seguridad]
+    H --> K[Revisión independiente de código y seguridad]
     K -->|Corrección| H
     K -->|Cambian los requisitos o el diseño principal| B
     K -->|Aprobado| L[Finalizado]
@@ -123,7 +124,7 @@ Separar los contextos evita que exploración, diseño, implementación y revisi
 - **Verificación**: Ejecutar la prueba de contrato y comprobar la estructura de respuesta documentada
 ```
 
-El [Task File Contract](.agents/skills/llm-friendly-context/references/task-template.md) lleva a la implementación la fuente, el resultado esperado, los archivos afectados y una verificación ejecutable. Solo añade un `Verification Focus` cuando una prueba podría pasar sin demostrar un comportamiento importante. Tras ejecutar la tarea, se aplican al cambio completo todos los controles pertinentes del repositorio antes del commit. Los revisores finales comparan el código terminado con los documentos aprobados y repiten la revisión después de las correcciones aceptadas.
+El [Task File Contract](.agents/skills/llm-friendly-context/references/task-template.md) lleva a la implementación la fuente, el resultado esperado, los archivos afectados y una verificación ejecutable. Solo añade un `Verification Focus` cuando una prueba podría pasar sin demostrar un comportamiento importante. Tras ejecutar la tarea, se aplican al cambio completo todos los controles pertinentes del repositorio antes del commit. Los revisores finales comparan el código terminado con los documentos aprobados. También buscan cambios fuera del alcance aprobado y problemas importantes de calidad del código. Cuando se acepta una corrección, la siguiente revisión se centra en los controles que esa corrección podría afectar. Ejecuta `$recipe-quality-profile` para definir reglas de revisión adicionales en `docs/project-context/quality.yaml` a partir de la evidencia del propio repositorio.
 
 ---
 
@@ -199,7 +200,8 @@ Invoca un flujo con `$recipe-name` en Codex. Escribe `$recipe-` y usa el autocom
 | `$recipe-plan` | Design Doc → esqueletos selectivos de integración/E2E → Work Plan | Planificación desde un Design Doc aprobado |
 | `$recipe-prepare-implementation` | Prepara las herramientas locales ya existentes que necesita un Work Plan aprobado | Petición expresa de preparación o capacidad necesaria no disponible |
 | `$recipe-build` | Ejecuta tareas de backend con validación entre pasos | Retomar una implementación de backend |
-| `$recipe-review` | Verifica el Design Doc y la seguridad, con correcciones aprobadas opcionales | Revisión tras implementar |
+| `$recipe-review` | Revisa el alcance de implementación, el cumplimiento del Design Doc, la calidad del código y la seguridad; aplica las correcciones aprobadas por el usuario | Revisión tras implementar |
+| `$recipe-quality-profile` | Define o actualiza reglas de revisión propias del repositorio en `docs/project-context/quality.yaml` | Configuración y mantenimiento de las reglas de revisión |
 | `$recipe-diagnose` | Investigación → verificación del punto de fallo → solución | Investigación de errores |
 | `$recipe-reverse-engineer` | Genera PRD y Design Docs a partir del código existente | Documentar sistemas heredados |
 | `$recipe-add-integration-tests` | Añade pruebas de integración/E2E a partir del Design Doc | Mejorar la cobertura del código existente |
@@ -213,7 +215,7 @@ Invoca un flujo con `$recipe-name` en Codex. Escribe `$recipe-` y usa el autocom
 | `$recipe-front-adjust` | Ajuste acotado de UI con pruebas del repositorio, material aportado o fuentes externas necesarias | Cambios puntuales de UI después de implementar |
 | `$recipe-front-plan` | Design Doc frontend → esqueletos selectivos de integración/E2E → Work Plan | Planificación frontend |
 | `$recipe-front-build` | Ejecuta tareas frontend con verificación específica y controles de calidad | Retomar una implementación frontend |
-| `$recipe-front-review` | Verifica cumplimiento y seguridad frontend, con correcciones React aprobadas opcionales | Revisión frontend posterior a la implementación |
+| `$recipe-front-review` | Revisa el alcance, el cumplimiento, la calidad del código y la seguridad del frontend; aplica las correcciones React aprobadas por el usuario | Revisión frontend posterior a la implementación |
 
 ### Fullstack (entre capas)
 
@@ -302,7 +304,7 @@ Codex crea estos agentes cuando un flujo los necesita. No hace falta aprender su
 
 | Agente | Función |
 |--------|---------|
-| `code-reviewer` | Valida el cumplimiento del Design Doc |
+| `code-reviewer` | Contrasta la implementación terminada con el alcance y los documentos aprobados, y señala problemas importantes de calidad del código |
 | `code-verifier` | Comprueba la coherencia entre documentos y código |
 | `security-reviewer` | Revisa la seguridad después de implementar |
 | `rule-advisor` | Elige skills para tareas independientes no cubiertas por un flujo |

diff --git a/README.ja.md b/README.ja.md
@@ -29,7 +29,7 @@ codex-workflowsは、実行中を通してこうした拡大を抑えます。
 | スコープ | 依頼内容を、目指す成果、明示的な除外事項、既存コード、実装の概算コストと照合します。コストに見合わない作業は、アーキテクチャになる前に取り除きます。 |
 | フェーズゲート | 要件・設計・計画の成果物を確認し、合格したものだけが次のフェーズを開始できます。新しいエージェントは、長い会話から意図を組み立て直すのではなく、承認済みの判断と必要な根拠を読みます。 |
 | 実行 | 実装が承認されると、Codexがタスク一式を自律的に実行します。各タスクは実装コミットの前に、対象を絞った検証と該当するリポジトリチェックを通過します。 |
-| 完了 | 独立したコード検証とセキュリティ検証が、変更全体を確認します。必須の修正は同じ実装・品質サイクルに戻り、任意の堅牢化は根拠を示したうえで見送れます。 |
+| 完了 | 独立したコードレビューとセキュリティレビューで、完成した変更が承認済みの範囲に収まり、重大な問題がないことを確認します。必須の修正は同じ実装・品質サイクルに戻します。 |
 
 このワークフローは、Codexを直接使う場合よりエージェント呼び出しとトークンを多く消費します。合意した成果を守る価値が、そのコストを上回るときに使ってください。
 
@@ -71,6 +71,7 @@ $recipe-implement JWTによるユーザー認証を追加する
 | React / TypeScriptのWebフロントエンドを設計・実装する | `$recipe-front-design` → `$recipe-front-plan` → `$recipe-front-build` |
 | バックエンドとReactフロントエンドをまとめて変更する | `$recipe-fullstack-implement` |
 | 設計どおりに実装されているかレビューする | `$recipe-review` または `$recipe-front-review` |
+| リポジトリ固有のレビュールールを定義・更新する | `$recipe-quality-profile` |
 | コードを変えずに問題を調査する | `$recipe-diagnose` |
 | 使い捨ての検証や単発スクリプトを実行する | Codexを直接使う |
 
@@ -88,7 +89,7 @@ flowchart LR
     D --> E[依存関係を踏まえて作業を計画]
     E --> F[実装範囲を承認]
     F --> H[タスクごとに実装・検証・品質確認・コミット]
-    H --> K[独立したコード検証とセキュリティ検証]
+    H --> K[独立したコードレビューとセキュリティレビュー]
     K -->|修正あり| H
     K -->|要件または主要設計が変更| B
     K -->|合格| L[完了]
@@ -123,7 +124,7 @@ ADRを作るのは、現在のスコープに属し、長く残る選択で、
 - **検証**: 契約テストを実行し、文書どおりのレスポンス形式を確認
 ```
 
-[Task File Contract](.agents/skills/llm-friendly-context/references/task-template.md)は、根拠、期待する結果、対象ファイル、実行可能な検証方法を実装フェーズへ渡します。テストが通っても重要な挙動を証明できないおそれがある場合だけ、`Verification Focus`を追加します。実行後は、コミット前にタスクの変更全体へ該当するリポジトリチェックをかけます。最終レビュアーは、承認済み文書と完成したコードを照合し、採用された修正後にもう一度確認します。
+[Task File Contract](.agents/skills/llm-friendly-context/references/task-template.md)は、根拠、期待する結果、対象ファイル、実行可能な検証方法を実装フェーズへ渡します。テストが通っても重要な挙動を証明できないおそれがある場合だけ、`Verification Focus`を追加します。実行後は、コミット前にタスクの変更全体へ該当するリポジトリチェックをかけます。最終レビュアーは、完成したコードを承認済み文書と照合します。さらに、承認範囲を超えた実装や重大なコード品質上の問題がないかも確認します。修正を採用したあとの再レビューでは、その修正の影響を受ける項目に対象を絞ります。`$recipe-quality-profile`を実行すると、リポジトリ内の根拠をもとに、固有のレビュールールを`docs/project-context/quality.yaml`へ追加できます。
 
 ---
 
@@ -199,7 +200,8 @@ Codexでは`$recipe-name`でレシピを呼び出します。`$recipe-`まで入
 | `$recipe-plan` | Design Doc → 必要な統合/E2Eテストのひな型 → Work Plan | 承認済みDesign Docからの計画 |
 | `$recipe-prepare-implementation` | 承認済みWork Planに必要な既存のリポジトリ内ツールを準備 | 明示的なセットアップ依頼、または必要なタスク機能が利用できない場合 |
 | `$recipe-build` | ステップ間の検証を含むバックエンドタスクの実行 | バックエンド実装の再開 |
-| `$recipe-review` | Design Doc準拠とセキュリティの検証、必要に応じて承認済み修正 | 実装後の確認 |
+| `$recipe-review` | 実装範囲、Design Doc準拠、コード品質、セキュリティをレビューし、ユーザーが承認した修正を適用 | 実装後の確認 |
+| `$recipe-quality-profile` | リポジトリ固有のレビュールールを`docs/project-context/quality.yaml`に定義・更新 | レビューポリシーの設定・保守 |
 | `$recipe-diagnose` | 問題調査 → 障害点の検証 → 解決策 | 不具合調査 |
 | `$recipe-reverse-engineer` | 既存コードからPRDとDesign Docを生成 | レガシーシステムの文書化 |
 | `$recipe-add-integration-tests` | Design Docをもとに統合/E2Eテストを追加 | 既存コードのテスト拡充 |
@@ -213,7 +215,7 @@ Codexでは`$recipe-name`でレシピを呼び出します。`$recipe-`まで入
 | `$recipe-front-adjust` | リポジトリ、提供資料、必要な外部根拠に基づく、範囲を絞ったUI調整 | 実装後の部分的なUI変更 |
 | `$recipe-front-plan` | フロントエンドDesign Doc → 必要な統合/E2Eテストのひな型 → Work Plan | フロントエンドの計画フェーズ |
 | `$recipe-front-build` | 対象を絞った検証と品質チェックを含むフロントエンドタスクの実行 | フロントエンド実装の再開 |
-| `$recipe-front-review` | フロントエンド準拠・セキュリティ検証と、必要に応じた承認済みReact修正 | フロントエンド実装後の確認 |
+| `$recipe-front-review` | フロントエンドの範囲、準拠状況、コード品質、セキュリティをレビューし、ユーザーが承認したReact修正を適用 | フロントエンド実装後の確認 |
 
 ### フルスタック（レイヤー横断）
 
@@ -302,7 +304,7 @@ Webフロントエンドで使うTypeScript向けには、Reactアプリケー
 
 | エージェント | 役割 |
 |--------------|------|
-| `code-reviewer` | Design Docへの準拠を検証 |
+| `code-reviewer` | 完成した実装を承認範囲や準拠すべき文書と照合し、重大なコード品質上の問題を確認 |
 | `code-verifier` | 文書とコードの整合性を検証 |
 | `security-reviewer` | 実装後のセキュリティ準拠をレビュー |
 | `rule-advisor` | レシピの管理外にある単独タスクのスキルを選定 |