agentleFS
Sign inStart free
Faaz17Faaz17/Agents-and-Skills/skills/project-ops/log-session/SKILL.md

log-session

Skill1 starsChanged 2 months agoMITView on GitHub

Update PROJECT_NOTES.md and BUILD_LOG.md at the end of a work session, covering the phase tracker, decisions made, gotchas hit, test results, and the next action. Use when the user says "log this", "update the notes", or wraps up a chunk of work.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 2 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Keep .claude/PROJECT_NOTES.md an accurate living snapshot and docs/BUILD_LOG.md an honest history.

    line 8
  2. Very specific:

    If a rule or event detail was confirmed this session, treat it as significant and follow the rule-change protocol in …

    line 32
  3. Very specific:

    If a ring test happened, make sure docs/BUILD_LOG.md records the actual pass and fail numbers rather than a summary.

    line 34
  4. Very specific:

    If git has uncommitted changes, offer to commit using the project format: type: lowercase present-tense description, with no Co-Authored-By …

    line 36
  5. Distinctive:

    Never delete history from the notes.

    line 40
  6. Very specific:

    Never round up a test rung.

    line 41
  7. Very specific:

    Keep PROJECT_NOTES.md skimmable, so a fresh session can orient in under a minute.

    line 42
  8. Very specific:

    Don't log to the Obsidian vault from this skill.

    line 43
  9. Distinctive:

    Write plainly: no em dashes, no emoji in headings, no title case.

    line 44

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/log-session, end-of-session notes update

Keep .claude/PROJECT_NOTES.md an accurate living snapshot and docs/BUILD_LOG.md an honest history. A fresh session reads both first, so write for that reader.

Steps

  1. Review the conversation: what got built, what was decided, what broke and how it was fixed, what was tested and at which rung.

  2. Append to docs/BUILD_LOG.md, newest at the top, under the format header:

    ## YYYY-MM-DD: short title

**Did:** what actually changed
**Tested:** which rung (compiles / bench / ring / match), and the result
**Learned:** anything that changes a future decision
**Next:** the immediate next action
  3. Update .claude/PROJECT_NOTES.md:
    • Recent activity log: add today's entry.
    • Open questions: close anything that got answered, and add anything new that emerged.
    • Next actions: rewrite so the top item is the literal next action.
    • What we know versus what we're assuming: if something moved from assumed to confirmed, move it and note the date.
    • Convert relative dates ("today", "last week") to absolute ones.
  4. If a rule or event detail was confirmed this session, treat it as significant and follow the rule-change protocol in .claude/rules/competition_rules.md. Update docs/RULES.md, docs/COMPETITION.md, AGENTS.md, and re-check every design decision made under the old assumption.
  5. If a ring test happened, make sure docs/BUILD_LOG.md records the actual pass and fail numbers rather than a summary. "17/20 stops" is useful; "edge sensing mostly works" is not.
  6. If git has uncommitted changes, offer to commit using the project format: type: lowercase present-tense description, with no Co-Authored-By trailers.

Rules

  • Never delete history from the notes. Check items off or move them, but don't erase them.
  • Never round up a test rung. If it was bench-tested, write bench. See .claude/rules/workflow.md.
  • Keep PROJECT_NOTES.md skimmable, so a fresh session can orient in under a minute. Detail goes in BUILD_LOG.md.
  • Don't log to the Obsidian vault from this skill. That's /obsidian-log, and only when the user asks. See docs/VAULT_SYNC.md for what belongs where.
  • Write plainly: no em dashes, no emoji in headings, no title case.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free