rbin-task-flow 1.19.4 → 1.23.0

package/.cursor/rules/task_analysis.mdc

@@ -1,191 +1,43 @@
 ---
-description: Sync .task-flow-tasks.txt with task system and analyze codebase for new tasks
-globs: **/*
-alwaysApply: true
+description: Suggests new tasks for tasks.input.txt via task-flow think. Use for think, suggest tasks, analyze codebase for missing tasks — not for sync (use task-flow-sync.mdc).
+alwaysApply: false
 ---
 
-- **Task Sync - Complete Synchronization:**
-  - **FASTEST FORMAT**: `task-flow: sync` → Complete sync of tasks.input.txt with system
-  - When user says "task-flow: sync" or "task-flow sync":
-    - **READ**: `.task-flow/tasks.input.txt` to find all tasks
-    - **READ**: `.task-flow/.internal/tasks.json` and `.task-flow/.internal/status.json` to see existing tasks and their status
-    - **SYNC**: Fully synchronize tasks and status between tasks.input.txt and system files
-    - **PRESERVE**: Keep status of existing tasks (done/pending/in_progress) when possible
+# task-flow: think
 
-- **Complete Sync Process:**
-  1. **Read files**:
-     - Read `.task-flow/tasks.input.txt` (all tasks from user input)
-     - Read `.task-flow/.internal/tasks.json` (existing generated tasks)
-     - Read `.task-flow/.internal/status.json` (existing task status)
-  
-  2. **Compare and identify changes**:
-     - **New tasks**: Tasks in tasks.input.txt that don't exist in tasks.json (by comparing `originalRequest`)
-     - **Removed tasks**: Tasks in tasks.json that don't exist in tasks.input.txt
-     - **Modified tasks**: Tasks that exist in both but `originalRequest` changed (text modified)
-     - **Unchanged tasks**: Tasks that exist in both with same `originalRequest`
-  
-  3. **Process new tasks**:
-     - For each new task in tasks.input.txt:
-       - Generate subtasks following [task_generation.mdc](mdc:.cursor/rules/task_generation.mdc) rules
-       - Add to tasks.json with sequential ID
-       - Add to status.json with "pending" status for task and all subtasks
-       - Add to tasks.status.md with `- [ ]` format
-  
-  4. **Process removed tasks**:
-     - For each task in tasks.json not found in tasks.input.txt:
-       - Remove from tasks.json
-       - Remove from status.json
-       - Remove from tasks.status.md
-  
-  5. **Process modified tasks**:
-     - For each task where `originalRequest` changed:
-       - Update title and description in tasks.json based on new text
-       - Regenerate subtasks (following task_generation.mdc rules)
-       - **PRESERVE STATUS**: Keep existing status from status.json (task and subtasks)
-       - Update tasks.status.md with new subtasks but preserve status marks (`- [x]` for done, `- [ ]` for pending)
-  
-  6. **Process unchanged tasks**:
-     - Keep tasks.json unchanged
-     - Keep status.json unchanged
-     - Keep tasks.status.md unchanged (preserve all status marks)
-  
-  7. **Synchronize status between files**:
-     - Read current `status.json` to get all existing statuses
-     - Read current `tasks.status.md` to get status marks
-     - **Compare and sync**: Ensure `status.json` and `tasks.status.md` are perfectly aligned
-     - If there are inconsistencies:
-       - Use `status.json` as source of truth for status values
-       - Update `tasks.status.md` to match `status.json` (convert "done" → `- [x]`, "pending" → `- [ ]`)
-       - Ensure both files reflect the same status for all tasks and subtasks
-  
-  8. **Rebuild files**:
-     - Rebuild tasks.json with all tasks in correct order (matching tasks.input.txt order)
-     - Rebuild status.json preserving all existing statuses (or updating if needed)
-     - Rebuild tasks.status.md with all tasks and correct status marks (synchronized with status.json)
-     - **DO NOT** update or populate `.task-flow/tasks.flow.md` — that file is filled only by `task-flow: generate flow`
-     - **ALWAYS regenerate summary section** at the top of tasks.status.md:
-       - Count completed tasks (all subtasks done)
-       - Count in-progress tasks (some subtasks done)
-       - Total remaining subtasks
-       - List each task with status and remaining subtasks count
-  
-  **Critical Rules:**
-  - ✅ Always preserve status of existing tasks/subtasks when possible
-  - ✅ **SYNC STATUS**: Ensure `status.json` and `tasks.status.md` are always synchronized
-  - ✅ Use `status.json` as source of truth, update `tasks.status.md` to match
-  - ✅ When regenerating subtasks for modified tasks, try to match existing subtasks by title/description
-  - ✅ If subtasks change significantly, mark new ones as "pending" but keep old ones as "done" if they were done
-  - ✅ Maintain sequential task IDs (1, 2, 3...) matching order in tasks.input.txt
-  - ✅ When removing tasks, remove all associated data (subtasks, status)
-  - ✅ After any status change, update BOTH `status.json` and `tasks.status.md` to keep them in sync
+**Not sync.** For `task-flow: sync` use [task-flow-sync.mdc](mdc:.cursor/rules/task-flow-sync.mdc) or `@task-flow-sync`.
 
-- **Task Analysis - Suggest New Tasks:**
-  - **FAST FORMAT**: `task-flow: think` → Analyze codebase and suggest new tasks
-  - When user says "task-flow: think", "analyze if there are new tasks to create", "check for new tasks", or "suggest tasks":
-    - **ANALYZE**: Current codebase, recent changes, TODOs, FIXMEs, and project structure
-    - **SUGGEST**: New tasks that should be added to `.task-flow/tasks.input.txt`
-    - **FORMAT**: Use RBIN Task Flow format: `- Task description` (no [ ] needed)
-    - **ASK**: Always ask user if they want to add the suggested tasks
-    - **ONLY ACTION**: If user confirms, add tasks to `.task-flow/tasks.input.txt` - nothing else
-    - **DON'T**: Automatically add tasks without confirmation
+**Prefer:** `@task-flow-think` · After user adds lines: `@task-flow-sync`
 
-- **Analysis Process:**
-  1. **Read existing tasks**: Check `.task-flow/tasks.input.txt` to see what's already planned
-  2. **Analyze codebase**: Look for:
-     - TODO/FIXME comments in code
-     - Missing tests or incomplete test coverage
-     - Incomplete features or half-implemented functionality
-     - Code quality issues (refactoring opportunities)
-     - Missing documentation
-     - Security improvements needed
-     - Performance optimizations
-     - Missing error handling
-  3. **Check recent changes**: Review git history or recent file modifications
-  4. **Identify gaps**: Compare what exists vs what should exist
-  5. **Suggest tasks**: Propose specific, actionable tasks
+## When to run
 
-- **Task Suggestion Format:**
-  ```markdown
-  ## Suggested Tasks for tasks.input.txt
-  
-  - Add unit tests for UserService
-  - Implement error handling in API endpoints
-  - Refactor authentication middleware
-  - Add API documentation with Swagger
-  - Optimize database queries in ReportService
-  ```
+User says `task-flow: think`, `suggest tasks`, `check for new tasks`, `analyze codebase for tasks`, etc.
 
-- **When User Confirms:**
-  - If user wants to add suggested tasks:
-    - Read `.task-flow/tasks.input.txt`
-    - Append new tasks (maintaining existing format)
-    - Don't remove or modify existing tasks
-    - Keep one task per line with `- ` format (no [ ] needed)
+## Process
 
-- **Natural Language Phrases:**
-  - **FAST FORMAT**: `task-flow: sync` or `task-flow sync` → Sync tasks.input.txt with system
-  - **FAST FORMAT**: `task-flow: think` or `task-flow think` → Analyze and suggest new tasks
-  - "sync tasks" → Same as task-flow: sync
-  - "sincronizar tasks" → Same as task-flow: sync
-  - "analise se tem tasks novas para criar" → Same as task-flow: think
-  - "check for new tasks" → Same as task-flow: think
-  - "suggest tasks" → Same as task-flow: think
-  - "what tasks should I add?" → Same as task-flow: think
-  - "analyze codebase for tasks" → Same as task-flow: think
-  - "find missing tasks" → Same as task-flow: think
+1. Read `.task-flow/tasks.input.txt` (existing planned tasks)
+2. Scan codebase for gaps: TODO/FIXME, missing tests, incomplete features, docs, security, performance, error handling
+3. Propose **specific** lines: `- Task description` (no `[ ]`)
+4. **Ask** before adding to `tasks.input.txt` — never auto-add
+5. If user confirms: append only; do not remove or edit existing lines
+6. Suggest `task-flow: sync` after input changes
 
-- **Example Workflows:**
-  ```
-  User: "task-flow: sync"
-  
-  AI Action (Complete Sync):
-  1. Read .task-flow/tasks.input.txt:
-     - Task 1: "Create auth system" (exists, unchanged)
-     - Task 2: "Add database" (MODIFIED - was "Setup database")
-     - Task 3: "New feature" (NEW - not in tasks.json)
-     - Task 4: REMOVED (was in tasks.json, not in tasks.input.txt)
-  
-  2. Read .task-flow/.internal/tasks.json:
-     - Task 1: exists, status: done
-     - Task 2: exists, status: in_progress (subtask 2.1 done, 2.2 pending)
-     - Task 4: exists, status: pending
-  
-  3. Process changes:
-     - Task 1: Unchanged → Keep as is, preserve status "done"
-     - Task 2: Modified → Update title/description, regenerate subtasks, PRESERVE status (2.1 done, 2.2 pending)
-     - Task 3: New → Generate subtasks, add with status "pending"
-     - Task 4: Removed → Remove from all files
-  
-  4. Sync status between files:
-     - Compare status.json and tasks.status.md
-     - Ensure both reflect same status (done → `- [x]`, pending → `- [ ]`)
-     - Update tasks.status.md to match status.json if inconsistencies found
-  
-  5. Rebuild files:
-     - tasks.json: Tasks 1, 2 (updated), 3 (new) - in order
-     - status.json: Preserve Task 1 (done), Task 2 (in_progress with preserved subtask status), Task 3 (pending)
-     - tasks.status.md: Reflect all changes with correct status marks, synchronized with status.json
-  
-  User: "task-flow: think"
-  AI Action (Analyze):
-  1. Read .task-flow/tasks/tasks.input.txt (existing tasks)
-  2. Analyze codebase for TODOs, missing features, etc.
-  3. Suggest new tasks:
-     - Add input validation to login endpoint
-     - Create migration for user preferences table
-     - Write tests for PaymentService
-  4. Ask: "Do you want to add these tasks to tasks.input.txt? [y/N]"
-  5. If user confirms (y): Add tasks to tasks.input.txt
-  6. If user declines (n): Do nothing, just show suggestions
-  
-  User: "analise se tem tasks novas para criar no task flow"
-  AI Action: Same as task-flow: think
-  ```
+## Output format
 
-- **Integration:**
-  - Works with [task_generation.mdc](mdc:.cursor/rules/task_generation.mdc) - after adding tasks, user can generate subtasks
-  - Follows [task_execution.mdc](mdc:.cursor/rules/task_execution.mdc) workflow
-  - Respects [git_control.mdc](mdc:.cursor/rules/git_control.mdc) - never commit automatically
+```markdown
+## Suggested Tasks for tasks.input.txt
 
-- **Principle:**
-  > **Analyze the codebase intelligently to suggest meaningful tasks. Don't add tasks automatically - let the user review and decide. Focus on actionable, specific tasks that improve the project.**
+- Add unit tests for UserService
+- Implement error handling in API endpoints
+```
+
+## Optional roadmap
+
+For package improvements see [.task-flow/OPTIMIZATION-PLAN.md](mdc:.task-flow/OPTIMIZATION-PLAN.md) — not part of think unless user asks.
+
+## Integration
+
+- [task-flow-sync.mdc](mdc:.cursor/rules/task-flow-sync.mdc) after new tasks are added
+- [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc) — never commit automatically
+
+**Principle:** Suggest actionable tasks; user decides what enters `tasks.input.txt`.

package/.cursor/rules/task_audit.mdc

@@ -1,19 +1,18 @@
 ---
-description: Audit codebase against coding standards and suggest incremental improvements
-globs: **/*
-alwaysApply: true
+description: Audits full codebase against coding standards for task-flow audit. Non-destructive; user chooses improvements.
+alwaysApply: false
 ---
 
 # 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).
+When the user runs `task-flow: audit`, perform a non-destructive analysis against the **checklist** in [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc). For deep architecture or examples, read only relevant sections of [coding-standards-full.md](mdc:.task-flow/docs/coding-standards-full.md) — do not load the entire file unless the user asks for depth.
 
 ---
 
 ## 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
+2. **Compares against the coding_standards checklist** 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
@@ -37,6 +36,8 @@ Scan the codebase to understand:
 
 ### Step 2 — Score each category
 
+Score using the **checklist** in [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc). For a category that needs examples (Nest gateways, DataHandler, long patterns), read **one section** of [coding-standards-full.md](mdc:.task-flow/docs/coding-standards-full.md) — not the whole file unless the user requests depth.
+
 For each category below, rate adherence: **Full / Partial / Missing**
 
 | Category | Score | Notes |

package/.cursor/rules/task_check.mdc

@@ -1,7 +1,6 @@
 ---
-description: Run lint fix when available, then build the current project
-globs: **/*
-alwaysApply: true
+description: Runs lint fix and build for task-flow check until project passes.
+alwaysApply: false
 ---
 
 # task-flow: check

package/.cursor/rules/task_estimate.mdc

@@ -1,7 +1,6 @@
 ---
-description: Task time estimation based on real task complexity for an average developer pace
-globs: **/*
-alwaysApply: true
+description: Estimates hours for task-flow estimate X. Average developer pace, no AI acceleration.
+alwaysApply: false
 ---
 
 - **Task Estimation - Time Estimation for Tasks:**
@@ -75,7 +74,7 @@ alwaysApply: true
   ```
 
 - **Integration:**
-  - Works with [task_execution.mdc](mdc:.cursor/rules/task_execution.mdc) workflow
+  - Works with [task-flow-cursor.mdc](mdc:.cursor/rules/task-flow-cursor.mdc) / `@task-flow-estimate`
   - Uses task data from `.task-flow/.internal/tasks.json`
   - Estimates are informational only (not stored)
 

package/.cursor/rules/task_execution.mdc

@@ -1,141 +1,29 @@
 ---
-description: Task management workflow with RBIN Task Flow
-globs: **/*
-alwaysApply: true
+description: Task Flow command index — use task-flow-cursor.mdc and @skills first. Legacy pointer only; do not duplicate CLAUDE.md.
+alwaysApply: false
 ---
 
-- **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)
-  - Task files: `.internal/tasks.json` (definitions), `.internal/status.json` (progress tracking), and `tasks.status.md` (human-readable status)
-
-- **Task Definition:**
-  - Edit `.task-flow/tasks.input.txt` to define tasks
-  - Use simple format: `- Task description` (no [ ] needed)
-  - AI will generate detailed subtasks from descriptions
-  - Keep descriptions clear and actionable
-
-- **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: check` - Run lint fix when available, then build the current project
-  - `task-flow: improve changes` - Audit only files changed in the current diff against `HEAD`
-  - `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)
-  - `task-flow: run all` - Work on all tasks
-  - `task-flow: status` - Show current task status
-  - `task-flow: review X` - Review specific task(s) (comma-separated or "all")
-  - `task-flow: refactor X` - Refactor specific task(s) (comma-separated or "all")
-  - `task-flow: estimate X` - Estimate time for task X (simplified - no "task" needed)
-  - `task-flow: estimate X,Y` - Estimate multiple tasks (comma-separated)
-  - `task-flow: estimate all` - Estimate all tasks
-  - `task-flow: report X` - Generate implementation report for task X (simplified - no "task" needed)
-  - `task-flow: report X,Y` - Generate reports for multiple tasks (comma-separated)
-  - `task-flow: report all` - Generate reports for all tasks
-  - `task-flow: generate flow` - Populate tasks.flow.md with dependencies, estimated hours, and AI model recommendations
-
-- **Workflow Example:**
-  ```markdown
-  1. Add tasks to `.task-flow/tasks.input.txt`:
-     - Implement user authentication
-     - Add database migrations
-     - Create API endpoints
-
-  2. Use AI command: task-flow: sync (generates detailed subtasks)
-  3. Use AI command: task-flow: status (view all tasks and progress)
-  4. Use AI command: task-flow: run next X (work on next X subtasks)
-  5. Tasks are automatically marked as done when completed
-  6. Use AI command: task-flow: review (verify completed tasks)
-  ```
-
-- **Commit Workflow:**
-  - After completing tasks, follow [commit_practices.mdc](mdc:.cursor/rules/commit_practices.mdc)
-  - Never execute git commands directly - follow [git_control.mdc](mdc:.cursor/rules/git_control.mdc)
-  - Suggest commits with descriptive messages referencing completed tasks
-
-- **Commit Message Format:**
-  ```bash
-  git add .
-  git commit -m "feat(module): Complete tasks from RBIN Task Flow
-
-  - Task 1: [description]
-  - Task 2: [description]
-
-  Completed via RBIN Task Flow"
-  ```
-
-- **Integration with Other Rules:**
-  - Follow [commit_practices.mdc](mdc:.cursor/rules/commit_practices.mdc) for commit format
-  - Follow [git_control.mdc](mdc:.cursor/rules/git_control.mdc) - NEVER execute git, only suggest
-  - See `CLAUDE.md` for complete RBIN Task Flow documentation
-  - See `README.md` for installation and setup instructions
-
-- **Best Practices:**
-  - Keep task descriptions concise but clear
-  - Let AI generate detailed implementation steps
-  - Review generated subtasks before starting work
-  - Update task status regularly through the menu
-  - Commit work frequently referencing task progress
-
-- **Task Generation:**
-  - See [task_generation.mdc](mdc:.cursor/rules/task_generation.mdc) for direct task generation rules
-  - When generating tasks, be efficient: read tasks.input.txt, generate JSONs, save files
-  - No need to explore codebase or read other files
-
-- **Task Analysis:**
-  - See [task_analysis.mdc](mdc:.cursor/rules/task_analysis.mdc) for analyzing codebase to suggest new tasks
-  - When user asks to analyze for new tasks, intelligently scan codebase and suggest additions
-
-- **Simplified Task Work:**
-  - See [task_work.mdc](mdc:.cursor/rules/task_work.mdc) for simplified "do next X subtasks" commands
-  - When user says "work on next X subtasks" or similar phrases, automatically find and implement them
-
-- **Task Review:**
-  - See [task_review.mdc](mdc:.cursor/rules/task_review.mdc) for reviewing completed tasks
-  - When user says "task-flow: review", verify if completed tasks are actually done
-
-- **Task Refactor:**
-  - See [task_refactor.mdc](mdc:.cursor/rules/task_refactor.mdc) for refactoring code from current commit
-  - When user says "task-flow: refactor", improve code quality without changing functionality
-
-- **Task Flow Generation:**
-  - See [task_generate_flow.mdc](mdc:.cursor/rules/task_generate_flow.mdc) for populating tasks.flow.md
-  - When user says "task-flow: generate flow", populate dependencies and model recommendations
-
-- **Task Flow Commands - Natural Language Interpretation:**
-  - **CRITICAL**: When user mentions **"task flow"**, they **ALWAYS** refer to **RBIN Task Flow**
-  - Common phrases that mean "work on RBIN Task Flow subtasks":
-    - "work on next x subtasks from task flow"
-    - "next subtasks from task flow"
-    - "task flow subtasks"
-    - "do next x subtasks"
-    - Any variation mentioning "task flow" + "subtasks"
-
-- **When User Asks to Work on Subtasks:**
-  - **STEP 1**: Read `.task-flow/.internal/tasks.json` and `.task-flow/.internal/status.json`
-  - **STEP 2**: Find next X pending subtasks in sequential order:
-    - Order: Task 1 → Subtask 1, 2, 3... → Task 2 → Subtask 1, 2, 3...
-    - Only count subtasks with status "pending"
-    - Skip subtasks already "done" or "in_progress"
-  - **STEP 3**: For each subtask:
-    - Read instructions from `.internal/tasks.json`
-    - Implement following step-by-step instructions
-    - After completion: Update `.internal/status.json` (subtask → "done") and `tasks.status.md` (mark as `- [x]`)
-  - **STEP 4**: If all subtasks of a task are done, update task status to "done" in both files
-
-- **Example:**
-  - User: "work on next 3 subtasks from task flow"
-  - Interpretation: Work on next 3 pending subtasks from RBIN Task Flow
-  - Action:
-    1. Read `.task-flow/.internal/tasks.json` and `.task-flow/.internal/status.json`
-    2. Find first 3 pending subtasks (e.g., 1.1, 1.2, 1.3 if all pending)
-    3. Work on 1.1 → mark done in .internal/status.json and tasks.status.md → work on 1.2 → mark done → work on 1.3 → mark done
-    4. Update both .internal/status.json and tasks.status.md after each completion
-
-- **Principle:**
-  > **Use RBIN Task Flow's AI commands for all task management. Define tasks in plain text, let AI generate details, track progress through tasks.status.md, and commit work with descriptive messages.**
+# RBIN Task Flow — Command index (stub)
+
+**Prefer:** [task-flow-cursor.mdc](mdc:.cursor/rules/task-flow-cursor.mdc) (always-on) · Claude: [CLAUDE.md](mdc:CLAUDE.md) · Codex: [AGENTS.md](mdc:AGENTS.md) · Details: [.task-flow/README.md](mdc:.task-flow/README.md)
+
+**Task flow** = RBIN Task Flow. Data: `.task-flow/` — never edit `.internal/` by hand.
+
+| Command | Invoke |
+|---------|--------|
+| `task-flow: sync` | `@task-flow-sync` |
+| `task-flow: run next X`, `run N` | `@task-flow-run` |
+| `task-flow: status` | `@task-flow-status` |
+| `task-flow: think` | `@task-flow-think` |
+| `task-flow: check` | `@task-flow-check` |
+| `task-flow: audit` | `@task-flow-audit` |
+| `task-flow: improve changes` | `@task-flow-improve-changes` |
+| `task-flow: review X` | `@task-flow-review` |
+| `task-flow: refactor X` | `@task-flow-refactor` |
+| `task-flow: estimate X` | `@task-flow-estimate` |
+| `task-flow: report X` | `@task-flow-report` |
+| `task-flow: generate flow` | `@task-flow-generate-flow` |
+| Implement code | `@rbin-coding-standards` |
+| Suggest commit | `@rbin-git` |
+
+Git: [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc). Run fallback: [task_work.mdc](mdc:.cursor/rules/task_work.mdc).

package/.cursor/rules/task_generate_flow.mdc

@@ -1,7 +1,6 @@
 ---
-description: Generate task flow with dependencies, estimated hours, and AI model recommendations
-globs: **/*
-alwaysApply: true
+description: Populates tasks.flow.md with dependencies and hours for task-flow generate flow.
+alwaysApply: false
 ---
 
 - **Task Flow Generation - Dependencies, Hours & Model Recommendations:**

package/.cursor/rules/task_generation.mdc

@@ -1,155 +1,37 @@
 ---
-description: Direct task generation from tasks.input.txt - be efficient and direct
-globs: .task-flow/tasks.input.txt, .task-flow/.internal/tasks.json, .task-flow/.internal/status.json
-alwaysApply: true
+description: Subtask generation templates and context rules for new tasks from tasks.input.txt. For task-flow sync use task-flow-sync.mdc or @task-flow-sync — not this file alone.
+globs: .task-flow/**
+alwaysApply: false
 ---
 
-- **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/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
+# Task generation (subtasks only)
 
-- **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)
+**Primary sync workflow:** [task-flow-sync.mdc](mdc:.cursor/rules/task-flow-sync.mdc) · `@task-flow-sync`
 
-- **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 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 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)
-  8. Write all three files immediately
+Use this rule for **subtask shape** when `task-flow-sync` creates or regenerates tasks.
 
-- **tasks.json Structure:**
-  ```json
-  {
-    "tasks": [
-      {
-        "id": 1,
-        "title": "Task Title",
-        "description": "Task description",
-        "originalRequest": "- Task description from tasks.input.txt",
-        "createdAt": "ISO 8601 timestamp",
-        "subtasks": [
-          {
-            "id": 1,
-            "title": "Subtask Title",
-            "description": "What this subtask does",
-            "instructions": "Step 1: Action\nStep 2: Action\nStep 3: Verify"
-          }
-        ]
-      }
-    ]
-  }
-  ```
+## Contexts
 
-- **status.json Structure:**
-  ```json
-  {
-    "tasks": {
-      "1": {
-        "status": "pending",
-        "subtasks": {
-          "1": "pending",
-          "2": "pending"
-        }
-      }
-    }
-  }
-  ```
+- Always list `.task-flow/contexts/` (all file types)
+- Match by keywords or `task-flow-screen nome.ext` → `.task-flow/contexts/nome.ext`
+- In instructions: `Context/reference: .task-flow/contexts/filename.ext`
 
-- **tasks.status.md Structure:**
-  ```markdown
-  # Task Status
+## Subtasks (per task)
 
-  <!-- ⚠️ WARNING: This file is automatically updated by AI. DO NOT edit manually. -->
+- 3–8 subtasks; sequential ids 1, 2, 3…
+- Title, description, instructions (3–5 steps)
+- Follow **checklist** in [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc): `src/app/`, `src/features/`, `src/shared/`, naming suffixes, service+use-case, `cn()`, RHF+zod
 
-  ## 📊 Summary
+## File structures (minimal)
 
-  - ✅ **Completed Tasks**: 0
-  - ⏳ **Tasks in Progress**: 2
-  - 📝 **Remaining Subtasks**: 8
+**tasks.json:** `id`, `title`, `description`, `originalRequest`, `createdAt`, `subtasks[]` with `id`, `title`, `description`, `instructions`.
 
-  **Tasks:**
-  - ✅ Task 1: First task (complete)
-  - ⏳ Task 2: Second task (3 remaining subtasks out of 5)
+**status.json:** `tasks.{id}.status`, `tasks.{id}.subtasks.{subtaskId}` → `pending` | `done` | `in_progress`.
 
-  ---
+**tasks.status.md:** banner “do not edit”; 📊 Summary; tasks `- [ ]`/`- [x]`; subtasks indented with two spaces.
 
-  ## Tasks
+## Rules
 
-  - [x] First task
-
-    - [x] Subtask Title 1
-    - [x] Subtask Title 2
-
-  - [ ] Second task
-
-    - [x] Subtask Title 1
-    - [ ] Subtask Title 2
-    - [ ] Subtask Title 3
-  ```
-  - **ALWAYS include summary section** at the top with:
-    - ✅ Completed tasks (all subtasks done)
-    - ⏳ Tasks in progress (some subtasks done)
-    - 📝 Total remaining subtasks
-    - List of tasks with status and how many subtasks remain
-  - All tasks and subtasks start as `- [ ]` (pending)
-  - Format: Task title with `- [ ]` or `- [x]`, then subtasks indented with `  - [ ]` or `  - [x]`
-  - **CRITICAL**: Always regenerate summary when updating tasks.status.md
-
-- **Example:**
-  - Input (`tasks.input.txt`): `- Create authentication system`
-  - 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
-  
-- **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/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. Always follow coding_standards.mdc patterns in subtask instructions.**
+- Be direct: generate → save; no codebase exploration beyond `contexts/`
+- No questions during generation
+- Regenerate summary in `tasks.status.md` when that file is rebuilt