--- name: work-journal-weekly description: Create or update the comprehensive Week_of_YYYY-MM-DD journal from daily vournal entries, with grouped tasks and user-confirmed impact. Use for comprehensive weekly work-journal requests; use work-journal-weekly-for-slack for Slack-ready summaries. --- # Weekly work journal Create one source-bound weekly journal. Completion means every distinct daily task is represented once, existing manual edits survive an update, and every impact claim has explicit user approval. ## Workflow 1. Resolve the week and paths. - Default to the week containing today in the Mac's local timezone. - Accept a full date such as `2026-08-20` and resolve it to that week's Monday. Ask for a full date when the user gives only a month and day. - Treat the week as Monday through Sunday. A current partial week is valid. Stop if the resolved Monday is in the future. - Write `/Users/skull/personal/vournal/YYYY/MonthLongName/Week_of_YYYY-MM-DD.md`, using the year and full English month name of that Monday. 2. Read all existing daily files for the resolved Monday through Sunday. Resolve each daily file from its own date, so a week may cross a month or year boundary. Read the existing weekly file too. Ignore `Week_of_*.md` and `Week_of_*_Slack.md` as daily sources. 3. Build a source inventory before drafting. Every meaningful list item must map to one category and one proposed weekly bullet. Preserve its links, attribution, and nested context. 4. Follow the create or update branch below. Show the required proposal and wait for approval before changing the weekly file. 5. Write the approved content with a trailing newline. Report the path, changed sections, and number of approved impact bullets. If the sources yield no approved change, leave the file untouched and say so. If no daily files and no weekly file exist, stop with "nothing to write." If the weekly file exists but daily files are missing, preserve it unchanged. A missing daily file is absence of evidence, not proof that prior work was deleted. ## Source model Recognize `### Ships`, `### Admin`, `### Calls`, `### Reviews`, and `### Personal`, and keep that order. Keep an item under its nearest recognized heading. Put an unheaded meaningful list item under Admin unless its content clearly identifies another recognized category. Merge daily items that describe the same work, but preserve distinct tasks. Remove day-level chronology from the weekly version and organize by category and workstream. Tightening and grouping may change phrasing, but may not add facts beyond the daily entries. ## Output contract The file has this shape: ```markdown ## Tasks ### Ships - ... ## Impact - ... ``` Within `## Tasks`, use the recognized `###` sections in their fixed order and omit empty sections. Add a `####` workstream when it separates at least two coherent groups or makes one substantial body of work easier to scan. Otherwise keep bullets directly under their `###` section. A workstream that spans categories remains split across the relevant category sections. Start every task with `- `. Merge overlapping daily wording while preserving facts, links, component names, and meaningful nested details. Match the daily style: concise, lowercase except for proper nouns, and information-dense. Describe the work performed, not unconfirmed value. Preserve accurate user conventions and correct only obvious errors that do not change meaning. Add `## Impact` only when it contains at least one approved `- ` bullet. ## Impact gate Draft bounded candidate effects from any task category. Each candidate must name the direct user, system, teammate, or process effect and show the supporting task, using "because" or equally explicit wording. Source text may support a candidate; it does not approve it. Ask the user to approve, edit, reject, or add candidates. The user's exact edit counts as approved wording. Claims about revenue, adoption, conversion, retention, product strategy, customer satisfaction, or another broad outcome require explicit confirmation. Write approved impact only. For a new weekly file, ask about every candidate. For an existing file, ask only about impact tied to a proposed addition or correction. Keep previously approved impact unless the user requests a revision or approves removal of its stale source. ## Create branch 1. Show the proposed categories, workstreams, merged bullets, and the daily source bullets represented by each merged bullet. 2. Ask the user to approve or revise the grouping. Completion requires a clear decision on every proposed group. 3. After grouping approval, show impact candidates with their supporting tasks and pass the impact gate. 4. Write the complete approved file. ## Update branch Weekly files are manually maintained. Compute a source delta and propose only source-backed changes: - Add a genuinely new item under the matching workstream or directly under its category. Create a workstream only when it meets the output rule. - For an edited source item, show the current weekly wording and proposed replacement. Apply it after approval. - Propose removal only when source history proves that a represented daily item was deleted, or when the user identifies it as stale. Missing daily files do not justify removal. - When an item fits more than one group, choose the group that best matches its primary outcome and include it once. - Preserve all unrelated text, section order, formatting, and approved impact. Show the task delta and any new impact candidates with source support. Apply only approved additions, replacements, removals, and impact. Do not regenerate the whole file during an update. ## Hard boundaries - Daily journal files, the existing weekly file, and user confirmations are the only factual sources. Following links does not authorize adding outside claims. - Metrics, impact, authorship, attendance, approvals, and links require source support. - User-written weekly content is removed only after a targeted stale-content proposal is approved. - Output stays under `/Users/skull/personal/vournal/YYYY/MonthLongName/`.