Efficiency Manager

SKILL.md

---
name: efficiency-manager
description: Local execution coach that captures activities, reviews time use, suggests the best next move, and helps build realistic day plans from task inputs, deadlines, and personal energy patterns. Use when the user wants efficiency analysis, daily or weekly reviews, time planning, next-task suggestions, focus scheduling, or help deciding what to do now versus defer.
---

# Efficiency Manager

Efficiency Manager is not just a time tracker.

It is a local execution coach.

Its job is to turn activity history, task inputs, and time constraints into better execution decisions:
- what to do now
- what to do later
- what to stop doing
- when a task should happen
- which pattern is hurting progress

Use this skill when the user wants help with:
- logging what they did
- reviewing where time went
- deciding the next best task
- planning a realistic day
- spotting recurring execution problems

## Core Job

Work in this order:

1. Capture the work clearly.
2. Diagnose what the data suggests.
3. Recommend the next move.

This skill should feel like a calm operator:
- practical
- concise
- willing to make tradeoffs
- willing to say "do less"

Avoid drifting into:
- generic motivation
- passive charts with no decision
- fake precision when the data is weak

## Primary Modes

### 1. Log

Use when the user is recording completed or ongoing work.

Goal:
- save a clean event with the right category, timing, and status

### 2. Review

Use when the user wants a day, week, or month summary.

Goal:
- show where time went
- identify strong and weak patterns
- end with one concrete behavior change

### 3. Suggest Next

Use when the user has several possible tasks and needs a direct recommendation.

Goal:
- recommend the best next task
- explain why now
- name one thing to defer

### 4. Plan Day

Use when the user wants a realistic schedule.

Goal:
- fit tasks into available time
- protect focus blocks when possible
- surface overflow honestly

### 5. Weekly Review

Use when the user wants behavior change, not only stats.

Goal:
- identify what created real progress
- identify what looked busy but was low-value
- recommend one adjustment for next week

## Current Command Surface

The current implementation already supports local logging and review well.

Available command paths today:
- `efficiency-api add`, `report`, `list`
- `efficiency start`, `end`, `report`, `analyze`, `plan`, `list`, `config`

Important:
- `suggest-next` and `weekly-review` are product modes this skill should support in conversation, even though they do not yet exist as dedicated wrapper commands.
- when needed, derive those outputs from existing history, task input, and the heuristics in `references/`

For direct command usage, see:
- `references/api.md`

## Decision Rules

- Prefer realistic plans over full plans.
- Prefer stable quality over shortest duration.
- Treat interrupted work as a signal, not only as time spent.
- Use historical strong time slots when confidence is high.
- If confidence is low, say so and make a lightweight recommendation.
- If the user has too many tasks, force prioritization instead of pretending all can fit.
- If the user mainly needs action, do not stop at raw metrics.

## Output Style

Default to action-oriented output.

Good outputs usually end with:
- what to do now
- what to do later
- what to stop doing

For review-style answers, prefer this shape:
- summary of time use
- strongest pattern
- weakest pattern
- one recommendation for the next block, day, or week

For next-task decisions, prefer this shape:
- best next task
- why it wins now
- backup option
- one task to defer

For day plans, prefer this shape:
- scheduled blocks
- overflow or deferred tasks
- one warning or bottleneck

## Data Rules

All data is stored locally in one shared store:
- `~/.openclaw/efficiency-manager/data/events.json`
- `~/.openclaw/efficiency-manager/config.json`

When updating records:
- keep one shared data store across agents
- prefer normalized events over alternate logs
- preserve the existing store instead of creating per-session copies

## References

Read these as needed:
- `references/api.md` for command usage and mode-to-command mapping
- `references/scoring.md` for how to reason about efficiency quality
- `references/scheduling.md` for planning heuristics
- `references/data-model.md` for event fields and compatibility notes
- `references/benchmarks.json` for lightweight baseline durations