Efficiency Manager

Local execution coach that captures activities, reviews time use, suggests the best next move, and helps build realistic day plans from task inputs, deadline...

Security Scan

The skill is internally coherent for a local time-tracking/execution-coach: it only reads/writes local files under ~/.openclaw/efficiency-manager and exposes CLI/wrapper scripts; nothing in the files or instructions requires unrelated credentials, network access, or elevated OS privileges.

Purpose & Capability

Name/description match the code and instructions: analyzer, reporter, scheduler, and storage modules implement local logging, review, and lightweight planning. Required resources (none declared) align with a local tool; code only uses filesystem (process.env.HOME) and normal local config.

Instruction Scope

SKILL.md and integration docs limit actions to local logging, reporting, and planning via the included wrapper/CLI. The skill instructs agents to read/write the shared local store and to call local scripts; it does not instruct reading unrelated system paths or transmitting data externally.

Install Mechanism

No install spec and no external downloads. All code is bundled in the skill. Integration is via local Node scripts (scripts/cli.js, scripts/efficiency-api wrapper) executed from the skill directory; this is expected for a local CLI-style skill.

Credentials

The skill requests no environment credentials. It accesses process.env.HOME to locate ~/.openclaw/efficiency-manager and persists data there. This is proportionate, but worth noting: data are stored unencrypted in a shared directory, so multi-user hosts or other agents on the same machine could access the stored history.

Persistence & Privilege

The skill persists a shared local store (~/.openclaw/efficiency-manager/data/events.json and config.json) and recommends agents use the shared store. It is not marked always:true and does not modify other skills. Persisting user history locally is expected for this tool but increases the footprint and lifetime of user data.

Assessment

This skill appears to do exactly what it says: local logging, reports, and simple planning using files under ~/.openclaw/efficiency-manager. Before installing or enabling it: 1) Review the CLI wrapper scripts (scripts/api-wrapper.js and scripts/cli.js) yourself to confirm no unexpected network calls; most shown modules only use fs and local heuristics. 2) Accept that all events and config are stored unencrypted under your HOME directory and shared across agents on the same machine — if your device is multi-user or you want stronger privacy, consider relocating or encrypting the store. 3) The skill can be invoked by agents (normal default behavior); if you do not want autonomous runs, restrict agent invocation policies in your environment. 4) If future versions add network capabilities, re-evaluate for exfiltration risk.

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