/log
Show recent git commits with a brief summary and continual context tied to the working directory / staging area.
$ npx -y skills add syahiidkamil/Software-Engineer-AI-Agent-Atlas --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/log
Context preview
What this command does when you run it.
Show recent git commits with a brief summary and continual context tied to the working directory / staging area.
Command definition
log.mddescription: Show recent git commits with a brief summary and continual context tied to the working directory / staging area.
argument-hint: "[count]"
Run `git log` to show recent commits, then add a short summary and any context that links those commits to the current working state.
Argument: $ARGUMENTS
- If `$ARGUMENTS` is a positive integer, use it as the commit count.
- Otherwise (empty, non-numeric, or zero/negative), default to **5**.
Steps
1. Run these in parallel via the Bash tool:
- `git log -n {count} --oneline --decorate` — the commit list
- `git status --short` — current working / staging state
- `git diff --stat HEAD` — what's changed since HEAD (staged + unstaged)
2. **Show the raw `git log` output first**, verbatim. Do not paraphrase commits.
3. **Summary** (2–4 bullets max). Cluster the commits by theme (feature area, refactor, chore, bug fix). Lead with what changed, not the commit subjects. Skip if the commits are unrelated noise.
4. **Continual context** — only include if there is a real link between recent commits and the current working/staging state. For each linked file or area:
- Name the commit(s) that last touched it
- Note whether the current change extends, reverts, or diverges from that direction
- Flag risks: e.g. "commit X just refactored this file; staged change re-edits the same lines — check for conflicts with the new structure"
If nothing in the working tree relates to the shown commits, write a single line: `No overlap between recent commits and current working state.` and stop.
Rules
- Keep it tight. The summary and context together should rarely exceed 10 lines.
- Don't speculate. If a connection isn't clear from the diff + log, don't invent one.
- Don't restate the commit subjects in the summary — Boss already sees them.
- Don't run extra commands (file reads, blame, etc.) unless the overlap is ambiguous and Boss would otherwise be misled.
Read more
description: Show recent git commits with a brief summary and continual context tied to the working directory / staging area. argument-hint: "[count]"
Run `git log` to show recent commits, then add a short summary and any context that links those commits to the current working state.
Argument: $ARGUMENTS
- If `$ARGUMENTS` is a positive integer, use it as the commit count.
- Otherwise (empty, non-numeric, or zero/negative), default to **5**.
Steps
1. Run these in parallel via the Bash tool:
- `git log -n {count} --oneline --decorate` — the commit list
- `git status --short` — current working / staging state
- `git diff --stat HEAD` — what's changed since HEAD (staged + unstaged)
2. **Show the raw `git log` output first**, verbatim. Do not paraphrase commits.
3. **Summary** (2–4 bullets max). Cluster the commits by theme (feature area, refactor, chore, bug fix). Lead with what changed, not the commit subjects. Skip if the commits are unrelated noise.
4. **Continual context** — only include if there is a real link between recent commits and the current working/staging state. For each linked file or area:
- Name the commit(s) that last touched it
- Note whether the current change extends, reverts, or diverges from that direction
- Flag risks: e.g. "commit X just refactored this file; staged change re-edits the same lines — check for conflicts with the new structure"
If nothing in the working tree relates to the shown commits, write a single line: `No overlap between recent commits and current working state.` and stop.
Rules
- Keep it tight. The summary and context together should rarely exceed 10 lines.
- Don't speculate. If a connection isn't clear from the diff + log, don't invent one.
- Don't restate the commit subjects in the summary — Boss already sees them.
- Don't run extra commands (file reads, blame, etc.) unless the overlap is ambiguous and Boss would otherwise be misled.
The senior-engineer layer for Claude Code. Explore before you build, clarify only what matters, capture it in living HTML, then hand it to Claude Code's native plan / goal / workflow loop.
Repo: syahiidkamil/Software-Engineer-AI-Agent-Atlas
Other commands on software-engineer-ai-agent-atlas.
- /change-core-self
Interview Boss about the project, then reason from first principles to design the ideal ATLAS operating identity/system-prompt for it — free to drop KISS/YAGNI/DRY/clean-architecture entirely when the project (and the LLM's own distribution) calls for a different mindset
Open command - /get-to-know
Initialize project context — understand the project, configure conventions, and set up project rules
Open command - /oneshotapp
One-shot an app autonomously — free-will the founding fork, build with deliberate decisions at every trigger, then adversarial review and a conscious final pass before delivery
Open command - /prototype
Brainstorm an idea into a clickable multi-screen React prototype — model the mind (Theory of Mind), interview to kill ambiguity, build a no-build CDN-React prototype under misc/prototypes/, run it, iterate until it matches Boss's vision.
Open command - /wireframe
Quickly sketch a standalone low-fidelity wireframe as self-contained HTML — gray boxes, dashed borders, no framework. Lighter than /plan:create-phase, static unlike /brainstorm:prototype.
Open command - /create-design-md
Discover the project's visual identity, prototype 3 HTML design variants for Boss to compare in a browser, iterate, then lock in DESIGN.md (Stitch-format, machine + human readable). The single source of truth AI coding agents read before generating UI.
Open command

