rbin-task-flow 1.25.0 → 1.26.0

package/.claude/skills/task-flow-generate-flow/SKILL.md

@@ -1,15 +0,0 @@
----
-name: task-flow-generate-flow
-description: Populates tasks.flow.md with dependencies, billing hours, and model recommendations for RBIN Task Flow tasks. Use when the user says task-flow generate flow, gerar flow, or tasks flow dependencies.
-disable-model-invocation: true
-paths: [".task-flow/**"]
----
-
-# Task Flow — Generate flow
-
-1. Read `.task-flow/.internal/tasks.json` and optional `status.json`.
-2. For each task: dependencies, hour range (billing), 3 models (GPT-5.x, Composer, Claude Haiku/Sonnet only — **never Opus**).
-3. Write `.task-flow/tasks.flow.md` (overwrite populated sections).
-4. Use AI judgment for model order and effort per task.
-
-Reference: `.cursor/rules/task_generate_flow.mdc`

package/.claude/skills/task-flow-improve-changes/SKILL.md

@@ -1,15 +0,0 @@
----
-name: task-flow-improve-changes
-description: Audits only uncommitted files against coding standards. Use when the user says task-flow improve changes, audit my diff, or check uncommitted changes against standards.
-disable-model-invocation: true
----
-
-# Task Flow — Improve changes
-
-1. Run `git diff --name-only HEAD` (read-only git).
-2. If empty, stop — no uncommitted changes.
-3. Audit **only** those paths using the same checklist as audit (`.cursor/rules/coding_standards.mdc`). Full reference: `.task-flow/guides/coding-standards-full.md` — relevant sections only if a category needs depth.
-4. Present findings; ask what to fix.
-5. Does **not** run lint/build — use `/task-flow-check` separately.
-
-Reference: `.cursor/rules/task_improve_changes.mdc`

package/.claude/skills/task-flow-refactor/SKILL.md

@@ -1,14 +0,0 @@
----
-name: task-flow-refactor
-description: Refactors code for task X without changing behavior; removes explanatory comments. Use when the user says task-flow refactor X or refactor completed task code.
-disable-model-invocation: true
----
-
-# Task Flow — Refactor
-
-1. Identify files related to task X (from implementation scope).
-2. Remove explanatory comments; keep only `// ────────────────────────────────` section separators.
-3. Improve names/structure; **no** behavior change.
-4. Never run git write commands.
-
-Reference: `.cursor/rules/task_refactor.mdc`, `.cursor/rules/code_comments.mdc`

package/.claude/skills/task-flow-review/SKILL.md

@@ -1,14 +0,0 @@
----
-name: task-flow-review
-description: Verifies completed RBIN Task Flow tasks are actually implemented in the codebase. Use when the user says task-flow review X, review task 1, or verify done tasks.
-disable-model-invocation: true
----
-
-# Task Flow — Review
-
-1. Read `tasks.json`, `status.json` for task ID(s) X or `all`.
-2. For each subtask marked `done`: verify files/code/tests exist and match requirements.
-3. Report ✅ correct vs ⚠️ falsely marked done.
-4. Ask if user wants status reverted to `pending` / `in_progress`.
-
-Reference: `.cursor/rules/task_review.mdc`

package/.claude/skills/task-flow-think/SKILL.md

@@ -1,19 +0,0 @@
----
-name: task-flow-think
-description: Analyzes the codebase and suggests new lines for tasks.input.txt without adding them automatically. Use when the user says task-flow think, suggest tasks, analise tasks novas, or check for missing tasks.
-disable-model-invocation: true
----
-
-# Task Flow — Think
-
-1. Read `.task-flow/tasks.input.txt` (existing plan).
-2. Scan codebase: TODOs, missing tests, half-done features, security/perf gaps.
-3. Propose new tasks as `- Description` lines (RBIN format).
-4. **Ask** user before writing to `tasks.input.txt`.
-5. If user confirms, append only new lines; then suggest `/task-flow-sync`.
-
-Optional: `graphify query` on large repos before suggesting.
-
-For deep verify + auto-add lacunas (no ask): `@task-flow-validate` (`task-flow: validate`).
-
-Reference: `.cursor/rules/task_analysis.mdc` · Sync after confirm: `@task-flow-sync`

package/.cursor/rules/task_analysis.mdc

@@ -1,45 +0,0 @@
----
-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-flow: think
-
-**Not sync.** For `task-flow: sync` use [task-flow-sync.mdc](mdc:.cursor/rules/task-flow-sync.mdc) or `@task-flow-sync`.
-
-**Not validate.** For deep verify + auto-add lacunas use [task_validate.mdc](mdc:.cursor/rules/task_validate.mdc) or `@task-flow-validate`.
-
-**Prefer:** `@task-flow-think` · After user adds lines: `@task-flow-sync`
-
-## When to run
-
-User says `task-flow: think`, `suggest tasks`, `check for new tasks`, `analyze codebase for tasks`, etc.
-
-## Process
-
-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
-
-## Output format
-
-```markdown
-## Suggested Tasks for tasks.input.txt
-
-- Add unit tests for UserService
-- Implement error handling in API endpoints
-```
-
-## Optional roadmap
-
-For package improvements see [.task-flow/guides/OPTIMIZATION-PLAN.md](mdc:.task-flow/guides/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_check.mdc

@@ -1,37 +0,0 @@
----
-description: Runs lint fix and build for task-flow check until project passes.
-alwaysApply: false
----
-
-# task-flow: check
-
-When the user runs `task-flow: check`:
-
-1. **Detect project scripts**: Read `package.json` and look for lint and build scripts.
-2. **Run lint first**: Prefer a fix-capable lint command if present (`lint:fix`, `lint-fix`, or equivalent). If there is only `lint`, run it and fix the reported issues.
-3. **Run build next**: If a `build` script exists, run it after lint succeeds.
-4. **Fix failures**: If lint or build fails, fix the issues and re-run until they pass.
-5. **Keep scope local**: This command is only for project checks. It does not run the coding-standards audit and does not change task files by itself.
-
----
-
-## How to execute
-
-- **Step 1**: Read `package.json` and identify which package manager and scripts the project uses.
-- **Step 2**: Run lint first, preferring an autofix variant when one exists.
-- **Step 3**: Fix any lint errors or warnings that should be resolved now.
-- **Step 4**: Run build and fix any failures.
-- **Step 5**: Report what ran, what was skipped, and whether the project is passing.
-
----
-
-## Natural language
-
-- **FAST FORMAT**: `task-flow: check` or `task-flow check`
-- "run checks", "run lint and build", "validate this project" → same command
-
----
-
-## Principle
-
-> **Use `task-flow: check` to make the current project pass its local validation steps before reviewing or committing changes.**

package/.cursor/rules/task_generate_flow.mdc

@@ -1,90 +0,0 @@
----
-description: Populates tasks.flow.md with dependencies and hours for task-flow generate flow.
-alwaysApply: false
----
-
-- **Task Flow Generation - Dependencies, Hours & Model Recommendations:**
-  - **FAST FORMAT**: `task-flow: generate flow` → Populate tasks.flow.md
-  - When user says "task-flow: generate flow", "generate flow", "gerar flow", or "flow":
-    - **READ**: `.task-flow/.internal/tasks.json` and optionally `status.json`
-    - **SEARCH**: Current versions of GPT-5.x, Composer, Claude (Haiku, Sonnet) via web search
-    - **WRITE**: Populate `.task-flow/tasks.flow.md` with the generated flow
-  - **DO NOT**: Populate tasks.flow.md when running `task-flow: sync`
-
-- **Generation Process:**
-  1. **Search for current model versions** (web search): one GPT-5.x coding-capable model, Composer (Cursor), Claude Haiku, Claude Sonnet. Include version next to each model (e.g. "Claude Sonnet 4.6").
-  2. Read tasks from tasks.json
-  3. For each task, determine:
-     - **Dependencies**: Which tasks must be completed first (or "—" if none)
-     - **Estimated hours** (for billing): infer from real task scope, ambiguity, dependencies, and validation needs. Subtask count informs scope, but do not use a fixed subtasks × hours formula. Do NOT show "dev mediano" or "mid-level".
-     - **3 model options** (in order of priority): one GPT-5.x model, one Composer, one Claude — always these 3. Include version and effort for each.
-     - **Model priority must be defined by AI judgment**, based on task nature, implementation risk, ambiguity, architecture impact, validation needs, and expected autonomy. Do not use a fixed ranking.
-     - **Effort** per model: low, medium, or high, defined by task level and difficulty. Do not infer effort from subtask count alone.
-  4. **Claude**: Use only Haiku or Sonnet — **never Opus**
-  5. **Effort heuristics**:
-     - **low**: localized change, clear requirement, low ambiguity, low regression risk, limited validation
-     - **medium**: multi-file implementation, moderate ambiguity, moderate regression risk, requires broader validation
-     - **high**: architecture or cross-cutting change, high ambiguity, high regression risk, sequencing concerns, or deep investigation/refactor
-  6. **Model heuristics**:
-     - **GPT-5.x**: prioritize when the task needs strong implementation, refactoring, debugging, or broader code reasoning
-     - **Composer**: prioritize when the task benefits from editor-native iteration, repo-wide navigation, and fast execution in the coding flow
-     - **Claude Haiku**: prioritize for simpler, well-bounded tasks with low effort
-     - **Claude Sonnet**: prioritize for tasks that need more synthesis, reasoning depth, or architectural analysis
-     - The first recommendation must reflect the best fit for that specific task, not a template order reused across all tasks
-
-- **Output Format (direct blocks per task):**
-  ```markdown
-  # Task Flow — Dependencies, Hours & Model Recommendations
-
-  <!-- Populated by task-flow: generate flow. Do not edit manually. -->
-  <!-- Horas: uso para cobrança ao cliente -->
-
-  ## Legenda
-
-  | Símbolo | Significado |
-  |---------|-------------|
-  | ✅ | Task concluída |
-  | ⚡ | Pode iniciar agora (deps satisfeitas) |
-  | 🔒 | Bloqueada por dependências |
-
-  **Esforço (Effort):** definido pelo nível e dificuldade real da task, não pela quantidade de subtasks
-  **Claude:** Haiku ou Sonnet — **não use Opus**
-
-  ## Tasks (blocos diretos por task)
-
-  ### ✅ Task 1 — [Título]
-  - **Depende de:** —
-  - **Horas cobrança:** 10-15h
-  - **Modelos sugeridos** (ordem de prioridade):
-    1. GPT-5.x [versão] — effort medium
-    2. Composer [versão] — effort medium
-    3. Claude Sonnet [versão] — effort medium
-
-  ### ⚡ Task 2 — [Título]
-  - **Depende de:** Task 1 ✅
-  - **Horas cobrança:** 10-15h
-  - **Modelos sugeridos** (ordem de prioridade):
-    1. Composer [versão] — effort medium
-    2. GPT-5.x [versão] — effort medium
-    3. Claude Sonnet [versão] — effort medium
-
-  ### 🔒 Task 3 — [Título]
-  - **Depende de:** Task 2
-  - **Horas cobrança:** 8-12h
-  - **Modelos sugeridos** (ordem de prioridade):
-    1. Claude Haiku [versão] — effort low
-    2. GPT-5.x [versão] — effort low
-    3. Composer [versão] — effort low
-  ```
-
-- **Model Rules:**
-  - **3 models per task**: One GPT-5.x model, one Composer, one Claude — always in order of priority
-  - **Version required**: Include current version next to each model name (from web search)
-  - **Effort required**: low, medium, or high for each model
-  - **AI-defined ranking**: order models by best fit for the task, not by a fixed global priority
-  - **No Opus**: Claude = Haiku or Sonnet only
-
-- **Natural Language:** "generate flow", "gerar flow", "flow"
-
-- **Principle:**
-  > **Populate tasks.flow.md with direct blocks per task. Dependencies, hours, and 3 model options (GPT-5.x, Composer, Claude) with version and effort. Let AI define ranking and effort from task context. Never use Opus.**

package/.cursor/rules/task_improve_changes.mdc

@@ -1,50 +0,0 @@
----
-description: Audits uncommitted files only for task-flow improve changes. Use git diff against HEAD scope.
-alwaysApply: false
----
-
-# task-flow: improve changes
-
-When the user runs `task-flow: improve changes`:
-
-1. **Audit current changes only**: Do the **same as** [task-flow: audit](mdc:.cursor/rules/task_audit.mdc) (score against the [coding_standards.mdc](mdc:.cursor/rules/coding_standards.mdc) checklist; [full doc](mdc:.task-flow/guides/coding-standards-full.md) only if needed), but **restricted to files that were changed and not yet committed**.
-2. **Do not run project checks here**: Lint fix and build now belong to [task-flow: check](mdc:.cursor/rules/task_check.mdc).
-
----
-
-## Scope: uncommitted files only
-
-1. **Get the list of uncommitted files** (read-only git; do not run `git add`/`git commit`). Use the list of paths from:
-   - Modified but not staged: `git diff --name-only`
-   - Staged but not committed: `git diff --name-only --cached`
-   - Combined: all files that differ from `HEAD` → `git diff --name-only HEAD`
-   - **Use** `git diff --name-only HEAD` so that both unstaged and staged (but uncommitted) changes are included.
-
-2. If there are **no uncommitted changes**, tell the user and stop.
-
-3. **Restrict the audit to those paths**: when performing the steps from [task_audit.mdc](mdc:.cursor/rules/task_audit.mdc) (explore, score, report, ask what to adopt, generate tasks), consider **only** the files in the list above. Do not score or suggest improvements for files that were not changed.
-
-4. **Same principles as audit**: non-destructive, incremental, suggest improvements and let the user choose. Only the scope is different: uncommitted files only.
-
----
-
-## How to execute
-
-- **Step 1**: Obtain uncommitted file list (e.g. run `git diff --name-only HEAD` or use your tools to get the list). If empty, stop.
-- **Step 2**: Read and analyze **only** the uncommitted files (and their immediate context if needed).
-- **Step 3**: For that subset, apply the same categories and scoring as in task-flow: audit (folder structure, thin app/, naming, cn(), forms, etc.) and note which of those categories are relevant to the changed files.
-- **Step 4**: Present findings and suggested improvements **only for the uncommitted files**.
-- **Step 5**: Ask which improvements the user wants; generate tasks or concrete edits only for the selected items, touching only uncommitted files where possible.
-
----
-
-## Natural language
-
-- **FAST FORMAT**: `task-flow: improve changes` or `task-flow improve changes`
-- "improve my changes", "audit my uncommitted changes", "check my changes against standards" → same command
-
----
-
-## Principle
-
-> **Use `task-flow: improve changes` as a scoped audit for the current diff against `HEAD`. Use `task-flow: check` separately when you want lint/build validation.**

package/.cursor/rules/task_refactor.mdc

@@ -1,94 +0,0 @@
----
-description: Refactors task-flow task code without behavior change. Use for task-flow refactor X.
-alwaysApply: false
----
-
-- **Task Refactor - Improve Code Quality:**
-  - **FAST FORMAT**: `task-flow: refactor X` or `task-flow: refactor X,Y` or `task-flow: refactor all` → Refactor specific task(s)
-  - **SIMPLIFIED SYNTAX**: No need to say "task" - just use the number: `task-flow: refactor 1` instead of `task-flow: refactor task 1`
-  - **REQUIRED**: Task ID is required - use `task-flow: refactor all` to refactor all tasks
-  - When user says "task-flow: refactor X", "task-flow: refactor X,Y", "task-flow: refactor all", or "refactor tasks":
-    - **IDENTIFY**: Files changed in current commit (or staged changes)
-    - **REFACTOR**: Improve code quality without changing functionality
-    - **REMOVE**: All explanatory comments (following code_comments.mdc rules)
-    - **PRESERVE**: Only separation comments in format: `// ────────────────────────────────`
-    - **IMPROVE**: Code structure, naming, organization, but keep behavior identical
-
-- **Refactoring Rules:**
-  1. **No Functional Changes**: Code must behave exactly the same
-  2. **Remove Comments**: Remove all explanatory comments
-  3. **Keep Separation Comments**: Preserve comments that separate code blocks:
-     ```typescript
-     // ────────────────────────────────
-     // Section Name
-     // ────────────────────────────────
-     ```
-  4. **Improve Code Quality**:
-     - Better variable/function names
-     - Extract repeated code
-     - Improve code organization
-     - Better error handling
-     - Remove dead code
-     - Simplify complex logic
-  5. **Follow Project Rules**: Respect [code_comments.mdc](mdc:.cursor/rules/code_comments.mdc)
-
-- **Comment Removal:**
-  - ❌ Remove: `// This function does X`
-  - ❌ Remove: `// Check if user exists`
-  - ❌ Remove: `// TODO: fix this later`
-  - ✅ Keep: `// ────────────────────────────────`
-  - ✅ Keep: `// ────────────────────────────────\n// Section Name\n// ────────────────────────────────`
-
-- **Process:**
-  1. Identify files changed in current commit/staged changes
-  2. Read each file
-  3. Refactor:
-     - Remove explanatory comments
-     - Improve code structure
-     - Better naming
-     - Extract functions if needed
-     - Simplify logic
-  4. Verify: Code still works the same way
-  5. Show summary of changes
-
-- **Natural Language Phrases:**
-  - **FAST FORMAT**: `task-flow: refactor X` or `task-flow: refactor X,Y` or `task-flow: refactor all`
-  - "refactor task 1"
-  - "refactor tasks 10,11"
-  - "refactor all tasks"
-  - "improve code quality"
-  - "clean up code"
-  - Any variation asking to refactor/improve code (must include task ID or "all")
-
-- **Example:**
-  ```
-  User: "task-flow: refactor 1"
-  
-  AI Action:
-  1. Identify files related to task 1 (from git history or task implementation)
-  2. Read each file
-  3. For each file:
-     - Remove explanatory comments
-     - Improve code structure
-     - Better naming
-     - Simplify logic
-  4. Preserve separation comments
-  5. Verify functionality unchanged
-  6. Show refactoring summary
-  
-  User: "task-flow: refactor all"
-  
-  AI Action:
-  1. Process all tasks
-  2. Identify files for each task
-  3. Refactor all files
-  4. Show summary
-  ```
-
-- **Integration:**
-  - Follows [code_comments.mdc](mdc:.cursor/rules/code_comments.mdc) - comment removal rules
-  - Works with [task-flow-cursor.mdc](mdc:.cursor/rules/task-flow-cursor.mdc) / `@task-flow-refactor`
-  - Respects [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc) — never commit automatically
-
-- **Principle:**
-  > **Refactor code to improve quality without changing behavior. Remove explanatory comments, keep only separation comments, improve structure and naming. Code must work exactly the same.**

package/.cursor/rules/task_review.mdc

@@ -1,88 +0,0 @@
----
-description: Verifies completed task-flow tasks are actually implemented. Use for task-flow review X or review all.
-alwaysApply: false
----
-
-- **Task Review - Verify Completed Tasks:**
-  - **FAST FORMAT**: `task-flow: review X` or `task-flow: review X,Y` or `task-flow: review all` → Review specific task(s)
-  - **SIMPLIFIED SYNTAX**: No need to say "task" - just use the number: `task-flow: review 1` instead of `task-flow: review task 1`
-  - **REQUIRED**: Task ID is required - use `task-flow: review all` to review all tasks
-  - When user says "task-flow: review X", "task-flow: review X,Y", "task-flow: review all", or "review completed tasks":
-    - **READ**: `.task-flow/.internal/tasks.json` and `.task-flow/.internal/status.json`
-    - **IDENTIFY**: All tasks/subtasks marked as "done"
-    - **VERIFY**: Check if each completed task/subtask is actually implemented
-    - **REPORT**: List tasks that are erroneously marked as done
-    - **SUGGEST**: Mark incorrectly completed tasks back to "pending" or "in_progress"
-
-- **Review Process:**
-  1. Read `.task-flow/.internal/tasks.json` to get all task definitions
-  2. Read `.task-flow/.internal/status.json` to get completion status
-  3. For each task/subtask marked as "done":
-     - Check if the implementation exists in codebase
-     - Verify if implementation matches the task requirements
-     - Check if tests exist (if required by task)
-     - Verify if documentation is updated (if required)
-  4. Identify discrepancies:
-     - Task marked "done" but code doesn't exist
-     - Task marked "done" but implementation incomplete
-     - Task marked "done" but tests missing
-     - Task marked "done" but requirements not met
-  5. Report findings and ask user if they want to correct status
-
-- **Review Report Format:**
-  ```
-  📋 Task Review Results:
-  
-  ✅ Correctly Completed:
-  - Task 1.2: User authentication (verified)
-  - Task 2.1: Database migration (verified)
-  
-  ⚠️  Erroneously Marked as Done:
-  - Task 1.3: API endpoint - Code exists but tests missing
-  - Task 2.4: Error handling - Implementation incomplete
-  
-  Do you want to update status for erroneous tasks? [y/N]
-  ```
-
-- **Natural Language Phrases:**
-  - **FAST FORMAT**: `task-flow: review X` or `task-flow: review X,Y` or `task-flow: review all`
-  - "review task 1"
-  - "review tasks 10,11"
-  - "review all tasks"
-  - "verify done tasks"
-  - "check if tasks are really done"
-  - "review task status"
-  - Any variation asking to review/verify completed tasks (must include task ID or "all")
-
-- **Example:**
-  ```
-  User: "task-flow: review 1"
-  
-  AI Action:
-  1. Read tasks.json and status.json
-  2. Find task 1 and its "done" subtasks
-  3. Verify each one:
-     - Check if files exist
-     - Check if code matches requirements
-     - Check if tests exist
-  4. Report findings
-  5. Ask if user wants to correct status
-  6. If confirmed, update status.json
-  
-  User: "task-flow: review all"
-  
-  AI Action:
-  1. Read tasks.json and status.json
-  2. Find all "done" tasks/subtasks
-  3. Verify each one
-  4. Report findings
-  5. Ask if user wants to correct status
-  ```
-
-- **Integration:**
-  - Works with [task-flow-cursor.mdc](mdc:.cursor/rules/task-flow-cursor.mdc) / `@task-flow-review`
-  - For verify + auto-add lacunas + sync: [task_validate.mdc](mdc:.cursor/rules/task_validate.mdc) / `@task-flow-validate`
-  - Respects [rbin-git-policy.mdc](mdc:.cursor/rules/rbin-git-policy.mdc) — never commit automatically
-
-- **Principle:**
-  > **Review completed tasks to ensure quality. Verify that "done" means actually done, not just marked. Help maintain accurate task status.**

package/lib/audit.js

@@ -1,44 +0,0 @@
-const { execSync } = require('child_process');
-const path = require('path');
-const chalk = require('chalk');
-
-function getUnstagedFiles(targetPath) {
-  const cwd = path.resolve(targetPath);
-  try {
-    const out = execSync('git diff --name-only', { encoding: 'utf8', cwd });
-    return out
-      .trim()
-      .split('\n')
-      .filter(Boolean);
-  } catch (err) {
-    if (err.stderr && (err.stderr.includes('not a git repository') || err.message.includes('not a git'))) {
-      return null;
-    }
-    throw err;
-  }
-}
-
-async function runAudit(targetPath = process.cwd()) {
-  const files = getUnstagedFiles(targetPath);
-
-  if (files === null) {
-    console.log(chalk.red('❌ Not a git repository. Run from a project root with git initialized.'));
-    return;
-  }
-
-  if (files.length === 0) {
-    console.log(chalk.yellow('⚠️  No unstaged changes. All modified files are staged (or working tree is clean).'));
-    console.log(chalk.gray('   Use "task-flow: audit" after editing files and before "git add".'));
-    return;
-  }
-
-  console.log(chalk.cyan('📋 Unstaged files (not yet added with git add):'));
-  console.log(chalk.cyan('─'.repeat(50)));
-  files.forEach((f) => console.log(chalk.white('  ' + f)));
-  console.log(chalk.cyan('─'.repeat(50)));
-  console.log(chalk.magenta('  Total:'), chalk.yellow(files.length), chalk.magenta('file(s)'));
-  console.log('');
-  console.log(chalk.gray('  Tip: run lint/test only on these paths, then "git add" when ready.'));
-}
-
-module.exports = { runAudit, getUnstagedFiles };

package/lib/check.js

@@ -1,113 +0,0 @@
-const fs = require('fs');
-const path = require('path');
-const { execSync } = require('child_process');
-const chalk = require('chalk');
-
-function getPackageManager(targetPath) {
-  const cwd = path.resolve(targetPath);
-
-  if (fs.existsSync(path.join(cwd, 'pnpm-lock.yaml'))) {
-    return 'pnpm';
-  }
-
-  if (fs.existsSync(path.join(cwd, 'yarn.lock'))) {
-    return 'yarn';
-  }
-
-  if (fs.existsSync(path.join(cwd, 'bun.lockb')) || fs.existsSync(path.join(cwd, 'bun.lock'))) {
-    return 'bun';
-  }
-
-  return 'npm';
-}
-
-function readPackageJson(targetPath) {
-  const packageJsonPath = path.join(path.resolve(targetPath), 'package.json');
-
-  if (!fs.existsSync(packageJsonPath)) {
-    return null;
-  }
-
-  return JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'));
-}
-
-function buildRunCommand(packageManager, scriptName, args = []) {
-  if (packageManager === 'yarn') {
-    return ['yarn', scriptName, ...args].join(' ');
-  }
-
-  return [packageManager, 'run', scriptName, ...(args.length > 0 ? ['--', ...args] : [])].join(' ');
-}
-
-function resolveLintScript(scripts = {}) {
-  if (scripts['lint:fix']) {
-    return { scriptName: 'lint:fix', label: 'lint:fix' };
-  }
-
-  if (scripts['lint-fix']) {
-    return { scriptName: 'lint-fix', label: 'lint-fix' };
-  }
-
-  if (scripts.lint) {
-    if (scripts.lint.includes('--fix')) {
-      return { scriptName: 'lint', label: 'lint' };
-    }
-
-    return { scriptName: 'lint', args: ['--fix'], label: 'lint --fix' };
-  }
-
-  return null;
-}
-
-function runScript(targetPath, packageManager, scriptConfig) {
-  const command = buildRunCommand(packageManager, scriptConfig.scriptName, scriptConfig.args);
-  execSync(command, {
-    cwd: path.resolve(targetPath),
-    stdio: 'inherit',
-    encoding: 'utf8'
-  });
-}
-
-async function runCheck(targetPath = process.cwd()) {
-  const cwd = path.resolve(targetPath);
-  const packageJson = readPackageJson(cwd);
-
-  if (!packageJson) {
-    console.log(chalk.red('❌ package.json not found. Run this command from a project root.'));
-    return;
-  }
-
-  const packageManager = getPackageManager(cwd);
-  const scripts = packageJson.scripts || {};
-  const lintScript = resolveLintScript(scripts);
-  const hasBuild = Boolean(scripts.build);
-  let ranSomething = false;
-
-  console.log(chalk.cyan('🔎 Running project checks'));
-  console.log(chalk.gray(`   Package manager: ${packageManager}`));
-
-  if (lintScript) {
-    ranSomething = true;
-    console.log(chalk.cyan(`\n▶ Running ${lintScript.label}`));
-    runScript(cwd, packageManager, lintScript);
-  } else {
-    console.log(chalk.yellow('\n⚠️  No lint script found. Skipping lint step.'));
-  }
-
-  if (hasBuild) {
-    ranSomething = true;
-    console.log(chalk.cyan('\n▶ Running build'));
-    runScript(cwd, packageManager, { scriptName: 'build' });
-  } else {
-    console.log(chalk.yellow('\n⚠️  No build script found. Skipping build step.'));
-  }
-
-  if (!ranSomething) {
-    console.log(chalk.yellow('\n⚠️  Nothing to run. Add a lint and/or build script to package.json.'));
-    return;
-  }
-
-  console.log(chalk.green('\n✅ Checks completed successfully.'));
-}
-
-module.exports = { runCheck };