Assistant Task Optimizer

Analyze an assistant task or project definition, identify optimization opportunities, present a prioritized plan, get user sign-off, then implement agreed changes.

This skill applies the patterns from references/06_TASK_EFFICIENCY_GUIDE.md and references/07_TASK_LEARNING_GUIDE.md. Read those guides if you want to understand the reasoning behind any recommendation.

Rules

Clarifying questions: For any step with a fixed set of options, use the current surface’s question tool when available, otherwise ask a concise question in chat.

• Always use this skill before making any edits to an assistant task or project — even if the user just says "take a look at my task."
• Do not silently apply changes beyond what was agreed in Phase 3.
• Flag tradeoffs explicitly — do not silently optimize toward one axis (speed vs. thoroughness).

Platform selection

The stable skill name remains cowork-optimizer. Identify Claude/Cowork, Codex, ChatGPT or a Google surface (Antigravity, Jules, Gemini app scheduled actions) and the actual task runner. Google routes are documented, not tested: say so when the audit relies on them. Optimise the shared procedure without changing its scheduler owner, permissions, or outcomes. Use reported metrics where exposed; mark estimates as estimates and unavailable usage as unknown. Inspect only the supplied project; for source-only projects, work from supplied task definitions and return proposed edits if write access is absent.

Phase 1: Ingest

If the content is already in the conversation, skip to Phase 2 immediately.

Otherwise, look for the task in the folders this session can actually reach before asking the user: the working directory, and each folder connected through a device bridge (search there with the bridge's shell, such as device_bash, giving the connected folder's path rather than ., since that shell may start elsewhere):

find "<folder>" -maxdepth 6 -name "TASK.md" -not -path "*/.git/*" 2>/dev/null

A cloud session's own container holds no user tasks, so an empty result there means "not reachable from here", not "no tasks".

If one or more TASK.md files are found, present the list and use the current surface’s question tool (or chat if unavailable) (one per found task + "Paste content here") to ask which to audit. If none are found, use the current surface’s question tool (or chat if unavailable) to ask how the user wants to provide it:

Buttons: Paste task instructions / Provide file path / Provide project folder path

If files are referenced inside the instructions (e.g., skill files, reference docs, templates), read those too — optimization depends on understanding the full dependency chain.

Read any referenced skill files. If the task invokes one or more skills (via /skill-name or a skills: directive), read those SKILL.md files before auditing. A task may be doing manually what a skill already handles better, or may be loading a skill for a narrow use case that doesn't justify the overhead.

Also check whether the task folder contains any of these companion files — they're highly informative for the audit:

• IMPROVEMENTS.md — tracks applied fixes, pending proposals, and known issues
• RUN_LOG.md — reveals which steps fail repeatedly or take long
• KNOWLEDGE_SUMMARY.md — indicates whether state is being carried efficiently between runs

If the content is already in the conversation, skip asking and proceed directly to Phase 2.

Phase 2: Audit

Analyze the task/project across eight dimensions. For each finding, note: what it is, why it's a problem, and the effort to fix (Low / Medium / High).

Read references/audit-dimensions.md for the full checklist. The dimensions are ranked by typical ROI:

Stop when you are confident there are no further significant findings. Dimensions 2.7–2.9 can be skipped if the task is already efficient.

Phase 3: Present the Plan

If no findings exceed ~500 tokens per run in estimated impact and none are qualitatively significant (clarity, correctness, structural), say so explicitly and stop: "This task is already well-optimized. No changes recommended." Do not generate a thin list of minor findings just to appear thorough.

Otherwise, produce a structured audit report in the conversation. Format:

Summary — one sentence characterizing the main issues and rough token cost estimate if calculable.

What already works — one or two lines naming the parts of the task that are efficient or well structured and should survive the edit. Without this the report can only be read as a list of deficiencies, including for a task that is largely fine.

For each finding that is a judgement rather than a measurement, carry a confidence and name what evidence would make you drop it. A finding with no answer to that is an opinion — leave it out.

Then a prioritized list of findings, highest ROI first. For each:

• Finding title (e.g., "Unconditional large file load in step 3")
• What the problem is
• Proposed fix
• Effort: Low / Medium / High
• Impact: token savings estimate, speed improvement, or qualitative benefit

Token estimation guide:

Flag tradeoffs explicitly. If a proposed change trades thoroughness for speed, say so. Let the user decide — don't silently optimize toward one axis.

Scope note: Self-improvement infrastructure (IMPROVEMENTS.md, RUN_LOG.md, KNOWLEDGE_SUMMARY.md) is valuable but represents a meaningful addition, not just a cleanup. Present it as an optional enhancement, not a required fix, unless the task already has partial scaffolding.

End with a question using the available tool or chat: All of them / Let me pick / None — findings only (If "Let me pick": follow up with numbered buttons for each finding.)

Phase 4: Implement

Once the user confirms which changes to make:

1. Back up before editing. Preferred: git add and commit the current state so there's a clean restore point. If git is not available, copy the file with a .bak suffix. Note the backup location in your response.
2. Apply changes one finding at a time.
3. After each non-trivial change, briefly note what you changed and why (one line).
4. Present the final revised task/project.
5. If the task has test prompts or a known test workflow, suggest running it to verify behavior is unchanged.

To roll back: restore from git through a temporary file, so a wrong path cannot empty the original: git show HEAD:./<file> > /tmp/restore && cat /tmp/restore > <file> (the ./ makes the path relative to the current directory; writing with cat truncates in place, so it also works on a mounted folder that refuses delete, where git checkout -- <file> fails). Otherwise copy the .bak file back to its original path and delete the modified version.

Apply vs. propose discipline:

• Apply directly (no further confirmation): clearly correct, low-risk, narrow-scope changes — typos, wrong dates, confirmed facts, adding a named sender to a noise list.
• Flag and ask before applying: anything that affects behavior in a non-obvious way, restructures how information is tracked, modifies core logic, touches 3+ files, or where you're not certain the user would agree.

Do not silently apply changes beyond what was agreed. If you spot something while implementing that wasn't in the plan, flag it and ask.

Phase 5: Wrap-up

After implementation:

• Summarize what changed vs. what was left alone (and why, if relevant).
• Note the new estimated TASK.md line count and token cost per run if measurably improved.
• Offer to package/export if the user needs to reinstall the task or share it.
• If the frontmatter description is vague or seems to trigger unreliably, offer to rewrite it: a good description names concrete user phrases, specific file types, and clear exclusions. Rewriting it is low-effort and can significantly improve how reliably Claude picks up the skill.

Edge Cases

• If the task file is empty or contains only a title: say "This task has no content to audit. Would you like me to help you write it from scratch instead?" and offer to run tasks/setup-scheduled-task.md.
• If the task is under 50 lines and already follows Guide 06 patterns: say "This task is already well-optimized. No changes recommended." Do not invent marginal findings.
• If the user provides a Cowork project folder (not a single TASK.md): read all task files in the folder and audit each independently, presenting findings grouped by file.
• If IMPROVEMENTS.md contains stale proposals (>10 pending, none applied): flag this as a finding — the improvement system itself needs maintenance.
• If the task uses MCP tools that are not configured in the current environment: note this in findings but do not treat it as an optimization issue — it's a setup problem, not an efficiency problem.