Work Report Generator
Turn unstructured daily notes and commit messages into a formal reports/YYYY-MM-DD/REPORT.md. Strict no-inference: every task, project assignment, and per-project hour count comes from the user, asked explicitly. Report template, anti-patterns, and closing checklist in RECIPES.md.
1. When to use
Daily or backfilled work reports written in a formal tone, in any language. Triggered by phrases like "generar reporte", "reporte de trabajo", "work report", "daily report", "reporte del día", or the /work-report slash command.
Skip this skill for: changelogs, release notes, retrospectives, CV/resume writing, stand-up summaries — those have different structures and audiences.
2. File layout
All artifacts live under reports/ at the repository root. Each day gets its own folder.
reports/
├── projects.md persistent catalog of general projects (one bullet per project, with short description)
└── YYYY-MM-DD/
├── LOG.md per-day scratchpad: raw user input, commit dumps, tasks grouped by project, hours per project
└── REPORT.md formal report, generated/regenerated from LOG.md
projects.mdis the single source of truth for project names across all reports. Reuse names verbatim so reports stay linkable.LOG.mdis the working scratchpad — append-only during a session. Paste raw input, record clarification answers, log per-project hours. It is the input to the formal report.REPORT.mdis the output. Regenerate fromLOG.mdat the end of the session. Never edit it by hand mid-session.
Create reports/, projects.md, and the per-day folder lazily on first invocation. Do not pre-seed projects.md with example data.
3. Conversation flow (strict order)
Follow this order every time. Do not skip steps even if inputs are obviously inferable — inference is forbidden (§5).
3.1 Language (once per session)
Ask: "¿En qué idioma quieres el reporte?" (default question in Spanish; switch to English if the user opened the conversation in English).
- Store the answer for the rest of the session. Do not re-ask for subsequent reports in the same session.
- If the user changes language mid-session, honor the new choice for new reports only — do not retroactively rewrite past ones unless asked.
- Scope of the language choice: governs
REPORT.mdonly.LOG.mdkeeps the raw input verbatim in its source language — never translate the LOG, never normalize its formatting. Translation rules (§7) apply only when emitting the report.
3.2 Date
Ask: "¿Para qué fecha es el reporte?" Accept YYYY-MM-DD, "today", "yesterday", or a relative reference. Convert to absolute YYYY-MM-DD and confirm before continuing.
One date per invocation. If the user wants to backfill several days, run the full flow (§3.1 onward) once per date — do not batch multiple days in a single session, do not interleave inputs for different dates. The reason: per-day artifacts (LOG.md, REPORT.md) and per-project hours must stay scoped to a single calendar day.
3.3 Project catalog review
- Read
reports/projects.md. If missing or empty, state explicitly: "El catálogo de proyectos está vacío. Vamos a construirlo conforme aparezcan en tus notas." - If non-empty, print the current list and ask: "¿Agregar, modificar o eliminar algún proyecto antes de empezar?"
- Apply changes to
projects.mdbefore moving on. Each entry is one line:- <Project Name> — <one-line description>.
3.4 Raw input collection
Ask the user to paste:
- Free-form comments about what they did (any order, any granularity).
- Optionally, commits as
<sha> <subject>\n\n<body>— full body, not just the subject line (only as input — see §6). - Optionally, issue/ticket excerpts — title and body, not titles alone.
Append everything verbatim to LOG.md under a ## Raw input section. Preserve the original formatting, language, indentation, and line breaks of what the user pasted. Do not reformat, translate, summarize, or de-duplicate at this stage.
3.5 Task extraction and project grouping
This is the preliminary analysis phase. Its only valid output is a list of candidate tasks surfaced as questions for the user. Specifically:
- Enumerate, don't author. Walk through the raw input and split it into discrete candidate tasks. Each candidate is a question to confirm, never a finished bullet.
- Never merge on your own. Merging two raw items into one task requires the user's explicit instruction ("junta esos dos"). Don't merge because items look related, share a verb, or touch the same file.
- Never split on your own. Splitting one raw item into multiple tasks also requires explicit instruction. When ambiguous (one task or two?), ask.
- Never invent. If raw input doesn't describe a task, do not add one to "round things out".
For each candidate task, ask one question:
- Project assignment: "¿A qué proyecto pertenece esta tarea?" Show the current catalog. If the user names a new project, add it to
projects.mdand confirm the short description.
Do not ask hours per task. Hours are tracked at the project level (§3.6).
Record confirmed tasks under a ## Tasks by project section in LOG.md, grouped by project, one bullet per task. Use the user's wording from the clarification, not your paraphrase.
3.6 Per-project hours
Once every task is grouped, walk through the projects with at least one task today. For each, ask:
- "¿Cuánto tiempo total le dedicaste a
<Project Name>hoy? (formato:2h 30min)"
Record under a ## Hours section in LOG.md.
Never estimate, round, or derive hours from the number/size of tasks. Ask.
3.7 Confirmation before close
Before generating REPORT.md, ask explicitly: "¿Algo más que agregar antes de cerrar el día?" Wait for an affirmative close — "listo", "ciérralo", "no, genera", "all done", or equivalent — before proceeding to §3.8.
- If the user adds more raw input, return to §3.4 and re-run §3.5–§3.6 on the new input only. Re-ask hours only for projects whose task list changed.
- Pause-and-resume is allowed. The flow does not need to finish in a single uninterrupted exchange. If the user steps away and returns later in the same session (or a future session for the same date), re-read
LOG.mdfor that date and resume from the last completed step. Never skip the §3.7 confirmation just because earlier steps already ran.
3.8 Report generation
Only after the explicit close confirmation from §3.7 and after every project with tasks today has a recorded hours figure, generate REPORT.md (§4).
3.9 Final review
Print the report path and a one-line summary of project totals + day total. Ask if the user wants edits before closing.
4. Report format
The report must be readable as raw text. No tables, no HTML, no emojis, no bold/italic decorators, no code fences, no horizontal rules, no nested bullets, no sub-headings. Only:
- Plain paragraphs.
- Numbered top-level sections:
1. Título,2. Título, etc. - Single-level bullets under each section with a
-prefix. - One
Tiempo del proyectoline per section; oneTiempo total del díaline at the very end.
Section header content. The header after each N. is the project name verbatim from projects.md. Nothing else on that line — no parenthetical decoration ((5h), (crítico), (Q2)), no trailing summary, no duplicated descriptor. Example: 1. Detector de Anomalías Online — not 1. Detector de Anomalías Online (4h 30min).
Task bullets describe the result, not the source artifact. Each bullet says what the work accomplished, in formal prose. Never reference commits, tickets, issues, PRs, or branches as the subject of the bullet — those are inputs to the report, not its content. The user can request explicit commit references via §6, in which case they land in a dedicated `Re