work-summary

FuZhiyu's avatarfrom FuZhiyu

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.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 5, 2025

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.
namework-summary
descriptionCreate 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:

  1. Inform user: "I see uncommitted changes. Should I run the code-quality-reviewer agent and commit the code first?"
  2. Wait for user confirmation
  3. If confirmed, use Task tool with subagent_type="code-quality-reviewer" then assist with git commit
  4. 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:

![Descriptive caption](./attachments/YYYY-MM-DD-description.png)

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

  1. Tell user the file path
  2. List what was documented
  3. Report any issues found by report-checker
  4. Ask: "Would you like me to add any specific information?"
  5. Do NOT suggest interpretations or next steps unless asked