log
The log slash command displays recent Git commits in a concise format and correlates them with the current working directory state. Run it with an optional numeric argument to control how many commits appear (defaults to 5 if omitted or invalid), and it automatically flags potential conflicts between staged changes and recently modified code areas. Use this when you need quick context on what's been committed recently and how it relates to uncommitted work.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/syahiidkamil/Software-Engineer-AI-Agent-Atlas/HEAD/.claude/commands/git/log.md -o ~/.claude/commands/log.mdlog.md
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.Designs feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences
Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development
Code review a pull request
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
Commit what is already staged — runs the commit subagent in the background, following the ATLAS commit convention.
Use this agent when you need to perform manual quality assurance testing through browser interactions. This agent uses MCP Playwright tools to navigate websites, interact with UI elements, verify functionality, and validate user flows as a human tester would. Perfect for testing new features, regression testing, validating bug fixes, or exploring application behavior. Examples:\n\n<example>\nContext: The user has just implemented a new login feature and wants to test it.\nuser: "I've added a new login form, can you test if it works correctly?"\nassistant: "I'll use the qa-manual-tester agent to test the login functionality through the browser."\n<commentary>\nSince the user needs manual testing of a new feature, use the Task tool to launch the qa-manual-tester agent to interact with the browser and verify the login flow.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to verify that a bug fix is working properly.\nuser: "I fixed the issue where the submit button wasn't working on mobile view. Can you verify?"\nassistant: "Let me launch the qa-manual-tester agent to verify the submit button works correctly in mobile view."\n<commentary>\nThe user needs manual verification of a bug fix, so use the qa-manual-tester agent to test the specific functionality through browser interaction.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to perform regression testing after code changes.\nuser: "I've refactored the checkout flow. Please test that everything still works."\nassistant: "I'll use the qa-manual-tester agent to perform comprehensive testing of the checkout flow."\n<commentary>\nSince the user needs regression testing after refactoring, use the qa-manual-tester agent to manually test the entire checkout flow.\n</commentary>\n</example>
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
Initialize project context — understand the project, configure conventions, and set up project rules