micro-projectlisted

# /micro-project **Input (optional):** a note from the user in `$ARGUMENTS` about what kind of project they want. ## Steps 1. Read `state.json`. The current day, or the most recently completed day if the current day isn't done yet, must have `status: "done"` — otherwise tell the user clearly to finish and run `/done` first, and stop. 2. Design a small, self-contained project applying that day's topic hands-on. It may deliberately pull in concepts/code from earlier **completed** days where it makes sense — if it does, say explicitly which days it's drawing on. Factor in `$ARGUMENTS` if the user specified a kind of project. 3. Create `day_<D>/micro_projects/<slug>/` (slug named for what the project is; if `/micro-project` is run again for the same day, this is a **new** subfolder/slug, not an overwrite): - `brief.md` — what to build and why, and which earlier days it draws on (if any). - `code/` — stubs in `months.<N>.language` (signature/typed-signature + doc comment, no implementation). - `code/tests/` (or the language's equivalent) — tests where reasonably testable. 4. Add this micro-project to `state.json` under that day's `micro_projects` array: `{slug, name, status: "in_progress", created: <ISO date>}`. 5. **Once tests pass** (when the user later works on it and asks you to check): run the test command matching `months.<N>.language`/`test_command`, the same way `/done` does. **Same no-shortcuts rule as `/done`** — refuse to mark it done on request without