/ai-cli-task check — Plan Feasibility Check

Check the implementation plan at three lifecycle checkpoints. Acts as the decision maker in the task state machine.

Usage

/ai-cli-task check <task_module_path> [--checkpoint post-plan|mid-exec|post-exec]

Checkpoints

1. post-plan (default)

Evaluates whether the implementation plan is ready for execution.

Reads: .target.md + all user-created plan .md files in the module + .summary.md (if exists) + .test/ (latest criteria file) + .bugfix/ (latest file if exists, to verify revised plan addresses execution issues)

Evaluation Criteria:

Outcomes:

2. mid-exec

Evaluates progress during execution when issues are encountered.

Reads: .target.md + plan files + .summary.md (if exists) + .test/ (latest criteria + results) + .analysis/ (latest file only) + current code changes (via git diff)

Evaluation Criteria:

Outcomes:

3. post-exec

Evaluates whether execution results meet the task requirements.

Reads: .target.md + plan files + .summary.md (if exists) + .test/ (all criteria + latest results) + .analysis/ (latest file only) + code changes + test results

Evaluation Criteria:

Outcomes:

Output Files

When writing to any history directory (.analysis/, .bugfix/, .test/), also overwrite that directory's summary.md with a condensed summary of all entries in the directory.

Execution Steps

1. •Read .index.md to get current task status
2. •Validate checkpoint is appropriate for current status:
   • •post-plan: requires status planning or re-planning
   • •mid-exec: requires status executing
   • •post-exec: requires status executing
3. •Validate dependencies: read depends_on from .index.md, check each dependency module's .index.md status against its required level (simple string → complete, extended object → at-or-past min_status). If any dependency is not met, verdict is BLOCKED with dependency details
4. •Read all relevant files per checkpoint (use .summary.md as primary context, latest file only from each history directory)
5. •Evaluate against criteria
6. •Write output files per outcome: evaluation to .analysis/ or .bugfix/ (per Outcomes tables above), and test results to .test/<date>-<checkpoint>-results.md when tests are evaluated (mid-exec and post-exec checkpoints)
7. •Update each written directory's summary.md — overwrite with condensed summary of ALL entries in that directory (.analysis/summary.md, .bugfix/summary.md, .test/summary.md as applicable per checkpoint)
8. •Write task-level .summary.md with condensed context: task state, plan summary, evaluation outcome, progress (completed_steps), known issues, key decisions (integrate from directory summaries)
9. •Update .index.md status and timestamp per outcome
10. •Write .auto-signal with verdict, next action, and checkpoint (see .auto-signal section below)
11. •Report evaluation result with detailed reasoning

State Transitions

post-plan PASS:          planning → review
post-plan PASS:          re-planning → review, phase: "" (cleared)
post-plan NEEDS_REVISION: (no change, files committed). If current status is `re-planning`, set `phase: needs-plan`
post-plan BLOCKED:       → blocked

mid-exec CONTINUE:       (no change)
mid-exec NEEDS_FIX:      (no change, files committed)
mid-exec REPLAN:         executing → re-planning, phase: needs-plan
mid-exec BLOCKED:        → blocked

post-exec ACCEPT:        (no change, signal → merge)
post-exec NEEDS_FIX:     (no change, files committed)
post-exec REPLAN:        executing → re-planning, phase: needs-plan

Git

All outcomes commit their output files and state updates, regardless of whether status changes.

.auto-signal

Every check outcome writes .auto-signal on completion:

When ACCEPT, the merge sub-command handles refactoring, merge, conflict resolution, and cleanup. See skills/merge/SKILL.md.

Task-Type-Aware Verification

Verification methods MUST match the task domain. Read type from .index.md and apply domain-appropriate verification. If test methods are mismatched for the task type → verdict is NEEDS_REVISION.

See references/task-type-verification.md for the full domain reference table, determination rules, and requirements.

Notes

• •Judgment bias: When uncertain between PASS and NEEDS_REVISION, prefer NEEDS_REVISION. When uncertain between ACCEPT and NEEDS_FIX, prefer NEEDS_FIX. False negatives (extra iteration) are cheaper than false positives (bad code merged).
• •Evaluation should be thorough but pragmatic — focus on blocking issues, not style preferences
• •Each assessment creates a new file in .analysis/ (full evaluation history preserved, latest = last by filename sort)
• •Each mid-exec issue creates a new file in .bugfix/ (one issue per file, filename includes date + summary)
• •For post-exec, if tests exist (.test/ criteria files), they MUST be run and pass for ACCEPT
• •Check writes test results to .test/<date>-<checkpoint>-results.md (e.g., 2024-01-15-post-exec-results.md) documenting test outcomes
• •depends_on in .index.md MUST be validated: if any dependency is not met (simple string → complete, extended object → at-or-past min_status), verdict is BLOCKED (not just flagged as risk)
• •Concurrency: Check acquires AiTasks/<module>/.lock before proceeding and releases on completion (see Concurrency Protection in commands/ai-cli-task.md)
• •No mental math: When evaluation involves numerical reasoning (performance estimates, size calculations, threshold comparisons, timing analysis), write a script and run it in shell instead of computing mentally. Scripts produce verifiable, reproducible results
• •Five-perspective audit: For thorough plan evaluation, apply security / performance / extensibility / consistency / correctness checks systematically. See references/five-perspective-audit.md for the full checklist