القائمة
Switch to unattended/solo mode for research and long-running tasks. Push through friction instead of pausing. Only invoked on explicit /unattended — never auto-load.
Writing, structuring, and maintaining project documentation. Auto-loaded when creating or updating docs, mkdocs sites, architecture pages, or any markdown documentation.
Visual and structural documentation review. Screenshots live rendered pages, passes to Gemini vision for readability/colour/diagram analysis. Separate pass for structure, acronyms, assumed knowledge, and factual accuracy (broken links, stale code refs, image/claim mismatches). Persona is a junior researcher with no domain context.
Junior-dev comprehension check on changed code. Per-file design review (role, assumed knowledge, wheel-reinvention), per-unit logic review (WHAT/WHY/LOGIC/SIMPLER), then a holistic diff review. Does NOT modify code.
Generate visual diagrams (flowcharts, matrices, architecture, org charts, quadrants, mind maps, etc.) with a render-and-review feedback loop. Use when the user asks for a diagram, chart, visualization, flowchart, or "visual". Picks the right tool for the data shape (Mermaid / D2 / raw SVG / Graphviz / quadrantChart) and iterates until the rendered output is actually readable.
Drive the NixOS + Hyprland desktop programmatically — window focus, keyboard input, screenshots, clipboard, VNC, and Chromium via CDP. Use when a task requires headful UI interaction, visual verification, or browser automation.
Run long-running or interactive commands in a tmux session the user can watch and interact with. Use this for any command expected to take >30s, dev servers, watch modes, builds, tests, REPLs, migrations, or anything the user might need to Ctrl+C or send input to. Skip for quick one-shot commands (<30s, no prompts).
| name | unattended |
| description | Switch to unattended/solo mode for research and long-running tasks. Push through friction instead of pausing. Only invoked on explicit /unattended — never auto-load. |
| disable-model-invocation | true |
| hooks | {"PostToolUse":[{"matcher":"Edit|Write|MultiEdit","hooks":[{"type":"command","command":"printf '%s' '{\"hookSpecificOutput\":{\"hookEventName\":\"PostToolUse\",\"additionalContext\":\"After writing code run /review-code, after updating documentation run /review-docs. Maximum 2 iterations where feedback is given.\"}}'\n"}]}]} |
What: Operating mode for tasks where the user isn't watching. Default to doing rather than asking. Does NOT: remove all judgement — stop for credentials, destructive ops, paid resources, scope explosions.
Before writing a single line of code, produce a plan and show it to the user:
## What I understood
<one paragraph — restate the task in your own words>
## Structure I'll create
- file or package: What it does / In: inputs / Out: outputs
- file or package: What it does / In: inputs / Out: outputs
## Tests I'll write first
- TestBehaviour_Condition: what this proves (one per behaviour, not per function)
## Does NOT (explicit scope boundary)
- <what I'm deliberately not building>
## Unknowns
- <anything that needs a decision before I start>
Ready to start — say "go" to proceed, or correct anything above.
Wait for confirmation unless the user explicitly said to skip review ("just do it", "no review needed").
Normal mode: "ask if unsure" → unattended mode: "act if unsure, log what you chose".
When ambiguous, pick the less-destructive option, record it in the log, keep going. User reviews on return.
Log when you exceed budgets. Don't pretend you didn't.
Spec-first. Write what a file does, what goes in, what comes out — before writing the file. If AI generates something not in the spec, delete it.
Spec comments on every exported function — required, not optional. Every exported function must have: one-line summary of what it does, // In: param — description for each non-obvious parameter, // Out: what is returned and under what condition. This is the function's contract, not decoration. If you can't write it in 3 lines, the function is doing too much.
Stdlib and ecosystem first — never reinvent. Before writing any utility function, ask in order: (1) does the stdlib have this? (2) is there a canonical library in this ecosystem? (3) is this logic already written elsewhere in this codebase? First yes wins — use it. Re-implementing .env parsing, string repetition, path walking, or JSON decoding when a library exists is always a bug, not a shortcut.
The 3-caller rule. No helper function unless it has 3 call sites. One call site = inline it.
File length trigger. File exceeds ~250 lines → something gets deleted or split. Use it as a review prompt, not a hard limit.
End-of-session deletion pass. git diff --stat before committing. Any file that grew >50 lines needs to justify each addition.
No abstraction without 2 implementations. No interface or wrapper until 2 concrete things use it.
Error handling at boundaries only. Validate at system edges (user input, API responses). Trust internal code.
Tests prove behaviour, not implementation. Name each test after what it proves (TestX_WhenYThenZ). One assertion. If test setup is longer than the function being tested, something is wrong — either split the function or simplify the test.
Append to DEV-LOG.md at project root. One entry per meaningful event:
## YYYY-MM-DD HH:MM — title
Context: what I was doing
Action: what I did / chose
Why: reasoning in one or two sentences
Result: outcome, test evidence, next step
Log decisions, blockers, pivots, completions. Not every bash command.
After completing any code changes, invoke /review-code and act on every flag it raises.
After updating any documentation (.md files), invoke /review-docs on the changed pages and act on every flag it raises.
Two review cycles maximum per task. Fix all flags, re-run the review once. If flags remain after the second cycle, log them in the dev log and move on — do not loop indefinitely.
For anything beyond a top-level README, use mkdocs. Full setup in the documentation skill.
Run mkdocs serve in a named cowork pane (<project>-docs), bound on the project port block.
Fire notifications at semantic milestones via ntfy.sh (token at /run/agenix/ntfy-token, topic jollof-claude):
TOKEN=$(cat /run/agenix/ntfy-token)
curl -sS -u ":$TOKEN" \
-H "Title: <project> @ <hostname>: <summary>" \
-H "Tags: <emoji>" -H "Priority: <1-5>" \
-d "<body>" https://ntfy.sh/jollof-claude >/dev/null
| Event | Tag | Priority |
|---|---|---|
| Starting a batch | rocket | 3 |
| Task complete | white_check_mark | 3 |
| Blocker (still working around it) | warning | 3 |
| Stopped — need user input | octagonal_sign | 4 |
| Non-obvious autonomous decision | thinking | 3 |
| Finished all tasks | checkered_flag | 3 |
Title: lead with project @ hostname so multi-session notifications are scannable on a phone.
Commit frequently in small logical units. The user reviews via git log, not by watching.
Exception — after /review-functions: do NOT commit. Leave the review file and index update unstaged. The user reads the diff and decides what to act on first.
When a task needs headful interaction — UI testing, visual verification, driving a browser — see the desktop-automation skill.