Work Progress Summary Pro

Record daily work items in a local SQLite database, replace a day's report when the user wants to correct it, edit or delete one logged task by entry id, tra...

Security Scan

The skill appears to implement the described local SQLite work-logging functionality, but its runtime instructions and shipped script reference environment variables (WORK_REPORT_SUMMARY_DB_NAME, WORK_REPORT_SUMMARY_HOME) and filesystem behaviors that are not declared in the registry metadata — a small but notable inconsistency you should review before installing.

Purpose & Capability

The name/description match the included Python script and SKILL.md: the code implements local SQLite storage, per-day records, per-entry updates/deletes, history tracking, and day/week reports. No unexpected network or cloud service integrations are present in the code.

Instruction Scope

The SKILL.md instructs the agent to read reference files and to persist databases under ~/.work_report_summary (or a user-specified path). It also expects the agent to run the shipped script with specific arguments. The instructions reference environment variables and on-disk paths (WORK_REPORT_SUMMARY_DB_NAME, WORK_REPORT_SUMMARY_HOME and a default ~/.work_report_summary) not declared in registry requirements, which is an inconsistency to note.

Install Mechanism

No install spec is provided (instruction-only plus a bundled Python script). That is low risk compared with arbitrary network downloads or package installs. The code is executed locally (python script) and does not fetch external binaries.

Credentials

Registry metadata lists no required environment variables, yet the script and docs optionally read WORK_REPORT_SUMMARY_DB_NAME and WORK_REPORT_SUMMARY_HOME to resolve storage. These env vars are not secret credentials and appear to be optional configuration, but the discrepancy between declared requirements and referenced env vars should be documented by the publisher.

Persistence & Privilege

always is false and there are no special privileges requested. The skill writes local files under a per-user directory (or an explicitly provided db-path). This is expected for a local logging tool; it does not modify other skills or system-wide settings.

What to consider before installing

This skill is mostly coherent and implements a local SQLite work log, with no network calls or secret requirements. Before installing: (1) review the included script yourself (it will create and write a .db file under ~/.work_report_summary by default or at a path you pass), (2) note the SKILL.md and script reference optional env vars WORK_REPORT_SUMMARY_DB_NAME and WORK_REPORT_SUMMARY_HOME even though the registry lists none — set these yourself if you want control over database location, (3) ensure you are comfortable with the agent writing files to your home directory (or supply an explicit --db-path to place the DB elsewhere), (4) verify there are no unexpected external endpoints (the shipped code appears local-only), and (5) if you need stricter guarantees, ask the publisher to declare the optional env vars in the metadata and to provide a checksum or signed release for the script. Overall risk is low but the metadata/manifest inconsistency warrants attention.

Work Report Summary

Overview

Persist work logs in SQLite instead of ad hoc notes so the same history can be queried later for exact daily or weekly summaries.

Workflow

1. Resolve the date as an explicit YYYY-MM-DD value before writing or reading.
2. Resolve the database target. Use default unless the user asks for a separate database. Persist to ~/.work_report_summary/<db_name>.db unless the user explicitly asks for another path.
3. Convert each work item into one JSON array element. Use task as required. Use status only when the user indicates done, in_progress, or blocked. Use details for brief outcome or blocker context.
4. Run the runtime script:
   • record to append entries for a day
   • replace-day to overwrite one day's report with the corrected full set
   • update-entry to revise one existing task by entry id
   • delete-entry to remove one existing task by entry id
   • entry-history to inspect all saved versions for one entry id
   • day-history to inspect all saved changes associated with one work date
   • day-report to inspect one day
   • week-report to inspect the Monday-Sunday week for an anchor date
5. Read the JSON output and answer in the user's language.
6. Stop and surface the error if the command fails. Do not invent missing data.

Recording Rules

• Split multiple tasks into separate items before calling record.
• Default status to done when the user simply says they finished something.
• Preserve short evidence in details when the user mentions outcome, link, or blocker context.
• Run one record command per date when the user gives updates for multiple days.
• Use replace-day when the user says they want to revise, correct, overwrite, or redo an existing daily report.
• Treat replace-day as a full replacement for that date, not a partial merge.
• Use update-entry when the user wants to correct just one logged task while leaving the rest of the day unchanged.
• Resolve the target entry id from day-report or week-report before calling update-entry.
• Use delete-entry when the user wants to remove one mistaken task while leaving the rest of the day unchanged.
• Use entry-history when the user asks what changed, wants an audit trail, or needs to inspect versions after an update or deletion.
• Use day-history when the user asks how a day's report changed over time, or wants to review all historical edits related to one report date.

Reporting Rules

• Use day-report for one explicit date.
• Use week-report for "this week" or any request anchored to a date inside the requested week.
• When the user writes in Chinese, prefer the response shapes in {baseDir}/references/chinese_output.md.
• Mention the exact date or week range in the final answer.
• State that a day has no recorded entries when the database is empty for that day.

References

• Read {baseDir}/references/commands.md for CLI arguments, payload shape, environment variables, and output fields.
• Read {baseDir}/references/chat_reference.md for example user prompts and command selection patterns.
• Read {baseDir}/references/chinese_output.md for concise Chinese response templates for record confirmations, single-entry updates, deletions, history queries, date-history queries, report corrections, daily queries, and weekly summaries.