rbin-task-flow 1.3.0 → 1.5.0

package/.cursor/rules/git_control.mdc

@@ -5,11 +5,12 @@ alwaysApply: true
 ---
 
 - **General Command Permission:**
-  - **✅ CAN execute** any system command without asking
-  - **✅ CAN execute** npm, yarn, pnpm, docker, etc without confirmation
-  - **✅ CAN execute** scripts, tests, linters, formatters without asking
+  - **✅ CAN execute** any system command without asking (Claude may run commands without asking for approval)
+  - **✅ CAN execute** npm, yarn, pnpm, docker, scripts, tests, linters, formatters without confirmation
   - **✅ DON'T need to ask** before executing simple or common commands
-  - **❌ ONLY EXCEPTION**: `git` commands that modify the repository
+  - **❌ EXCEPTIONS** (do not execute without user approval):
+    - **Git**: `git` commands that modify the repository (add, commit, push, pull, merge, checkout, etc.)
+    - **Cloud/remote resources**: Commands that run or connect to cloud/remote resources (e.g. database connections, cloud CLI that provisions resources, migrations against remote DB, deploying to production)
 
 - **Read Commands - Automatic Execution:**
   - **✅ ALWAYS execute without asking** commands that only read information:
@@ -85,4 +86,4 @@ alwaysApply: true
   - RBIN Task Flow workflow should not include automatic git execution
 
 - **Fundamental Principle:**
-  > **User has complete control over the Git repository. AI can execute any system command without asking, EXCEPT git commands. For git, only suggests, analyzes, and informs. Never modifies git state.**
+  > **Claude may execute commands without asking, except: (1) git commands that modify the repository, and (2) commands that run cloud/remote resources (e.g. database, cloud provisioning). For those, only suggest or ask for approval.**

package/.cursor/rules/task_audit.mdc

@@ -0,0 +1,158 @@
+---
+description: Audit codebase against coding standards and suggest incremental improvements
+globs: **/*
+alwaysApply: true
+---
+
+# task-flow: audit
+
+When the user runs `task-flow: audit`, perform a non-destructive analysis of the current project against the coding standards defined in [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc).
+
+---
+
+## What This Command Does
+
+1. **Scans the project** to understand its current structure, tech stack, and patterns
+2. **Compares against coding_standards.mdc** to identify gaps and misalignments
+3. **Reports a compatibility score** per category
+4. **Asks the user** which improvements they want to adopt — never assumes or imposes
+5. **Respects project context** — an existing company project can't be fully restructured overnight
+
+---
+
+## How to Execute
+
+### Step 1 — Explore the project
+
+Scan the codebase to understand:
+- Folder structure (is there `src/app`, `features`, `shared`? something else?)
+- Tech stack in use (`package.json`)
+- How routes/pages are organized
+- How components are structured (size, responsibilities)
+- How API calls are made (fetch, axios, react-query, or raw calls in components?)
+- How forms are handled (controlled, uncontrolled, react-hook-form?)
+- How styles are applied (Tailwind, CSS modules, styled-components, inline?)
+- File naming conventions in use
+- Presence of tests and what kind
+
+### Step 2 — Score each category
+
+For each category below, rate adherence: **Full / Partial / Missing**
+
+| Category | Score | Notes |
+|----------|-------|-------|
+| Folder structure (`app/features/shared`) | | |
+| `app/` is thin (no logic in routes) | | |
+| Feature-based organization | | |
+| Page/Screen as orchestrator (short, composes components) | | |
+| Component single responsibility | | |
+| React Query (service + use-case split) | | |
+| Forms (react-hook-form + zod) | | |
+| `cn()` for class merging | | |
+| File naming conventions | | |
+| TypeScript strictness (no `any`) | | |
+| `DataHandler` pattern (or equivalent) | | |
+| Providers composition | | |
+| E2E tests (Playwright/Cypress/Detox) | | |
+
+### Step 3 — Present findings clearly
+
+Show the score table with honest notes. Examples:
+- "Routes contain business logic — pages are 200+ lines"
+- "API calls are made directly in components with `fetch`"
+- "No consistent naming convention found"
+- "Tailwind classes concatenated with template literals instead of `cn()`"
+- "Structure is MVC-like, not feature-based — migration would be significant"
+
+### Step 4 — Ask what to adopt
+
+After presenting the report, ask:
+
+> "Which of these would you like to improve in this project? I'll generate tasks for each selected item.
+>
+> Keep in mind: some changes (like restructuring to `app/features/shared`) may not be practical for an existing project. I'll suggest incremental, non-breaking improvements where possible."
+
+List the improvable items as options. Let the user choose one, several, or all.
+
+### Step 5 — Generate tasks for selected improvements
+
+For each selected improvement:
+- Create a task in `.task-flow/tasks.input.txt` (or show the task descriptions so the user can paste them)
+- Tasks must be incremental and safe — never propose wholesale rewrites unless the user explicitly asks
+- Examples of incremental tasks:
+  - "Componentize the `UserDashboard` page — extract `UserStatsCard` and `UserActivityList` components"
+  - "Replace raw `fetch` calls in `auth.ts` with a `useCreateSession` service using react-query"
+  - "Add `cn()` helper and replace string concatenation in `Button` and `Card` components"
+  - "Extract `LoginForm` business logic from `login/page.tsx` into `features/auth/pages/login.page.tsx`"
+
+---
+
+## Important Principles
+
+- **Non-destructive by default**: Suggest improvements, don't impose them
+- **Incremental**: Prefer "improve this component" over "rewrite this module"
+- **Context-aware**: A greenfield project can adopt everything; a legacy company project needs gradual migration
+- **Honest**: If the project has a completely different architecture that works, say so — don't force standards where they don't fit
+- **No auto-execution**: This command only analyzes and suggests. The user decides what to implement.
+
+---
+
+## Example Output Format
+
+```
+## task-flow: audit — Coding Standards Report
+
+### Project: [detected project name]
+### Type: [Next.js / Expo / NestJS / Monorepo]
+
+---
+
+### Compatibility Score
+
+| Category | Score | Notes |
+|----------|-------|-------|
+| Folder structure | Partial | Has `src/components` and `src/pages` — no `features/` or `shared/` |
+| app/ is thin | Missing | `pages/dashboard.tsx` is 340 lines with business logic |
+| Feature-based organization | Missing | Code organized by type (components/, hooks/) not by domain |
+| Page as orchestrator | Missing | Pages fetch data and render complex JSX directly |
+| Component single responsibility | Partial | Some components are focused, others handle too much |
+| React Query | Missing | Using `useEffect + fetch` directly in components |
+| Forms (RHF + Zod) | Partial | Using react-hook-form but no Zod validation |
+| cn() for class merging | Missing | Using template literals: `className={\`btn \${isActive ? 'active' : ''}\`}` |
+| File naming | Partial | Inconsistent — mix of PascalCase and kebab-case |
+| TypeScript strictness | Partial | Some `any` usages found |
+| DataHandler pattern | Missing | Manual if/else for loading states in each component |
+| Providers composition | Full | Already uses an AppProviders component |
+| E2E tests | Missing | No test files found |
+
+---
+
+### Overall: 2 Full / 5 Partial / 6 Missing
+
+---
+
+### What would you like to improve?
+
+I can generate tasks for any of these. Note that restructuring to `app/features/shared` would be a significant change — I'd suggest tackling it only if you're planning a larger refactor.
+
+Quick wins (low effort, high impact):
+- [ ] Add `cn()` helper and apply to all components
+- [ ] Add Zod schemas to existing react-hook-form forms
+- [ ] Extract `DataHandler` component and apply to data-fetching components
+
+Medium effort:
+- [ ] Migrate `useEffect + fetch` to React Query (service + use-case pattern)
+- [ ] Split large pages into orchestrator + focused components
+
+Larger effort:
+- [ ] Introduce `features/` structure for new features going forward
+- [ ] Add E2E tests with Playwright/Cypress
+
+Which would you like me to generate tasks for?
+```
+
+---
+
+## Principle
+
+> **Audit is a conversation, not a verdict. The goal is to help the developer adopt better patterns at their own pace, respecting the reality of the project they're working on.**

package/.cursor/rules/task_execution.mdc

@@ -6,6 +6,7 @@ alwaysApply: true
 
 - **RBIN Task Flow - AI-Powered Task Management:**
   - This project uses **RBIN Task Flow** for task tracking and management
+  - **Models**: Claude and Cursor use the **default model** of each environment. Do not specify or require a particular model.
   - **IMPORTANT**: When user mentions "task flow", they always refer to **RBIN Task Flow**
   - Tasks are defined in plain text: `.task-flow/tasks.input.txt`
   - Task data is stored in: `.task-flow/.internal/` (do not edit directly - internal system files)
@@ -20,6 +21,7 @@ alwaysApply: true
 - **AI Commands:**
   - `task-flow: sync` - Sync new tasks from tasks.input.txt
   - `task-flow: think` - Analyze codebase and suggest new tasks
+  - `task-flow: audit` - Audit codebase against coding standards and suggest incremental improvements
   - `task-flow: run next X` - Work on next X subtasks sequentially
   - `task-flow: run X` - Work on all pending subtasks of task X (simplified - no "task" needed)
   - `task-flow: run X,Y` - Work on multiple tasks (comma-separated)

package/.cursor/rules/task_generation.mdc

@@ -7,31 +7,32 @@ alwaysApply: true
 - **Task Generation - Direct and Efficient:**
   - When user asks to "Read tasks.input.txt and generate detailed subtasks updating task status":
     - **READ**: `.task-flow/tasks.input.txt` (only process lines starting with `- `)
-    - **READ**: `.task-flow/screens/` directory to list available screenshots (ALWAYS check this directory)
+    - **READ**: `.task-flow/contexts/` directory to list available context files (ALWAYS check this directory)
     - **GENERATE**: Two JSON files and one markdown file with the exact structure below
     - **SAVE**: All files to `.task-flow/`
     - **DON'T**: Check existing JSONs, explore codebase, or ask questions
 
-- **Screenshot Reference System:**
-  - **AUTOMATIC**: Always check `.task-flow/screens/` directory for available screenshots (PNG, JPG files)
-  - **NO LISTING NEEDED**: Don't require screenshots to be listed in tasks.input.txt - always scan the directory
-  - **AUTOMATIC MATCHING**: Automatically match screenshots to tasks based on keywords (e.g., "login" → `login_recover_signup.png`, "dashboard" → `dashboard.png`, "paciente" → `patient.png`)
-  - **SPECIFIC REFERENCE**: If task contains `task-flow-screen nome_do_arquivo.png`, reference that specific screenshot from `.task-flow/screens/`
-  - **PATH ALWAYS**: `task-flow-screen` always references files in `.task-flow/screens/` directory
-  - **INCLUDE**: Add screenshot reference in instructions: "Visual reference: `.task-flow/screens/filename.png`"
+- **Context Reference System:**
+  - **PURPOSE**: `.task-flow/contexts/` is for AIs to consult reference material (any type: .md, .txt, .png, .jpg, .json, etc.) when generating and working on tasks
+  - **AUTOMATIC**: Always check `.task-flow/contexts/` directory for available context files (all file types)
+  - **NO LISTING NEEDED**: Don't require context files to be listed in tasks.input.txt - always scan the directory
+  - **AUTOMATIC MATCHING**: Match context files to tasks by keywords (e.g., "login" → `login-mockup.png` or `api-login.md`, "dashboard" → `dashboard.png`)
+  - **SPECIFIC REFERENCE**: If task contains `task-flow-screen nome_arquivo.ext`, reference that file from `.task-flow/contexts/`
+  - **PATH ALWAYS**: `task-flow-screen` always references files in `.task-flow/contexts/`
+  - **INCLUDE**: In subtask instructions, add the reference: "Context/reference: `.task-flow/contexts/filename.ext`" (or "Visual reference" for images)
 
 - **Required Actions:**
   1. Read `tasks.input.txt`:
      - Process task lines (only process lines starting with `- `)
      - Check for `task-flow-screen nome_do_arquivo.png` markers in task descriptions
-  2. **ALWAYS** list available screenshots from `.task-flow/screens/` directory (PNG, JPG files)
+  2. **ALWAYS** list available context files from `.task-flow/contexts/` directory (all file types: .md, .txt, .png, .jpg, .json, etc.)
   3. For each task line, create a task with sequential ID starting at 1
   4. Generate 3-8 subtasks per task with:
      - Clear title
      - Brief description
      - Step-by-step instructions (3-5 steps)
-     - **AUTOMATIC**: Include relevant screenshot references when applicable (match by keywords)
-     - **SPECIFIC**: If task has `task-flow-screen nome_do_arquivo.png`, reference that specific screenshot from `.task-flow/screens/`
+     - **AUTOMATIC**: Include relevant context references when applicable (match by keywords)
+     - **SPECIFIC**: If task has `task-flow-screen nome_arquivo.ext`, reference that file from `.task-flow/contexts/`
   5. Create `.task-flow/.internal/tasks.json` with structure below
   6. Create `.task-flow/.internal/status.json` with all tasks/subtasks as "pending"
   7. Create `.task-flow/tasks.status.md` with all tasks and subtasks marked as `- [ ]` (pending)
@@ -117,30 +118,38 @@ alwaysApply: true
 
 - **Example:**
   - Input (`tasks.input.txt`): `- Create authentication system`
-  - Screenshots available: `login_recover_signup.png`
-  - Output: Task with ID 1, 5 subtasks with screenshot references:
-    - Subtask 1: "Setup database schema" (no screenshot)
-    - Subtask 2: "Create login form" → Instructions include: "Visual reference: `.task-flow/screens/login_recover_signup.png`"
-    - Subtask 3: "Implement registration" → Instructions include screenshot reference
-    - Subtask 4: "Add JWT authentication" (no screenshot)
-    - Subtask 5: "Test authentication flow" → Instructions include screenshot reference
+  - Context files available: `login_recover_signup.png`
+  - Output: Task with ID 1, 5 subtasks with context references:
+    - Subtask 1: "Setup database schema" (no context)
+    - Subtask 2: "Create login form" → Instructions include: "Visual reference: `.task-flow/contexts/login_recover_signup.png`"
+    - Subtask 3: "Implement registration" → Instructions include context reference
+    - Subtask 4: "Add JWT authentication" (no context)
+    - Subtask 5: "Test authentication flow" → Instructions include context reference
   
-- **Screenshot Reference Examples:**
-  - Task: `- Dentist authentication system` → Automatically matches and references `login_recover_signup.png` from `.task-flow/screens/`
-  - Task: `- Basic dashboard with structure task-flow-screen dashboard.png` → References specific `.task-flow/screens/dashboard.png`
-  - Task: `- Complete patient CRUD` → Automatically matches and references `patient.png` and `patient_profile.png` from `.task-flow/screens/` if available
-  - **IMPORTANT**: `task-flow-screen` always references files in `.task-flow/screens/` - no need to specify full path
+- **Context Reference Examples:**
+  - Task: `- Dentist authentication system` → Automatically matches and references `login_recover_signup.png` from `.task-flow/contexts/`
+  - Task: `- Basic dashboard with structure task-flow-screen dashboard.png` → References specific `.task-flow/contexts/dashboard.png`
+  - Task: `- Complete patient CRUD` → Automatically matches and references `patient.png` and `patient_profile.png` from `.task-flow/contexts/` if available
+  - **IMPORTANT**: `task-flow-screen` always references files in `.task-flow/contexts/` - no need to specify full path
+  - **FILE TYPES**: Contexts can be any type (images, markdown, text, JSON, etc.) for the AI to read and use when working on tasks
 
 - **Critical Rules:**
   - ✅ Be direct: Read → Generate → Save
-  - ✅ **ALWAYS** check `.task-flow/screens/` directory for available screenshots (automatic, no need to list in tasks.input.txt)
-  - ✅ Automatically match and reference relevant screenshots in subtask instructions based on keywords
-  - ✅ Support `task-flow-screen nome_do_arquivo.png` format - always references `.task-flow/screens/nome_do_arquivo.png`
-  - ✅ No exploration of codebase beyond screenshots directory
+  - ✅ **ALWAYS** check `.task-flow/contexts/` directory for available context files (automatic, no need to list in tasks.input.txt)
+  - ✅ Automatically match and reference relevant context files in subtask instructions based on keywords
+  - ✅ Support `task-flow-screen nome_do_arquivo.png` format - always references `.task-flow/contexts/nome_do_arquivo.png`
+  - ✅ No exploration of codebase beyond `.task-flow/contexts/` directory
   - ✅ No questions - just generate
   - ✅ Use current timestamp for `createdAt`
   - ✅ All statuses start as "pending"
   - ✅ Subtask IDs are sequential per task (1, 2, 3...)
 
+- **Coding Standards:**
+  - When generating subtask instructions, always follow the patterns defined in [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc)
+  - Subtask instructions must reference the correct file structure: `src/app/`, `src/features/`, `src/shared/`
+  - Subtask instructions must specify the correct file naming suffix (`.page.tsx`, `.service.tsx`, `.use-case.ts`, etc.)
+  - Subtask instructions must enforce the service + use-case split for API calls
+  - Subtask instructions must enforce `cn()` for class merging, `Controller` for form inputs, and `zodResolver` for validation
+
 - **Principle:**
-  > **When generating tasks, be fast and direct. Read tasks.input.txt, generate JSONs and tasks.status.md with proper structure, save files. No exploration needed.**
+  > **When generating tasks, be fast and direct. Read tasks.input.txt, generate JSONs and tasks.status.md with proper structure, save files. Always follow coding_standards.mdc patterns in subtask instructions.**

package/.cursor/rules/task_work.mdc

@@ -62,8 +62,8 @@ alwaysApply: true
      - Skip "done" and "in_progress" subtasks
   3. **For each subtask**:
      - Read full instructions from `tasks.json`
-     - **CHECK**: If instructions mention screenshot references (`.task-flow/screens/...`), verify screenshot exists
-     - **REFERENCE**: Use screenshots as visual reference when implementing UI-related subtasks
+     - **CHECK**: If instructions mention context references (`.task-flow/contexts/...`), verify the context file exists
+     - **CONSULT**: Read and use context files from `.task-flow/contexts/` when implementing (images, .md, .txt, .json, etc. – any type that helps the task)
      - Implement following step-by-step instructions
      - Test/verify implementation
      - Update `status.json` to mark as "done"
@@ -91,8 +91,8 @@ alwaysApply: true
      - Skip "done" and "in_progress" subtasks
   4. **For each subtask** (only if dependency check passed):
      - Read full instructions from `tasks.json`
-     - **CHECK**: If instructions mention screenshot references (`.task-flow/screens/...`), verify screenshot exists
-     - **REFERENCE**: Use screenshots as visual reference when implementing UI-related subtasks
+     - **CHECK**: If instructions mention context references (`.task-flow/contexts/...`), verify the context file exists
+     - **CONSULT**: Read and use context files from `.task-flow/contexts/` when implementing (images, .md, .txt, .json, etc. – any type that helps the task)
      - Implement following step-by-step instructions
      - Test/verify implementation
      - Update `status.json` to mark as "done"
@@ -206,15 +206,16 @@ alwaysApply: true
   - If file doesn't exist → create it
   - If instructions unclear → ask for clarification (but try to infer first)
 
-- **Screenshot Support:**
-  - **AUTOMATIC**: When implementing subtasks, check if instructions reference screenshots
-  - **REFERENCE**: Use screenshots from `.task-flow/screens/` as visual reference for UI implementation
-  - **MATCHING**: Match screenshot references mentioned in subtask instructions
-  - **NO NEED**: User doesn't need to explicitly mention screenshots - they're automatically considered
+- **Context Support:**
+  - **PURPOSE**: `.task-flow/contexts/` holds reference material (any file type) for the AI to consult when working on tasks
+  - **AUTOMATIC**: When implementing subtasks, check if instructions reference context files
+  - **CONSULT**: Read and use files from `.task-flow/contexts/` as needed (specs, mockups, examples, .md, .txt, .png, .json, etc.)
+  - **MATCHING**: Use the context files mentioned in subtask instructions; support any extension, not only images
+  - **NO NEED**: User doesn't need to explicitly mention context files - they're automatically considered
 
 - **Integration:**
   - Works with [task_execution.mdc](mdc:.cursor/rules/task_execution.mdc) - same workflow
-  - Follows [task_generation.mdc](mdc:.cursor/rules/task_generation.mdc) - screenshots are automatically referenced in generated subtasks
+  - Follows [task_generation.mdc](mdc:.cursor/rules/task_generation.mdc) - context files are automatically referenced in generated subtasks
   - Follows [commit_practices.mdc](mdc:.cursor/rules/commit_practices.mdc) - suggest commit after completion
   - Respects [git_control.mdc](mdc:.cursor/rules/git_control.mdc) - never commit automatically
 

package/.cursor/settings.json

@@ -1,3 +1 @@
-{
-  "model": "claude-sonnet-4-5-20250929"
-}
+{}

package/.model-versions.json

@@ -1,17 +1 @@
-{
-  "claude": {
-    "current": "claude-sonnet-4-5-20250929",
-    "latest": "claude-sonnet-4-5-20250929",
-    "checkUrl": "https://docs.anthropic.com/claude/docs/models-overview"
-  },
-  "cursor": {
-    "current": "claude-sonnet-4-5-20250929",
-    "latest": "claude-sonnet-4-5-20250929",
-    "checkUrl": "https://docs.cursor.com/models"
-  },
-  "gemini": {
-    "current": "gemini-3-flash",
-    "latest": "gemini-3-flash",
-    "checkUrl": "https://ai.google.dev/models/gemini"
-  }
-}
+{"claude":{"current":"claude-sonnet-4-5-20250929","latest":"claude-sonnet-4-5-20250929","checkUrl":"https://docs.anthropic.com/claude/docs/models-overview"},"cursor":{"current":"claude-sonnet-4-5-20250929","latest":"claude-sonnet-4-5-20250929","checkUrl":"https://docs.cursor.com/models"}}

package/.task-flow/contexts/example.png.txt

@@ -0,0 +1,29 @@
+# Example Context
+
+This folder (`.task-flow/contexts/`) is for AIs to consult reference material when working on tasks.
+
+## Purpose
+
+- **Contexts** = any files that help the AI understand what to build or how to do it
+- The AI reads and uses these files when generating subtasks and when implementing them
+- Different file types are supported: images, docs, specs, examples, etc.
+
+## Supported file types (examples)
+
+- **Images:** `.png`, `.jpg` – mockups, screenshots, diagrams
+- **Text / docs:** `.md`, `.txt` – specs, requirements, notes
+- **Data / config:** `.json`, `.yaml` – examples, schema, sample data
+- **Other:** any file that is useful as context for the task
+
+## How to use
+
+1. Add your context files to this folder with descriptive names (e.g. kebab-case)
+2. RBIN Task Flow lists and references them when generating subtasks
+3. To reference a specific file in a task, use: `task-flow-screen filename.ext`
+
+## Example names
+
+- `login-mockup.png`
+- `api-contract.json`
+- `requirements.md`
+- `dashboard-spec.txt`

package/.task-flow/tasks.input.txt

@@ -7,12 +7,13 @@
 3. Use `task-flow: sync` to generate subtasks from your tasks
 4. Use `task-flow: status` to view task progress
 
-## Screenshots:
+## Contexts:
 
-- Add your screenshots to the `.task-flow/screens/` folder (PNG or JPG)
-- RBIN Task Flow automatically detects and references available screenshots when generating subtasks
-- To reference a specific screenshot in a task, use: `task-flow-screen filename.png`
-- Example: `- Create login screen task-flow-screen login.png`
+- The `.task-flow/contexts/` folder is for AIs to consult when working on tasks (different file types: .md, .txt, .png, .jpg, .json, etc.)
+- Add specs, mockups, requirements, examples, or any reference file to this folder
+- RBIN Task Flow detects and references them when generating and implementing subtasks
+- To reference a specific context in a task: `task-flow-screen filename.ext`
+- Example: `- Create login screen task-flow-screen login-mockup.png`
 
 ## Tasks:
 

package/CLAUDE.md

@@ -1,5 +1,9 @@
 # Claude Code Instructions
 
+## Models
+
+Claude and Cursor use the **default model** of each environment. No specific model is set in this project; do not specify or require a particular model.
+
 ## Development Rules
 
 All development rules are automatically loaded from `.cursor/rules/` directory. These rules include:
@@ -17,6 +21,7 @@ This project uses RBIN Task Flow for task management:
 - **AI Commands**: Use AI-powered commands for task management:
   - `task-flow: sync` - Synchronize tasks from tasks.input.txt
   - `task-flow: think` - Analyze code and suggest new tasks
+  - `task-flow: audit` - Audit codebase against coding standards and suggest incremental improvements
   - `task-flow: status` - View current task status
   - `task-flow: run next X` - Work on next X subtasks
   - `task-flow: run X` - Execute all pending subtasks of task X (simplified - no "task" needed)
@@ -36,3 +41,7 @@ This project uses RBIN Task Flow for task management:
   - `.task-flow/.internal/` - Internal system files (ignore)
 
 Follow all rules defined in `.cursor/rules/` for consistent development practices.
+
+## Codex
+
+When using OpenAI Codex in this repo, it reads **AGENTS.md** at the project root. That file summarizes the same norms (git, commits, comments, RBIN Task Flow) so Codex follows the same conventions as Cursor/Claude. Full details remain in `.cursor/rules/` and this file.