assisted-log
Skill14 starsChanged 4 days agoMITView on GitHub
Writes a concise summary of this session's work into today's daily journal under ### Assisted. Use only when the user asks to log the session, summarize it for the daily note, or invokes /assisted-log. Never offer it.
In this repository12 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- cc-release-reviewSkill
- verifySkill
- code-theorySkill
- code-walkthroughSkill
- downloads-triageSkill
- editorSkill
- release-gateSkill
- release-shipSkill
- release-sweepSkill
- rexSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Run only when asked. Never offer it at a stopping point ([[feedback-colog-work-to-daily-note]]).
- Very specific: line 18
Get the note: Run obsidian vault=notes periodic-notes:create date=YYYY-MM-DD and use the path it prints.
- Distinctive: line 22
Add a count only when it is the point ("moved 48").
- Distinctive: line 30
Place it: Read the note.
- Distinctive: line 32
If the section already has a paragraph for this period, rewrite it to cover the earlier and new work together within the same 25–60 words.
- Very specific: line 33
Never touch the user's lines, ## Sky, ## Review, or ## Index.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Assisted log
Summarize what this session did with Claude into today's daily journal, as one paragraph under ### Assisted. The user writes their own log under ## Notes. This section is the record of the assisted work beside it, in the same terse register.
Run only when asked. Never offer it at a stopping point ([[feedback-colog-work-to-daily-note]]).
Steps
- Check the date and time. Run
date '+%F %H'. The note isjournals/YYYY-MM-DD.md. The period is the argument if given; otherwise it is when most of the session's work happened, not when the log runs—before 12 ismorning, 12–17 isafternoon, and after that isevening. A morning session logged at 12:05 is stillmorning. The journal day runs until Mark sleeps and wakes, not until midnight: work after midnight before he has slept goes in the previous day's note asevening. If it is the small hours and you can't tell, ask. - Get the note. Run
obsidian vault=notes periodic-notes:create date=YYYY-MM-DDand use the path it prints. Never create a journal any other way. If the command printserror:or Obsidian is not running, stop and report it. Draft the paragraph from this session's actual record: tool results, commits, PRs, files written. One paragraph starting with
<period>:, 25–60 words however long the session. Write one short clause per outcome, joined by semicolons:- Name what shipped or changed, with its identifier: release, issue or PR number, short SHA, note title (plain, no wikilinks or paths).
- Add a count only when it is the point ("moved 48").
Leave out how it was done, how it was checked, causes, and anything the identifier already says. If an outcome needs a sentence to explain, it is too much detail; drop to its name. Record only what was done, never what is left or next. No headings, bullets, checkboxes, or commentary on the work. American spelling, unspaced em dashes; label a guess as one.
morning: dusk v5.3.0 released—JSON night on every band (#136), Meeus claim corrected (#138); Sky skill simplified (`a752675`); Reminders reachable via `osascript`; Writing ideas (48) and Reading list (23) moved to Reminders.Place it. Read the note.
### Assistedgoes at the end of## Notes, after the user's own lines, before the next##heading. Create it there if it is missing.- If the section already has a paragraph for this period, rewrite it to cover the earlier and new work together within the same 25–60 words; do not append to it. Otherwise add the new paragraph after the existing ones, separated by a blank line.
- Never touch the user's lines,
## Sky,## Review, or## Index.
Edit the note in place. Never rewrite the whole file.
- Report the paragraph as written and the note's path. Say nothing else.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

