writing-work-logslisted

# writing-work-logs This skill turns the current conversation into a durable `docs/logs/` entry — a Markdown file that records what shipped, what went smoothly, what diverged (and why), and concrete lessons for future tasks in this project. Scope (which tasks get a log at all) lives in [`docs/logs/README.md`](../../../docs/logs/README.md) — don't re-decide it here. The log is most valuable when written _during_ the same session as the task, because that is when real-time context is available: spoke verdicts, exact test counts, coverage numbers, lint/typecheck outcomes, and the specific sequence of events that caused a divergence. After the session closes, that context must be reconstructed from memory or git history — both are less precise. ## Step 1 — Determine task identity Read the conversation context and extract: - **Task name and namespace**: the module, feature, or task just completed (e.g. `core/config`, `aws/ssocredentials`, or a freeform slug like `writing-work-logs-skill` for non-submodule work) - **Date**: today's date in `YYYY-MM-DD` format — do not guess. Read it from the `currentDate` field in the session's system-reminder context; if that is unavailable, run `date +%Y-%m-%d` - **Target filename**: - Submodule task: `YYYY-MM-DD-<ns>-<module>.md` (e.g. `2026-06-30-core-config.md`) - General task: `YYYY-MM-DD-<slug>.md` (e.g. `2026-06-30-writing-work-logs-skill.md`) - **Target path**: `docs/logs/<filename>` If the identity is genuinely