work-summary
Create factual working journal entries in Notes/WorkingJournal/ after completing analysis work. Use when user asks to "summarize work", "document results", or "create working journal entry". Ensures code is committed, copies figures to attachments, and creates objective summaries with citations.
When & Why to Use This Skill
This Claude skill automates the generation of factual, objective working journal entries to document technical analysis. It ensures data integrity by verifying Git commits, organizing visual figures, and creating structured reports with direct citations to code and output files, facilitating reproducible and professional project documentation.
Use Cases
- Documenting data analysis results: Automatically create a structured journal entry that links specific findings to the underlying code and output data for better traceability.
- Maintaining a research audit trail: Generate objective summaries of experimental steps, including Git commit hashes and methodology, to ensure research reproducibility.
- Standardizing project handovers: Create consistent, factual reports of completed work that allow team members to understand the objective, data, and results without subjective interpretation.
- Organizing technical figures: Automatically move and link analysis plots and charts into a centralized working journal with descriptive captions and source references.
| name | work-summary |
|---|---|
| description | Create factual working journal entries in Notes/WorkingJournal/ after completing analysis work. Use when user asks to "summarize work", "document results", or "create working journal entry". Ensures code is committed, copies figures to attachments, and creates objective summaries with citations. |
Work Summary Skill
Create factual working journal entries that document completed analysis work without interpretation or recommendations.
When to Use
Activate when user requests:
- "Summarize the work"
- "Document the results"
- "Create a working journal entry"
- "Write up the analysis"
Instructions
Step 1: Verify Git Commit
Check if code has been committed:
git status
If uncommitted changes exist:
- Inform user: "I see uncommitted changes. Should I run the code-quality-reviewer agent and commit the code first?"
- Wait for user confirmation
- If confirmed, use Task tool with
subagent_type="code-quality-reviewer"then assist with git commit - Get commit info:
git log -1 --pretty=format:"%H%n%s"
If clean: Get latest commit: git log -1 --pretty=format:"%H%n%s"
Step 2: Confirm Understanding
If you have context from recent work:
- Summarize your understanding of objective, code location, output location
- Use AskUserQuestion tool to confirm with user
If you don't have context:
- Ask user for: objective, code location, output location
Then read code files, output files, and documentation to gather information.
Step 3: Handle Figures
If figures exist in output folder:
mkdir -p Notes/WorkingJournal/attachments
cp Output/[subfolder]/figure.png Notes/WorkingJournal/attachments/YYYY-MM-DD-description.png
In markdown:

Source: [Original](../../Output/[subfolder]/figure.png)
Step 4: Create Working Journal Entry
Filename: Notes/WorkingJournal/YYYY-MM-DD-[Author]-[Description].md
Front Matter:
---
author: "[[Author]]"
date: YYYY-MM-DD
project: "[[IntermediaryDemand]]"
git_commit: [full hash if available]
git_message: "[message if available]"
permalink: working-journal/YYYY-MM-DD-author-description
---
Step 5: Write Summary
Structure can be flexible, but typically include:
- Objective section
- Summary of what was done
- Data description
- Methodology description
- Results with tables/figures
- Technical implementation details (code and outputs)
Use relative paths from Notes/WorkingJournal/:
- Code:
../../Code/ - Output:
../../Output/ - Data:
../../Data/
Critical Rules - MUST FOLLOW
1. Be Factual and Objective
✓ DO:
- State what was done and what was found
- Report numerical results precisely
- Describe methods used
- Link every claim to source (code, output, documentation)
✗ DO NOT:
- Interpret economic meaning without user request
- Speculate on causes or implications
- Make recommendations or suggest next steps
- Use subjective assessments ("excellent", "poor", "successful")
2. Examples
Good (Factual):
- "Processed 4.7M holdings from 11,857 submissions"
- "Difference of -30% (-$243B)"
- "Front-end tenors within 7% of benchmark"
- "Classification success rate: 70% (3,988 of 5,699)"
Bad (Speculative/Interpretive):
- "This suggests the classification is insufficient"
- "The results indicate strong performance"
- "This likely means we should use BKMS data"
- "The excellent match validates our approach"
3. Cite Everything
Every claim must link to supporting evidence:
[descriptive text](../../path/to/file)- Code files for methodology
- Output files for results
- Documentation for data sources
4. Figures
- Copy to attachments/ with descriptive filename
- Cite original source location
- Use descriptive captions
Step 6: Verify Report Quality
After creating the report, use the report-checker agent to verify quality:
Use Task tool with subagent_type="report-checker"
Pass: report path, code location, output location, objective
The agent will check:
- All claims are cited and accurate
- No speculation or unsupported interpretation
- Numbers match source files
- No subjective language
If issues found, revise the report before finalizing.
After Creating
- Tell user the file path
- List what was documented
- Report any issues found by report-checker
- Ask: "Would you like me to add any specific information?"
- Do NOT suggest interpretations or next steps unless asked