
Work Summary
- 15 installs
- 8 repo stars
- Updated December 5, 2025
- fuzhiyu/researchprojecttemplate
Create factual working-journal entries after analysis work, ensuring code is committed, figures copied, and summaries cited.
About
Generates objective working-journal entries documenting completed analysis without interpretation, verifying git commits and copying figures. A developer uses it when asked to summarize or document completed analysis work.
- Verifies git commit before writing the summary
- Produces factual, cited entries with copied figures
Work Summary by the numbers
- 15 all-time installs (skills.sh)
- Ranked #1,075 of 1,879 Documentation skills by installs in the Skillselion catalog
- Data as of Jul 24, 2026 (Skillselion catalog sync)
npx skills add https://github.com/fuzhiyu/researchprojecttemplate --skill work-summaryAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 15 |
|---|---|
| repo stars | ★ 8 |
| Last updated | December 5, 2025 |
| Repository | fuzhiyu/researchprojecttemplate ↗ |
What it does
Create factual working-journal entries after analysis work, ensuring code is committed, figures copied, and summaries cited.
Files
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 statusIf 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.pngIn 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, objectiveThe 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