rbin-task-flow 1.19.5 → 1.23.0

package/.cursor/rules/commit_practices.mdc

@@ -1,141 +1,8 @@
 ---
-description: Commit practices after task and subtask completion, including automatic message suggestions
-globs: **/*
-alwaysApply: true
+description: Legacy commit examples — prefer rbin-git-policy.mdc (always-on). Invoke @rbin-git for full suggestion flow.
+alwaysApply: false
 ---
 
-- **Notification and Commit Suggestion After Tasks:**
-  - **Always notify user** when a task or subtask is marked as `done`
-  - **Suggest a commit message** based on changes made
-  - **Include context** of task/subtask in commit suggestion
-  - **CRITICAL: NEVER execute git commands** - only suggest, user executes
-
-- **When to Apply:**
-  - After `set_task_status` with status `done` for any task or subtask
-  - After complete implementation of a subtask
-  - After completion of a parent task (when all subtasks are done)
-
-- **Commit Suggestion Format:**
-  ```bash
-  # ✅ DO: Recommended format
-  git commit -m "feat(module): Short description of change
-  
-  - Implementation details
-  - Task/Subtask ID: X.Y
-  - Main changes made"
-  
-  # Real example:
-  git commit -m "feat(auth): Implement user login validation
-  
-  - Add email format validation
-  - Add password strength checks
-  - Task ID: 3.2"
-  ```
-
-- **Suggestion Process:**
-  1. **Analyze changes**: Use `git status` and `git diff` to identify modified files (read-only, never modify)
-  2. **Extract task context**: Include task/subtask ID and title/description
-  3. **Generate message**: Create message following conventional commits
-  4. **Present to user**: Show formatted suggestion ready to use
-  5. **NEVER execute**: Only suggest, user decides when and how to commit
-
-- **Commit Types (Conventional Commits):**
-  - `feat`: New feature (complete task)
-  - `fix`: Bug fix
-  - `refactor`: Refactoring without behavior change
-  - `docs`: Documentation changes
-  - `style`: Formatting, semicolons, etc (no code change)
-  - `test`: Test addition or fix
-  - `chore`: Build, dependency changes, etc
-
-- **Suggested Message Structure:**
-  ```bash
-  <type>(<scope>): <short description>
-  
-  <optional body with details>
-  - Task/Subtask: <ID>
-  - Modified files: <summary list>
-  ```
-
-- **Suggestion Examples:**
-  
-  **For implementation subtask:**
-  ```bash
-  git commit -m "feat(api): Add user authentication endpoint
-  
-  - Implement POST /api/auth/login
-  - Add JWT token generation
-  - Add input validation middleware
-  - Subtask ID: 5.3"
-  ```
-  
-  **For complete task:**
-  ```bash
-  git commit -m "feat(dashboard): Complete user analytics dashboard
-  
-  - Add real-time metrics display
-  - Implement chart visualizations
-  - Add data export functionality
-  - Task ID: 7"
-  ```
-  
-  **For fix:**
-  ```bash
-  git commit -m "fix(auth): Resolve token expiration issue
-  
-  - Fix JWT refresh logic
-  - Update token validation
-  - Subtask ID: 8.1"
-  ```
-
-- **Useful Commands for Analysis:**
-  - `git status --short` - List modified files compactly
-  - `git diff --stat` - Change statistics
-  - `git diff --name-only` - Only names of modified files
-  - `git log --oneline -5` - Last commits for context
-
-- **When NOT to Suggest Commit:**
-  - ❌ DON'T: If there are no git changes (no modified files)
-  - ❌ DON'T: If user already committed recently (last 5 minutes)
-  - ❌ DON'T: If there are unresolved merge conflicts
-  - ❌ DON'T: If repository is not a git repo
-
-- **Suggestion Presentation:**
-  - **Always notify user** when a task/subtask is completed with clear message and emoji ✅
-  - **Show formatted suggestion** ready to copy/paste
-  - **Include statistics** of changes (modified files, lines added/removed)
-  
-  **Presentation example:**
-  ```markdown
-  ✅ Task 3.2 completed!
-  
-  📝 Commit suggestion:
-  ```bash
-  git commit -m "feat(module): Change description
-  
-  - Detail 1
-  - Detail 2
-  - Task ID: 3.2"
-  ```
-  
-  📊 Changes detected:
-  - 3 files modified
-  - 45 lines added, 12 removed
-  ```
-
-- **Integration with RBIN Task Flow:**
-  - After marking a task as completed, automatically:
-    1. Check if there are git changes
-    2. Analyze modified files
-    3. Generate commit suggestion based on task
-    4. Present to user clearly
-
-- **Git Control:**
-  - **NEVER execute git commands** - only suggest
-  - Follow [git_control.mdc](mdc:.cursor/rules/git_control.mdc) for complete user control over git
-  - Present suggestions ready for user to copy and execute
-
-- **References:**
-  - Follow [Conventional Commits](https://www.conventionalcommits.org/) patterns
-  - Integrate with RBIN Task Flow workflow
-  - Git control: [git_control.mdc](mdc:.cursor/rules/git_control.mdc)
+- **Superseded by** [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc) (always-on).
+- **Skill:** `@rbin-git` for extended commit templates and Task Flow integration.
+- **Principle:** Suggest commits after `done`; user runs `git add` / `git commit`.

package/.cursor/rules/cursor_rules.mdc

@@ -1,9 +1,10 @@
 ---
-description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
-globs: .cursor/rules/*.mdc
-alwaysApply: true
+globs: .cursor/rules/**
+alwaysApply: false
 ---
 
+> **Invoke with `@cursor_rules` only** — manual `@` mention; no `description` (avoids broad Apply Intelligently matches).
+
 - **Required Rule Structure:**
   ```markdown
   ---

package/.cursor/rules/git_control.mdc

@@ -1,89 +1,8 @@
 ---
-description: Complete user control over Git commands - AI never executes git commands, but can execute any other command without asking
-globs: **/*
-alwaysApply: true
+description: Legacy git detail — prefer rbin-git-policy.mdc (always-on). Invoke @rbin-git for commit suggestions.
+alwaysApply: false
 ---
 
-- **General Command Permission:**
-  - **✅ 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
-  - **❌ 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:
-    - `cat`, `head`, `tail`, `less`, `more` - File viewing
-    - `grep`, `find`, `ls`, `tree` - Search and listing
-    - `wc`, `stat`, `file` - File information
-    - `read_file` (tool) - File reading
-    - Any command that **does not modify** files or system
-  - **✅ NEVER ask** before executing read commands
-  - **✅ Execute immediately** without waiting for user confirmation
-
-- **Absolute Prohibition of Executing Git Commands:**
-  - **❌ NEVER execute** `git` commands automatically
-  - **❌ NEVER do** `git add`, `git commit`, `git push`, `git pull`, `git merge`, etc
-  - **❌ NEVER modify** git repository state
-  - **✅ ONLY suggest** git commands when appropriate
-  - **✅ ONLY read** git information (git status, git diff, git log) for analysis
-
-- **Allowed Git Commands (Read Only):**
-  - ✅ `git status` - To check repository state
-  - ✅ `git diff` - To analyze changes
-  - ✅ `git log` - To view history
-  - ✅ `git show` - To view commit details
-  - ✅ `git branch` - To list branches (without creating/modifying)
-  - ✅ Any git command that **only reads** information
-
-- **Prohibited Git Commands (Never Execute):**
-  - ❌ `git add` - User adds files
-  - ❌ `git commit` - User makes commits
-  - ❌ `git push` - User pushes
-  - ❌ `git pull` - User pulls
-  - ❌ `git merge` - User merges
-  - ❌ `git checkout` - User switches branches
-  - ❌ `git branch -d` or `-D` - User deletes branches
-  - ❌ `git reset` - User resets
-  - ❌ `git rebase` - User rebases
-  - ❌ `git tag` - User creates tags
-  - ❌ Any command that **modifies** the repository
-
-- **When to Suggest Git Commands:**
-  - ✅ After task/subtask completion - suggest commit message
-  - ✅ When there are uncommitted changes - suggest commit
-  - ✅ When there are conflicts - suggest resolution (but don't execute)
-  - ✅ When update is needed - suggest pull (but don't execute)
-  - ✅ Always present as **suggestion**, never execute
-
-- **Suggestion Format:**
-  ```markdown
-  ✅ Task completed!
-
-  📝 Commit suggestion (you execute):
-  ```bash
-  git add .
-  git commit -m "feat(module): Description"
-  ```
-  ```
-
-  **NEVER do:**
-  ```bash
-  # ❌ DON'T: Execute automatically
-  git add .
-  git commit -m "..."
-  ```
-
-- **Exceptions and Special Cases:**
-  - **NO EXCEPTION for git**: This rule is absolute for git commands
-  - **For non-git commands**: Execute directly without asking
-  - **For git commands**: Even if user explicitly asks, **always suggest** instead of executing
-  - If in doubt about whether a command is git or not, check if it starts with `git` before executing
-
-- **Integration with Other Rules:**
-  - [commit_practices.mdc](mdc:.cursor/rules/commit_practices.mdc) - Suggest commits, never execute
-  - RBIN Task Flow workflow should not include automatic git execution
-
-- **Fundamental Principle:**
-  > **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.**
+- **Superseded by** [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc) (always-on).
+- **Skill:** `@rbin-git` for Conventional Commit suggestions after subtasks.
+- **Principle:** Never execute git write commands; read-only git is OK.

package/.cursor/rules/graphify-task-flow.mdc

@@ -0,0 +1,31 @@
+---
+description: Use Graphify knowledge graph only when executing RBIN Task Flow commands that need codebase navigation (task-flow run, think, review, audit). Prefer graphify query over blind grep when graphify-out exists. Never override task-flow status updates or git rules.
+alwaysApply: false
+---
+
+- **Graphify + RBIN Task Flow (coexistence):**
+  - **Graphify** maps repo structure (`graphify-out/graph.json`, `GRAPH_REPORT.md`). **Task Flow** owns tasks (`.task-flow/`), status, and commands `task-flow: …`.
+  - **Do not compete:** Task Flow rules (`task_work`, `task-flow-sync`, `rbin-git-policy`, etc.) always win for workflow, git, and status files.
+
+- **When to use Graphify:**
+  - **`task-flow: run` / `run next X`:** Before implementing a subtask in a non-trivial codebase, if `graphify-out/graph.json` exists, use `graphify query "<feature or module from subtask>"` or read `graphify-out/GRAPH_REPORT.md` god nodes — then implement. If no graph exists, proceed with normal search or suggest `graphify extract .`.
+  - **`task-flow: think`:** Optional `graphify query` for gap analysis on large repos.
+  - **`task-flow: review X`:** Optional `graphify affected "<symbol>"` to verify impact surface.
+  - **`task-flow: audit`:** Graphify is structural only; scoring uses [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc) checklist. Deep dive: sections of [coding-standards-full.md](mdc:.task-flow/docs/coding-standards-full.md) only if user asks for depth.
+
+- **When NOT to use Graphify:**
+  - `task-flow: sync`, `status`, `estimate`, `report`, `generate flow` — only `.task-flow/` files.
+  - Updating `status.json` / `tasks.status.md` — never defer to Graphify.
+  - Git write operations — [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc) only suggests commits.
+
+- **If `.cursor/rules/graphify.mdc` exists with upstream Graphify install:**
+  - Prefer this rule (`graphify-task-flow`) for Task Flow sessions; avoid duplicating full `GRAPH_REPORT.md` into context unless needed.
+  - RBIN Task Flow init sets upstream `graphify.mdc` to `alwaysApply: false` to save context.
+
+- **CLI (project root):**
+  - Build graph: `graphify extract .` (re-run after large refactors).
+  - Query: `graphify query "question"` · `graphify affected "node"`.
+  - Guide: [.task-flow/GRAPHIFY.md](mdc:.task-flow/GRAPHIFY.md)
+
+- **Principle:**
+  > **Task Flow decides what to do; Graphify helps find where in the code — only during implementation and exploration commands.**

package/.cursor/rules/rbin-git-policy.mdc

@@ -0,0 +1,47 @@
+---
+description: RBIN git policy — never write git; suggest Conventional Commits after Task Flow work. User runs all git write commands.
+alwaysApply: true
+---
+
+# RBIN — Git policy (always)
+
+## Non-git commands
+
+- **May run without asking:** npm, tests, linters, docker, scripts, read-only shell (`cat`, `grep`, `ls`, `read_file`), etc.
+- **Do not run without approval:** cloud/remote provisioning, DB migrations against remote DB, production deploy.
+
+## Git write — never execute
+
+Never run: `git add`, `commit`, `push`, `pull`, `merge`, `checkout`, `reset`, `rebase`, `tag`, `branch -d`/`-D`, or any command that modifies the repo.
+
+Even if the user asks to commit — **suggest** the command; they execute it.
+
+## Git read — allowed
+
+`git status`, `git diff`, `git log`, `git show`, `git branch` (list only) — use to analyze changes before suggesting a commit.
+
+## After Task Flow subtask or task `done`
+
+1. Notify completion (clear message).
+2. If there are uncommitted changes: suggest commit (never run it).
+3. Read-only: `git status --short`, `git diff --stat` (optional).
+4. Include Task/Subtask ID and title in the message.
+
+**Do not suggest commit** if: no changes, merge conflicts, or not a git repo.
+
+## Conventional Commits
+
+Types: `feat`, `fix`, `refactor`, `docs`, `style`, `test`, `chore`.
+
+```bash
+git commit -m "feat(scope): Short description
+
+- Detail
+- Subtask ID: 3.2"
+```
+
+## On demand
+
+Extended examples and presentation: `@rbin-git` skill · legacy [commit_practices.mdc](mdc:.cursor/rules/commit_practices.mdc), [git_control.mdc](mdc:.cursor/rules/git_control.mdc).
+
+**Principle:** AI may act freely except git writes and risky remote ops — user owns git history.

package/.cursor/rules/self_improve.mdc

@@ -1,9 +1,9 @@
 ---
-description: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
-globs: **/*
-alwaysApply: true
+alwaysApply: false
 ---
 
+> **Invoke with `@self_improve` only** — manual `@` mention; not Apply Intelligently.
+
 - **Rule Improvement Triggers:**
   - New code patterns not covered by existing rules
   - Repeated similar implementations across files

package/.cursor/rules/task-flow-cursor.mdc

@@ -0,0 +1,51 @@
+---
+description: RBIN Task Flow entry point for Cursor. When the user says task flow, task-flow, or any task-flow colon command, follow Task Flow paths and invoke the matching skill or rule below.
+alwaysApply: true
+---
+
+# RBIN Task Flow (Cursor)
+
+**Task flow** = **RBIN Task Flow**. Data lives in `.task-flow/` — never edit `.internal/` by hand.
+
+| Path | Purpose |
+|------|---------|
+| `.task-flow/tasks.input.txt` | Define tasks (`- description`) |
+| `.task-flow/tasks.status.md` | Progress (auto) |
+| `.task-flow/.internal/tasks.json` | Definitions |
+| `.task-flow/.internal/status.json` | Status source of truth |
+| `.task-flow/contexts/` | Specs / mockups |
+
+## Prefer skills (`.cursor/skills/`)
+
+| User intent | Invoke |
+|-------------|--------|
+| `task-flow: sync` | `@task-flow-sync` or [task-flow-sync.mdc](mdc:.cursor/rules/task-flow-sync.mdc) |
+| `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` |
+| Implementing code | `@rbin-coding-standards` |
+| Suggest commit | `@rbin-git` |
+
+Natural language (`work on next 3 subtasks`) = same as `task-flow: run next 3`.
+
+## Git (always)
+
+Never write git — user runs all commits. Policy: [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc). Suggest via `@rbin-git`.
+
+## Graphify (optional)
+
+On `run` / `think`, if `graphify-out/` exists: `graphify query` before repo-wide grep. Rule: `graphify-task-flow`. Guide: `.task-flow/GRAPHIFY.md`.
+
+## More detail
+
+- Workflows: `.task-flow/CURSOR.md`
+- Full guide: `.task-flow/platforms/cursor.md`
+- Codex parity: `.task-flow/CODEX.md`

package/.cursor/rules/task-flow-sync.mdc

@@ -0,0 +1,46 @@
+---
+description: Full task-flow sync — reconciles tasks.input.txt with tasks.json, status.json, and tasks.status.md. Use for task-flow sync, sync tasks, or sincronizar tasks. Prefer @task-flow-sync skill.
+globs: .task-flow/**
+alwaysApply: false
+---
+
+# task-flow: sync
+
+**Prefer:** `@task-flow-sync` · Skill workflow: `.claude/skills/task-flow-sync/workflow.md`
+
+## 1. Read
+
+- `.task-flow/tasks.input.txt` (lines starting with `- ` only)
+- `.task-flow/.internal/tasks.json`, `status.json` if they exist
+- List `.task-flow/contexts/` for matching references
+
+## 2. Diff by `originalRequest`
+
+| Change | Action |
+|--------|--------|
+| **New** | Generate task + 3–8 subtasks; all `pending` |
+| **Removed** | Drop from `tasks.json`, `status.json`, `tasks.status.md` |
+| **Modified** | Update title/description; regen subtasks; **preserve** done/pending status where possible |
+| **Unchanged** | Leave task data and status as-is |
+
+Task IDs stay sequential (1, 2, 3…) matching `tasks.input.txt` order.
+
+## 3. New / regenerated subtasks
+
+- `originalRequest`: exact input line; `createdAt`: ISO 8601 for new tasks
+- 3–8 subtasks: title, description, instructions (3–5 steps)
+- Contexts: keyword match or `task-flow-screen file.ext` → `.task-flow/contexts/file.ext`
+- Subtask instructions: **checklist** in [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc) only — not [coding-standards-full.md](mdc:.task-flow/docs/coding-standards-full.md)
+- More templates: [task_generation.mdc](mdc:.cursor/rules/task_generation.mdc)
+
+**Sync rules:** no codebase exploration; no questions; do not fill `tasks.flow.md` (only `generate flow`).
+
+## 4. Align status
+
+- `status.json` = source of truth
+- Rebuild `tasks.status.md` checkboxes to match; **regenerate 📊 Summary** (completed / in progress / remaining counts)
+- After regen: new subtasks → `pending`; keep `done` on matched subtasks when possible
+
+## 5. Principles
+
+> Preserve progress when possible. Fast: read → diff → write. User runs `task-flow: status` or `@task-flow-run` next.