hiyabh Work Summary Generator
Purpose
Automatically generate structured work summaries, progress reports, and task tickets from the current session's activity. Instead of manually tracking what was done, Claude analyzes the session and produces organized output.
This follows Anthropic's practice of automation skills that read daily activity and produce organized work summaries or open tickets for other developers autonomously.
Summary Types
1. Session Summary (Quick)
For end-of-session wrap-up:
# Work Summary - {Date}
## Done
- Bullet list of completed items
## In Progress
- Items started but not finished
## Blockers
- Anything preventing progress
## Time Estimate
Approximate effort spent: X hours
2. Progress Report (Detailed)
For stakeholder updates or team communication:
# Progress Report: {Project Name}
**Period**: {Date range}
**Author**: Generated by Claude
## Executive Summary
2-3 sentences on overall progress.
## Completed Tasks
| Task | Status | Impact |
|------|--------|--------|
| ... | Done | ... |
## Upcoming Work
Prioritized list of next tasks.
## Risks & Blockers
Items that could delay progress.
## Metrics (if applicable)
- Tests passing: X/Y
- Files changed: N
- New features: N
3. Task Ticket
For creating actionable tickets for other developers:
# {Ticket Title}
## Description
What needs to be done and why.
## Acceptance Criteria
- [ ] Specific measurable criteria
- [ ] That define "done"
## Technical Notes
Implementation hints, relevant files, gotchas.
## Priority
High / Medium / Low
## Estimated Effort
Small (< 2h) / Medium (2-8h) / Large (> 8h)
How It Works
Generating a Summary
- Analyze the conversation history for this session
- Identify all tasks worked on, decisions made, and files changed
- Categorize into done/in-progress/blocked
- Generate the appropriate summary type
- Save to
reports/YYYY-MM-DD-{type}.md - Present to user for review/editing
Creating Tickets
- Identify a discrete piece of work from the session
- Extract requirements and technical context
- Format as a ticket with clear acceptance criteria
- Save to
reports/tickets/directory - Present to user - they decide where to post it
Output Formats
Summaries can be generated as:
- Markdown (default) - saved to reports directory
- Hebrew - if user requests, generate in Hebrew with RTL formatting
- Clipboard-ready - formatted for pasting into Slack/Teams/email
Key Principles
- Summaries should be HONEST - don't inflate what was done
- "In progress" is valid - not everything gets finished in one session
- Blockers are the most actionable part - highlight them clearly
- Tickets should be self-contained - another dev should understand without context
- Keep summaries concise - nobody reads a 3-page daily summary
- If Hebrew is requested, use professional business Hebrew, not literal translation