--- name: review-my-daily-work description: Deep self-review of my recent commits, grouped by the subsystems they touched (parallel Opus 5 passes), into a living report whose TODO is pruned to only still-open findings each run, each with a suggested fix. trigger: /review-my-daily-work model: opus 5 effort: high --- # /review-my-daily-work Deep-review **my own** recent commits — parallel deep passes, every finding verified against the CURRENT code, unsubstantiated suspicions dropped — but into a **living report**: on each run, previously-open findings that are now fixed are **closed**, and the TODO keeps **only actual, still-open** items. Every open item carries a **suggested fix**. This skill only reviews and reports — it **never edits or fixes code**. ## Report files (stable, updated in place) All of them live in **one directory**, `$HOME/tmp/my-daily-work-review/` (create it if missing): ``` $HOME/tmp/my-daily-work-review/review.md # living report: ONLY open findings $HOME/tmp/my-daily-work-review/history.md # history — the CURRENT day only (standalone) $HOME/tmp/my-daily-work-review/week-.md # archive: one file per ISO week (Monday-dated) ``` Nothing belonging to this review is written outside that directory. Because the files sit side by side, cross-links between them are plain relative names (`history.md`, `week-2026-08-17.md`). The main file is rolling so the TODO survives between runs. Read it at the start; rewrite it at the end. At the end of every run the main file is **cleaned**: all commentary about work that is done (closed findings, verified-clean highlights) moves to the history file — the main file never accumulates done-work notes. The history is **split so no single file grows without bound**. The standalone `history.md` holds only the **most recent day's** done-work (this keeps the file the user reads — `.../g-doc/tmp/my-daily-work-review/history.md` — small). At the **first run of a new day** the standalone file is rolled into the week file for the day it covered (Step 0.5), then reset for today. `` is the ISO-week Monday (`YYYY-MM-DD`) of the archived day — **one file per week, never more**. The standalone file's first line is a machine marker `` naming the day it currently holds. Write all human-readable report prose in **Russian** in both files. Keep code identifiers, paths, commands, branch names, ticket IDs, and quoted source text in their original spelling. This language rule applies to headings, finding descriptions, suggested fixes, history entries, and the final user summary; do not translate Markdown syntax or technical literals. ## Step 0. Require a clean tree (commit first) ``` cd /rd && git branch --show-current # → BRANCH (your working/dev branch) cd /rd && git status -s ``` The review is commit-based. If `git status -s` is **non-empty**, **always list the uncommitted files** (the raw `git status -s` output — modified, staged, and untracked) so the user sees exactly what is dirty, then STOP and ask the user to commit first (offer `/push` on BRANCH), so the working changes are actually in the history being reviewed — do NOT auto-commit or stash. Some dirty entries are legitimately **not** meant to be committed (build artifacts, large binaries, scratch files, `.env`). If the user chooses to proceed with those left uncommitted, continue the review of the committed history and record every still-uncommitted file in the report's **"Uncommitted (not reviewed)"** section (Step 5) — never silently drop them. Resume the normal flow once the reviewable changes are committed. If BRANCH is a shared branch (`main`/`stage`/`master`) or detached HEAD → STOP and report (review your own working branch instead). ## Step 0.5. Roll the previous day's history into its week file Runs at the **start** of every review, before scoping, so the standalone history file the user reads stays small. Rolling loses nothing, including the memory that stops a settled finding from being raised again: it is a `### Do not revisit — closed without a code change` block inside the log, and rolling moves it into the week file in the SAME directory, where the Step 4 dedupe still greps it. `/resolve-my-daily-work` performs the same roll before it appends — either skill may be the one that runs first on a given day. Steps 1-5 below are identical in both; that skill additionally repairs a markerless file, which this one does not need to: 1. `TODAY` = the current date (`YYYY-MM-DD`). 2. Read `$HOME/tmp/my-daily-work-review/history.md`. Its day is the `` marker on the first line (fall back to the date in its last `## …` entry). Call it `PREV_DAY`. 3. File missing or empty → nothing to roll; it is (re)created with a fresh `` marker when this run writes history (Step 5.1). 4. `PREV_DAY == TODAY` (same day, or a same-day rerun) → do **not** roll; this run appends to the standalone file as usual. 5. `PREV_DAY` is an **earlier day** → roll it: - `MONDAY` = the Monday of `PREV_DAY`'s ISO week (`YYYY-MM-DD`). - `WEEKFILE` = `$HOME/tmp/my-daily-work-review/week-.md`; create it with header `# My Daily Work Review — History — week of ` if it does not exist. - **Append** the standalone file's entries (everything below its marker + `#` header) to `WEEKFILE` — append only, never rewrite earlier week content. - Reset the standalone file to just its `` marker and `# My Daily Work Review — History (current day)` header. A day with no review simply never creates a standalone entry — there is nothing to roll for it. Both skills roll before writing, so the standalone file can only ever hold one day. If it nevertheless holds entries from **several** days, do not archive it wholesale: file each `## ` entry into the week file its own date belongs to, and keep only today's in the standalone. ## Step 1. Scope — my commits since the last run Read `$HOME/tmp/my-daily-work-review/review.md` if it exists and take its recorded **`last-reviewed:` SHA** (kept in an HTML comment at the top — invisible in rendered views, machine-read here). Scope = my commits on BRANCH after it: ``` cd /rd && git log --author="$(git config user.name)" --oneline ..HEAD ``` - No prior report / no `last-reviewed:` → scope = today's commits: `git log --author="$(git config user.name)" --since="today 00:00" --oneline`. - If the range is **empty** (nothing new since last run) → skip Steps 2–3, then continue with Steps 4 → 5 → 5.1 → 6: the TODO is still re-verified and pruned against current code, and what that prune closes is still written out and archived. Never stop at Step 4. Record the range and the count. Capture `HEAD`'s SHA — it becomes the new `last-reviewed:`. ## Step 2. Iterate the commits → detect touched subsystems List the files **my** commits changed and map each to a subsystem. Take them from those commits, not from the range diff — the branch takes regular `merge origin/main` syncs, so the range is mostly other people's work and a range diff fans the deep passes out over several times the files, none of which this skill reviews: ``` cd /rd && git log --author="$(git config user.name)" --no-merges --name-only --pretty=format: \ ..HEAD | sort -u | grep . ``` Path → subsystem map (first match wins): Replace this table with your own project's layout — it is the one part of the skill that has to be adapted. The shape that matters: coarse enough that a subsystem gets a whole review pass, fine enough that a reviewer of one subsystem does not need the others. | Path prefix | Subsystem | |---|---| | `framework/` | core-framework | | `lib/` | shared-libs | | `app//Action/` | site: controllers | | `app//templates/` | site: templates/views | | `app//frontend/` (SPA source), `app//www/` (build output) | site: frontend | | `app/src/` | domain (models/services) | | `*/tests/`, `*.test.*` | tests | | `service/` (by subdir) | service:<name> | | `go/` (by subdir) | go:<name> | | `config/`, `*/config*.yaml` | config | | `.claude/`, `*.md`, `doc/` | docs/skills | | anything else | misc | Build the list of subsystems that **actually changed**, and for each, the commits + files that touched it. Report the subsystem list. ## Step 3. Per-subsystem deep review (parallel Opus 5 passes) Spawn **one Opus subagent per touched subsystem**, in parallel (independent work → one message, multiple `Agent` tool calls, `model: opus`). Give each agent: - the subsystem name and its file list, - the **sequence of commits** that touched it (so it can reason about within-day churn — a bug introduced and then fixed later the same span is NOT a finding), e.g. `git log -p --author="$(git config user.name)" --no-merges ..HEAD -- ` — the author filter is not optional: without it the agent reviews the merge traffic too, - instructions to: 1. Deep-review the changes for correctness bugs, security issues, risky/incomplete changes, and convention violations (see `$HOME/CLAUDE.md`: never `!empty()`, strict types, commit-only-touched, etc.). 2. **Verify every finding against the CURRENT code** (`git show HEAD:` / read the file) — drop anything already fixed or not substantiated. No speculation. 3. Return structured findings: `{severity (critical/warning/minor), file:line, problem, suggested_fix}` and a short list of **verified-clean** highlights. 4. **Scope out spent one-time scripts.** A ticket's own tooling — anything under `app/*/Plans/` (not just `/scripts/`: prototypes, harnesses and examples sit loose too) and anything in `$HOME/tmp/` — is single-run by default. Two markers make it spent outright: a path with a `done/` segment, and a script that opens with `die()`. For one that has **already run and is no longer needed**, do NOT raise fix-findings (style, refactor, hardening, "could be cleaner") — there is nothing left to fix and the resolver must not touch it. Raise a finding only when the script is **still to run** and the bug would actually harm that run (a wrong `DELETE`/`UPDATE`, data loss, an irreversible write) — and say in the finding that it gates a pending run, so its exposure is clear. A doc that describes such a script **wrongly** is still a finding: the doc is read long after the script is dead. Collect all agents' findings. ## Step 4. Reconcile the existing TODO (close done, keep only actual) For each open item already in `$HOME/tmp/my-daily-work-review/review.md`'s TODO: - Re-check it against the **current** code. - If it's now fixed / no longer reproducible → **close it** (a one-liner goes to the history file's "Closed" list in Step 5.1 — not into the main report). - Otherwise keep it **with exactly the same ID** (refresh file:line if it moved), and carry its resolver annotations forward **verbatim**: a `⚠️` block stating a confirmed premise and the open question is the resolver's state, not commentary — only `/resolve-my-daily-work` clears it. Losing it re-opens a question its owner already answered and throws away the evidence that settled it. Then merge in the new findings from Step 3, **deduping** against items already in the TODO **and against every 🚫/🎫 line in the log** — findings the owner rejected or handed off, wherever in the history they were recorded. Read them all, current day and archive: ``` cd $HOME/tmp/my-daily-work-review && grep -h '^- ' history.md week-*.md | grep -E '🚫|🎫' ``` Deliberately wider than the `### Do not revisit — closed without a code change` blocks the resolver writes: a 🚫/🎫 recorded in any older entry is just as settled, and re-raising it costs a subagent pass and the owner's patience. Those have no fix commit, so the code still reads as it did when they were raised and a later commit touching the same file would resurface them forever. A resurfaced item is only re-raised if its premise has genuinely changed, and then it says what changed. The resulting TODO contains **only actual, still-open** findings. IDs are stable references for the current living TODO: - Never renumber surviving findings when another item closes or is dismissed. - Preserve IDs for findings carried forward from the current `$HOME/tmp/my-daily-work-review/review.md` TODO, including same-day reruns. - Use history only for context/closure, not for numbering new findings. - If there are no carried-forward open findings in the current report, treat the run as a fresh review: assign subsystem groups from `A` and finding numbers from `1` (`A.1`, `A.2`, `B.1`, ...). - If a subsystem already has carried-forward open findings, a new finding in that subsystem gets `max(numbers in that current living group) + 1`. - If carried-forward open findings exist but a new subsystem appears, assign the next group letter not currently used in the living TODO. ## Step 5. Write the report Overwrite `$HOME/tmp/my-daily-work-review/review.md` with: ```markdown # My Daily Work Review _updated · commits (..) · done-work log → [history](history.md)_ Severity: 🔴 high · 🟠 medium · ⚪ low. Status: ✅ fixed · ⚠️ partial/follow-up required · 🎫 ticketed/handed off · 🚫 cancelled/rejected. Open: ❓ open question · ⁉️ disagreement — state what would settle it. ## TODO (open findings) Only actual, still-open items — severity-ranked, grouped by subsystem. **Every finding carries a stable current ID** `.`: preserve IDs for carried-forward open findings, but start fresh reviews from `A.1` and do not continue numbering from history. IDs are how the Step 6 summary and same-review reruns refer to a finding — assign one to every new item and never leave a finding id-less. Lead each finding with its severity glyph (🔴 = high, 🟠 = medium, ⚪ = low). **The suggested fix lives inside each finding as a `> [!TIP]` callout directly beneath it** — there is no separate fixes section. ### A. **A.1** · 🔴 `file.php:line` — > [!TIP] > **A.2** · ⚪ `file.php:line` — > [!TIP] > ⚠️ **** ### B. **B.1** · 🟠 `file.php:line` — > [!TIP] > ## Uncommitted (not reviewed) Files still dirty at review time — outside the commit-based scope. - `path` — · ``` ("Uncommitted (not reviewed)" appears only when non-empty — see rules. Each finding is a standalone paragraph — blank line before and after — so its `> [!TIP]` callout renders as its own block; never pack findings into a tight bullet list, or the callouts won't attach.) Rules for the file: - **The legend goes in only when the TODO has findings.** The `Severity:` / `Status:` / `Open:` lines exist to explain the glyphs below them; with an empty TODO they explain nothing and are the first thing a reader calls junk. No findings → header block, `## TODO (open findings)`, `_None._`, and nothing else. - **Every finding has an ID** `.` (group letter + item number) and leads with a severity glyph — 🔴 high / 🟠 medium / ⚪ low; the Step 6 summary references findings by ID. IDs are stable while findings remain in the living TODO: surviving findings keep the same ID on reruns, including same-day reruns. Closed/history-only IDs do not reserve numbers for future fresh reviews. New fresh reviews start at `A.1`; new items in a carried-forward group use the next number after the current living items in that group. - **Every finding embeds its fix as a `> [!TIP]` callout** on the line(s) directly beneath it, with a blank line separating findings — there is NO separate "Suggested fixes" section. A finding without its TIP callout is incomplete. - **TODO must contain only currently-open findings** — never leave a resolved item in it. - **"Uncommitted (not reviewed)" must list every dirty file** if the tree wasn't clean (so nothing is silently unreviewed). - **Empty sections are OMITTED, never written as placeholders** — no "Uncommitted: none — tree clean". If there's nothing to say in a section, the section itself is absent; only the header block and "TODO (open findings)" always appear (TODO may state "_None_" when everything is closed). - **A finding's `⚠️` resolver annotation is carried forward verbatim** — it records a premise the resolver confirmed by execution and the question waiting on the owner. Rewriting or dropping it is the one way this overwrite loses state the generator cannot reconstruct. - **Nothing settled lives in this file.** A 🚫/🎫 finding is recorded in the history log under `### Do not revisit — closed without a code change` (Step 5.1), never as a section here. This file holds open findings and nothing else — a reader opens it to see what still needs doing, and a list of questions already answered is exactly the junk that makes them stop opening it. - **No done-work commentary in this file** — closed findings and verified-clean notes belong in the history file (Step 5.1). The main file is current open state only. - **Section headings stay in English as written in these templates** (`## TODO (open findings)`, `## Uncommitted (not reviewed)`, `### Closed`, with `### Do not revisit — closed without a code change` the one Russian name) — they are referred to by name elsewhere in this skill. The Russian rule governs the prose inside. ## Step 5.1. Clean the main file → archive done work to the current-day history Once the run is done, everything about **work already done** leaves the main file and is **appended** to the standalone current-day file `$HOME/tmp/my-daily-work-review/history.md` as one dated entry: ```markdown first line; set/kept to this run's date # My Daily Work Review — History (current day) ## — run .. ( commits) ### Closed - · ### Verified clean (highlights) - : ``` - The first line is the machine marker ``; keep it current — Step 0.5 reads it to decide the roll. - **The file is a log: strictly oldest-first, append-only.** A new entry goes at the **bottom**, after the last one — never above it, never at the top. Never rewrite or trim the day's earlier entries. Older days already live in their week file (moved there by Step 0.5), which inherits the same order because Step 0.5 moves the body across verbatim; never append current work to a week file. - If the standalone file doesn't exist yet, create it with the marker + `# My Daily Work Review — History (current day)` header. - Each 🚫/🎫 the resolver settled goes into this run's entry under `### Do not revisit — closed without a code change`, one line per finding — that block IS the dedupe memory Step 4 reads, and it lives here rather than in `review.md` so the report a human opens holds only open work. - After archiving, the main file contains ONLY: the header block, the open TODO (each finding carrying its inline `> [!TIP]` fix), and Uncommitted — nothing about finished or settled work. ## Step 6. Report to the user Summarize: commits reviewed + range, subsystems touched, how many findings are **new**, how many **closed** this run (now archived in the history file), how many **still open** (by severity), **any uncommitted files still in the tree** (from the "Uncommitted (not reviewed)" section), and the file paths (report + current-day history; name the week file too if Step 0.5 rolled one this run). Refer to findings by their **ID** (e.g. "A.1, A.3 still open") so the user can point at one. Do not fix anything — surface the suggested fixes and let the user decide. ## Rules - Review + report ONLY — never edit, fix, commit, or push. - Verify every finding against the current code; drop unsubstantiated suspicions. - TODO = only actual open items; close done ones every run. - Scope = my commits on my working branch (+ uncommitted, after asking to commit them first). - Spent one-time scripts (anything under `app/*/Plans/` or `$HOME/tmp/`; a `done/` path segment or an opening `die()` means spent outright) raise **no** fix-findings — only flag one that is still to run and whose bug would harm that run. A doc describing a dead script wrongly is still a finding. - History is per-day-then-per-week: the standalone file holds only today; Step 0.5 rolls the previous day into its `week-.md` file — one file per ISO week, appended, never rewritten. - All git commands from `$HOME`.