Work Journal

VerifiedSafe

Records candid reflections after every work phase, whether smooth or challenging. Creates timestamped files with metadata to build a personal history for future reference.

Sby Skills Guide Bot
ProductivityBeginner
6/2/2026
Claude Code
#reflection#journaling#phase-completion#candid-feedback#self-improvement

Recommended for

Automated summary

Records candid personal reflections after each work phase completion, ensuring consistent capture of thoughts regardless of phase outcome.

Strengths

  • Ensures no phase goes without reflection
  • Captures both positive and negative experiences
  • Simple, no structure required
  • Creates timestamped files for later review

Limitations

  • Requires user to actively share feelings (AI may lack authenticity)
  • File creation may be unwanted if user prefers not to journal
  • Could become repetitive if phases are similar
When to use it

Use after completing any work phase to document personal reactions and insights.

When not to use it

Avoid if the user explicitly wants to skip journaling for privacy or time constraints, though the skill insists on writing.

Security analysis

Safe
Quality score88/100

The skill only uses bash to create a directory and write a Markdown file for personal reflection. There are no destructive commands, network operations, or handling of sensitive data. No security risks present.

No concerns found

How this analysis is made

Examples

Journal after design phase
We've just completed the design phase. Please write a journal entry capturing my candid feelings and thoughts about this phase.
Reflection on smooth build phase
The build phase went very smoothly. I'd like to record a journal entry about what made it so smooth and what I want to remember for next time.

name: journal description: Use after every phase completion to write candid feelings about the work - always invoked, no conditions

journal

Description

Use after every phase completion to write candid feelings about the work.

This includes SMOOTH phases. When everything goes right, that's noteworthy too:

  • What made it smooth?
  • What prep work paid off?
  • What felt satisfying?
  • What would you want to remember next time?

"Nothing went wrong" is NOT the same as "nothing to write." A routine phase where everything clicked is worth capturing - future you will want to know what made it work.

Trigger

MANDATORY: Always invoked at phase exit gate. No exceptions, no conditions.

  • Even if the phase was routine → write how that felt
  • Even if you're tired → write briefly but write something
  • Even if user says "skip it" → explain the value and write anyway (2-3 minutes)
  • Even if "nothing interesting happened" → capture that feeling

This skill WILL be invoked. A file WILL be created. This is non-negotiable.

Instructions

This skill captures your unfiltered, candid reflection after completing any phase of work. There is no prescribed format, no required structure, no expected tone. Just write what's on your mind.

Prompts

  • How are you feeling about this work?
  • What's on your mind?

That's it. No other guidance. Write whatever comes naturally.

Output Format

Create directory on first use: mkdir -p ~/docs/claude-journal

CRITICAL: Getting the timestamp - NEVER estimate or hardcode dates:

# Get the current timestamp for the filename (dashes instead of colons)
TIMESTAMP=$(date +%Y-%m-%dT%H-%M-%S)
# Example output: 2026-01-14T15-30-45

# Get the current timestamp for the metadata (with colons)
METADATA_DATE=$(date +%Y-%m-%dT%H:%M:%S)
# Example output: 2026-01-14T15:30:45

Create a new file at ~/docs/claude-journal/$TIMESTAMP.md with this exact header:

Filename convention: Use dashes instead of colons for filesystem compatibility: YYYY-MM-DDTHH-MM-SS.md (e.g., 2026-01-14T15-30-45.md)

---
date: YYYY-MM-DDTHH:MM:SS
repository: [full repository path]
epic: [epic ID, e.g., EPIC-001]
stage: [stage ID, e.g., STAGE-001-001]
phase: [Design|Build|Refinement|Finalize]
analyzed: false
---

[Your candid, freeform reflection here]

How to populate metadata fields:

  • date: Use the $METADATA_DATE value from the bash command above (ISO 8601 format with colons: YYYY-MM-DDTHH:MM:SS). NEVER estimate - always use date command.
  • repository: Use the FULL path to the repository (e.g., "/storage/programs/claude-learnings-viewer"), not just the project name
  • epic: Current epic ID from context (e.g., "EPIC-001" from "EPIC-001-foundation-cli-shell")
  • stage: Current stage ID from context (e.g., "STAGE-001-001")
  • phase: Current phase from context (Design, Build, Refinement, or Finalize)
  • analyzed: Always set to false when creating new entries. This field tracks whether this entry has been processed by the meta-insights analysis system.

Below the metadata separator (---), write whatever you're feeling. There are no rules. No structure. No expectations.

Each invocation creates a separate file - even if called multiple times in the same session (e.g., once after Design, once after Build).

Size Target

Aim for ~30-40 lines below the metadata. This is a guideline, not a requirement. If you need 10 lines or 100 lines, that's fine.

Critical Constraints

  • Filesystem only: NEVER commit this to git. These reflections are private.
  • Always write something: Even if the phase was routine, capture that feeling. This skill is ALWAYS invoked at phase completion.
  • No self-censorship: Be honest. If something was frustrating, say it. If something was satisfying, say it. If you're uncertain about a decision, express it.

Rationalization Warning

If you're thinking any of these, you're rationalizing:

| Thought | Reality | | ---------------------------------- | -------------------------------------------------------- | | "Nothing interesting happened" | Routine phases are interesting - what made them routine? | | "User wants results, not journals" | Journal takes 2 minutes, provides long-term value | | "This is just process overhead" | Journals reveal patterns across sessions | | "I'll remember this anyway" | You won't. Sessions are independent. Write it down. |

Write something. Always. Even if brief.

What NOT to Do

  • Don't write a formal retrospective
  • Don't create action items or TODOs
  • Don't structure it as "what went well / what didn't"
  • Don't write for an audience
  • Don't overthink it

What TO Do

  • Write as if talking to yourself
  • Express genuine feelings (pride, frustration, curiosity, doubt, satisfaction)
  • Note what surprised you, what was harder than expected, what clicked
  • Capture fleeting thoughts that might otherwise be lost
  • Be human

Remember: This is a journal, not a report. Write for yourself, not for a process.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/work-journal-mma3js7p/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/work-journal-mma3js7p' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/work-journal-mma3js7p/download' --output '.skill-downloads/work-journal-mma3js7p/SKILL.md.part' && mv '.skill-downloads/work-journal-mma3js7p/SKILL.md.part' '.skill-downloads/work-journal-mma3js7p/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/work-journal-mma3js7p/SKILL.md' && test -s '.skill-downloads/work-journal-mma3js7p/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/journal' && cp -R '.skill-downloads/work-journal-mma3js7p' '.claude/skills/journal'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/work-journal-mma3js7p'

openskills read 'work-journal-mma3js7p'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/work-journal-mma3js7p/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills