Daily Report Skill
Reads your git commit history, groups commits thematically, and produces a polished, copy-paste-ready daily work report. Default output language is Turkish; pass -en to switch to English.
Modes and Flags
| Invocation | Language | Behavior |
|---|---|---|
/report | Turkish (default) | Interactive — asks for name, company, project, commit range; ends with a save prompt |
/report -tr | Turkish (explicit) | Same as above |
/report -en | English | Same interactive flow, but the report content is written in English |
/report --direkt | Turkish | Zero questions; uses saved preferences; auto-saves to ~/Desktop/rapor.md |
/report -en --direkt | English | Zero questions; uses saved preferences; auto-saves to ~/Desktop/rapor.md |
/report --direkt -tr | Turkish | Same as /report --direkt |
Flag order does not matter. -en --direkt and --direkt -en behave identically.
The output format is identical across all modes and languages. Header, company line, project line are always written. Only the paragraph content language changes.
All interactions with the user are in Turkish
Regardless of the report output language, ask questions and show messages to the user in Turkish. The -en flag only changes the report content that gets written into the code block / file.
Preferences File
User preferences are stored at ~/.claude/report-preferences.json. On startup, read this file:
cat ~/.claude/report-preferences.json 2>/dev/null || echo "{}"
Format:
{
"isim": "John Doe",
"sirket": "Acme Corp",
"projeAdi": "Demo Project"
}
Save rule (interactive mode only): After all interactive steps are complete (excluding commit range), write the user's inputs to this file with the Write tool. Create the file if it does not exist. On subsequent runs, the saved values are offered as the first option.
--direkt mode: Reads preferences but never writes them. If the file is missing or any of isim, sirket, projeAdi is empty, abort with: "Direkt mod için önce /report komutuyla en az bir kez interaktif çalıştırma yapılmalı."
Interactive Mode (/report)
- Check git repo
- Read preferences
- Ask for name
- Ask for company
- Ask for project name
- Ask for commit range
- Save preferences
- Analyze commits and group them
- Render the report
- Ask whether to save to file
Step 0: Git repository check
git rev-parse --is-inside-work-tree
If not a git repo, abort with: "Bu dizin bir git deposu değil. Lütfen bir git deposunda çalıştırın."
Step 1: Name
If isim exists in preferences, ask via AskUserQuestion:
Question: "İsminizi seçin veya yeni girin:" Options:
- "{saved name}" — Önceki tercih
- "Yeni isim gir"
If the user picks "Yeni isim gir" or no saved name exists:
Question: "Adınızı ve soyadınızı yazın (örn: John Doe):" (Free-text input)
Step 2: Company
If sirket exists, ask via AskUserQuestion:
Question: "Şirket adını seçin veya yeni girin:" Options:
- "{saved company}" — Önceki tercih
- "Yeni şirket adı gir"
Otherwise:
Question: "Şirket adını yazın (örn: Acme Corp):"
Step 3: Project
If projeAdi exists, ask via AskUserQuestion:
Question: "Proje adını seçin veya yeni girin:" Options:
- "{saved project}" — Önceki tercih
- "Yeni proje adı gir"
Otherwise:
Question: "Proje adını yazın (örn: Demo Project):"
Step 4: Commit range
Question: "Hangi commit'ler rapora dahil edilsin?" Options:
- "Bugün" — Bugünkü commit'ler
- "Son N commit" — Belirli sayıda son commit
If "Bugün": get today's date in YYYY-MM-DD, then run:
git log --after="YYYY-MM-DD 00:00" --before="YYYY-MM-DD 23:59" --oneline --no-merges
If "Son N commit": ask the count via free-text input, then run:
git log -N --oneline --no-merges
Step 5: Save preferences
Write to ~/.claude/report-preferences.json:
{
"isim": "{name}",
"sirket": "{company}",
"projeAdi": "{project}"
}
Step 6: Git analysis
If no commits found: "Seçilen aralıkta hiçbir commit bulunamadı. Tarih veya commit sayısını kontrol edin."
For each commit, get details:
git show <hash> --stat --format="%H%n%s%n%b"
For many commits, batch:
git log -N --stat --no-merges --format="%H %s"
Thematic grouping
Group commits by:
- Directory/module proximity — commits touching the same area
- Feature surface — commits whose messages share keywords
- Related changes — a feature implementation plus its follow-up fixes
- Independent changes — config, dependencies, etc., go in their own group
CRITICAL — No grouping cap: There is no upper limit on paragraph count. As commits grow, paragraphs grow. 10, 15, 20+ paragraphs are fine. Never artificially compress unrelated work into a single paragraph. If two changes are not thematically related, they get separate paragraphs.
CRITICAL — Completeness: No commit may be skipped or lost in summarization. After grouping, verify every commit is represented in at least one paragraph. Cross-check the final report against the commit list. Tiny commits (one-line fixes, bumps) can be folded into a related paragraph but must still be mentioned.
Paragraph writing — Turkish (default or -tr)
For each group, write a concise, professional Turkish paragraph:
- Edilgen çatı: "eklendi", "giderildi", "yeniden tasarlandı", "güçlendirildi"
- Anlat ne yapıldığını, nasıl yapıldığını değil
- Teknik jargon serbest: cache invalidation, server-side pagination, constraint, migration, Edge Function, rollover, audit log
- Yasak: fonksiyon adı, dosya adı, değişken adı, dosya yolu
- Her paragraf 2-4 cümle
- Yasak: uzun tire
—, noktalı virgül;, paragraf sonunda isim
Good Turkish examples:
- "PDF oluşturma altyapısı güçlendirildi. Edge Function'a dinamik veri üretimi ve cache invalidation stratejisi eklendi. Büyük veri setlerinde oluşan timeout problemleri giderildi."
- "Paket yönetimi arayüzü yeniden tasarlandı. Hizmet kalemi formları kart tabanlı layout ile modernize edildi, aylık saat ve rollover desteği eklendi."
Bad Turkish examples (DO NOT DO):
- "pdfGenerator.ts dosyasındaki generatePdf fonksiyonu refactor edildi." → file/function name
- "useReservationStore hook'u güncellendi." → hook name
- "src/components/wizard altında değişiklikler yapıldı." → file path
Paragraph writing — English (-en)
For each group, write a concise, professional and warm English paragraph. Tone goal: a thoughtful senior engineer summarizing their day for a kind manager — clear, confident, never robotic, never marketing-y.
- Passive voice preferred: "was rebuilt", "was added", "was resolved", "was tightened"
- Tell what was done, not how
- Technical jargon is welcome: cache invalidation, server-side pagination, constraint, migration, edge function, rollover, audit log, idempotency
- Forbidden: function names, file names, variable names, file paths, framework internals (e.g. "the Redux slice", "the useFoo hook", "the FooButton component")
- 2-4 sentences per paragraph
- Forbidden punctuation/style: em dashes
—, semicolons;, name suffixes at the end of paragraphs, hype words ("seamlessly", "robust", "cutting-edge", "leverage") - Tone: professional and kind. Avoid passive-aggressive ("finally"), avoid bragging ("dramatically improved"), avoid corporate filler ("synergize"). Just clear, calm reporting.
Good English examples:
- "The reporting module was rebuilt. The PDF generation service now supports parametric data flow and a cache invalidation strategy, and timeout issues on large datasets were resolved."
- "The subscription and credit management layer was extended. The plan editor was redesigned around card-based forms with monthly hours, extra credits, and rollover support, and the pricing engine now c