How do I install the Log Session skill?

Run npx skillmds@latest add faaz17/log-session in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Log Session safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Log Session?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Log Session free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Log Session?

Faaz17 (@faaz17) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Log Session by faaz17 — Agent Skill

Name: Log Session
Author: Faaz17

Log Session

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.

Faaz17 fa01458 2.5 KB Updated Sep 17, 2026

File contents

/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

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

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

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

---name: log-sessiondescription: 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.---# /log-session, end-of-session notes updateKeep `.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.## Steps1. 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.

Frequently asked questions