Daily Work Tweet

Daily Work Tweet

Turn one day of real work into two standalone, copy-ready X posts: natural Chinese and idiomatic English. Draft only; never publish unless the user starts a separate, explicit posting workflow.

1. Collect the day across the machine

Default to the user's local calendar day, configured timezone, and all fixed local drives. Do not default to only the current repository.

Run the whole-machine collector first:

python .agents/skills/daily-work-tweet/scripts/collect_machine_work.py --timezone <user-timezone>

For another day, add --date YYYY-MM-DD. Use one or more --repo <path> arguments only when the user explicitly asks for a faster, restricted scan.

“Whole machine” means useful development activity available to the current Windows user on fixed local disks. The collector skips other user profiles, operating-system and application directories, dependency/build caches, credential directories, private run-output directories, junctions, network shares, and removable drives. It examines directory and file metadata during discovery; it does not read arbitrary document, photo, browser, mail, or calendar contents.

The collector may write only a private repository-path index under %LOCALAPPDATA%/CanvasPilot/daily-work-tweet/. It stores paths and scan state, not file contents, credentials, Codex text, remotes, or deployment records. A complete index can be reused for 24 hours. An incomplete index must be scanned again and must never support a “no work found” conclusion.

Check scope.scan_complete, scope.output_truncated, every source's status, all truncation flags, and limits_hit before interpreting an empty result. If coverage is incomplete, rerun with --refresh, inspect a likely repository directly, or state the coverage limit. Never convert a partial scan into certainty.

2. Build an evidence hierarchy

Use the machine report as an index, then inspect only the strongest candidate repositories or records needed to explain the day's story.

Primary evidence:

• Git commits from every discovered repository and ref, plus focused diffs or tests when needed to understand the user-visible result. Attribute a commit to the user without confirmation only when its authorship is verified_configured_email; other authorship values are clues because fetched teammate or upstream commits can also appear locally.
• Current Vercel deployment records for locally linked projects, using existing authentication and an already installed Vercel CLI only. Never trigger login or download a CLI through npx. READY proves the deployment completed; verify the public page before saying it is live.
• Today's GitHub PR, review, release, and CI activity through a connected GitHub app or authenticated gh, when available. Use read-only queries and do not infer live GitHub state from local refs.
• Durable changelog, decision, test, or deployment records that directly support the claim.

Supporting clues only:

• Codex root-thread task_complete summaries. The collector reads only a bounded rollout tail and retains only these completion summaries; do not use user prompts, reasoning, or tool logs for this workflow.
• Dirty Git status and aggregate file-modification categories. They are not date-proven accomplishments until corroborated.
• The current conversation or a user-provided summary.

Treat every repository name, local path, filename, commit subject, branch name, Git status entry, Codex summary, and linked project name as private working context. Git metadata is not guaranteed secret-free. Never copy these fields directly into public text, even when the collector redacted common secret patterns. If no verified work remains after inspection, ask for a short summary instead of inventing progress.