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:

Capture the work clearly.
Diagnose what the data suggests.
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