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:

bash

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:

bash

mkdir -p Notes/WorkingJournal/attachments
cp Output/[subfolder]/figure.png Notes/WorkingJournal/attachments/YYYY-MM-DD-description.png

In markdown:

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:

yaml

---
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:

code

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