Menu
Summarizes your recent git activity into a chill standup script you can recite to your boss
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | bosskey |
| description | Summarizes your recent git activity into a chill standup script you can recite to your boss |
| user_invocable | true |
| disable-model-invocation | true |
| argument-hint |
Turn your recent git history into a standup script that sounds good without inviting follow up questions.
Run git config user.name to get the current user's git identity. Use the result as the author filter for all log queries.
Run a git log filtered to that author. Collect the last 3 days of commits OR the last 10 commits, whichever set is larger.
Use something like:
git log --author="<name>" --since="3 days ago" --pretty=format:"%H %s" --no-merges
Then also:
git log --author="<name>" --pretty=format:"%H %s" --no-merges -10
Merge and deduplicate the two lists.
For each commit, read the diff to understand what actually changed:
git show <hash> --stat
git show <hash>
Don't just rely on commit messages. Look at the code to understand the substance of the work.
Analyze all the commits together and write a status update the user can read verbatim in a standup, meeting, email, or slack message.
Tone rules:
Translation guide, think along these lines:
Present the result like this:
Your Boss Key, ready to go:
Here's where I'm at:
- [bullet 1]
- [bullet 2]
- [bullet 3]
- ...
Next up I'm [one liner about what's coming].
Also include a shorter hallway version for when someone catches you off guard:
"Been heads down on [vague but real sounding summary], making good progress. Should have more to share soon."
Keep it chill. The goal is to sound like someone who's been getting stuff done and has things under control. Not a robot, not a try hard, just a person doing their job well.
Writing-style convention applied to ALL prose output. Strict rule, no exceptions, no off-switch, no "this once it's clearer." Never use em dashes (—) or en dashes (–) as punctuation. Em dashes are the single most reliable tell that text was written by an LLM, and humans almost universally use commas, periods, semicolons, colons, or sentence restructuring in those positions instead. Hyphens (-) inside compound words (e.g., "copy-pasted", "well-known", "user-level") are fine. Em or en dashes inside proper nouns such as song titles, album names, or book chapter titles are fine. The skill body also lists secondary tells to avoid: inflated verbs ("delve", "leverage", "utilize"), boilerplate scaffolding ("it's worth noting that"), and structural tics. Auto-loads on every conversation; binds every response, plan, commit message, doc, comment, code identifier label, and chat reply you produce.
Set up VibeStack conventions for the project in the current directory, creates CLAUDE.md, Makefile, docs/, and TODO.md based on the actual codebase. Skips any of those that already exist. Run this once per project after installing VibeStack at the user level.
Set up a self-contained GitHub Actions CI workflow for the current project. Detects language(s) from the codebase (TS/JS, Python, Go, Rust) and writes `.github/workflows/ci.yml` with lint, test, and build gates. Idempotent, skips if the workflow already exists unless the user asks to reconcile.
Convention for using CLI tools and environment variables when interacting with third-party services like AWS, Vercel, Supabase, Stripe, GitHub, and Google Cloud. Auto-loads when working with external services, deployments, infrastructure, or API integrations.
Reference map of the user's local development environment, installed languages, runtimes, version managers, databases, cloud CLIs, and tools on this machine. READ this file BEFORE telling the user a tool is unavailable, BEFORE asking which deploy target / cloud / DB to use, and BEFORE proposing to install something. If a CLI is listed as installed, assume it works. If listed as not installed, don't suggest commands that depend on it without flagging the install step. If the file shows "(not yet populated)" below, run the discovery steps to fill it in on first use.
Capture conversation learnings into docs and clean up the docs folder