@winton979/task-cli 1.4.2 → 1.5.0

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.
 
@@ -79,43 +82,45 @@ task init
 
 After initialization, Task CLI creates the `.ai/` workspace and installs workflow skills into both `.claude/skills/` and `.codex/skills/`.
 
-### Prerequisites
-
-Task CLI can use a Grill Me compatible skill for requirement and bug exploration.
-
-Recommended:
-
-```bash
-npx add-skill PJ-SBN-593844/skill-grill-me
-```
-
-If no Grill Me compatible skill is installed, `task-fast`, `task-explore`, and `bug-explore` fall back to built-in clarification prompts.
+### Exploration Protocol
+
+Task CLI embeds the `grilling` primitive from [Matt Pocock's skills collection](https://github.com/mattpocock/skills.git). Its wording is the methodological foundation for exploration, not a runtime dependency.
+
+`task-explore` and `bug-explore` preserve the primitive's body verbatim. Their only workflow-specific interpretation of it is that "act on it" means creating the brief. `task-fast` uses a narrower clarification loop so the fast path remains fast.
+
+Task CLI neither requires nor installs a companion interviewing skill.
 
 ---
 
 ## 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 +171,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 +273,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 +289,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,18 +305,12 @@ 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`.
 
----
-
-something else:
-> Task CLI does not install Grill Me automatically.
-> Users remain free to choose any Grill Me compatible implementation, and the explore skills fall back to built-in clarification if none is installed.
-
-## License
+## License
 
 MIT
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@winton979/task-cli",
-  "version": "1.4.2",
+  "version": "1.5.0",
   "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

@@ -13,11 +13,15 @@ const GITIGNORE_BLOCK = [
   '.ai/bugs/active/*.md',
 ].join('\n');
 
-const GRILL_ME_HINTS = [
-  'grill-me',
-  'skill-grill-me',
-  'grill me',
-];
+const GRILLING_GUIDANCE = `Grilling
+
+Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
+
+If a *fact* can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
+
+Do not act on it until I confirm we have reached a shared understanding.`;
 
 const DECISIONS_READ_GUIDANCE = `Decision Intake
 
@@ -60,23 +64,24 @@ Handle a small requirement in one continuous workflow with minimal ceremony.
 
 Workflow
 
-1. If a Grill Me compatible skill is available in the current environment, use it for requirement clarification.
-2. If no Grill Me compatible skill is available, clarify the requirement yourself with focused questions just far enough to remove ambiguity.
-3. Read the project code and conventions needed to avoid obvious conflicts.
-4. Read .ai/decisions/decisions.md if it exists and has entries. Pull in only decisions that materially constrain this task.
-5. Before finalizing the brief, perform a Complexity Assessment.
-6. Create a concise task brief and save it to:
+1. Read the project code and conventions needed to avoid obvious conflicts.
+2. If a fact can be found by exploring the environment, look it up rather than asking the user.
+3. Ask only questions whose answers can change the implementation or acceptance criteria. Ask them one at a time, waiting for feedback on each before continuing. For each question, provide your recommended answer.
+4. Put unresolved decisions to the user; do not make them on the user's behalf.
+5. Read .ai/decisions/decisions.md if it exists and has entries. Pull in only decisions that materially constrain this task.
+6. Before finalizing the brief, perform a Complexity Assessment.
+7. Create a concise task brief and save it to:
 
 .ai/tasks/active/YYYY-MM-DD-task-name.md
 
-7. Show the brief before coding.
-8. If the user does not object, implement immediately.
-9. Verify the result against the acceptance criteria.
-10. Archive the brief automatically by moving it to:
+8. Show the brief as the fast-path summary of shared understanding, ask the user to confirm it, and stop. Do not code until the user confirms.
+9. Once the user confirms the brief, implement immediately.
+10. Verify the result against the acceptance criteria.
+11. Archive the brief automatically by moving it to:
 
 .ai/tasks/archive/YYYY-MM-DD-task-name.md
 
-11. Summarize the outcome and any follow-up risks.
+12. Summarize the outcome and any follow-up risks.
 
 ${DECISIONS_READ_GUIDANCE}
 
@@ -123,10 +128,10 @@ TASK_DONE
 
   'task-explore': {
     name: 'task-explore',
-    description: 'Clarify a requirement and generate the execution brief in one step, without implementing.',
+    description: 'Grill the user relentlessly about a requirement; generate an execution brief only after shared understanding, without implementing.',
     content: `---
 name: task-explore
-description: Clarify a requirement and generate the execution brief in one step, without implementing.
+description: Grill the user relentlessly about a requirement; generate an execution brief only after shared understanding, without implementing.
 user-invocable: true
 ---
 
@@ -136,17 +141,17 @@ Clarify requirements and leave behind a ready-to-execute brief.
 
 Workflow
 
-1. If a Grill Me compatible skill is available in the current environment, use it for requirement exploration.
-2. If no Grill Me compatible skill is available, explore the requirement yourself through focused questions.
-3. Continue until the task is sufficiently understood.
-4. Do not write code.
-5. Do not create implementation details.
-6. Before writing the brief, inspect .ai/decisions/decisions.md if it exists and has entries. Pull in only decisions that materially constrain this task.
-7. Once the requirement is clear, generate a concise task brief and save it to:
+1. Grill the requirement using the Grilling section below.
+2. Do not write code or create implementation details.
+3. Before writing the brief, inspect .ai/decisions/decisions.md if it exists and has entries. Pull in only decisions that materially constrain this task.
+4. For this workflow, "act on it" means creating the brief.
+5. Generate a concise task brief and save it to:
 
 .ai/tasks/active/YYYY-MM-DD-task-name.md
 
-8. Show the saved brief and stop.
+6. Show the saved brief and stop.
+
+${GRILLING_GUIDANCE}
 
 ${DECISIONS_READ_GUIDANCE}
 
@@ -241,51 +246,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
+
+Why it matters.
 
-## Suggestions
+### Confidence
 
-Optional improvements.
+High / Medium / Low
 
-## Missing Acceptance Criteria
+## Unknowns
 
-Anything not fully implemented.
+Areas that cannot be verified from available information.
+
+## Final Assessment
+
+State whether approval is blocked and what remains risky.
 `,
   },
 
@@ -321,10 +363,10 @@ TASK_CANCELLED
 
   'bug-explore': {
     name: 'bug-explore',
-    description: 'Investigate a bug and generate a fix brief in one step, without writing code.',
+    description: 'Grill the user relentlessly about a bug while investigating its evidence; generate a fix brief only after shared understanding, without writing code.',
     content: `---
 name: bug-explore
-description: Investigate a bug and generate a fix brief in one step, without writing code.
+description: Grill the user relentlessly about a bug while investigating its evidence; generate a fix brief only after shared understanding, without writing code.
 user-invocable: true
 ---
 
@@ -334,24 +376,24 @@ Investigate a bug and leave behind a ready-to-fix brief.
 
 Rules
 
-1. If a Grill Me compatible skill is available in the current environment, use it for bug exploration.
-2. If no Grill Me compatible skill is available, ask focused questions and drive the investigation yourself.
-3. Do not write code.
-4. Do not suggest fixes before enough evidence exists.
-5. Identify root cause candidates.
-6. Request evidence whenever possible.
-7. Separate:
+1. Grill the bug using the Grilling section below.
+2. Investigate the bug and gather reproducible evidence. Do not write code or suggest fixes before enough evidence exists.
+3. Identify root cause candidates.
+4. Separate:
 
    * observed behavior
    * expected behavior
    * assumptions
 
-8. Before writing the brief, inspect .ai/decisions/decisions.md if it exists and has entries. Pull in only decisions that materially constrain the observed behavior, expected behavior, or likely root cause.
-9. Once the bug is sufficiently understood, generate a brief and save it to:
+5. Before writing the brief, inspect .ai/decisions/decisions.md if it exists and has entries. Pull in only decisions that materially constrain the observed behavior, expected behavior, or likely root cause.
+6. For this workflow, "act on it" means creating the brief.
+7. Generate a brief and save it to:
 
 .ai/bugs/active/YYYY-MM-DD-bug-name.md
 
-10. Show the saved brief and stop.
+8. Show the saved brief and stop.
+
+${GRILLING_GUIDANCE}
 
 ${DECISIONS_READ_GUIDANCE}
 
@@ -434,45 +476,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 |
+|-----------|--------|----------|
+
+## Findings
+
+For every finding include:
+
+### Severity
+
+Critical / High / Medium / Low
+
+### Issue
+
+What is wrong.
 
-## Pass/Fail
+### Evidence
 
-Assessment.
+Concrete code, diff, test result, or behavior supporting the finding.
 
-## Risks
+### Impact
 
-Potential issues.
+Why it matters.
 
-## Recommendations
+### Confidence
 
-Further improvements.
+High / Medium / Low
+
+## Unknowns
+
+Areas that cannot be verified from available information.
+
+## Final Assessment
+
+State whether approval is blocked and what remains risky.
 `,
   },
 
@@ -705,55 +795,19 @@ 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');
 }
 
-function hasGrillMeHint(value) {
-  const normalized = value.toLowerCase();
-  return GRILL_ME_HINTS.some((hint) => normalized.includes(hint));
-}
-
-function detectLocalGrillMeSkill(fs, path, cwd, skillRoot) {
-  const root = path.join(cwd, skillRoot);
-  if (!fs.existsSync(root)) {
-    return null;
-  }
-
-  for (const entry of fs.readdirSync(root, { withFileTypes: true })) {
-    if (!entry.isDirectory()) {
-      continue;
-    }
-
-    if (MANAGED_SKILL_NAMES.includes(entry.name)) {
-      continue;
-    }
-
-    if (hasGrillMeHint(entry.name)) {
-      return entry.name;
-    }
-
-    const skillPath = path.join(root, entry.name, 'SKILL.md');
-    if (!fs.existsSync(skillPath)) {
-      continue;
-    }
-
-    const content = fs.readFileSync(skillPath, 'utf-8');
-    const metadata = content
-      .split('---')
-      .slice(1, 2)
-      .join('\n');
-
-    if (hasGrillMeHint(metadata)) {
-      return entry.name;
-    }
-  }
-
-  return null;
-}
-
 function logCheck(log, ok, label, detail) {
   if (ok) {
     log.chalk.green(`  OK   ${label}${detail ? ` - ${detail}` : ''}`);
@@ -863,8 +917,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 +953,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,22 +1006,16 @@ export function doctor(cwd, { fs, path, log }) {
         matches ? 'current' : 'outdated, run `task refresh`'
       );
     }
-  }
 
-  const grillMeFindings = [
-    [CLAUDE_SKILLS_DIR, detectLocalGrillMeSkill(fs, path, cwd, CLAUDE_SKILLS_DIR)],
-    [CODEX_SKILLS_DIR, detectLocalGrillMeSkill(fs, path, cwd, CODEX_SKILLS_DIR)],
-  ];
+    for (const skillName of LEGACY_MANAGED_SKILL_NAMES) {
+      const legacySkillDir = path.join(cwd, skillRoot, skillName);
+      if (!fs.existsSync(legacySkillDir)) {
+        continue;
+      }
 
-  for (const [skillRoot, skillName] of grillMeFindings) {
-    if (skillName) {
-      logCheck(log, true, `${skillRoot} Grill Me companion`, `detected ${skillName}`);
-      continue;
+      checks.push(false);
+      logCheck(log, false, `${skillRoot}/${skillName}`, 'legacy managed skill, run `task refresh`');
     }
-
-    console.log(chalk.yellow(
-      `  WARN ${skillRoot} Grill Me companion - not detected locally; task-fast, task-explore, and bug-explore will use built-in clarification fallback`
-    ));
   }
 
   const gitignorePath = path.join(cwd, '.gitignore');