@winton979/task-cli 1.4.2 → 1.4.3

package/README.md

@@ -4,9 +4,9 @@ A workflow methodology for AI coding agents.
 
 Task CLI separates requirement exploration from implementation, so AI agents decide whether complexity is justified **before** they start coding.
 
-**Explore** — Understand the problem. Assess whether additional complexity is warranted.
-**Implement** — Solve the accepted problem with the least necessary complexity.
-**Review** — Validate against the brief, not against new ideas introduced during coding.
+**Explore** — Understand the problem. Assess whether additional complexity is warranted.
+**Implement** — Solve the accepted problem with the least necessary complexity.
+**Audit** — Independently try to find failure evidence when the risk justifies it.
 
 Designed for:
 
@@ -25,7 +25,7 @@ Designed for:
 ### Traditional AI Workflow
 
 ```text
-Requirement → Solution Design → Code → Review
+Requirement → Solution Design → Code → Review
 ```
 
 The AI often starts designing before the requirement is fully clarified. Complexity gets introduced during coding, and review happens against whatever the AI produced rather than against the original intent.
@@ -42,8 +42,10 @@ Complexity Assessment  ──►  Is added complexity justified?
 Brief
     ↓
 Implement  ──►  Simplest acceptable solution
-    ↓
-Review  ──►  Validate against the brief
+    ↓
+Validation  ──►  Verify against the brief
+    ↓
+Audit  ──►  Optional, risk-triggered failure search
 ```
 
 Exploration and implementation are intentionally separated.
@@ -59,7 +61,8 @@ Most AI coding agents fail because they mix exploration and implementation in th
 | Explore                   | What problem are we solving?               |
 | Complexity Assessment     | Is additional complexity justified?        |
 | Implement                 | What is the simplest acceptable solution?  |
-| Review                    | Did we satisfy the brief?                  |
+| Validation                | Did the implementation satisfy the brief?  |
+| Audit                     | Can we find evidence that it fails?        |
 
 This keeps AI agents from over-designing solutions during requirement discovery, and keeps implementation focused on the accepted scope.
 
@@ -95,27 +98,33 @@ If no Grill Me compatible skill is installed, `task-fast`, `task-explore`, and `
 
 ## Quick Start
 
-### Small Feature / Enhancement
-
-```text
-/task-fast
-    ↓
-clarify + brief + implement + validate
-    ↓
-/task-review   or   /task-cancel
-```
-
-### Larger Requirement
-
-```text
-/task-explore  →  TASK_READY  →  /task-implement  →  /task-review  or  /task-cancel
-```
-
-### Bug Fix
-
-```text
-/bug-explore  →  BUG_READY  →  /bug-fix  →  /bug-review  or  /bug-cancel
-```
+### Small Feature / Enhancement
+
+```text
+/task-fast
+    ↓
+clarify + brief + implement + validate
+    ↓
+archive automatically
+```
+
+### Larger Requirement
+
+```text
+/task-explore  →  TASK_READY  →  /task-implement  →  optional /task-audit
+```
+
+### Bug Fix
+
+```text
+/bug-explore  →  BUG_READY  →  /bug-fix  →  optional /bug-audit
+```
+
+Use `/task-cancel` or `/bug-cancel` when abandoning the current attempt before accepting it.
+
+Run audit only when the risk is worth the extra pass, such as before a PR, after a large diff, when changing public APIs or core modules, when fixing production bugs, when security or data integrity is involved, or when the user explicitly asks for it.
+
+For the highest-value audit, start a fresh session or use a different reviewer context and provide only the brief, final code or git diff, and relevant tests. Audit quality comes from new perspective and evidence, not from asking the same context to approve its own work.
 
 ### CLI Commands
 
@@ -166,18 +175,18 @@ The workflow encourages the simplest acceptable implementation instead of the mo
 
 **Task Workflow**
 
-* `task-fast`
-* `task-explore`
-* `task-implement`
-* `task-review`
-* `task-cancel`
+* `task-fast`
+* `task-explore`
+* `task-implement`
+* `task-audit`
+* `task-cancel`
 
 **Bug Workflow**
 
-* `bug-explore`
-* `bug-fix`
-* `bug-review`
-* `bug-cancel`
+* `bug-explore`
+* `bug-fix`
+* `bug-audit`
+* `bug-cancel`
 
 **Decision Logging**
 
@@ -268,7 +277,7 @@ Detailed specification workflows such as OpenSpec can improve alignment, traceab
 
 The difficulty is that the same level of ceremony does not fit day-to-day engineering. For frequent bug fixes, small features, and fast iteration, the process becomes heavier than the change itself — maintenance overhead grows, documentation quality drifts, and teams gradually stop using the workflow as intended.
 
-Task CLI takes a narrower approach: clarify the requirement, capture only the minimum useful brief, execute against acceptance criteria, review the result, and keep a lightweight decision trail. The goal is a workflow people will actually keep using.
+Task CLI takes a narrower approach: clarify the requirement, capture only the minimum useful brief, execute and validate against acceptance criteria, run audit only when risk justifies it, and keep a lightweight decision trail. The goal is a workflow people will actually keep using.
 
 ---
 
@@ -284,7 +293,7 @@ Task CLI takes a narrower approach: clarify the requirement, capture only the mi
 **Tradeoffs**
 
 * less suitable for large cross-team initiatives that need formal design traceability
-* relies more on engineer judgment and review quality than a full spec process
+* relies more on engineer judgment and risk-triggered audit quality than a full spec process
 * stores less long-form historical context than a dedicated spec repository
 
 ---
@@ -300,7 +309,7 @@ task refresh
 This will:
 
 * keep `.ai/tasks`, `.ai/bugs`, and `.ai/decisions`
-* remove only managed skills from `.claude/skills/` and `.codex/skills/`: `task-fast`, `task-explore`, `task-implement`, `task-review`, `task-cancel`, `bug-explore`, `bug-fix`, `bug-review`, `bug-cancel`, `decision-log`, `decision-sweep-weekly`, `decision-curate`
+* remove only managed skills from `.claude/skills/` and `.codex/skills/`, including legacy `task-review` and `bug-review`, then reinstall the current set: `task-fast`, `task-explore`, `task-implement`, `task-audit`, `task-cancel`, `bug-explore`, `bug-fix`, `bug-audit`, `bug-cancel`, `decision-log`, `decision-sweep-weekly`, `decision-curate`
 * reinstall the latest versions of those skills
 
 Unrelated custom skills in the same project are left untouched. Inspect the current setup first with `task doctor`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@winton979/task-cli",
-  "version": "1.4.2",
+  "version": "1.4.3",
   "description": "Lightweight task workflow CLI for AI-assisted development",
   "license": "MIT",
   "repository": {

package/src/cli.js

@@ -26,8 +26,9 @@ Usage:
 
 Recommended flows after init:
   fast: task-fast
-  task: task-explore -> task-implement -> task-review | task-cancel
-  bug:  bug-explore -> bug-fix -> bug-review | bug-cancel`);
+  task: task-explore -> task-implement -> task-audit (optional, risk-triggered)
+  bug:  bug-explore -> bug-fix -> bug-audit (optional, risk-triggered)
+  cancel: task-cancel | bug-cancel`);
 }
 
 switch (cmd) {

package/src/init.js

@@ -241,51 +241,88 @@ How acceptance criteria were satisfied.
 `,
   },
 
-  'task-review': {
-    name: 'task-review',
-    description: 'Review the latest task implementation against the corresponding task brief.',
+  'task-audit': {
+    name: 'task-audit',
+    description: 'Independently audit a completed task implementation against the task brief.',
     content: `---
-name: task-review
-description: Review the latest task implementation against the corresponding task brief.
+name: task-audit
+description: Independently audit a completed task implementation against the task brief. The objective is to find evidence of failure, not to justify the implementation.
 user-invocable: true
 ---
 
 Purpose
 
-Review implementation against the corresponding task brief.
+Perform an independent audit of a completed task implementation.
 
 Rules
 
 1. Use the latest matching brief from .ai/tasks/active/ or .ai/tasks/archive/.
-2. Review the actual changes, not just the intent.
+2. Inspect the actual implementation via final code and git diff.
+3. Use the least implementation context possible: task brief, final code, git diff, and existing tests.
+4. Ignore implementation reasoning from the current conversation.
+5. Do not prove the implementation correct. Try to invalidate it with evidence.
+6. If evidence is unavailable, mark the area UNKNOWN instead of guessing.
+7. Run relevant tests when practical. If tests cannot be run, list that under Unknowns.
+8. Do not suggest unrelated improvements.
+9. Overall Result must be FAIL when any acceptance criterion is FAIL, or when a material UNKNOWN blocks approval.
+10. Overall Result may be PASS only when no significant evidence of failure exists.
+
+Audit Phases
+
+1. Requirement coverage: for each acceptance criterion, mark PASS, FAIL, or UNKNOWN.
+2. Break attempt: construct edge cases, invalid inputs, and unexpected user actions that may violate the brief.
+3. Regression analysis: check behavior changes, compatibility issues, state corruption, and hidden side effects.
+4. Engineering risk: check maintainability, unnecessary complexity, duplication, performance, memory, concurrency, and security.
+
+Severity
+
+Critical - Causes incorrect behavior or violates requirements.
+High - Likely production issue.
+Medium - Real issue with limited impact.
+Low - Concrete issue with low impact. Do not use Low for preferences.
 
-Evaluate
+Output
 
-1. Goal completion
-2. Acceptance criteria coverage
-3. Edge cases
-4. Maintainability
-5. Performance impact
-6. Security impact
-7. Regression risks
+## Overall Result
 
-Output
+PASS or FAIL
 
-## Pass/Fail
+## Acceptance Criteria
 
-Overall assessment.
+| Criterion | Result | Evidence |
+|-----------|--------|----------|
 
 ## Findings
 
-Issues found.
+For every finding include:
+
+### Severity
+
+Critical / High / Medium / Low
+
+### Issue
+
+What is wrong.
+
+### Evidence
+
+Concrete code, diff, test result, or behavior supporting the finding.
+
+### Impact
 
-## Suggestions
+Why it matters.
 
-Optional improvements.
+### Confidence
 
-## Missing Acceptance Criteria
+High / Medium / Low
 
-Anything not fully implemented.
+## Unknowns
+
+Areas that cannot be verified from available information.
+
+## Final Assessment
+
+State whether approval is blocked and what remains risky.
 `,
   },
 
@@ -434,45 +471,93 @@ Verification performed.
 `,
   },
 
-  'bug-review': {
-    name: 'bug-review',
-    description: 'Review the latest bug fix against the corresponding bug brief.',
+  'bug-audit': {
+    name: 'bug-audit',
+    description: 'Independently audit a completed bug fix against the bug brief and root cause.',
     content: `---
-name: bug-review
-description: Review the latest bug fix against the corresponding bug brief.
+name: bug-audit
+description: Independently audit a completed bug fix against the bug brief and root cause. The objective is to find evidence of failure, not to justify the implementation.
 user-invocable: true
 ---
 
 Purpose
 
-Review implementation against the corresponding bug brief.
+Perform an independent audit of a completed bug fix.
 
 Rules
 
 1. Use the latest matching brief from .ai/bugs/active/ or .ai/bugs/archive/.
-2. Check whether the reported root cause was truly addressed.
+2. Inspect the actual fix via final code and git diff.
+3. Use the least implementation context possible: bug brief, final code, git diff, and existing tests.
+4. Ignore implementation reasoning from the current conversation.
+5. Do not prove the fix correct. Try to invalidate it with evidence.
+6. If evidence is unavailable, mark the area UNKNOWN instead of guessing.
+7. Run relevant tests when practical. If tests cannot be run, list that under Unknowns.
+8. Do not suggest unrelated improvements.
+9. Overall Result must be FAIL when root cause validation is FAIL, any acceptance criterion is FAIL, or a material UNKNOWN blocks approval.
+10. Overall Result may be PASS only when no significant evidence of failure exists.
+
+Audit Phases
+
+1. Root cause validation: determine whether the confirmed or suspected root cause was actually eliminated.
+2. Acceptance criteria coverage: for each criterion, mark PASS, FAIL, or UNKNOWN.
+3. Break attempt: construct inputs or flows that reproduce the old bug or expose adjacent failures.
+4. Regression analysis: check behavior changes, compatibility issues, state corruption, and hidden side effects.
+5. Engineering risk: check maintainability, unnecessary complexity, duplication, performance, memory, concurrency, and security.
+
+Severity
+
+Critical - Root cause not fixed or requirement violated.
+High - Likely production issue.
+Medium - Real issue with limited impact.
+Low - Concrete issue with low impact. Do not use Low for preferences.
 
-Check
+Output
 
-1. Root cause addressed
-2. Regression risks
-3. Side effects
-4. Edge cases
-5. Test coverage
+## Overall Result
 
-Output
+PASS or FAIL
+
+## Root Cause Validation
+
+PASS / FAIL / UNKNOWN, with evidence.
+
+## Acceptance Criteria
+
+| Criterion | Result | Evidence |
+|-----------|--------|----------|
 
-## Pass/Fail
+## Findings
+
+For every finding include:
+
+### Severity
+
+Critical / High / Medium / Low
+
+### Issue
+
+What is wrong.
+
+### Evidence
+
+Concrete code, diff, test result, or behavior supporting the finding.
+
+### Impact
 
-Assessment.
+Why it matters.
 
-## Risks
+### Confidence
 
-Potential issues.
+High / Medium / Low
 
-## Recommendations
+## Unknowns
 
-Further improvements.
+Areas that cannot be verified from available information.
+
+## Final Assessment
+
+State whether approval is blocked and what remains risky.
 `,
   },
 
@@ -705,7 +790,14 @@ Requirements
   },
 };
 
-const MANAGED_SKILL_NAMES = Object.values(SKILLS).map((skill) => skill.name);
+const LEGACY_MANAGED_SKILL_NAMES = [
+  'task-review',
+  'bug-review',
+];
+const MANAGED_SKILL_NAMES = [
+  ...Object.values(SKILLS).map((skill) => skill.name),
+  ...LEGACY_MANAGED_SKILL_NAMES,
+];
 
 function skillFilePath(path, cwd, skillRoot, skillName) {
   return path.join(cwd, skillRoot, skillName, 'SKILL.md');
@@ -863,8 +955,9 @@ export function init(cwd, { fs, path, log }) {
 
   log.info(`\nTask workflow initialized. Recommended flows:
   fast:  task-fast
-  task:  task-explore -> task-implement -> task-review | task-cancel
-  bug:   bug-explore -> bug-fix -> bug-review | bug-cancel
+  task:  task-explore -> task-implement -> task-audit (optional, risk-triggered)
+  bug:   bug-explore -> bug-fix -> bug-audit (optional, risk-triggered)
+  cancel: task-cancel | bug-cancel
   other: decision-log | decision-curate
   sweep: decision-sweep-weekly`);
 }
@@ -898,8 +991,9 @@ export function refresh(cwd, { fs, path, log }) {
 
   log.info(`\nTask workflow refreshed. Managed skills reinstalled:
   fast:  task-fast
-  task:  task-explore -> task-implement -> task-review | task-cancel
-  bug:   bug-explore -> bug-fix -> bug-review | bug-cancel
+  task:  task-explore -> task-implement -> task-audit (optional, risk-triggered)
+  bug:   bug-explore -> bug-fix -> bug-audit (optional, risk-triggered)
+  cancel: task-cancel | bug-cancel
   other: decision-log | decision-curate
   sweep: decision-sweep-weekly`);
 }
@@ -950,6 +1044,16 @@ export function doctor(cwd, { fs, path, log }) {
         matches ? 'current' : 'outdated, run `task refresh`'
       );
     }
+
+    for (const skillName of LEGACY_MANAGED_SKILL_NAMES) {
+      const legacySkillDir = path.join(cwd, skillRoot, skillName);
+      if (!fs.existsSync(legacySkillDir)) {
+        continue;
+      }
+
+      checks.push(false);
+      logCheck(log, false, `${skillRoot}/${skillName}`, 'legacy managed skill, run `task refresh`');
+    }
   }
 
   const grillMeFindings = [