From Ottonomous
Synthesizes code diffs into semantic HTML summaries for PRs, release notes, or change overviews. Invoked via /summary with optional staged or branch argument.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ottonomous:summaryThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Scope:** $ARGUMENTS
Scope: $ARGUMENTS
| Argument | Files to summarize |
|---|---|
(none) or branch | Branch diff: git diff main...HEAD --name-only |
staged | Staged changes: git diff --cached --name-only |
| Phase | Purpose |
|---|---|
| 1. Analyze | Get changed files and diffs |
| 2. Read | Read changed files and their diffs |
| 3. Synthesize | Create semantic narrative from code and diffs |
| 4. Generate | Convert to HTML, open in browser |
Get changed files using scope command. If no changes found, report: "No changes to summarize."
git diff main...HEAD --name-only
For each changed file, read the file content and diff:
git diff main...HEAD -- <file>
Read the full file for context when the diff alone isn't sufficient to understand the change.
Get repo info for links:
git remote get-url origin
Parse to get {org}/{repo} for GitHub links.
Generate semantic summary following this format:
# {Branch Name}
## Overview
{2-3 sentences: what this branch accomplishes from a business/feature perspective}
### Technical Implementation
{Integration points, architecture decisions, key patterns used}
### Key Review Areas
{What reviewers should focus on, potential risks, areas needing careful attention}
### What Changed
{High-level summary of functionality changes and why they matter}
## Semantic Changes by Component
### [src/auth/users.ts](https://github.com/{org}/{repo}/blob/{branch}/src/auth/users.ts)
- **Purpose of changes:** What problem does this solve or what feature does it add?
- **Behavioral changes:** How does the behavior differ from before?
- **Data flow impact:** How do these changes affect data flow through the system?
- **Performance considerations:** Changes to scan frequency, read/write patterns, potential bottlenecks
- **Subtle bug risks:** Race conditions, stale data, cache invalidation, timing issues introduced
- **Dependencies affected:** What other parts of the codebase might be impacted?
### [src/api/routes.ts](https://github.com/{org}/{repo}/blob/{branch}/src/api/routes.ts)
- **Purpose of changes:** ...
- **Behavioral changes:** ...
- **Data flow impact:** ...
- **Performance considerations:** ...
- **Subtle bug risks:** ...
- **Dependencies affected:** ...
## Breaking Changes
{If any exist - before/after comparison, migration path. Omit section entirely if none.}
## Files Changed
<details>
<summary>{count} files</summary>
| File | Summary |
|------|---------|
| [src/auth/users.ts](https://github.com/{org}/{repo}/blob/{branch}/src/auth/users.ts) | Added profile CRUD |
| [src/api/routes.ts](https://github.com/{org}/{repo}/blob/{branch}/src/api/routes.ts) | New profile endpoints |
**List every file individually — no wildcards.** Count must match table rows.
</details>
Key principles:
Create directories:
mkdir -p .otto/summaries
Save markdown to .otto/summaries/{branch}-{date}.md
Convert to HTML using the md-to-html script:
node skills/summary/scripts/md-to-html.js .otto/summaries/{branch}-{date}.md .otto/summaries/{branch}-{date}.html
Open in browser:
open .otto/summaries/{branch}-{date}.html
Report:
Summary generated: .otto/summaries/{branch}-{date}.html
npx claudepluginhub brsbl/ottonomous --plugin ottonomousGenerates concise branch summaries for PR descriptions by analyzing git diffs and commit history.
Visualizes git diffs, branches, commits, PRs, and ranges as interactive HTML reports with architecture diagrams, KPI dashboards, code review cards, and side-by-side comparisons.
Generate HTML artifacts for code review, PR explanation, and codebase understanding — rendered diffs with inline annotations, severity-coded findings, refactor risk maps, before/after migration views, and subsystem walkthroughs. Use whenever the user wants to review, explain, or understand a PR, refactor, codebase area, or subsystem — especially before merging, when onboarding others to a change, or when the GitHub diff view doesn't show enough context. Default to attaching an HTML explainer to every non-trivial PR.