agentsclimarketplace

Log session

Skill gtrabanco/agentic-workflow/skills/log-session

Append a structured entry to the project's session log (`docs/LOGS.md`): what was done this session, files touched, decisions taken, and the next step — so the next session (or another person) can pick up the thread without re-reading git history. Run it before `/clear`, before closing Claude Code, or at any natural stopping point. On Claude Code and want hand-tuned per-skill model/effort tiers? Install the `#claude` branch instead (`npx skills add gtrabanco/agentic-workflow#claude`) — see the README. This branch is model-agnostic: the skill inherits whatever model and effort your agent session is already using. Triggers: "log this session", "log-session", "write a session log", "journal what we did", "record this session before I clear", "save the session summary".From its SKILL.md

Install
npx -y skills add gtrabanco/agentic-workflow --skill log-session

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 6 commands, including `git log` and 5 more.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

7.5 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

Log Session

Capture the why and the what-next of a working session — the context that git history alone never records. A commit says what changed; a session log says what you were trying to do, what you decided, and where to resume.

Deliberately cheap (sonnet/medium): this is structured summarization, not judgment. It must never reach for an expensive model.

Turn contract — verify before ending the turn

✓ The entry was APPENDED to docs/LOGS.md (file edited, not just drafted) with accurate git facts
✓ No past entry was edited
✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English PRs/issues/commits/SPECs unless one of the first two says otherwise
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

About to end the turn with any box unchecked? The turn is NOT done — complete the missing box first (weak models drop end-of-document duties; this list is first on purpose).

When to use

  • Before /clear (or your agent's context-reset equivalent) — you're about to wipe context; capture it first.
  • Before closing your agent for the day.
  • At a natural stopping point — a feature paused mid-way, a thread you want to be able to resume cold.
  • After a long session with several decisions worth remembering.

This is the manual, rich counterpart to the lightweight auto-logging hooks the template/ ships (see template/.claude/). The hooks capture the mechanical facts for free on every exit; this skill writes the thoughtful entry when you want one.

Step 0 — Discover the project (always first)

Per the agent guide's Workflow conventions + documentation map, locate the session log. Default path: docs/LOGS.md. If the documentation map names a different location, use that. If no log file exists yet, create it from the shape in template/docs/LOGS.md (a short header + the entry format below) and say so.

If a session-start marker exists (.claude/.session-*.start, written by the template's SessionStart hook), read it to bound the session precisely — it holds the HEAD sha and start time at session open.

Process

  1. Establish the session boundary.

    • If a marker is present, the session spans marker_sha..HEAD plus any uncommitted work.
    • Otherwise, use your own conversation context as the source of truth for what happened this session, and corroborate with git log of the recent commits and git status / git diff --stat for uncommitted changes.
  2. Gather the mechanical facts (cheaply, with git):

    • branch (git branch --show-current),
    • commits this session (git log --oneline <since>..HEAD),
    • files touched (git diff --stat <since>..HEAD + uncommitted).
  3. Write the narrative — the part only you can add:

    • Summary: 1–3 sentences on what this session set out to do and what actually got done.
    • Decisions: the non-obvious choices made and why (the rationale that would otherwise be lost). Link related docs/issues.
    • Next: the concrete next step(s) — the command to run, the unfinished thread, the open question. Write it so a cold reader knows exactly where to resume.
  4. Append the entry to docs/LOGS.md, newest at the bottom (append-only, chronological). Use this format so the auto-hook entries and these stay compatible:

    ## <ISO-8601 timestamp> — <branch> — manual
    - **Commits:** <n> (`<short-sha>…<short-sha>`)
    - **Files:** <comma-separated paths, or a count if many>
    - **Summary:** <what this session did>
    - **Decisions:** <key choices + why; omit the line if none>
    - **Next:** <the concrete next step>
    

    If the user passed a note as an argument, prepend it to the Summary.

  5. Commit policy. docs/LOGS.md is documentation — keep it coherent, but do not open a PR just for a log entry. If you're mid-feature on a branch, the entry rides along with the next commit. If the working tree is otherwise clean and the user wants it persisted, ask before committing a standalone docs(log): session <date> commit. Never push without the project's push convention.

Guardrails

  • Never use an expensive model for this. It's summarization; sonnet is the ceiling, and the hooks do the free mechanical version.
  • Don't invent facts. Decisions and next steps come from the actual session (your context + git), not plausible-sounding filler. If a section has nothing real, omit its line rather than padding.
  • Append, never rewrite. Past entries are a historical record — don't edit or "tidy" them. Same reasoning as not rewriting a delivered feature's planning artifacts.
  • One file, append-only. Don't fan session logs across files.

Portability (agents other than Claude Code)

The workflow is the contract; Claude Code features are conveniences. On an agent that lacks one, apply the fallback — never skip the step the feature enables:

  • No Claude Code hooks — the template's auto-logging hooks (SessionStart marker, SessionEnd entry) don't run on other agents, so there is no marker file and no free mechanical entry: this skill is the only journal writer. Run it before ending every session, and bound the session with git alone (Process step 1's no-marker path).
  • No /clear — read it as your agent's context-reset / new-conversation equivalent, in the triggers and in the closing block alike.
  • No per-skill model:/effort: — the intent stands: use a cheap model for this. It's summarization, never judgment.

Relationship to other skills

  • Complements the template/'s SessionEnd hook (free, mechanical, automatic on /clear and exit) and the opt-in SessionStart restore hook (re-injects the last entry to resume context). This skill is the rich, manual entry.
  • Pairs with execute-phase's per-feature progress.md: that tracks progress within a feature; the session log is cross-cutting — whatever you touched this session, across features/fixes.
  • Not part of the PR gate — it's a working-memory aid, not a merge artifact.

Done when

  • A new entry is appended to docs/LOGS.md with at least Summary and Next.

  • The mechanical facts (branch, commits, files) are accurate to git.

  • The closing → Next: block is printed:

    → Next: /clear (or your agent's context reset) is now safe — the session is captured
      · resume later → the command named in the entry's **Next** line
    

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in ~1.6k tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

  • Use third-person for skill descriptionsin 54 of 1951, across 35 files
  • Start descriptions with Use whenin 43 of 1951, across 29 files
  • Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
  • Use active voicein 40 of 1951, across 36 files
  • Map file responsibilities before defining tasksin 36 of 1951, across 29 files
  • Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
  • Ask one question at a timein 35 of 1951
  • Offer execution options after saving the planin 33 of 1951, across 24 files
  • Include complete code in every stepin 33 of 1951, across 27 files
  • Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
  • Announce the skill usage at the startin 30 of 1951
  • Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

  • Print the closing Next block as last output
  • Locate the session log file at docs/LOGS.md
  • Create the log file if it does not exist
  • Use git to gather branch commits and touched files
  • Write a summary of session goals and actions
  • Define concrete next steps for resuming work

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.