Catalog
github/desk-journal

github

desk-journal

Write, append, or read desk journal entries. The journal is persistent memory — what survives session boundaries. A good entry has: what was done, current state, next step.

global
New~598
v1.0Saved Jul 22, 2026

Desk Journal

Manage a desk's journal — the persistent memory that survives session boundaries.

When to use

  • End of session: Write what was done, current state, next step
  • Start of session: Read the journal to pick up where you left off
  • Mid-session checkpoint: Note significant progress or decisions
  • Desk wind-down: Write a final summary when a desk is being closed

How to write a journal entry

Append to desks/<desk-name>/journal.md. Each entry is a section:

## <date><short summary>
- **Worked on:** <what was done this session>
- **Current state:** <where things stand right now>
- **Next step:** <what the next session should pick up>

Guidelines

  • Be specific. "Worked on security scanning" is useless to the next session. "Scanned repos A, B, C for CWE-502; found 3 findings in A, 0 in B and C; findings triaged to bench" — that's a trail.
  • Include what didn't work. Dead ends are valuable — they prevent the next session from walking the same path.
  • Keep it short. The journal is a trail marker, not a diary. 3-5 lines per entry. If you need more, the important context should go on the bench as a separate artifact.
  • Always include next step. The next session starts from zero. Without a next step, it has to re-derive everything.

End-of-desk entry

When a desk is being wound down (not just a session ending, but the desk itself closing):

## <date> — Desk closed
- **Summary:** <what this desk accomplished overall>
- **Artifacts:** <what's on the bench from this desk>
- **Handoff:** <anything another desk or the operator needs to know>

Reading the journal

At session start, read the desk's journal to pick up context. The most recent entry is the most important — it has the current state and next step. Earlier entries provide history if needed.

Principles

  • The journal is a cairn — stones left so the next traveler finds the way. Every entry is a stone.
  • Honesty over completeness. "I got stuck on X and don't know why" is more useful than silence.
  • The journal is for the next session, not for the current one. Write for someone who knows nothing about what you just did.
Files1
1 files · 1.0 KB

Select a file to preview

Overall Score

79/100

Grade

B

Good

Safety

90

Quality

78

Clarity

82

Completeness

68

Summary

This skill teaches agents how to write, append, and read persistent desk journal entries that survive session boundaries. It provides structured entry templates (session entries and desk closure entries) and emphasizes specificity, brevity, and forward-looking documentation to create an effective audit trail for multi-session workflows.

Detected Capabilities

file appendfile readfile writemarkdown formatting

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

session handoffdesk journal readdesk journal writeend of sessioncontext persistencemulti-session workflowdesk closureprogress checkpointwork trail

Use Cases

  • End-of-session context preservation to hand off work to the next session
  • Start-of-session context recovery to understand where previous work left off
  • Mid-session checkpointing to record significant progress or decisions
  • Desk wind-down documentation when closing a work context
  • Dead-end tracking to prevent duplicate failed investigation paths across sessions

Quality Notes

  • Excellent metaphorical framing ('cairn', 'trail marker') makes the purpose intuitive and memorable
  • Clear structural templates with concrete examples reduce ambiguity
  • Explicit guidelines on specificity, honesty, and brevity prevent low-quality entries
  • Well-defined use cases cover the full lifecycle (session start, mid-session, session end, desk closure)
  • Principles section articulates the philosophy behind the skill, helping agents understand why the rules matter
  • Strong emphasis on 'next step' and forward-looking context ensures continuity across sessions
  • Balanced guidance between brevity (3-5 lines) and completeness (don't omit dead ends)
  • No error handling guidance provided (e.g., what if journal file doesn't exist, permission denied, or is corrupted)
  • No guidance on file location discovery or desk-name resolution
  • No examples of actual journal entries with dates and concrete content, only templates
Model: claude-haiku-4-5-20251001Analyzed: Jul 22, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Use github/desk-journal in your dev environment

Command Palette

Search for a command to run...