Merge branch 'EveryInc:main' into fix/git-worktree-env-copy

This commit is contained in:
Ben Fisher
2025-11-27 22:31:25 -08:00
committed by GitHub
39 changed files with 9460 additions and 274 deletions

View File

@@ -11,8 +11,8 @@
"plugins": [
{
"name": "compounding-engineering",
"description": "AI-powered development tools that get smarter with every use. Make each unit of engineering work easier than the last. Includes 17 specialized agents, 6 commands, and 1 skill.",
"version": "1.1.0",
"description": "AI-powered development tools that get smarter with every use. Make each unit of engineering work easier than the last. Includes 24 specialized agents, 16 commands, and 11 skills.",
"version": "2.8.0",
"author": {
"name": "Kieran Klaassen",
"url": "https://github.com/kieranklaassen",

39
.github/workflows/deploy-docs.yml vendored Normal file
View File

@@ -0,0 +1,39 @@
name: Deploy Documentation to GitHub Pages
on:
push:
branches: [main]
paths:
- 'plugins/compounding-engineering/docs/**'
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: "pages"
cancel-in-progress: false
jobs:
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Pages
uses: actions/configure-pages@v4
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: 'plugins/compounding-engineering/docs'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4

View File

@@ -8,13 +8,19 @@ This repository is a Claude Code plugin marketplace that distributes the `compou
every-marketplace/
├── .claude-plugin/
│ └── marketplace.json # Marketplace catalog (lists available plugins)
├── docs/ # Documentation site (GitHub Pages)
│ ├── index.html # Landing page
│ ├── css/ # Stylesheets
│ ├── js/ # JavaScript
│ └── pages/ # Reference pages
└── plugins/
└── compounding-engineering/ # The actual plugin
├── .claude-plugin/
│ └── plugin.json # Plugin metadata
├── agents/ # 17 specialized AI agents
├── commands/ # 6 slash commands
├── skills/ # 1 skill (gemini-imagegen)
├── agents/ # 24 specialized AI agents
├── commands/ # 13 slash commands
├── skills/ # 11 skills
├── mcp-servers/ # 2 MCP servers (playwright, context7)
├── README.md # Plugin documentation
└── CHANGELOG.md # Version history
```
@@ -86,7 +92,21 @@ When adding new functionality, bump the version in:
- [ ] `plugins/compounding-engineering/CHANGELOG.md` → document changes
- [ ] `CLAUDE.md` → update structure diagram if needed
#### 5. Validate JSON files
#### 5. Rebuild documentation site
Run the release-docs command to update all documentation pages:
```bash
claude /release-docs
```
This will:
- Update stats on the landing page
- Regenerate reference pages (agents, commands, skills, MCP servers)
- Update the changelog page
- Validate all counts match actual files
#### 6. Validate JSON files
```bash
cat .claude-plugin/marketplace.json | jq .
@@ -167,6 +187,73 @@ Each plugin has its own plugin.json with detailed metadata:
}
```
## Documentation Site
The documentation site is at `/docs` in the repository root (for GitHub Pages). This site is built with plain HTML/CSS/JS (based on Evil Martians' LaunchKit template) and requires no build step to view.
### Documentation Structure
```
docs/
├── index.html # Landing page with stats and philosophy
├── css/
│ ├── style.css # Main styles (LaunchKit-based)
│ └── docs.css # Documentation-specific styles
├── js/
│ └── main.js # Interactivity (theme toggle, mobile nav)
└── pages/
├── getting-started.html # Installation and quick start
├── agents.html # All 24 agents reference
├── commands.html # All 13 commands reference
├── skills.html # All 11 skills reference
├── mcp-servers.html # MCP servers reference
└── changelog.html # Version history
```
### Keeping Docs Up-to-Date
**IMPORTANT:** After ANY change to agents, commands, skills, or MCP servers, run:
```bash
claude /release-docs
```
This command:
1. Counts all current components
2. Reads all agent/command/skill/MCP files
3. Regenerates all reference pages
4. Updates stats on the landing page
5. Updates the changelog from CHANGELOG.md
6. Validates counts match across all files
### Manual Updates
If you need to update docs manually:
1. **Landing page stats** - Update the numbers in `docs/index.html`:
```html
<span class="stat-number">24</span> <!-- agents -->
<span class="stat-number">13</span> <!-- commands -->
```
2. **Reference pages** - Each page in `docs/pages/` documents all components in that category
3. **Changelog** - `docs/pages/changelog.html` mirrors `CHANGELOG.md` in HTML format
### Viewing Docs Locally
Since the docs are static HTML, you can view them directly:
```bash
# Open in browser
open docs/index.html
# Or start a local server
cd docs
python -m http.server 8000
# Then visit http://localhost:8000
```
## Testing Changes
### Test Locally

675
docs/css/docs.css Normal file
View File

@@ -0,0 +1,675 @@
/* Documentation-specific styles */
/* ============================================
Documentation Layout
============================================ */
.docs-layout {
display: grid;
grid-template-columns: 1fr;
min-height: 100vh;
}
@media (min-width: 1024px) {
.docs-layout {
grid-template-columns: 280px 1fr;
}
}
/* ============================================
Sidebar
============================================ */
.docs-sidebar {
position: fixed;
top: 0;
left: -300px;
width: 280px;
height: 100vh;
background-color: var(--color-background);
border-right: 1px solid var(--color-border);
overflow-y: auto;
transition: left 0.3s ease;
z-index: 100;
}
.docs-sidebar.open {
left: 0;
}
@media (min-width: 1024px) {
.docs-sidebar {
position: sticky;
left: 0;
}
}
.sidebar-header {
padding: var(--space-l);
border-bottom: 1px solid var(--color-border);
}
.sidebar-header .nav-brand {
display: flex;
align-items: center;
gap: var(--space-s);
text-decoration: none;
color: var(--color-text-primary);
font-weight: 600;
}
.sidebar-header .logo-icon {
color: var(--color-accent);
font-size: var(--font-size-l);
}
.sidebar-header .logo-text {
display: inline;
}
.sidebar-nav {
padding: var(--space-l);
}
.nav-section {
margin-bottom: var(--space-xl);
}
.nav-section h3 {
font-size: var(--font-size-xs);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
color: var(--color-text-tertiary);
margin: 0 0 var(--space-m) 0;
}
.nav-section ul {
list-style: none;
margin: 0;
padding: 0;
}
.nav-section li {
margin: 0;
}
.nav-section a {
display: block;
padding: var(--space-s) var(--space-m);
color: var(--color-text-secondary);
text-decoration: none;
font-size: var(--font-size-s);
border-radius: var(--radius-s);
transition: all 0.2s ease;
}
.nav-section a:hover {
color: var(--color-text-primary);
background-color: var(--color-surface);
}
.nav-section a.active {
color: var(--color-accent);
background-color: var(--color-accent-light);
}
/* ============================================
Main Content
============================================ */
.docs-content {
padding: var(--space-xl);
max-width: 900px;
}
@media (min-width: 1024px) {
.docs-content {
padding: var(--space-xxl);
}
}
.docs-header {
display: flex;
align-items: center;
justify-content: space-between;
margin-bottom: var(--space-xl);
}
.breadcrumb {
display: flex;
align-items: center;
gap: var(--space-s);
font-size: var(--font-size-s);
color: var(--color-text-tertiary);
}
.breadcrumb a {
color: var(--color-text-secondary);
text-decoration: none;
}
.breadcrumb a:hover {
color: var(--color-accent);
}
.mobile-menu-toggle {
display: flex;
align-items: center;
justify-content: center;
width: 40px;
height: 40px;
background: none;
border: 1px solid var(--color-border);
border-radius: var(--radius-s);
color: var(--color-text-secondary);
cursor: pointer;
}
@media (min-width: 1024px) {
.mobile-menu-toggle {
display: none;
}
}
/* ============================================
Article Styles
============================================ */
.docs-article {
line-height: 1.7;
}
.docs-article h1 {
font-size: var(--font-size-xl);
margin-bottom: var(--space-l);
}
.docs-article h2 {
font-size: var(--font-size-l);
margin-top: var(--space-xxl);
margin-bottom: var(--space-l);
padding-bottom: var(--space-s);
border-bottom: 1px solid var(--color-border);
display: flex;
align-items: center;
gap: var(--space-s);
}
.docs-article h2 i {
color: var(--color-accent);
}
.docs-article h3 {
font-size: var(--font-size-m);
margin-top: var(--space-xl);
margin-bottom: var(--space-m);
}
.docs-article h4 {
font-size: var(--font-size-s);
margin-top: var(--space-l);
margin-bottom: var(--space-s);
}
.docs-article p {
margin-bottom: var(--space-l);
}
.docs-article .lead {
font-size: var(--font-size-l);
color: var(--color-text-secondary);
margin-bottom: var(--space-xl);
}
.docs-article ul,
.docs-article ol {
margin-bottom: var(--space-l);
padding-left: var(--space-xl);
}
.docs-article li {
margin-bottom: var(--space-s);
}
/* ============================================
Code Blocks in Docs
============================================ */
.docs-article .card-code-block {
margin: var(--space-l) 0;
}
.docs-article code {
font-family: var(--font-mono);
font-size: 0.9em;
background-color: var(--color-surface);
padding: 2px 6px;
border-radius: var(--radius-xs);
color: var(--color-accent);
}
.docs-article pre code {
background: none;
padding: 0;
color: var(--color-code-text);
}
/* ============================================
Tables
============================================ */
.docs-table {
width: 100%;
border-collapse: collapse;
margin: var(--space-l) 0;
font-size: var(--font-size-s);
}
.docs-table th,
.docs-table td {
padding: var(--space-m);
text-align: left;
border-bottom: 1px solid var(--color-border);
}
.docs-table th {
font-weight: 600;
color: var(--color-text-primary);
background-color: var(--color-surface);
}
.docs-table td {
color: var(--color-text-secondary);
}
.docs-table code {
font-size: 0.85em;
}
/* ============================================
Callouts
============================================ */
.callout {
display: flex;
gap: var(--space-m);
padding: var(--space-l);
border-radius: var(--radius-m);
margin: var(--space-l) 0;
}
.callout-icon {
font-size: var(--font-size-l);
flex-shrink: 0;
}
.callout-content h4 {
margin: 0 0 var(--space-s) 0;
font-size: var(--font-size-s);
}
.callout-content p {
margin: 0;
font-size: var(--font-size-s);
}
.callout-info {
background-color: rgba(99, 102, 241, 0.1);
border: 1px solid rgba(99, 102, 241, 0.2);
}
.callout-info .callout-icon {
color: var(--color-accent);
}
.callout-info .callout-content h4 {
color: var(--color-accent);
}
.callout-tip {
background-color: rgba(16, 185, 129, 0.1);
border: 1px solid rgba(16, 185, 129, 0.2);
}
.callout-tip .callout-icon {
color: var(--color-success);
}
.callout-tip .callout-content h4 {
color: var(--color-success);
}
.callout-warning {
background-color: rgba(245, 158, 11, 0.1);
border: 1px solid rgba(245, 158, 11, 0.2);
}
.callout-warning .callout-icon {
color: var(--color-warning);
}
.callout-warning .callout-content h4 {
color: var(--color-warning);
}
/* ============================================
Badges
============================================ */
.badge {
display: inline-block;
padding: 2px 8px;
font-size: var(--font-size-xs);
font-weight: 600;
border-radius: var(--radius-s);
text-transform: uppercase;
letter-spacing: 0.03em;
}
.badge-critical {
background-color: rgba(239, 68, 68, 0.15);
color: var(--color-error);
}
.badge-important {
background-color: rgba(245, 158, 11, 0.15);
color: var(--color-warning);
}
.badge-nice {
background-color: rgba(99, 102, 241, 0.15);
color: var(--color-accent);
}
/* ============================================
Philosophy Grid
============================================ */
.philosophy-grid {
display: grid;
grid-template-columns: repeat(1, 1fr);
gap: var(--space-l);
margin: var(--space-xl) 0;
}
@media (min-width: 640px) {
.philosophy-grid {
grid-template-columns: repeat(2, 1fr);
}
}
.philosophy-card {
padding: var(--space-xl);
background-color: var(--color-surface);
border-radius: var(--radius-m);
border: 1px solid var(--color-border);
}
.philosophy-icon {
font-size: var(--font-size-xl);
color: var(--color-accent);
margin-bottom: var(--space-m);
}
.philosophy-card h4 {
margin: 0 0 var(--space-s) 0;
color: var(--color-text-primary);
}
.philosophy-card p {
margin: 0;
font-size: var(--font-size-s);
color: var(--color-text-secondary);
}
/* ============================================
Blockquotes
============================================ */
.highlight-quote {
font-size: var(--font-size-l);
font-style: italic;
color: var(--color-accent);
padding: var(--space-xl);
margin: var(--space-xl) 0;
background: linear-gradient(135deg, var(--color-accent-lighter), transparent);
border-left: 4px solid var(--color-accent);
border-radius: var(--radius-m);
}
/* ============================================
Navigation Footer
============================================ */
.docs-nav-footer {
display: flex;
justify-content: space-between;
gap: var(--space-l);
margin-top: var(--space-xxl);
padding-top: var(--space-xl);
border-top: 1px solid var(--color-border);
}
.nav-prev,
.nav-next {
display: flex;
flex-direction: column;
gap: var(--space-xs);
padding: var(--space-l);
background-color: var(--color-surface);
border-radius: var(--radius-m);
text-decoration: none;
transition: all 0.2s ease;
flex: 1;
max-width: 300px;
}
.nav-prev:hover,
.nav-next:hover {
background-color: var(--color-surface-hover);
border-color: var(--color-accent);
}
.nav-next {
text-align: right;
margin-left: auto;
}
.nav-label {
font-size: var(--font-size-xs);
color: var(--color-text-tertiary);
text-transform: uppercase;
letter-spacing: 0.05em;
}
.nav-title {
font-weight: 600;
color: var(--color-accent);
display: flex;
align-items: center;
gap: var(--space-s);
}
.nav-next .nav-title {
justify-content: flex-end;
}
/* ============================================
Mobile Sidebar Overlay
============================================ */
@media (max-width: 1023px) {
.docs-sidebar.open::before {
content: '';
position: fixed;
top: 0;
left: 0;
right: 0;
bottom: 0;
background-color: rgba(0, 0, 0, 0.5);
z-index: -1;
}
}
/* ============================================
Changelog Styles
============================================ */
.version-section {
margin-bottom: var(--space-xxl);
padding-bottom: var(--space-xl);
border-bottom: 1px solid var(--color-border);
}
.version-section:last-child {
border-bottom: none;
}
.version-header {
display: flex;
align-items: center;
gap: var(--space-m);
margin-bottom: var(--space-l);
flex-wrap: wrap;
}
.version-header h2 {
margin: 0;
padding: 0;
border: none;
font-size: var(--font-size-xl);
color: var(--color-text-primary);
}
.version-date {
font-size: var(--font-size-s);
color: var(--color-text-tertiary);
background-color: var(--color-surface);
padding: var(--space-xs) var(--space-m);
border-radius: var(--radius-s);
}
.version-badge {
font-size: var(--font-size-xs);
font-weight: 600;
padding: var(--space-xs) var(--space-m);
border-radius: var(--radius-s);
background-color: var(--color-accent);
color: white;
}
.version-badge.major {
background-color: var(--color-warning);
}
.version-description {
font-size: var(--font-size-m);
color: var(--color-text-secondary);
margin-bottom: var(--space-l);
font-style: italic;
}
.changelog-category {
margin-bottom: var(--space-l);
padding: var(--space-l);
background-color: var(--color-surface);
border-radius: var(--radius-m);
border-left: 4px solid var(--color-border);
}
.changelog-category h3 {
margin: 0 0 var(--space-m) 0;
font-size: var(--font-size-m);
display: flex;
align-items: center;
gap: var(--space-s);
}
.changelog-category h3 i {
font-size: var(--font-size-s);
}
.changelog-category h4 {
margin: var(--space-l) 0 var(--space-s) 0;
font-size: var(--font-size-s);
color: var(--color-text-secondary);
}
.changelog-category ul {
margin: 0;
padding-left: var(--space-xl);
}
.changelog-category li {
margin-bottom: var(--space-s);
}
.changelog-category.added {
border-left-color: var(--color-success);
}
.changelog-category.added h3 {
color: var(--color-success);
}
.changelog-category.improved {
border-left-color: var(--color-accent);
}
.changelog-category.improved h3 {
color: var(--color-accent);
}
.changelog-category.changed {
border-left-color: var(--color-warning);
}
.changelog-category.changed h3 {
color: var(--color-warning);
}
.changelog-category.fixed {
border-left-color: var(--color-error);
}
.changelog-category.fixed h3 {
color: var(--color-error);
}
.version-summary {
margin-top: var(--space-l);
}
.version-summary h4 {
margin-bottom: var(--space-m);
}
.version-summary table {
width: 100%;
max-width: 400px;
border-collapse: collapse;
font-size: var(--font-size-s);
}
.version-summary th,
.version-summary td {
padding: var(--space-s) var(--space-m);
text-align: left;
border-bottom: 1px solid var(--color-border);
}
.version-summary th {
font-weight: 600;
background-color: var(--color-surface);
}
.version-summary .positive {
color: var(--color-success);
font-weight: 600;
}
.version-summary .negative {
color: var(--color-error);
font-weight: 600;
}

2886
docs/css/style.css Normal file

File diff suppressed because it is too large Load Diff

1038
docs/index.html Normal file

File diff suppressed because it is too large Load Diff

225
docs/js/main.js Normal file
View File

@@ -0,0 +1,225 @@
/**
* Compounding Engineering Documentation
* Main JavaScript functionality
*/
document.addEventListener('DOMContentLoaded', () => {
initMobileNav();
initSmoothScroll();
initCopyCode();
initThemeToggle();
});
/**
* Mobile Navigation Toggle
*/
function initMobileNav() {
const mobileToggle = document.querySelector('[data-mobile-toggle]');
const navigation = document.querySelector('[data-navigation]');
if (!mobileToggle || !navigation) return;
mobileToggle.addEventListener('click', () => {
navigation.classList.toggle('open');
mobileToggle.classList.toggle('active');
// Update aria-expanded
const isOpen = navigation.classList.contains('open');
mobileToggle.setAttribute('aria-expanded', isOpen);
});
// Close menu when clicking outside
document.addEventListener('click', (event) => {
if (!mobileToggle.contains(event.target) && !navigation.contains(event.target)) {
navigation.classList.remove('open');
mobileToggle.classList.remove('active');
mobileToggle.setAttribute('aria-expanded', 'false');
}
});
// Close menu when clicking a nav link
navigation.querySelectorAll('.nav-link').forEach(link => {
link.addEventListener('click', () => {
navigation.classList.remove('open');
mobileToggle.classList.remove('active');
mobileToggle.setAttribute('aria-expanded', 'false');
});
});
}
/**
* Smooth Scroll for Anchor Links
*/
function initSmoothScroll() {
document.querySelectorAll('a[href^="#"]').forEach(anchor => {
anchor.addEventListener('click', function(e) {
const targetId = this.getAttribute('href');
if (targetId === '#') return;
const targetElement = document.querySelector(targetId);
if (!targetElement) return;
e.preventDefault();
const navHeight = document.querySelector('.nav-container')?.offsetHeight || 0;
const targetPosition = targetElement.getBoundingClientRect().top + window.pageYOffset - navHeight - 24;
window.scrollTo({
top: targetPosition,
behavior: 'smooth'
});
// Update URL without jumping
history.pushState(null, null, targetId);
});
});
}
/**
* Copy Code Functionality
*/
function initCopyCode() {
document.querySelectorAll('.card-code-block').forEach(block => {
// Create copy button
const copyBtn = document.createElement('button');
copyBtn.className = 'copy-btn';
copyBtn.innerHTML = '<i class="fa-regular fa-copy"></i>';
copyBtn.setAttribute('aria-label', 'Copy code');
copyBtn.setAttribute('title', 'Copy to clipboard');
// Style the button
copyBtn.style.cssText = `
position: absolute;
top: 8px;
right: 8px;
padding: 6px 10px;
background: rgba(255, 255, 255, 0.1);
border: none;
border-radius: 6px;
color: #94a3b8;
cursor: pointer;
opacity: 0;
transition: all 0.2s ease;
font-size: 14px;
`;
// Make parent relative for positioning
block.style.position = 'relative';
block.appendChild(copyBtn);
// Show/hide on hover
block.addEventListener('mouseenter', () => {
copyBtn.style.opacity = '1';
});
block.addEventListener('mouseleave', () => {
copyBtn.style.opacity = '0';
});
// Copy functionality
copyBtn.addEventListener('click', async () => {
const code = block.querySelector('code');
if (!code) return;
try {
await navigator.clipboard.writeText(code.textContent);
copyBtn.innerHTML = '<i class="fa-solid fa-check"></i>';
copyBtn.style.color = '#34d399';
setTimeout(() => {
copyBtn.innerHTML = '<i class="fa-regular fa-copy"></i>';
copyBtn.style.color = '#94a3b8';
}, 2000);
} catch (err) {
console.error('Failed to copy:', err);
copyBtn.innerHTML = '<i class="fa-solid fa-xmark"></i>';
copyBtn.style.color = '#f87171';
setTimeout(() => {
copyBtn.innerHTML = '<i class="fa-regular fa-copy"></i>';
copyBtn.style.color = '#94a3b8';
}, 2000);
}
});
});
}
/**
* Theme Toggle (Light/Dark)
*/
function initThemeToggle() {
// Check for saved theme preference or default to dark
const savedTheme = localStorage.getItem('theme') || 'dark';
document.documentElement.className = `theme-${savedTheme}`;
// Create theme toggle button if it doesn't exist
const existingToggle = document.querySelector('[data-theme-toggle]');
if (existingToggle) {
existingToggle.addEventListener('click', toggleTheme);
updateThemeToggleIcon(existingToggle, savedTheme);
}
}
function toggleTheme() {
const html = document.documentElement;
const currentTheme = html.classList.contains('theme-dark') ? 'dark' : 'light';
const newTheme = currentTheme === 'dark' ? 'light' : 'dark';
html.className = `theme-${newTheme}`;
localStorage.setItem('theme', newTheme);
const toggle = document.querySelector('[data-theme-toggle]');
if (toggle) {
updateThemeToggleIcon(toggle, newTheme);
}
}
function updateThemeToggleIcon(toggle, theme) {
const icon = toggle.querySelector('i');
if (icon) {
icon.className = theme === 'dark' ? 'fa-solid fa-sun' : 'fa-solid fa-moon';
}
}
/**
* Intersection Observer for Animation on Scroll
*/
function initScrollAnimations() {
const observerOptions = {
threshold: 0.1,
rootMargin: '0px 0px -50px 0px'
};
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
entry.target.classList.add('visible');
observer.unobserve(entry.target);
}
});
}, observerOptions);
document.querySelectorAll('.agent-card, .command-card, .skill-card, .mcp-card, .stat-card').forEach(card => {
card.style.opacity = '0';
card.style.transform = 'translateY(20px)';
card.style.transition = 'opacity 0.5s ease, transform 0.5s ease';
observer.observe(card);
});
}
// Add visible class styles
const style = document.createElement('style');
style.textContent = `
.agent-card.visible,
.command-card.visible,
.skill-card.visible,
.mcp-card.visible,
.stat-card.visible {
opacity: 1 !important;
transform: translateY(0) !important;
}
`;
document.head.appendChild(style);
// Initialize scroll animations after a short delay
setTimeout(initScrollAnimations, 100);

649
docs/pages/agents.html Normal file
View File

@@ -0,0 +1,649 @@
<!DOCTYPE html>
<html lang="en" class="theme-dark">
<head>
<meta charset="utf-8" />
<title>Agent Reference - Compounding Engineering</title>
<meta content="Complete reference for all 23 specialized AI agents in the Compounding Engineering plugin." name="description" />
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />
<link href="../css/docs.css" rel="stylesheet" type="text/css" />
<script src="../js/main.js" type="text/javascript" defer></script>
</head>
<body>
<div class="background-gradient"></div>
<div class="docs-layout">
<aside class="docs-sidebar">
<div class="sidebar-header">
<a href="../index.html" class="nav-brand">
<span class="logo-icon"><i class="fa-solid fa-layer-group"></i></span>
<span class="logo-text">CE Docs</span>
</a>
</div>
<nav class="sidebar-nav">
<div class="nav-section">
<h3>Getting Started</h3>
<ul>
<li><a href="getting-started.html">Installation</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Reference</h3>
<ul>
<li><a href="agents.html" class="active">Agents (23)</a></li>
<li><a href="commands.html">Commands (13)</a></li>
<li><a href="skills.html">Skills (11)</a></li>
<li><a href="mcp-servers.html">MCP Servers (2)</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Resources</h3>
<ul>
<li><a href="changelog.html">Changelog</a></li>
</ul>
</div>
<div class="nav-section">
<h3>On This Page</h3>
<ul>
<li><a href="#review-agents">Review (10)</a></li>
<li><a href="#research-agents">Research (4)</a></li>
<li><a href="#workflow-agents">Workflow (5)</a></li>
<li><a href="#design-agents">Design (3)</a></li>
<li><a href="#docs-agents">Docs (1)</a></li>
</ul>
</div>
</nav>
</aside>
<main class="docs-content">
<div class="docs-header">
<nav class="breadcrumb">
<a href="../index.html">Home</a>
<span>/</span>
<a href="getting-started.html">Docs</a>
<span>/</span>
<span>Agents</span>
</nav>
<button class="mobile-menu-toggle" data-sidebar-toggle>
<i class="fa-solid fa-bars"></i>
</button>
</div>
<article class="docs-article">
<h1><i class="fa-solid fa-users-gear color-accent"></i> Agent Reference</h1>
<p class="lead">
Think of agents as your expert teammates who never sleep. You've got 23 specialists here—each one obsessed with a single domain. Call them individually when you need focused expertise, or orchestrate them together for multi-angle analysis. They're opinionated, they're fast, and they remember your codebase better than you do.
</p>
<div class="usage-box">
<h3>How to Use Agents</h3>
<div class="card-code-block">
<pre><code># Basic invocation
claude agent [agent-name]
# With a specific message
claude agent [agent-name] "Your message here"
# Examples
claude agent kieran-rails-reviewer
claude agent security-sentinel "Audit the payment flow"</code></pre>
</div>
</div>
<!-- Review Agents -->
<section id="review-agents">
<h2><i class="fa-solid fa-code-pull-request"></i> Review Agents (10)</h2>
<p>Your code review dream team. These agents catch what humans miss at 2am—security holes, performance cliffs, architectural drift, and those "it works but I hate it" moments. They're picky. They disagree with each other. That's the point.</p>
<div class="agent-detail" id="kieran-rails-reviewer">
<div class="agent-detail-header">
<h3>kieran-rails-reviewer</h3>
<span class="agent-badge">Rails</span>
</div>
<p class="agent-detail-description">
Your senior Rails developer who's seen too many "clever" solutions fail in production. Obsessed with code that's boring, predictable, and maintainable. Strict on existing code (because touching it risks everything), pragmatic on new isolated features (because shipping matters). If you've ever thought "this works but feels wrong," this reviewer will tell you why.
</p>
<h4>Key Principles</h4>
<ul>
<li><strong>Existing Code Modifications</strong> - Very strict. Added complexity needs strong justification.</li>
<li><strong>New Code</strong> - Pragmatic. If it's isolated and works, it's acceptable.</li>
<li><strong>Turbo Streams</strong> - Simple turbo streams MUST be inline arrays in controllers.</li>
<li><strong>Testing as Quality</strong> - Hard-to-test code = poor structure that needs refactoring.</li>
<li><strong>Naming (5-Second Rule)</strong> - Must understand what a view/component does in 5 seconds from its name.</li>
<li><strong>Namespacing</strong> - Always use <code>class Module::ClassName</code> pattern.</li>
<li><strong>Duplication > Complexity</strong> - Simple duplicated code is better than complex DRY abstractions.</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent kieran-rails-reviewer "Review the UserController"</code></pre>
</div>
</div>
<div class="agent-detail" id="dhh-rails-reviewer">
<div class="agent-detail-header">
<h3>dhh-rails-reviewer</h3>
<span class="agent-badge">Rails</span>
</div>
<p class="agent-detail-description">
What if DHH reviewed your Rails PR? He'd ask why you're building React inside Rails, why you need six layers of abstraction for a form, and whether you've forgotten that Rails already solved this problem. This agent channels that energy—blunt, opinionated, allergic to complexity.
</p>
<h4>Key Focus Areas</h4>
<ul>
<li>Identifies deviations from Rails conventions</li>
<li>Spots JavaScript framework patterns infiltrating Rails</li>
<li>Tears apart unnecessary abstractions</li>
<li>Challenges overengineering and microservices mentality</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent dhh-rails-reviewer</code></pre>
</div>
</div>
<div class="agent-detail" id="kieran-python-reviewer">
<div class="agent-detail-header">
<h3>kieran-python-reviewer</h3>
<span class="agent-badge">Python</span>
</div>
<p class="agent-detail-description">
Your Pythonic perfectionist who believes type hints aren't optional and <code>dict.get()</code> beats try/except KeyError. Expects modern Python 3.10+ patterns—no legacy syntax, no <code>typing.List</code> when <code>list</code> works natively. If your code looks like Java translated to Python, prepare for rewrites.
</p>
<h4>Key Focus Areas</h4>
<ul>
<li>Type hints for all functions</li>
<li>Pythonic patterns and idioms</li>
<li>Modern Python syntax</li>
<li>Import organization</li>
<li>Module extraction signals</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent kieran-python-reviewer</code></pre>
</div>
</div>
<div class="agent-detail" id="kieran-typescript-reviewer">
<div class="agent-detail-header">
<h3>kieran-typescript-reviewer</h3>
<span class="agent-badge">TypeScript</span>
</div>
<p class="agent-detail-description">
TypeScript's type system is a gift—don't throw it away with <code>any</code>. This reviewer treats <code>any</code> like a code smell that needs justification. Expects proper types, clean imports, and code that doesn't need comments because the types explain everything. You added TypeScript for safety; this agent makes sure you actually get it.
</p>
<h4>Key Focus Areas</h4>
<ul>
<li>No <code>any</code> without justification</li>
<li>Component/module extraction signals</li>
<li>Import organization</li>
<li>Modern TypeScript patterns</li>
<li>Testability assessment</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent kieran-typescript-reviewer</code></pre>
</div>
</div>
<div class="agent-detail" id="security-sentinel">
<div class="agent-detail-header">
<h3>security-sentinel</h3>
<span class="agent-badge critical">Security</span>
</div>
<p class="agent-detail-description">
Security vulnerabilities hide in boring code—the "just grab the user ID from params" line that ships a privilege escalation bug to production. This agent thinks like an attacker: SQL injection, XSS, auth bypass, leaked secrets. Run it before touching authentication, payments, or anything with PII. Your users' data depends on paranoia.
</p>
<h4>Security Checks</h4>
<ul>
<li>Input validation analysis</li>
<li>SQL injection risk assessment</li>
<li>XSS vulnerability detection</li>
<li>Authentication/authorization audit</li>
<li>Sensitive data exposure scanning</li>
<li>OWASP Top 10 compliance</li>
<li>Hardcoded secrets search</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent security-sentinel "Audit the payment flow"</code></pre>
</div>
</div>
<div class="agent-detail" id="performance-oracle">
<div class="agent-detail-header">
<h3>performance-oracle</h3>
<span class="agent-badge">Performance</span>
</div>
<p class="agent-detail-description">
Your code works fine with 10 users. What happens at 10,000? This agent time-travels to your future scaling problems—N+1 queries that murder your database, O(n²) algorithms hiding in loops, missing indexes, memory leaks. It thinks in Big O notation and asks uncomfortable questions about what breaks first when traffic spikes.
</p>
<h4>Analysis Areas</h4>
<ul>
<li>Algorithmic complexity (Big O notation)</li>
<li>N+1 query pattern detection</li>
<li>Proper index usage verification</li>
<li>Memory management review</li>
<li>Caching opportunity identification</li>
<li>Network usage optimization</li>
<li>Frontend bundle impact</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent performance-oracle</code></pre>
</div>
</div>
<div class="agent-detail" id="architecture-strategist">
<div class="agent-detail-header">
<h3>architecture-strategist</h3>
<span class="agent-badge">Architecture</span>
</div>
<p class="agent-detail-description">
Every "small change" either reinforces your architecture or starts eroding it. This agent zooms out to see if your fix actually fits the system's design—or if you're bolting duct tape onto a crumbling foundation. It speaks SOLID principles, microservice boundaries, and API contracts. Call it when you're about to make a change that "feels weird."
</p>
<h4>Analysis Areas</h4>
<ul>
<li>Overall system structure understanding</li>
<li>Change context within architecture</li>
<li>Architectural violation identification</li>
<li>SOLID principles compliance</li>
<li>Microservice boundary assessment</li>
<li>API contract evaluation</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent architecture-strategist</code></pre>
</div>
</div>
<div class="agent-detail" id="data-integrity-guardian">
<div class="agent-detail-header">
<h3>data-integrity-guardian</h3>
<span class="agent-badge critical">Data</span>
</div>
<p class="agent-detail-description">
Migrations can't be rolled back once they're run on production. This agent is your last line of defense before you accidentally drop a column with user data, create a race condition in transactions, or violate GDPR. It obsesses over referential integrity, rollback safety, and data constraints. Your database is forever; migrations should be paranoid.
</p>
<h4>Review Areas</h4>
<ul>
<li>Migration safety and reversibility</li>
<li>Data constraint validation</li>
<li>Transaction boundary review</li>
<li>Referential integrity preservation</li>
<li>Privacy compliance (GDPR, CCPA)</li>
<li>Data corruption scenario checking</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent data-integrity-guardian</code></pre>
</div>
</div>
<div class="agent-detail" id="pattern-recognition-specialist">
<div class="agent-detail-header">
<h3>pattern-recognition-specialist</h3>
<span class="agent-badge">Patterns</span>
</div>
<p class="agent-detail-description">
Patterns tell stories—Factory, Observer, God Object, Copy-Paste Programming. This agent reads your code like an archaeologist reading artifacts. It spots the good patterns (intentional design), the anti-patterns (accumulated tech debt), and the duplicated blocks you swore you'd refactor later. Runs tools like jscpd because humans miss repetition that machines catch instantly.
</p>
<h4>Detection Areas</h4>
<ul>
<li>Design patterns (Factory, Singleton, Observer, etc.)</li>
<li>Anti-patterns and code smells</li>
<li>TODO/FIXME comments</li>
<li>God objects and circular dependencies</li>
<li>Naming consistency</li>
<li>Code duplication</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent pattern-recognition-specialist</code></pre>
</div>
</div>
<div class="agent-detail" id="code-simplicity-reviewer">
<div class="agent-detail-header">
<h3>code-simplicity-reviewer</h3>
<span class="agent-badge">Quality</span>
</div>
<p class="agent-detail-description">
Simplicity is violent discipline. This agent asks "do you actually need this?" about every line, every abstraction, every dependency. YAGNI isn't a suggestion—it's the law. Your 200-line feature with three layers of indirection? This agent will show you the 50-line version that does the same thing. Complexity is a liability; simplicity compounds.
</p>
<h4>Simplification Checks</h4>
<ul>
<li>Analyze every line for necessity</li>
<li>Simplify complex logic</li>
<li>Remove redundancy and duplication</li>
<li>Challenge abstractions</li>
<li>Optimize for readability</li>
<li>Eliminate premature generalization</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent code-simplicity-reviewer</code></pre>
</div>
</div>
</section>
<!-- Research Agents -->
<section id="research-agents">
<h2><i class="fa-solid fa-microscope"></i> Research Agents (4)</h2>
<p>Stop guessing. These agents dig through documentation, GitHub repos, git history, and real-world examples to give you answers backed by evidence. They read faster than you, remember more than you, and synthesize patterns you'd miss. Perfect for "how should I actually do this?" questions.</p>
<div class="agent-detail" id="framework-docs-researcher">
<div class="agent-detail-header">
<h3>framework-docs-researcher</h3>
<span class="agent-badge">Research</span>
</div>
<p class="agent-detail-description">
Official docs are scattered. GitHub examples are inconsistent. Deprecations hide in changelogs. This agent pulls it all together—docs, source code, version constraints, real-world examples. Ask "how do I use Hotwire Turbo?" and get back patterns that actually work in production, not toy tutorials.
</p>
<h4>Capabilities</h4>
<ul>
<li>Fetch official framework and library documentation</li>
<li>Identify version-specific constraints and deprecations</li>
<li>Search GitHub for real-world usage examples</li>
<li>Analyze gem/library source code using <code>bundle show</code></li>
<li>Synthesize findings with practical examples</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent framework-docs-researcher "Research Hotwire Turbo patterns"</code></pre>
</div>
</div>
<div class="agent-detail" id="best-practices-researcher">
<div class="agent-detail-header">
<h3>best-practices-researcher</h3>
<span class="agent-badge">Research</span>
</div>
<p class="agent-detail-description">
"Best practices" are everywhere and contradictory. This agent cuts through the noise by evaluating sources (official docs, trusted blogs, real GitHub repos), checking recency, and synthesizing actionable guidance. You get code templates, patterns that scale, and answers you can trust—not StackOverflow copy-paste roulette.
</p>
<h4>Capabilities</h4>
<ul>
<li>Leverage multiple sources (Context7 MCP, web search, GitHub)</li>
<li>Evaluate information quality and recency</li>
<li>Synthesize into actionable guidance</li>
<li>Provide code examples and templates</li>
<li>Research issue templates and community engagement</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent best-practices-researcher "Find pagination patterns"</code></pre>
</div>
</div>
<div class="agent-detail" id="git-history-analyzer">
<div class="agent-detail-header">
<h3>git-history-analyzer</h3>
<span class="agent-badge">Git</span>
</div>
<p class="agent-detail-description">
Your codebase has a history—decisions, patterns, mistakes. This agent does archaeology with git tools: file evolution, blame analysis, contributor expertise mapping. Ask "why does this code exist?" and get the commit that explains it. Spot patterns in how bugs appear. Understand the design decisions buried in history.
</p>
<h4>Analysis Techniques</h4>
<ul>
<li>Trace file evolution using <code>git log --follow</code></li>
<li>Determine code origins using <code>git blame -w -C -C -C</code></li>
<li>Identify patterns from commit history</li>
<li>Map key contributors and expertise areas</li>
<li>Extract historical patterns of issues and fixes</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent git-history-analyzer "Analyze changes to User model"</code></pre>
</div>
</div>
<div class="agent-detail" id="repo-research-analyst">
<div class="agent-detail-header">
<h3>repo-research-analyst</h3>
<span class="agent-badge">Research</span>
</div>
<p class="agent-detail-description">
Every repo has conventions—some documented, most tribal knowledge. This agent reads ARCHITECTURE.md, issue templates, PR patterns, and actual code to reverse-engineer the standards. Perfect for joining a new project or ensuring your PR matches the team's implicit style. Finds the rules nobody wrote down.
</p>
<h4>Analysis Areas</h4>
<ul>
<li>Architecture and documentation files (ARCHITECTURE.md, README.md, CLAUDE.md)</li>
<li>GitHub issues for patterns and conventions</li>
<li>Issue/PR templates and guidelines</li>
<li>Implementation patterns using ast-grep or rg</li>
<li>Project-specific conventions</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent repo-research-analyst</code></pre>
</div>
</div>
</section>
<!-- Workflow Agents -->
<section id="workflow-agents">
<h2><i class="fa-solid fa-gears"></i> Workflow Agents (5)</h2>
<p>Tedious work you hate doing. These agents handle the grind—reproducing bugs, resolving PR comments, running linters, analyzing specs. They're fast, they don't complain, and they free you up to solve interesting problems instead of mechanical ones.</p>
<div class="agent-detail" id="bug-reproduction-validator">
<div class="agent-detail-header">
<h3>bug-reproduction-validator</h3>
<span class="agent-badge">Bugs</span>
</div>
<p class="agent-detail-description">
Half of bug reports aren't bugs—they're user errors, environment issues, or misunderstood features. This agent systematically reproduces the reported behavior, classifies what it finds (Confirmed, Can't Reproduce, Not a Bug, etc.), and assesses severity. Saves you from chasing ghosts or missing real issues.
</p>
<h4>Classification Types</h4>
<ul>
<li><strong>Confirmed</strong> - Bug reproduced successfully</li>
<li><strong>Cannot Reproduce</strong> - Unable to reproduce</li>
<li><strong>Not a Bug</strong> - Expected behavior</li>
<li><strong>Environmental</strong> - Environment-specific issue</li>
<li><strong>Data</strong> - Data-related issue</li>
<li><strong>User Error</strong> - User misunderstanding</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent bug-reproduction-validator</code></pre>
</div>
</div>
<div class="agent-detail" id="pr-comment-resolver">
<div class="agent-detail-header">
<h3>pr-comment-resolver</h3>
<span class="agent-badge">PR</span>
</div>
<p class="agent-detail-description">
Code review comments pile up. This agent reads them, plans fixes, implements changes, and reports back what it did. It doesn't argue with reviewers or skip hard feedback—it just resolves the work systematically. Great for burning through a dozen "change this variable name" comments in seconds.
</p>
<h4>Workflow</h4>
<ul>
<li>Analyze code review comments</li>
<li>Plan the resolution before implementation</li>
<li>Implement requested modifications</li>
<li>Verify resolution doesn't break functionality</li>
<li>Provide clear resolution reports</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent pr-comment-resolver</code></pre>
</div>
</div>
<div class="agent-detail" id="lint">
<div class="agent-detail-header">
<h3>lint</h3>
<span class="agent-badge">Quality</span>
</div>
<p class="agent-detail-description">
Linters are pedantic robots that enforce consistency. This agent runs StandardRB, ERBLint, and Brakeman for you—checking Ruby style, ERB templates, and security issues. It's fast (uses the Haiku model) and catches the formatting noise before CI does.
</p>
<h4>Tools Run</h4>
<ul>
<li><code>bundle exec standardrb</code> - Ruby file checking/fixing</li>
<li><code>bundle exec erblint --lint-all</code> - ERB templates</li>
<li><code>bin/brakeman</code> - Security scanning</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent lint</code></pre>
</div>
</div>
<div class="agent-detail" id="spec-flow-analyzer">
<div class="agent-detail-header">
<h3>spec-flow-analyzer</h3>
<span class="agent-badge">Testing</span>
</div>
<p class="agent-detail-description">
Specs always have gaps—edge cases nobody thought about, ambiguous requirements, missing error states. This agent maps all possible user flows, identifies what's unclear or missing, and generates the questions you need to ask stakeholders. Runs before you code to avoid building the wrong thing.
</p>
<h4>Analysis Areas</h4>
<ul>
<li>Map all possible user flows and permutations</li>
<li>Identify gaps, ambiguities, and missing specifications</li>
<li>Consider different user types, roles, permissions</li>
<li>Analyze error states and edge cases</li>
<li>Generate critical questions requiring clarification</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent spec-flow-analyzer</code></pre>
</div>
</div>
<div class="agent-detail" id="every-style-editor">
<div class="agent-detail-header">
<h3>every-style-editor</h3>
<span class="agent-badge">Content</span>
</div>
<p class="agent-detail-description">
Style guides are arbitrary rules that make writing consistent. This agent enforces Every's particular quirks—title case in headlines, no overused filler words ("actually," "very"), active voice, Oxford commas. It's a line-by-line grammar cop for content that needs to match the brand.
</p>
<h4>Style Checks</h4>
<ul>
<li>Title case in headlines, sentence case elsewhere</li>
<li>Company singular/plural usage</li>
<li>Remove overused words (actually, very, just)</li>
<li>Enforce active voice</li>
<li>Apply formatting rules (Oxford commas, em dashes)</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent every-style-editor</code></pre>
</div>
</div>
</section>
<!-- Design Agents -->
<section id="design-agents">
<h2><i class="fa-solid fa-palette"></i> Design Agents (3)</h2>
<p>Design is iteration. These agents take screenshots, compare them to Figma, make targeted improvements, and repeat. They fix spacing, alignment, colors, typography—the visual details that compound into polish. Perfect for closing the gap between "it works" and "it looks right."</p>
<div class="agent-detail" id="design-iterator">
<div class="agent-detail-header">
<h3>design-iterator</h3>
<span class="agent-badge">Design</span>
</div>
<p class="agent-detail-description">
Design doesn't happen in one pass. This agent runs a loop: screenshot the UI, analyze what's off (spacing, colors, alignment), implement 3-5 targeted fixes, repeat. Run it for 10 iterations and watch rough interfaces transform into polished designs through systematic refinement.
</p>
<h4>Process</h4>
<ul>
<li>Take focused screenshots of target elements</li>
<li>Analyze current state and identify 3-5 improvements</li>
<li>Implement targeted CSS/design changes</li>
<li>Document changes made</li>
<li>Repeat for specified iterations (default 10)</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent design-iterator</code></pre>
</div>
</div>
<div class="agent-detail" id="figma-design-sync">
<div class="agent-detail-header">
<h3>figma-design-sync</h3>
<span class="agent-badge">Figma</span>
</div>
<p class="agent-detail-description">
Designers hand you a Figma file. You build it. Then: "the spacing is wrong, the font is off, the colors don't match." This agent compares your implementation to the Figma spec, identifies every visual discrepancy, and fixes them automatically. Designers stay happy. You stay sane.
</p>
<h4>Workflow</h4>
<ul>
<li>Extract design specifications from Figma</li>
<li>Capture implementation screenshots</li>
<li>Conduct systematic visual comparison</li>
<li>Make precise code changes to fix discrepancies</li>
<li>Verify implementation matches design</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent figma-design-sync</code></pre>
</div>
</div>
<div class="agent-detail" id="design-implementation-reviewer">
<div class="agent-detail-header">
<h3>design-implementation-reviewer</h3>
<span class="agent-badge">Review</span>
</div>
<p class="agent-detail-description">
Before you ship UI changes, run this agent. It compares your implementation against Figma at a pixel level—layouts, typography, colors, spacing, responsive behavior. Uses the Opus model for detailed visual analysis. Catches the "close enough" mistakes that users notice but you don't.
</p>
<h4>Comparison Areas</h4>
<ul>
<li>Layouts and structure</li>
<li>Typography (fonts, sizes, weights)</li>
<li>Colors and themes</li>
<li>Spacing and alignment</li>
<li>Different viewport sizes</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent design-implementation-reviewer</code></pre>
</div>
</div>
</section>
<!-- Docs Agents -->
<section id="docs-agents">
<h2><i class="fa-solid fa-file-lines"></i> Documentation Agent (1)</h2>
<div class="agent-detail" id="ankane-readme-writer">
<div class="agent-detail-header">
<h3>ankane-readme-writer</h3>
<span class="agent-badge">Docs</span>
</div>
<p class="agent-detail-description">
Andrew Kane writes READMEs that are models of clarity—concise, scannable, zero fluff. This agent generates gem documentation in that style: 15 words max per sentence, imperative voice, single-purpose code examples. If your README rambles, this agent will fix it.
</p>
<h4>Section Order</h4>
<ol>
<li>Header (title + description)</li>
<li>Installation</li>
<li>Quick Start</li>
<li>Usage</li>
<li>Options</li>
<li>Upgrading</li>
<li>Contributing</li>
<li>License</li>
</ol>
<h4>Style Guidelines</h4>
<ul>
<li>Imperative voice throughout</li>
<li>15 words max per sentence</li>
<li>Single-purpose code fences</li>
<li>Up to 4 badges maximum</li>
<li>No HTML comments</li>
</ul>
<div class="card-code-block">
<pre><code>claude agent ankane-readme-writer</code></pre>
</div>
</div>
</section>
<!-- Navigation -->
<nav class="docs-nav-footer">
<a href="getting-started.html" class="nav-prev">
<span class="nav-label">Previous</span>
<span class="nav-title"><i class="fa-solid fa-arrow-left"></i> Getting Started</span>
</a>
<a href="commands.html" class="nav-next">
<span class="nav-label">Next</span>
<span class="nav-title">Commands <i class="fa-solid fa-arrow-right"></i></span>
</a>
</nav>
</article>
</main>
</div>
<script>
document.querySelector('[data-sidebar-toggle]')?.addEventListener('click', () => {
document.querySelector('.docs-sidebar').classList.toggle('open');
});
</script>
</body>
</html>

495
docs/pages/changelog.html Normal file
View File

@@ -0,0 +1,495 @@
<!DOCTYPE html>
<html lang="en" class="theme-dark">
<head>
<meta charset="utf-8" />
<title>Changelog - Compounding Engineering</title>
<meta content="Version history and release notes for the Compounding Engineering plugin." name="description" />
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />
<link href="../css/docs.css" rel="stylesheet" type="text/css" />
<script src="../js/main.js" type="text/javascript" defer></script>
</head>
<body>
<div class="background-gradient"></div>
<div class="docs-layout">
<aside class="docs-sidebar">
<div class="sidebar-header">
<a href="../index.html" class="nav-brand">
<span class="logo-icon"><i class="fa-solid fa-layer-group"></i></span>
<span class="logo-text">CE Docs</span>
</a>
</div>
<nav class="sidebar-nav">
<div class="nav-section">
<h3>Getting Started</h3>
<ul>
<li><a href="getting-started.html">Installation</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Reference</h3>
<ul>
<li><a href="agents.html">Agents (23)</a></li>
<li><a href="commands.html">Commands (13)</a></li>
<li><a href="skills.html">Skills (11)</a></li>
<li><a href="mcp-servers.html">MCP Servers (two)</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Resources</h3>
<ul>
<li><a href="changelog.html" class="active">Changelog</a></li>
</ul>
</div>
<div class="nav-section">
<h3>On This Page</h3>
<ul>
<li><a href="#v2.6.0">v2.6.0</a></li>
<li><a href="#v2.5.0">v2.5.0</a></li>
<li><a href="#v2.4.1">v2.4.1</a></li>
<li><a href="#v2.4.0">v2.4.0</a></li>
<li><a href="#v2.3.0">v2.3.0</a></li>
<li><a href="#v2.2.1">v2.2.1</a></li>
<li><a href="#v2.2.0">v2.2.0</a></li>
<li><a href="#v2.1.0">v2.1.0</a></li>
<li><a href="#v2.0.0">v2.0.0</a></li>
<li><a href="#v1.1.0">v1.1.0</a></li>
<li><a href="#v1.0.0">v1.0.0</a></li>
</ul>
</div>
</nav>
</aside>
<main class="docs-content">
<div class="docs-header">
<nav class="breadcrumb">
<a href="../index.html">Home</a>
<span>/</span>
<a href="getting-started.html">Docs</a>
<span>/</span>
<span>Changelog</span>
</nav>
<button class="mobile-menu-toggle" data-sidebar-toggle>
<i class="fa-solid fa-bars"></i>
</button>
</div>
<article class="docs-article">
<h1><i class="fa-solid fa-clock-rotate-left color-accent"></i> Changelog</h1>
<p class="lead">
All notable changes to the compounding-engineering plugin. This project follows
<a href="https://semver.org/">Semantic Versioning</a> and
<a href="https://keepachangelog.com/">Keep a Changelog</a> conventions.
</p>
<!-- Version 2.6.0 -->
<section id="v2.6.0" class="version-section">
<div class="version-header">
<h2>v2.6.0</h2>
<span class="version-date">2024-11-26</span>
</div>
<div class="changelog-category removed">
<h3><i class="fa-solid fa-minus"></i> Removed</h3>
<ul>
<li>
<strong><code>feedback-codifier</code> agent</strong> - Removed from workflow agents.
Agent count reduced from 24 to 23.
</li>
</ul>
</div>
</section>
<!-- Version 2.5.0 -->
<section id="v2.5.0" class="version-section">
<div class="version-header">
<h2>v2.5.0</h2>
<span class="version-date">2024-11-25</span>
</div>
<div class="changelog-category added">
<h3><i class="fa-solid fa-plus"></i> Added</h3>
<ul>
<li>
<strong><code>/report-bug</code> command</strong> - New slash command for reporting bugs in the
compounding-engineering plugin. Provides a structured workflow that gathers bug information
through guided questions, collects environment details automatically, and creates a GitHub
issue in the EveryInc/every-marketplace repository.
</li>
</ul>
</div>
</section>
<!-- Version 2.4.1 -->
<section id="v2.4.1" class="version-section">
<div class="version-header">
<h2>v2.4.1</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category improved">
<h3><i class="fa-solid fa-arrow-up"></i> Improved</h3>
<ul>
<li>
<strong>design-iterator agent</strong> - Added focused screenshot guidance: always capture
only the target element/area instead of full page screenshots. Includes browser_resize
recommendations, element-targeted screenshot workflow using browser_snapshot refs, and
explicit instruction to never use fullPage mode.
</li>
</ul>
</div>
</section>
<!-- Version 2.4.0 -->
<section id="v2.4.0" class="version-section">
<div class="version-header">
<h2>v2.4.0</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category fixed">
<h3><i class="fa-solid fa-bug"></i> Fixed</h3>
<ul>
<li>
<strong>MCP Configuration</strong> - Moved MCP servers back to <code>plugin.json</code>
following working examples from anthropics/life-sciences plugins.
</li>
<li>
<strong>Context7 URL</strong> - Updated to use HTTP type with correct endpoint URL.
</li>
</ul>
</div>
</section>
<!-- Version 2.3.0 -->
<section id="v2.3.0" class="version-section">
<div class="version-header">
<h2>v2.3.0</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category changed">
<h3><i class="fa-solid fa-arrows-rotate"></i> Changed</h3>
<ul>
<li>
<strong>MCP Configuration</strong> - Moved MCP servers from inline <code>plugin.json</code>
to separate <code>.mcp.json</code> file per Claude Code best practices.
</li>
</ul>
</div>
</section>
<!-- Version 2.2.1 -->
<section id="v2.2.1" class="version-section">
<div class="version-header">
<h2>v2.2.1</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category fixed">
<h3><i class="fa-solid fa-bug"></i> Fixed</h3>
<ul>
<li>
<strong>Playwright MCP Server</strong> - Added missing <code>"type": "stdio"</code> field
required for MCP server configuration to load properly.
</li>
</ul>
</div>
</section>
<!-- Version 2.2.0 -->
<section id="v2.2.0" class="version-section">
<div class="version-header">
<h2>v2.2.0</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category added">
<h3><i class="fa-solid fa-plus"></i> Added</h3>
<ul>
<li>
<strong>Context7 MCP Server</strong> - Bundled Context7 for instant framework documentation
lookup. Provides up-to-date docs for Rails, React, Next.js, and more than 100 other frameworks.
</li>
</ul>
</div>
</section>
<!-- Version 2.1.0 -->
<section id="v2.1.0" class="version-section">
<div class="version-header">
<h2>v2.1.0</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category added">
<h3><i class="fa-solid fa-plus"></i> Added</h3>
<ul>
<li>
<strong>Playwright MCP Server</strong> - Bundled <code>@playwright/mcp</code> for browser
automation across all projects. Provides screenshot, navigation, click, fill, and evaluate tools.
</li>
</ul>
</div>
<div class="changelog-category changed">
<h3><i class="fa-solid fa-arrows-rotate"></i> Changed</h3>
<ul>
<li>Replaced all Puppeteer references with Playwright across agents and commands:
<ul>
<li><code>bug-reproduction-validator</code> agent</li>
<li><code>design-iterator</code> agent</li>
<li><code>design-implementation-reviewer</code> agent</li>
<li><code>figma-design-sync</code> agent</li>
<li><code>generate_command</code> command</li>
</ul>
</li>
</ul>
</div>
</section>
<!-- Version 2.0.2 -->
<section id="v2.0.2" class="version-section">
<div class="version-header">
<h2>v2.0.2</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category changed">
<h3><i class="fa-solid fa-arrows-rotate"></i> Changed</h3>
<ul>
<li>
<strong>design-iterator agent</strong> - Updated description to emphasize proactive usage
when design work isn't coming together on first attempt.
</li>
</ul>
</div>
</section>
<!-- Version 2.0.1 -->
<section id="v2.0.1" class="version-section">
<div class="version-header">
<h2>v2.0.1</h2>
<span class="version-date">2024-11-24</span>
</div>
<div class="changelog-category added">
<h3><i class="fa-solid fa-plus"></i> Added</h3>
<ul>
<li><strong>CLAUDE.md</strong> - Project instructions with versioning requirements</li>
<li><strong>docs/solutions/plugin-versioning-requirements.md</strong> - Workflow documentation</li>
</ul>
</div>
</section>
<!-- Version 2.0.0 -->
<section id="v2.0.0" class="version-section">
<div class="version-header">
<h2>v2.0.0</h2>
<span class="version-date">2024-11-24</span>
<span class="version-badge major">Major Release</span>
</div>
<p class="version-description">
Major reorganization consolidating agents, commands, and skills from multiple sources into
a single, well-organized plugin.
</p>
<div class="changelog-category added">
<h3><i class="fa-solid fa-plus"></i> Added</h3>
<h4>New Agents (seven)</h4>
<ul>
<li><code>design-iterator</code> - Iteratively refine UI components through systematic design iterations</li>
<li><code>design-implementation-reviewer</code> - Verify UI implementations match Figma design specifications</li>
<li><code>figma-design-sync</code> - Synchronize web implementations with Figma designs</li>
<li><code>bug-reproduction-validator</code> - Systematically reproduce and validate bug reports</li>
<li><code>spec-flow-analyzer</code> - Analyze user flows and identify gaps in specifications</li>
<li><code>lint</code> - Run linting and code quality checks on Ruby and ERB files</li>
<li><code>ankane-readme-writer</code> - Create READMEs following Ankane-style template for Ruby gems</li>
</ul>
<h4>New Commands (nine)</h4>
<ul>
<li><code>/changelog</code> - Create engaging changelogs for recent merges</li>
<li><code>/plan_review</code> - Multi-agent plan review in parallel</li>
<li><code>/resolve_parallel</code> - Resolve TODO comments in parallel</li>
<li><code>/resolve_pr_parallel</code> - Resolve PR comments in parallel</li>
<li><code>/reproduce-bug</code> - Reproduce bugs using logs and console</li>
<li><code>/prime</code> - Prime/setup command</li>
<li><code>/create-agent-skill</code> - Create or edit Claude Code skills</li>
<li><code>/heal-skill</code> - Fix skill documentation issues</li>
<li><code>/codify</code> - Document solved problems for knowledge base</li>
</ul>
<h4>New Skills (10)</h4>
<ul>
<li><code>andrew-kane-gem-writer</code> - Write Ruby gems following Andrew Kane's patterns</li>
<li><code>codify-docs</code> - Capture solved problems as categorized documentation</li>
<li><code>create-agent-skills</code> - Expert guidance for creating Claude Code skills</li>
<li><code>dhh-ruby-style</code> - Write Ruby/Rails code in DHH's 37signals style</li>
<li><code>dspy-ruby</code> - Build type-safe LLM applications with DSPy.rb</li>
<li><code>every-style-editor</code> - Review copy for Every's style guide compliance</li>
<li><code>file-todos</code> - File-based todo tracking system</li>
<li><code>frontend-design</code> - Create production-grade frontend interfaces</li>
<li><code>git-worktree</code> - Manage Git worktrees for parallel development</li>
<li><code>skill-creator</code> - Guide for creating effective Claude Code skills</li>
</ul>
</div>
<div class="changelog-category changed">
<h3><i class="fa-solid fa-arrows-rotate"></i> Changed</h3>
<h4>Agents Reorganized by Category</h4>
<ul>
<li><code>review/</code> (10 agents) - Code quality, security, performance reviewers</li>
<li><code>research/</code> (four agents) - Documentation, patterns, history analysis</li>
<li><code>design/</code> (three agents) - UI/design review and iteration</li>
<li><code>workflow/</code> (six agents) - PR resolution, bug validation, linting</li>
<li><code>docs/</code> (one agent) - README generation</li>
</ul>
</div>
<div class="version-summary">
<h4>Summary</h4>
<table>
<thead>
<tr>
<th>Component</th>
<th>v1.1.0</th>
<th>v2.0.0</th>
<th>Change</th>
</tr>
</thead>
<tbody>
<tr>
<td>Agents</td>
<td>17</td>
<td>24</td>
<td class="positive">+7</td>
</tr>
<tr>
<td>Commands</td>
<td>6</td>
<td>15</td>
<td class="positive">+9</td>
</tr>
<tr>
<td>Skills</td>
<td>1</td>
<td>11</td>
<td class="positive">+10</td>
</tr>
</tbody>
</table>
</div>
</section>
<!-- Version 1.1.0 -->
<section id="v1.1.0" class="version-section">
<div class="version-header">
<h2>v1.1.0</h2>
<span class="version-date">2024-11-22</span>
</div>
<div class="changelog-category added">
<h3><i class="fa-solid fa-plus"></i> Added</h3>
<ul>
<li>
<strong>gemini-imagegen Skill</strong>
<ul>
<li>Text-to-image generation with Google's Gemini API</li>
<li>Image editing and manipulation</li>
<li>Multi-turn refinement via chat interface</li>
<li>Multiple reference image composition (up to 14 images)</li>
<li>Model support: <code>gemini-2.5-flash-image</code> and <code>gemini-3-pro-image-preview</code></li>
</ul>
</li>
</ul>
</div>
<div class="changelog-category fixed">
<h3><i class="fa-solid fa-bug"></i> Fixed</h3>
<ul>
<li>Corrected component counts in documentation (17 agents, not 15)</li>
</ul>
</div>
</section>
<!-- Version 1.0.0 -->
<section id="v1.0.0" class="version-section">
<div class="version-header">
<h2>v1.0.0</h2>
<span class="version-date">2024-10-09</span>
<span class="version-badge">Initial Release</span>
</div>
<p class="version-description">
Initial release of the compounding-engineering plugin.
</p>
<div class="changelog-category added">
<h3><i class="fa-solid fa-plus"></i> Added</h3>
<h4>17 Specialized Agents</h4>
<p><strong>Code Review (five)</strong></p>
<ul>
<li><code>kieran-rails-reviewer</code> - Rails code review with strict conventions</li>
<li><code>kieran-python-reviewer</code> - Python code review with quality standards</li>
<li><code>kieran-typescript-reviewer</code> - TypeScript code review</li>
<li><code>dhh-rails-reviewer</code> - Rails review from DHH's perspective</li>
<li><code>code-simplicity-reviewer</code> - Final pass for simplicity and minimalism</li>
</ul>
<p><strong>Analysis & Architecture (four)</strong></p>
<ul>
<li><code>architecture-strategist</code> - Architectural decisions and compliance</li>
<li><code>pattern-recognition-specialist</code> - Design pattern analysis</li>
<li><code>security-sentinel</code> - Security audits and vulnerability assessments</li>
<li><code>performance-oracle</code> - Performance analysis and optimization</li>
</ul>
<p><strong>Research (four)</strong></p>
<ul>
<li><code>framework-docs-researcher</code> - Framework documentation research</li>
<li><code>best-practices-researcher</code> - External best practices gathering</li>
<li><code>git-history-analyzer</code> - Git history and code evolution analysis</li>
<li><code>repo-research-analyst</code> - Repository structure and conventions</li>
</ul>
<p><strong>Workflow (three)</strong></p>
<ul>
<li><code>every-style-editor</code> - Every's style guide compliance</li>
<li><code>pr-comment-resolver</code> - PR comment resolution</li>
<li><code>feedback-codifier</code> - Feedback pattern codification</li>
</ul>
<h4>Six Slash Commands</h4>
<ul>
<li><code>/plan</code> - Create implementation plans</li>
<li><code>/review</code> - Comprehensive code reviews</li>
<li><code>/work</code> - Execute work items systematically</li>
<li><code>/triage</code> - Triage and prioritize issues</li>
<li><code>/resolve_todo_parallel</code> - Resolve TODOs in parallel</li>
<li><code>/generate_command</code> - Generate new slash commands</li>
</ul>
<h4>Infrastructure</h4>
<ul>
<li>MIT license</li>
<li>Plugin manifest (<code>plugin.json</code>)</li>
<li>Pre-configured permissions for Rails development</li>
</ul>
</div>
</section>
</article>
</main>
</div>
</body>
</html>

523
docs/pages/commands.html Normal file
View File

@@ -0,0 +1,523 @@
<!DOCTYPE html>
<html lang="en" class="theme-dark">
<head>
<meta charset="utf-8" />
<title>Command Reference - Compounding Engineering</title>
<meta content="Complete reference for all 16 slash commands in the Compounding Engineering plugin." name="description" />
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />
<link href="../css/docs.css" rel="stylesheet" type="text/css" />
<script src="../js/main.js" type="text/javascript" defer></script>
</head>
<body>
<div class="background-gradient"></div>
<div class="docs-layout">
<aside class="docs-sidebar">
<div class="sidebar-header">
<a href="../index.html" class="nav-brand">
<span class="logo-icon"><i class="fa-solid fa-layer-group"></i></span>
<span class="logo-text">CE Docs</span>
</a>
</div>
<nav class="sidebar-nav">
<div class="nav-section">
<h3>Getting Started</h3>
<ul>
<li><a href="getting-started.html">Installation</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Reference</h3>
<ul>
<li><a href="agents.html">Agents (23)</a></li>
<li><a href="commands.html" class="active">Commands (13)</a></li>
<li><a href="skills.html">Skills (11)</a></li>
<li><a href="mcp-servers.html">MCP Servers (two)</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Resources</h3>
<ul>
<li><a href="changelog.html">Changelog</a></li>
</ul>
</div>
<div class="nav-section">
<h3>On This Page</h3>
<ul>
<li><a href="#workflow-commands">Workflow (four)</a></li>
<li><a href="#utility-commands">Utility (12)</a></li>
</ul>
</div>
</nav>
</aside>
<main class="docs-content">
<div class="docs-header">
<nav class="breadcrumb">
<a href="../index.html">Home</a>
<span>/</span>
<a href="getting-started.html">Docs</a>
<span>/</span>
<span>Commands</span>
</nav>
<button class="mobile-menu-toggle" data-sidebar-toggle>
<i class="fa-solid fa-bars"></i>
</button>
</div>
<article class="docs-article">
<h1><i class="fa-solid fa-terminal color-accent"></i> Command Reference</h1>
<p class="lead">
Here's the thing about slash commands: they're workflows you'd spend 20 minutes doing manually, compressed into one line. Type <code>/plan</code> and watch three agents launch in parallel to research your codebase while you grab coffee. That's the point—automation that actually saves time, not busywork dressed up as productivity.
</p>
<!-- Workflow Commands -->
<section id="workflow-commands">
<h2><i class="fa-solid fa-arrows-spin"></i> Workflow Commands (four)</h2>
<p>These are the big four: Plan your feature, Review your code, Work through the implementation, and Codify what you learned. Every professional developer does this cycle—these commands just make you faster at it.</p>
<div class="command-detail" id="workflows-plan">
<div class="command-detail-header">
<code class="command-detail-name">/plan</code>
</div>
<p class="command-detail-description">
You've got a feature request and a blank page. This command turns "we need OAuth" into a structured plan that actually tells you what to build—researched, reviewed, and ready to execute.
</p>
<h4>Arguments</h4>
<p><code>[feature description, bug report, or improvement idea]</code></p>
<h4>Workflow</h4>
<ol>
<li><strong>Repository Research (Parallel)</strong> - Launch three agents simultaneously:
<ul>
<li><code>repo-research-analyst</code> - Project patterns</li>
<li><code>best-practices-researcher</code> - Industry standards</li>
<li><code>framework-docs-researcher</code> - Framework documentation</li>
</ul>
</li>
<li><strong>SpecFlow Analysis</strong> - Run <code>spec-flow-analyzer</code> for user flows</li>
<li><strong>Choose Detail Level</strong>:
<ul>
<li><strong>MINIMAL</strong> - Simple bugs/small improvements</li>
<li><strong>MORE</strong> - Standard features</li>
<li><strong>A LOT</strong> - Major features with phases</li>
</ul>
</li>
<li><strong>Write Plan</strong> - Save as <code>plans/&lt;issue_title&gt;.md</code></li>
<li><strong>Review</strong> - Call <code>/plan_review</code> for multi-agent feedback</li>
</ol>
<div class="callout callout-info">
<div class="callout-icon"><i class="fa-solid fa-circle-info"></i></div>
<div class="callout-content">
<p>This command does NOT write code. It only researches and creates the plan.</p>
</div>
</div>
<div class="card-code-block">
<pre><code>/plan Add OAuth integration for third-party auth
/plan Fix N+1 query in user dashboard</code></pre>
</div>
</div>
<div class="command-detail" id="workflows-review">
<div class="command-detail-header">
<code class="command-detail-name">/review</code>
</div>
<p class="command-detail-description">
Twelve specialized reviewers examine your PR in parallel—security, performance, architecture, patterns. It's like code review by committee, except the committee finishes in two minutes instead of two days.
</p>
<h4>Arguments</h4>
<p><code>[PR number, GitHub URL, branch name, or "latest"]</code></p>
<h4>Workflow</h4>
<ol>
<li><strong>Setup</strong> - Detect review target, optionally use git-worktree for isolation</li>
<li><strong>Launch 12 Parallel Review Agents</strong>:
<ul>
<li><code>kieran-rails-reviewer</code>, <code>dhh-rails-reviewer</code></li>
<li><code>security-sentinel</code>, <code>performance-oracle</code></li>
<li><code>architecture-strategist</code>, <code>data-integrity-guardian</code></li>
<li><code>pattern-recognition-specialist</code>, <code>git-history-analyzer</code></li>
<li>And more...</li>
</ul>
</li>
<li><strong>Ultra-Thinking Analysis</strong> - Stakeholder perspectives, scenario exploration</li>
<li><strong>Simplification Review</strong> - Run <code>code-simplicity-reviewer</code></li>
<li><strong>Synthesize Findings</strong> - Categorize by severity (P1/P2/P3)</li>
<li><strong>Create Todo Files</strong> - Using file-todos skill for all findings</li>
</ol>
<div class="callout callout-warning">
<div class="callout-icon"><i class="fa-solid fa-triangle-exclamation"></i></div>
<div class="callout-content">
<p><strong>P1 (Critical) findings BLOCK MERGE.</strong> Address these before merging.</p>
</div>
</div>
<div class="card-code-block">
<pre><code>/review 42
/review https://github.com/owner/repo/pull/42
/review feature-branch-name
/review latest</code></pre>
</div>
</div>
<div class="command-detail" id="workflows-work">
<div class="command-detail-header">
<code class="command-detail-name">/work</code>
</div>
<p class="command-detail-description">
Point this at a plan file and watch it execute—reading requirements, setting up environment, running tests, creating commits, opening PRs. It's the "just build the thing" button you wish you always had.
</p>
<h4>Arguments</h4>
<p><code>[plan file, specification, or todo file path]</code></p>
<h4>Phases</h4>
<ol>
<li><strong>Quick Start</strong>
<ul>
<li>Read plan & clarify requirements</li>
<li>Setup environment (live or worktree)</li>
<li>Create TodoWrite task list</li>
</ul>
</li>
<li><strong>Execute</strong>
<ul>
<li>Task execution loop with progress tracking</li>
<li>Follow existing patterns</li>
<li>Test continuously</li>
<li>Figma sync if applicable</li>
</ul>
</li>
<li><strong>Quality Check</strong>
<ul>
<li>Run test suite</li>
<li>Run linting</li>
<li>Optional reviewer agents for complex changes</li>
</ul>
</li>
<li><strong>Ship It</strong>
<ul>
<li>Create commit with conventional format</li>
<li>Create pull request</li>
<li>Notify with summary</li>
</ul>
</li>
</ol>
<div class="card-code-block">
<pre><code>/work plans/user-authentication.md
/work todos/042-ready-p1-performance-issue.md</code></pre>
</div>
</div>
<div class="command-detail" id="workflows-compound">
<div class="command-detail-header">
<code class="command-detail-name">/compound</code>
</div>
<p class="command-detail-description">
Just fixed a gnarly bug? This captures the solution before you forget it. Seven agents analyze what you did, why it worked, and how to prevent it next time. Each documented solution compounds your team's knowledge.
</p>
<h4>Arguments</h4>
<p><code>[optional: brief context about the fix]</code></p>
<h4>Workflow</h4>
<ol>
<li><strong>Preconditions</strong> - Verify problem is solved and verified working</li>
<li><strong>Launch seven parallel subagents</strong>:
<ul>
<li>Context Analyzer - Extract YAML frontmatter skeleton</li>
<li>Solution Extractor - Identify root cause and solution</li>
<li>Related Docs Finder - Find cross-references</li>
<li>Prevention Strategist - Develop prevention strategies</li>
<li>Category Classifier - Determine docs category</li>
<li>Documentation Writer - Create the file</li>
<li>Optional Specialized Agent - Based on problem type</li>
</ul>
</li>
<li><strong>Create Documentation</strong> - File in <code>docs/solutions/[category]/</code></li>
</ol>
<h4>Auto-Triggers</h4>
<p>Phrases: "that worked", "it's fixed", "working now", "problem solved"</p>
<div class="card-code-block">
<pre><code>/compound
/compound N+1 query optimization</code></pre>
</div>
</div>
</section>
<!-- Utility Commands -->
<section id="utility-commands">
<h2><i class="fa-solid fa-wrench"></i> Utility Commands (12)</h2>
<p>The supporting cast—commands that do one specific thing really well. Generate changelogs, resolve todos in parallel, triage findings, create new commands. The utilities you reach for daily.</p>
<div class="command-detail" id="changelog">
<div class="command-detail-header">
<code class="command-detail-name">/changelog</code>
</div>
<p class="command-detail-description">
Turn your git history into a changelog people actually want to read. Breaking changes at the top, fun facts at the bottom, everything organized by what matters to your users.
</p>
<h4>Arguments</h4>
<p><code>[optional: daily|weekly, or time period in days]</code></p>
<h4>Output Sections</h4>
<ul>
<li>Breaking Changes (top priority)</li>
<li>New Features</li>
<li>Bug Fixes</li>
<li>Other Improvements</li>
<li>Shoutouts</li>
<li>Fun Fact</li>
</ul>
<div class="card-code-block">
<pre><code>/changelog daily
/changelog weekly
/changelog 7</code></pre>
</div>
</div>
<div class="command-detail" id="create-agent-skill">
<div class="command-detail-header">
<code class="command-detail-name">/create-agent-skill</code>
</div>
<p class="command-detail-description">
Need a new skill? This walks you through creating one that actually works—proper frontmatter, clear documentation, all the conventions baked in. Think of it as scaffolding for skills.
</p>
<h4>Arguments</h4>
<p><code>[skill description or requirements]</code></p>
<div class="card-code-block">
<pre><code>/create-agent-skill PDF processing for document analysis
/create-agent-skill Web scraping with error handling</code></pre>
</div>
</div>
<div class="command-detail" id="generate-command">
<div class="command-detail-header">
<code class="command-detail-name">/generate_command</code>
</div>
<p class="command-detail-description">
Same idea, but for commands instead of skills. Tell it what workflow you're tired of doing manually, and it generates a proper slash command with all the right patterns.
</p>
<h4>Arguments</h4>
<p><code>[command purpose and requirements]</code></p>
<div class="card-code-block">
<pre><code>/generate_command Security audit for codebase
/generate_command Automated performance testing</code></pre>
</div>
</div>
<div class="command-detail" id="heal-skill">
<div class="command-detail-header">
<code class="command-detail-name">/heal-skill</code>
</div>
<p class="command-detail-description">
Skills drift—APIs change, URLs break, parameters get renamed. When a skill stops working, this figures out what's wrong and fixes the documentation. You approve the changes before anything commits.
</p>
<h4>Arguments</h4>
<p><code>[optional: specific issue to fix]</code></p>
<h4>Approval Options</h4>
<ol>
<li>Apply and commit</li>
<li>Apply without commit</li>
<li>Revise changes</li>
<li>Cancel</li>
</ol>
<div class="card-code-block">
<pre><code>/heal-skill API endpoint URL changed
/heal-skill parameter validation error</code></pre>
</div>
</div>
<div class="command-detail" id="plan-review">
<div class="command-detail-header">
<code class="command-detail-name">/plan_review</code>
</div>
<p class="command-detail-description">
Before you execute a plan, have three reviewers tear it apart—Rails conventions, best practices, simplicity. Better to find the problems in the plan than in production.
</p>
<h4>Arguments</h4>
<p><code>[plan file path or plan content]</code></p>
<h4>Review Agents</h4>
<ul>
<li><code>dhh-rails-reviewer</code> - Rails conventions</li>
<li><code>kieran-rails-reviewer</code> - Rails best practices</li>
<li><code>code-simplicity-reviewer</code> - Simplicity and clarity</li>
</ul>
<div class="card-code-block">
<pre><code>/plan_review plans/user-authentication.md</code></pre>
</div>
</div>
<div class="command-detail" id="report-bug">
<div class="command-detail-header">
<code class="command-detail-name">/report-bug</code>
</div>
<p class="command-detail-description">
Something broken? This collects all the context—what broke, what you expected, error messages, environment—and files a proper bug report. No more "it doesn't work" issues.
</p>
<h4>Arguments</h4>
<p><code>[optional: brief description of the bug]</code></p>
<h4>Information Collected</h4>
<ul>
<li>Bug category (Agent/Command/Skill/MCP/Installation)</li>
<li>Specific component name</li>
<li>Actual vs expected behavior</li>
<li>Steps to reproduce</li>
<li>Error messages</li>
<li>Environment info (auto-gathered)</li>
</ul>
<div class="card-code-block">
<pre><code>/report-bug Agent not working
/report-bug Command failing with timeout</code></pre>
</div>
</div>
<div class="command-detail" id="reproduce-bug">
<div class="command-detail-header">
<code class="command-detail-name">/reproduce-bug</code>
</div>
<p class="command-detail-description">
Give it a GitHub issue number and it tries to actually reproduce the bug—reading the issue, analyzing code paths, iterating until it finds the root cause. Then it posts findings back to the issue.
</p>
<h4>Arguments</h4>
<p><code>[GitHub issue number]</code></p>
<h4>Investigation Process</h4>
<ol>
<li>Read GitHub issue details</li>
<li>Launch parallel investigation agents</li>
<li>Analyze code for failure points</li>
<li>Iterate until root cause found</li>
<li>Post findings to GitHub issue</li>
</ol>
<div class="card-code-block">
<pre><code>/reproduce-bug 142</code></pre>
</div>
</div>
<div class="command-detail" id="triage">
<div class="command-detail-header">
<code class="command-detail-name">/triage</code>
</div>
<p class="command-detail-description">
Got a pile of code review findings or security audit results? This turns them into actionable todos—one at a time, you decide: create the todo, skip it, or modify and re-present.
</p>
<h4>Arguments</h4>
<p><code>[findings list or source type]</code></p>
<h4>User Decisions</h4>
<ul>
<li><strong>"yes"</strong> - Create/update todo file, change status to ready</li>
<li><strong>"next"</strong> - Skip and delete from todos</li>
<li><strong>"custom"</strong> - Modify and re-present</li>
</ul>
<div class="callout callout-info">
<div class="callout-icon"><i class="fa-solid fa-circle-info"></i></div>
<div class="callout-content">
<p>This command does NOT write code. It only categorizes and creates todo files.</p>
</div>
</div>
<div class="card-code-block">
<pre><code>/triage code-review-findings.txt
/triage security-audit-results</code></pre>
</div>
</div>
<div class="command-detail" id="resolve-parallel">
<div class="command-detail-header">
<code class="command-detail-name">/resolve_parallel</code>
</div>
<p class="command-detail-description">
All those TODO comments scattered through your codebase? This finds them, builds a dependency graph, and spawns parallel agents to resolve them all at once. Clears the backlog in minutes.
</p>
<h4>Arguments</h4>
<p><code>[optional: specific TODO pattern or file]</code></p>
<h4>Process</h4>
<ol>
<li>Analyze TODO comments from codebase</li>
<li>Create dependency graph (mermaid diagram)</li>
<li>Spawn parallel <code>pr-comment-resolver</code> agents</li>
<li>Commit and push after completion</li>
</ol>
<div class="card-code-block">
<pre><code>/resolve_parallel
/resolve_parallel authentication
/resolve_parallel src/auth/</code></pre>
</div>
</div>
<div class="command-detail" id="resolve-pr-parallel">
<div class="command-detail-header">
<code class="command-detail-name">/resolve_pr_parallel</code>
</div>
<p class="command-detail-description">
Same deal, but for PR review comments. Fetch unresolved threads, spawn parallel resolver agents, commit the fixes, and mark threads as resolved. Your reviewers will wonder how you're so fast.
</p>
<h4>Arguments</h4>
<p><code>[optional: PR number or current PR]</code></p>
<h4>Process</h4>
<ol>
<li>Get all unresolved PR comments</li>
<li>Create TodoWrite list</li>
<li>Launch parallel <code>pr-comment-resolver</code> agents</li>
<li>Commit, resolve threads, and push</li>
</ol>
<div class="card-code-block">
<pre><code>/resolve_pr_parallel
/resolve_pr_parallel 123</code></pre>
</div>
</div>
<div class="command-detail" id="resolve-todo-parallel">
<div class="command-detail-header">
<code class="command-detail-name">/resolve_todo_parallel</code>
</div>
<p class="command-detail-description">
Those todo files in your <code>/todos</code> directory? Point this at them and watch parallel agents knock them out—analyzing dependencies, executing in the right order, marking resolved as they finish.
</p>
<h4>Arguments</h4>
<p><code>[optional: specific todo ID or pattern]</code></p>
<h4>Process</h4>
<ol>
<li>Get unresolved TODOs from <code>/todos/*.md</code></li>
<li>Analyze dependencies</li>
<li>Spawn parallel agents</li>
<li>Commit, mark as resolved, push</li>
</ol>
<div class="card-code-block">
<pre><code>/resolve_todo_parallel
/resolve_todo_parallel 042
/resolve_todo_parallel p1</code></pre>
</div>
</div>
<div class="command-detail" id="prime">
<div class="command-detail-header">
<code class="command-detail-name">/prime</code>
</div>
<p class="command-detail-description">
Your project initialization command. What exactly it does depends on your project setup—think of it as the "get everything ready" button before you start coding.
</p>
<div class="card-code-block">
<pre><code>/prime</code></pre>
</div>
</div>
</section>
<!-- Navigation -->
<nav class="docs-nav-footer">
<a href="agents.html" class="nav-prev">
<span class="nav-label">Previous</span>
<span class="nav-title"><i class="fa-solid fa-arrow-left"></i> Agents</span>
</a>
<a href="skills.html" class="nav-next">
<span class="nav-label">Next</span>
<span class="nav-title">Skills <i class="fa-solid fa-arrow-right"></i></span>
</a>
</nav>
</article>
</main>
</div>
<script>
document.querySelector('[data-sidebar-toggle]')?.addEventListener('click', () => {
document.querySelector('.docs-sidebar').classList.toggle('open');
});
</script>
</body>
</html>

View File

@@ -0,0 +1,582 @@
<!DOCTYPE html>
<html lang="en" class="theme-dark">
<head>
<meta charset="utf-8" />
<title>Getting Started - Compounding Engineering</title>
<meta content="Complete guide to installing and using the Compounding Engineering plugin for Claude Code." name="description" />
<meta content="width=device-width, initial-scale=1" name="viewport" />
<!-- Styles -->
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />
<link href="../css/docs.css" rel="stylesheet" type="text/css" />
<script src="../js/main.js" type="text/javascript" defer></script>
</head>
<body>
<div class="background-gradient"></div>
<div class="docs-layout">
<!-- Sidebar -->
<aside class="docs-sidebar">
<div class="sidebar-header">
<a href="../index.html" class="nav-brand">
<span class="logo-icon"><i class="fa-solid fa-layer-group"></i></span>
<span class="logo-text">CE Docs</span>
</a>
</div>
<nav class="sidebar-nav">
<div class="nav-section">
<h3>Getting Started</h3>
<ul>
<li><a href="#installation" class="active">Installation</a></li>
<li><a href="#quick-start">Quick Start</a></li>
<li><a href="#configuration">Configuration</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Core Concepts</h3>
<ul>
<li><a href="#philosophy">Philosophy</a></li>
<li><a href="#agents">Using Agents</a></li>
<li><a href="#commands">Using Commands</a></li>
<li><a href="#skills">Using Skills</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Guides</h3>
<ul>
<li><a href="#code-review">Code Review Workflow</a></li>
<li><a href="#creating-agents">Creating Custom Agents</a></li>
<li><a href="#creating-skills">Creating Custom Skills</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Reference</h3>
<ul>
<li><a href="agents.html">Agent Reference</a></li>
<li><a href="commands.html">Command Reference</a></li>
<li><a href="skills.html">Skill Reference</a></li>
<li><a href="mcp-servers.html">MCP Servers</a></li>
<li><a href="changelog.html">Changelog</a></li>
</ul>
</div>
</nav>
</aside>
<!-- Main Content -->
<main class="docs-content">
<div class="docs-header">
<nav class="breadcrumb">
<a href="../index.html">Home</a>
<span>/</span>
<span>Getting Started</span>
</nav>
<button class="mobile-menu-toggle" data-sidebar-toggle>
<i class="fa-solid fa-bars"></i>
</button>
</div>
<article class="docs-article">
<h1>Getting Started with Compounding Engineering</h1>
<p class="lead">
Five minutes from now, you'll run a single command that spins up 10 AI agents—each with a different specialty—to review your pull request in parallel. Security, performance, architecture, accessibility, all happening at once. That's the plugin. Let's get you set up.
</p>
<!-- Installation Section -->
<section id="installation">
<h2><i class="fa-solid fa-download"></i> Installation</h2>
<h3>Prerequisites</h3>
<ul>
<li><a href="https://claude.ai/claude-code" target="_blank">Claude Code</a> installed and configured</li>
<li>A GitHub account (for marketplace access)</li>
<li>Node.js 18+ (for MCP servers)</li>
</ul>
<h3>Step 1: Add the Marketplace</h3>
<p>Think of the marketplace as an app store. You're adding it to Claude Code's list of places to look for plugins:</p>
<div class="card-code-block">
<pre><code>claude /plugin marketplace add https://github.com/EveryInc/every-marketplace</code></pre>
</div>
<h3>Step 2: Install the Plugin</h3>
<p>Now grab the plugin itself:</p>
<div class="card-code-block">
<pre><code>claude /plugin install compounding-engineering</code></pre>
</div>
<h3>Step 3: Verify Installation</h3>
<p>Check that it worked:</p>
<div class="card-code-block">
<pre><code>claude /plugin list</code></pre>
</div>
<p>You'll see <code>compounding-engineering</code> in the list. If you do, you're ready.</p>
<div class="callout callout-info">
<div class="callout-icon"><i class="fa-solid fa-circle-info"></i></div>
<div class="callout-content">
<h4>Known Issue: MCP Servers</h4>
<p>
The bundled MCP servers (Playwright for browser automation, Context7 for docs) don't always auto-load. If you need them, there's a manual config step below. Otherwise, ignore this—everything else works fine.
</p>
</div>
</div>
</section>
<!-- Quick Start Section -->
<section id="quick-start">
<h2><i class="fa-solid fa-rocket"></i> Quick Start</h2>
<p>Let's see what this thing can actually do. I'll show you three workflows you'll use constantly:</p>
<h3>Run a Code Review</h3>
<p>This is the big one. Type <code>/review</code> and watch it spawn 10+ specialized reviewers:</p>
<div class="card-code-block">
<pre><code># Review a PR by number
/review 123
# Review the current branch
/review
# Review a specific branch
/review feature/my-feature</code></pre>
</div>
<h3>Use a Specialized Agent</h3>
<p>Sometimes you just need one expert. Call them directly:</p>
<div class="card-code-block">
<pre><code># Rails code review with Kieran's conventions
claude agent kieran-rails-reviewer "Review the UserController"
# Security audit
claude agent security-sentinel "Audit authentication flow"
# Research best practices
claude agent best-practices-researcher "Find pagination patterns for Rails"</code></pre>
</div>
<h3>Invoke a Skill</h3>
<p>Skills are like loading a reference book into Claude's brain. When you need deep knowledge in a specific domain:</p>
<div class="card-code-block">
<pre><code># Generate images with Gemini
skill: gemini-imagegen
# Write Ruby in DHH's style
skill: dhh-ruby-style
# Create a new Claude Code skill
skill: create-agent-skills</code></pre>
</div>
</section>
<!-- Configuration Section -->
<section id="configuration">
<h2><i class="fa-solid fa-gear"></i> Configuration</h2>
<h3 id="mcp-configuration">MCP Server Configuration</h3>
<p>
If the MCP servers didn't load automatically, paste this into <code>.claude/settings.json</code>:
</p>
<div class="card-code-block">
<pre><code>{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"env": {}
},
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
}
}
}</code></pre>
</div>
<h3>Environment Variables</h3>
<p>Right now, only one skill needs an API key. If you use Gemini's image generation:</p>
<table class="docs-table">
<thead>
<tr>
<th>Variable</th>
<th>Required For</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>GEMINI_API_KEY</code></td>
<td>gemini-imagegen</td>
<td>Google Gemini API key for image generation</td>
</tr>
</tbody>
</table>
</section>
<!-- Philosophy Section -->
<section id="philosophy">
<h2><i class="fa-solid fa-lightbulb"></i> The Compounding Engineering Philosophy</h2>
<blockquote class="highlight-quote">
Every unit of engineering work should make subsequent units of work easier&mdash;not harder.
</blockquote>
<p>Here's how it works in practice—the four-step loop you'll run over and over:</p>
<div class="philosophy-grid">
<div class="philosophy-card">
<div class="philosophy-icon"><i class="fa-solid fa-brain"></i></div>
<h4>1. Plan</h4>
<p>
Before you write a single line, figure out what you're building and why. Use research agents to gather examples, patterns, and context. Think of it as Google Search meets expert consultation.
</p>
</div>
<div class="philosophy-card">
<div class="philosophy-icon"><i class="fa-solid fa-robot"></i></div>
<h4>2. Delegate</h4>
<p>
Now build it—with help. Each agent specializes in something (Rails, security, design). You stay in the driver's seat, but you've got a team of specialists riding shotgun.
</p>
</div>
<div class="philosophy-card">
<div class="philosophy-icon"><i class="fa-solid fa-magnifying-glass"></i></div>
<h4>3. Assess</h4>
<p>
Before you ship, run the gauntlet. Security agent checks for vulnerabilities. Performance agent flags N+1 queries. Architecture agent questions your design choices. All at once, all in parallel.
</p>
</div>
<div class="philosophy-card">
<div class="philosophy-icon"><i class="fa-solid fa-book"></i></div>
<h4>4. Codify</h4>
<p>
You just solved a problem. Write it down. Next time you (or your teammate) face this, you'll have a runbook. That's the "compounding" part—each solution makes the next one faster.
</p>
</div>
</div>
</section>
<!-- Using Agents Section -->
<section id="agents">
<h2><i class="fa-solid fa-users-gear"></i> Using Agents</h2>
<p>
Think of agents as coworkers with different job titles. You wouldn't ask your security engineer to design your UI, right? Same concept here—each agent has a specialty, and you call the one you need.
</p>
<h3>Invoking Agents</h3>
<div class="card-code-block">
<pre><code># Basic syntax
claude agent [agent-name] "[optional message]"
# Examples
claude agent kieran-rails-reviewer
claude agent security-sentinel "Audit the payment flow"
claude agent git-history-analyzer "Show changes to user model"</code></pre>
</div>
<h3>Agent Categories</h3>
<table class="docs-table">
<thead>
<tr>
<th>Category</th>
<th>Count</th>
<th>Purpose</th>
</tr>
</thead>
<tbody>
<tr>
<td>Review</td>
<td>10</td>
<td>Code review, security audits, performance analysis</td>
</tr>
<tr>
<td>Research</td>
<td>four</td>
<td>Best practices, documentation, git history</td>
</tr>
<tr>
<td>Design</td>
<td>three</td>
<td>UI iteration, Figma sync, design review</td>
</tr>
<tr>
<td>Workflow</td>
<td>five</td>
<td>Bug reproduction, PR resolution, linting</td>
</tr>
<tr>
<td>Docs</td>
<td>one</td>
<td>README generation</td>
</tr>
</tbody>
</table>
<p>
<a href="agents.html" class="button secondary">
<i class="fa-solid fa-arrow-right"></i> View All Agents
</a>
</p>
</section>
<!-- Using Commands Section -->
<section id="commands">
<h2><i class="fa-solid fa-terminal"></i> Using Commands</h2>
<p>
Commands are macros that run entire workflows for you. One command can spin up a dozen agents, coordinate their work, collect results, and hand you a summary. It's automation all the way down.
</p>
<h3>Running Commands</h3>
<div class="card-code-block">
<pre><code># Workflow commands
/plan
/review 123
/work
/compound
# Utility commands
/changelog
/triage
/reproduce-bug</code></pre>
</div>
<h3>The Review Workflow</h3>
<p>Let me show you what happens when you run <code>/review</code>. Here's the sequence:</p>
<ol>
<li><strong>Detection</strong> - Figures out what you want reviewed (PR number, branch name, or current changes)</li>
<li><strong>Isolation</strong> - Spins up a git worktree so the review doesn't mess with your working directory</li>
<li><strong>Parallel execution</strong> - Launches 10+ agents simultaneously (security, performance, architecture, accessibility...)</li>
<li><strong>Synthesis</strong> - Sorts findings by severity (P1 = blocks merge, P2 = should fix, P3 = nice-to-have)</li>
<li><strong>Persistence</strong> - Creates todo files so you don't lose track of issues</li>
<li><strong>Summary</strong> - Hands you a readable report with action items</li>
</ol>
<p>
<a href="commands.html" class="button secondary">
<i class="fa-solid fa-arrow-right"></i> View All Commands
</a>
</p>
</section>
<!-- Using Skills Section -->
<section id="skills">
<h2><i class="fa-solid fa-wand-magic-sparkles"></i> Using Skills</h2>
<p>
Here's the difference: agents are <em>who</em> does the work, skills are <em>what they know</em>. When you invoke a skill, you're loading a reference library into Claude's context—patterns, templates, examples, workflows. It's like handing Claude a technical manual.
</p>
<h3>Invoking Skills</h3>
<div class="card-code-block">
<pre><code># In your prompt, reference the skill
skill: gemini-imagegen
# Or ask Claude to use it
"Use the dhh-ruby-style skill to refactor this code"</code></pre>
</div>
<h3>Skill Structure</h3>
<p>Peek inside a skill directory and you'll usually find:</p>
<ul>
<li><strong>SKILL.md</strong> - The main instructions (what Claude reads first)</li>
<li><strong>references/</strong> - Deep dives on concepts and patterns</li>
<li><strong>templates/</strong> - Copy-paste code snippets</li>
<li><strong>workflows/</strong> - Step-by-step "how to" guides</li>
<li><strong>scripts/</strong> - Actual executable code (when words aren't enough)</li>
</ul>
<p>
<a href="skills.html" class="button secondary">
<i class="fa-solid fa-arrow-right"></i> View All Skills
</a>
</p>
</section>
<!-- Code Review Workflow Guide -->
<section id="code-review">
<h2><i class="fa-solid fa-code-pull-request"></i> Code Review Workflow Guide</h2>
<p>
You'll spend most of your time here. This workflow is why the plugin exists—to turn code review from a bottleneck into a superpower.
</p>
<h3>Basic Review</h3>
<div class="card-code-block">
<pre><code># Review a PR
/review 123
# Review current branch
/review</code></pre>
</div>
<h3>Understanding Findings</h3>
<p>Every finding gets a priority label. Here's what they mean:</p>
<ul>
<li><span class="badge badge-critical">P1 Critical</span> - Don't merge until this is fixed. Think: SQL injection, data loss, crashes in production.</li>
<li><span class="badge badge-important">P2 Important</span> - Fix before shipping. Performance regressions, N+1 queries, shaky architecture.</li>
<li><span class="badge badge-nice">P3 Nice-to-Have</span> - Would be better, but ship without it if you need to. Documentation, minor cleanup, style issues.</li>
</ul>
<h3>Working with Todo Files</h3>
<p>After a review, you'll have a <code>todos/</code> directory full of markdown files. Each one is a single issue to fix:</p>
<div class="card-code-block">
<pre><code># List all pending todos
ls todos/*-pending-*.md
# Triage findings
/triage
# Resolve todos in parallel
/resolve_todo_parallel</code></pre>
</div>
</section>
<!-- Creating Custom Agents -->
<section id="creating-agents">
<h2><i class="fa-solid fa-plus"></i> Creating Custom Agents</h2>
<p>
The built-in agents cover a lot of ground, but every team has unique needs. Maybe you want a "rails-api-reviewer" that enforces your company's API standards. That's 10 minutes of work.
</p>
<h3>Agent File Structure</h3>
<div class="card-code-block">
<pre><code>---
name: my-custom-agent
description: Brief description of what this agent does
---
# Agent Instructions
You are [role description].
## Your Responsibilities
1. First responsibility
2. Second responsibility
## Guidelines
- Guideline one
- Guideline two</code></pre>
</div>
<h3>Agent Location</h3>
<p>Drop your agent file in one of these directories:</p>
<ul>
<li><code>.claude/agents/</code> - Just for this project (committed to git)</li>
<li><code>~/.claude/agents/</code> - Available in all your projects (stays on your machine)</li>
</ul>
<div class="callout callout-tip">
<div class="callout-icon"><i class="fa-solid fa-lightbulb"></i></div>
<div class="callout-content">
<h4>The Easy Way</h4>
<p>
Don't write the YAML by hand. Just run <code>/create-agent-skill</code> and answer a few questions. The command generates the file, validates the format, and puts it in the right place.
</p>
</div>
</div>
</section>
<!-- Creating Custom Skills -->
<section id="creating-skills">
<h2><i class="fa-solid fa-plus"></i> Creating Custom Skills</h2>
<p>
Skills are heavier than agents—they're knowledge bases, not just prompts. You're building a mini library that Claude can reference. Worth the effort for things you do repeatedly.
</p>
<h3>Skill Directory Structure</h3>
<div class="card-code-block">
<pre><code>my-skill/
SKILL.md # Main skill file (required)
references/ # Supporting documentation
concept-one.md
concept-two.md
templates/ # Code templates
basic-template.md
workflows/ # Step-by-step procedures
workflow-one.md
scripts/ # Executable scripts
helper.py</code></pre>
</div>
<h3>SKILL.md Format</h3>
<div class="card-code-block">
<pre><code>---
name: my-skill
description: Brief description shown when skill is invoked
---
# Skill Title
Detailed instructions for using this skill.
## Quick Start
...
## Reference Materials
The skill includes references in the `references/` directory.
## Templates
Use templates from the `templates/` directory.</code></pre>
</div>
<div class="callout callout-tip">
<div class="callout-icon"><i class="fa-solid fa-lightbulb"></i></div>
<div class="callout-content">
<h4>Get Help Building Skills</h4>
<p>
Type <code>skill: create-agent-skills</code> and Claude loads expert guidance on skill architecture, best practices, file organization, and validation. It's like having a senior engineer walk you through it.
</p>
</div>
</div>
</section>
<!-- Navigation -->
<nav class="docs-nav-footer">
<a href="../index.html" class="nav-prev">
<span class="nav-label">Previous</span>
<span class="nav-title"><i class="fa-solid fa-arrow-left"></i> Home</span>
</a>
<a href="agents.html" class="nav-next">
<span class="nav-label">Next</span>
<span class="nav-title">Agent Reference <i class="fa-solid fa-arrow-right"></i></span>
</a>
</nav>
</article>
</main>
</div>
<script>
// Sidebar toggle for mobile
document.querySelector('[data-sidebar-toggle]')?.addEventListener('click', () => {
document.querySelector('.docs-sidebar').classList.toggle('open');
});
// Active link highlighting
const sections = document.querySelectorAll('section[id]');
const navLinks = document.querySelectorAll('.sidebar-nav a');
window.addEventListener('scroll', () => {
let current = '';
sections.forEach(section => {
const sectionTop = section.offsetTop;
if (pageYOffset >= sectionTop - 100) {
current = section.getAttribute('id');
}
});
navLinks.forEach(link => {
link.classList.remove('active');
if (link.getAttribute('href') === `#${current}`) {
link.classList.add('active');
}
});
});
</script>
</body>
</html>

409
docs/pages/mcp-servers.html Normal file
View File

@@ -0,0 +1,409 @@
<!DOCTYPE html>
<html lang="en" class="theme-dark">
<head>
<meta charset="utf-8" />
<title>MCP Servers Reference - Compounding Engineering</title>
<meta content="Complete reference for the two MCP servers in the Compounding Engineering plugin." name="description" />
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />
<link href="../css/docs.css" rel="stylesheet" type="text/css" />
<script src="../js/main.js" type="text/javascript" defer></script>
</head>
<body>
<div class="background-gradient"></div>
<div class="docs-layout">
<aside class="docs-sidebar">
<div class="sidebar-header">
<a href="../index.html" class="nav-brand">
<span class="logo-icon"><i class="fa-solid fa-layer-group"></i></span>
<span class="logo-text">CE Docs</span>
</a>
</div>
<nav class="sidebar-nav">
<div class="nav-section">
<h3>Getting Started</h3>
<ul>
<li><a href="getting-started.html">Installation</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Reference</h3>
<ul>
<li><a href="agents.html">Agents (23)</a></li>
<li><a href="commands.html">Commands (13)</a></li>
<li><a href="skills.html">Skills (11)</a></li>
<li><a href="mcp-servers.html" class="active">MCP Servers (two)</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Resources</h3>
<ul>
<li><a href="changelog.html">Changelog</a></li>
</ul>
</div>
<div class="nav-section">
<h3>On This Page</h3>
<ul>
<li><a href="#playwright">Playwright</a></li>
<li><a href="#context7">Context7</a></li>
<li><a href="#manual-config">Manual Configuration</a></li>
</ul>
</div>
</nav>
</aside>
<main class="docs-content">
<div class="docs-header">
<nav class="breadcrumb">
<a href="../index.html">Home</a>
<span>/</span>
<a href="getting-started.html">Docs</a>
<span>/</span>
<span>MCP Servers</span>
</nav>
<button class="mobile-menu-toggle" data-sidebar-toggle>
<i class="fa-solid fa-bars"></i>
</button>
</div>
<article class="docs-article">
<h1><i class="fa-solid fa-server color-accent"></i> MCP Servers Reference</h1>
<p class="lead">
Think of MCP servers as power tools that plug into Claude Code. Want Claude to actually <em>open a browser</em> and click around your app? That's Playwright. Need the latest Rails docs without leaving your terminal? That's Context7. The plugin bundles both servers—they just work when you install.
</p>
<div class="callout callout-warning">
<div class="callout-icon"><i class="fa-solid fa-triangle-exclamation"></i></div>
<div class="callout-content">
<h4>Known Issue: Auto-Loading</h4>
<p>
Sometimes MCP servers don't wake up automatically. If Claude can't take screenshots or look up docs, you'll need to add them manually. See <a href="#manual-config">Manual Configuration</a> for the fix.
</p>
</div>
</div>
<!-- Playwright -->
<section id="playwright">
<h2><i class="fa-brands fa-chrome"></i> Playwright</h2>
<p>
You know how you can tell a junior developer "open Chrome and click the login button"? Now you can tell Claude the same thing. Playwright gives Claude hands to control a real browser—clicking buttons, filling forms, taking screenshots, running JavaScript. It's like pair programming with someone who has a browser open next to you.
</p>
<h3>Tools Provided</h3>
<table class="docs-table">
<thead>
<tr>
<th>Tool</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>browser_navigate</code></td>
<td>Go to any URL—your localhost dev server, production, staging, that competitor's site you're studying</td>
</tr>
<tr>
<td><code>browser_take_screenshot</code></td>
<td>Capture what you're seeing right now. Perfect for "does this look right?" design reviews</td>
</tr>
<tr>
<td><code>browser_click</code></td>
<td>Click buttons, links, whatever. Claude finds it by text or CSS selector, just like you would</td>
</tr>
<tr>
<td><code>browser_fill_form</code></td>
<td>Type into forms faster than you can. Great for testing signup flows without manual clicking</td>
</tr>
<tr>
<td><code>browser_snapshot</code></td>
<td>Get the page's accessibility tree—how screen readers see it. Useful for understanding structure without HTML noise</td>
</tr>
<tr>
<td><code>browser_evaluate</code></td>
<td>Run any JavaScript in the page. Check localStorage, trigger functions, read variables—full console access</td>
</tr>
</tbody>
</table>
<h3>When You'll Use This</h3>
<ul>
<li><strong>Design reviews without leaving the terminal</strong> - "Take a screenshot of the new navbar on mobile" gets you a PNG in seconds</li>
<li><strong>Testing signup flows while you code</strong> - "Fill in the registration form with test@example.com and click submit" runs the test for you</li>
<li><strong>Debugging production issues</strong> - "Navigate to the error page and show me what's in localStorage" gives you the state without opening DevTools</li>
<li><strong>Competitive research</strong> - "Go to competitor.com and screenshot their pricing page" builds your swipe file automatically</li>
</ul>
<h3>Example Usage</h3>
<div class="card-code-block">
<pre><code># Just talk to Claude naturally—it knows when to use Playwright
# Design review
"Take a screenshot of the login page"
# Testing a form
"Navigate to /signup and fill in the email field with test@example.com"
# Debug JavaScript state
"Go to localhost:3000 and run console.log(window.currentUser)"
# The browser runs in the background. You'll get results without switching windows.</code></pre>
</div>
<h3>Configuration</h3>
<div class="card-code-block">
<pre><code>{
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"env": {}
}
}</code></pre>
</div>
</section>
<!-- Context7 -->
<section id="context7">
<h2><i class="fa-solid fa-book-open"></i> Context7</h2>
<p>
Ever ask Claude about a framework and get an answer from 2023? Context7 fixes that. It's a documentation service that keeps Claude current with 100+ frameworks—Rails, React, Next.js, Django, whatever you're using. Think of it as having the official docs piped directly into Claude's brain.
</p>
<h3>Tools Provided</h3>
<table class="docs-table">
<thead>
<tr>
<th>Tool</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>resolve-library-id</code></td>
<td>Maps "Rails" to the actual library identifier Context7 uses. You don't call this—Claude does it automatically</td>
</tr>
<tr>
<td><code>get-library-docs</code></td>
<td>Fetches the actual documentation pages. Ask "How does useEffect work?" and this grabs the latest React docs</td>
</tr>
</tbody>
</table>
<h3>What's Covered</h3>
<p>Over 100 frameworks and libraries. Here's a taste of what you can look up:</p>
<div class="framework-grid">
<div class="framework-category">
<h4>Backend</h4>
<ul>
<li>Ruby on Rails</li>
<li>Django</li>
<li>Laravel</li>
<li>Express</li>
<li>FastAPI</li>
<li>Spring Boot</li>
</ul>
</div>
<div class="framework-category">
<h4>Frontend</h4>
<ul>
<li>React</li>
<li>Vue.js</li>
<li>Angular</li>
<li>Svelte</li>
<li>Next.js</li>
<li>Nuxt</li>
</ul>
</div>
<div class="framework-category">
<h4>Mobile</h4>
<ul>
<li>React Native</li>
<li>Flutter</li>
<li>SwiftUI</li>
<li>Kotlin</li>
</ul>
</div>
<div class="framework-category">
<h4>Tools & Libraries</h4>
<ul>
<li>Tailwind CSS</li>
<li>PostgreSQL</li>
<li>Redis</li>
<li>GraphQL</li>
<li>Prisma</li>
<li>And many more...</li>
</ul>
</div>
</div>
<h3>Example Usage</h3>
<div class="card-code-block">
<pre><code># Just ask about the framework—Claude fetches current docs automatically
"Look up the Rails ActionCable documentation"
"How does the useEffect hook work in React?"
"What are the best practices for PostgreSQL indexes?"
# You get answers based on the latest docs, not Claude's training cutoff</code></pre>
</div>
<h3>Configuration</h3>
<div class="card-code-block">
<pre><code>{
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
}
}</code></pre>
</div>
</section>
<!-- Manual Configuration -->
<section id="manual-config">
<h2><i class="fa-solid fa-gear"></i> Manual Configuration</h2>
<p>
If the servers don't load automatically (you'll know because Claude can't take screenshots or fetch docs), you need to wire them up yourself. It's a two-minute copy-paste job.
</p>
<h3>Project-Level Configuration</h3>
<p>To enable for just this project, add this to <code>.claude/settings.json</code> in your project root:</p>
<div class="card-code-block">
<pre><code>{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"env": {}
},
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
}
}
}</code></pre>
</div>
<h3>Global Configuration</h3>
<p>Or enable everywhere—every project on your machine gets these servers. Add to <code>~/.claude/settings.json</code>:</p>
<div class="card-code-block">
<pre><code>{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"env": {}
},
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
}
}
}</code></pre>
</div>
<h3>Requirements</h3>
<table class="docs-table">
<thead>
<tr>
<th>Server</th>
<th>Requirement</th>
</tr>
</thead>
<tbody>
<tr>
<td>Playwright</td>
<td>Node.js 18+ and npx</td>
</tr>
<tr>
<td>Context7</td>
<td>Internet connection (HTTP endpoint)</td>
</tr>
</tbody>
</table>
<h3>Verifying MCP Servers</h3>
<p>After you add the config, restart Claude Code. Then test that everything works:</p>
<div class="card-code-block">
<pre><code># Ask Claude what it has
"What MCP tools do you have access to?"
# Test Playwright (should work now)
"Take a screenshot of the current directory listing"
# Test Context7 (should fetch real docs)
"Look up Rails Active Record documentation"
# If either fails, double-check your JSON syntax and file paths</code></pre>
</div>
</section>
<!-- Navigation -->
<nav class="docs-nav-footer">
<a href="skills.html" class="nav-prev">
<span class="nav-label">Previous</span>
<span class="nav-title"><i class="fa-solid fa-arrow-left"></i> Skills</span>
</a>
<a href="getting-started.html" class="nav-next">
<span class="nav-label">Back to</span>
<span class="nav-title">Getting Started <i class="fa-solid fa-arrow-right"></i></span>
</a>
</nav>
</article>
</main>
</div>
<style>
.framework-grid {
display: grid;
grid-template-columns: repeat(2, 1fr);
gap: var(--space-l);
margin: var(--space-l) 0;
}
@media (min-width: 768px) {
.framework-grid {
grid-template-columns: repeat(4, 1fr);
}
}
.framework-category {
background-color: var(--color-surface);
padding: var(--space-l);
border-radius: var(--radius-m);
border: 1px solid var(--color-border);
}
.framework-category h4 {
margin: 0 0 var(--space-s) 0;
color: var(--color-accent);
font-size: var(--font-size-s);
}
.framework-category ul {
margin: 0;
padding-left: var(--space-l);
}
.framework-category li {
margin: var(--space-xs) 0;
font-size: var(--font-size-s);
color: var(--color-text-secondary);
}
</style>
<script>
document.querySelector('[data-sidebar-toggle]')?.addEventListener('click', () => {
document.querySelector('.docs-sidebar').classList.toggle('open');
});
</script>
</body>
</html>

586
docs/pages/skills.html Normal file
View File

@@ -0,0 +1,586 @@
<!DOCTYPE html>
<html lang="en" class="theme-dark">
<head>
<meta charset="utf-8" />
<title>Skill Reference - Compounding Engineering</title>
<meta content="Complete reference for all 11 intelligent skills in the Compounding Engineering plugin." name="description" />
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />
<link href="../css/docs.css" rel="stylesheet" type="text/css" />
<script src="../js/main.js" type="text/javascript" defer></script>
</head>
<body>
<div class="background-gradient"></div>
<div class="docs-layout">
<aside class="docs-sidebar">
<div class="sidebar-header">
<a href="../index.html" class="nav-brand">
<span class="logo-icon"><i class="fa-solid fa-layer-group"></i></span>
<span class="logo-text">CE Docs</span>
</a>
</div>
<nav class="sidebar-nav">
<div class="nav-section">
<h3>Getting Started</h3>
<ul>
<li><a href="getting-started.html">Installation</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Reference</h3>
<ul>
<li><a href="agents.html">Agents (23)</a></li>
<li><a href="commands.html">Commands (13)</a></li>
<li><a href="skills.html" class="active">Skills (11)</a></li>
<li><a href="mcp-servers.html">MCP Servers (2)</a></li>
</ul>
</div>
<div class="nav-section">
<h3>Resources</h3>
<ul>
<li><a href="changelog.html">Changelog</a></li>
</ul>
</div>
<div class="nav-section">
<h3>On This Page</h3>
<ul>
<li><a href="#development-tools">Development (7)</a></li>
<li><a href="#content-workflow">Content & Workflow (3)</a></li>
<li><a href="#image-generation">Image Generation (1)</a></li>
</ul>
</div>
</nav>
</aside>
<main class="docs-content">
<div class="docs-header">
<nav class="breadcrumb">
<a href="../index.html">Home</a>
<span>/</span>
<a href="getting-started.html">Docs</a>
<span>/</span>
<span>Skills</span>
</nav>
<button class="mobile-menu-toggle" data-sidebar-toggle>
<i class="fa-solid fa-bars"></i>
</button>
</div>
<article class="docs-article">
<h1><i class="fa-solid fa-wand-magic-sparkles color-accent"></i> Skill Reference</h1>
<p class="lead">
Think of skills as reference manuals that Claude Code can read mid-conversation. When you're writing Rails code and want DHH's style, or building a gem like Andrew Kane would, you don't need to paste documentation—just invoke the skill. Claude reads it, absorbs the patterns, and writes code that way.
</p>
<div class="usage-box">
<h3>How to Use Skills</h3>
<div class="card-code-block">
<pre><code># In your prompt, reference the skill
skill: [skill-name]
# Examples
skill: gemini-imagegen
skill: dhh-ruby-style
skill: create-agent-skills</code></pre>
</div>
</div>
<div class="callout callout-info">
<div class="callout-icon"><i class="fa-solid fa-circle-info"></i></div>
<div class="callout-content">
<h4>Skills vs Agents</h4>
<p>
<strong>Agents</strong> are personas—they <em>do</em> things. <strong>Skills</strong> are knowledge—they teach Claude <em>how</em> to do things. Use <code>claude agent [name]</code> when you want someone to review your code. Use <code>skill: [name]</code> when you want to write code in a particular style yourself.
</p>
</div>
</div>
<!-- Development Tools -->
<section id="development-tools">
<h2><i class="fa-solid fa-code"></i> Development Tools (7)</h2>
<p>These skills teach Claude specific coding styles and architectural patterns. Use them when you want code that follows a particular philosophy—not just any working code, but code that looks like it was written by a specific person or framework.</p>
<div class="skill-detail" id="create-agent-skills">
<div class="skill-detail-header">
<h3>create-agent-skills</h3>
<span class="skill-badge">Meta</span>
</div>
<p class="skill-detail-description">
You're writing a skill right now, but you're not sure if you're structuring the SKILL.md file correctly. Should the examples go before the theory? How do you organize workflows vs. references? This skill is the answer—it's the master template for building skills themselves.
</p>
<h4>Capabilities</h4>
<ul>
<li>Skill architecture and best practices</li>
<li>Router pattern for complex multi-step skills</li>
<li>Progressive disclosure design principles</li>
<li>SKILL.md structure guidance</li>
<li>Asset management (workflows, references, templates, scripts)</li>
<li>XML structure patterns</li>
</ul>
<h4>Workflows Included</h4>
<ul>
<li><code>create-new-skill</code> - Start from scratch</li>
<li><code>add-reference</code> - Add reference documentation</li>
<li><code>add-template</code> - Add code templates</li>
<li><code>add-workflow</code> - Add step-by-step procedures</li>
<li><code>add-script</code> - Add executable scripts</li>
<li><code>audit-skill</code> - Validate skill structure</li>
<li><code>verify-skill</code> - Test skill functionality</li>
</ul>
<div class="card-code-block">
<pre><code>skill: create-agent-skills</code></pre>
</div>
</div>
<div class="skill-detail" id="skill-creator">
<div class="skill-detail-header">
<h3>skill-creator</h3>
<span class="skill-badge">Meta</span>
</div>
<p class="skill-detail-description">
The simpler, step-by-step version of <code>create-agent-skills</code>. When you just want a checklist to follow from blank file to packaged skill, use this. It's less about theory, more about "do step 1, then step 2."
</p>
<h4>6-Step Process</h4>
<ol>
<li>Understand skill usage patterns with examples</li>
<li>Plan reusable skill contents</li>
<li>Initialize skill using template</li>
<li>Edit skill with clear instructions</li>
<li>Package skill into distributable zip</li>
<li>Iterate based on testing feedback</li>
</ol>
<div class="card-code-block">
<pre><code>skill: skill-creator</code></pre>
</div>
</div>
<div class="skill-detail" id="dhh-ruby-style">
<div class="skill-detail-header">
<h3>dhh-ruby-style</h3>
<span class="skill-badge">Rails</span>
</div>
<p class="skill-detail-description">
You want Rails controllers that are five lines, not fifty. Models that handle authorization, broadcasting, and business logic without service objects everywhere. This skill teaches Claude to write code the way DHH writes it at 37signals—REST-pure, Hotwire-first, no architectural astronautics.
</p>
<h4>Key Patterns</h4>
<ul>
<li><strong>REST Purity</strong> - 7 REST actions only</li>
<li><strong>Fat Models</strong> - Business logic, authorization, broadcasting in models</li>
<li><strong>Thin Controllers</strong> - 1-5 line actions</li>
<li><strong>Current Attributes</strong> - Request context</li>
<li><strong>Hotwire/Turbo</strong> - Model-level broadcasting</li>
</ul>
<h4>Ruby Syntax Preferences</h4>
<ul>
<li>Symbol arrays <code>%i[...]</code></li>
<li>Modern hash syntax</li>
<li>Ternaries for simple conditionals</li>
<li>Bang methods for mutations</li>
</ul>
<div class="card-code-block">
<pre><code>skill: dhh-ruby-style</code></pre>
</div>
</div>
<div class="skill-detail" id="andrew-kane-gem-writer">
<div class="skill-detail-header">
<h3>andrew-kane-gem-writer</h3>
<span class="skill-badge">Ruby</span>
</div>
<p class="skill-detail-description">
Andrew Kane has written 100+ Ruby gems with 374 million downloads. Every gem follows the same patterns: minimal dependencies, class macro DSLs, Rails integration without Rails coupling. When you're building a gem and want it to feel production-ready from day one, this is how you do it.
</p>
<h4>Philosophy</h4>
<ul>
<li>Simplicity over cleverness</li>
<li>Zero or minimal dependencies</li>
<li>Explicit code over metaprogramming</li>
<li>Rails integration without Rails coupling</li>
</ul>
<h4>Key Patterns</h4>
<ul>
<li>Class macro DSL for configuration</li>
<li><code>ActiveSupport.on_load</code> for Rails integration</li>
<li><code>class << self</code> with <code>attr_accessor</code></li>
<li>Railtie pattern for hooks</li>
<li>Minitest (no RSpec)</li>
</ul>
<h4>Reference Files</h4>
<ul>
<li><code>references/module-organization.md</code></li>
<li><code>references/rails-integration.md</code></li>
<li><code>references/database-adapters.md</code></li>
<li><code>references/testing-patterns.md</code></li>
</ul>
<div class="card-code-block">
<pre><code>skill: andrew-kane-gem-writer</code></pre>
</div>
</div>
<div class="skill-detail" id="dspy-ruby">
<div class="skill-detail-header">
<h3>dspy-ruby</h3>
<span class="skill-badge">AI</span>
</div>
<p class="skill-detail-description">
You're adding AI features to your Rails app, but you don't want brittle prompt strings scattered everywhere. DSPy.rb gives you type-safe signatures, composable predictors, and tool-using agents. This skill shows you how to use it—from basic inference to ReAct agents that iterate until they get the answer right.
</p>
<h4>Predictor Types</h4>
<ul>
<li><strong>Predict</strong> - Basic inference</li>
<li><strong>ChainOfThought</strong> - Reasoning with explanations</li>
<li><strong>ReAct</strong> - Tool-using agents with iteration</li>
<li><strong>CodeAct</strong> - Dynamic code generation</li>
</ul>
<h4>Supported Providers</h4>
<ul>
<li>OpenAI (GPT-4, GPT-4o-mini)</li>
<li>Anthropic Claude</li>
<li>Google Gemini</li>
<li>Ollama (free, local)</li>
<li>OpenRouter</li>
</ul>
<h4>Requirements</h4>
<table class="docs-table">
<tr>
<td><code>OPENAI_API_KEY</code></td>
<td>For OpenAI provider</td>
</tr>
<tr>
<td><code>ANTHROPIC_API_KEY</code></td>
<td>For Anthropic provider</td>
</tr>
<tr>
<td><code>GOOGLE_API_KEY</code></td>
<td>For Gemini provider</td>
</tr>
</table>
<div class="card-code-block">
<pre><code>skill: dspy-ruby</code></pre>
</div>
</div>
<div class="skill-detail" id="frontend-design">
<div class="skill-detail-header">
<h3>frontend-design</h3>
<span class="skill-badge">Design</span>
</div>
<p class="skill-detail-description">
You've seen what AI usually generates: Inter font, purple gradients, rounded corners on everything. This skill teaches Claude to design interfaces that don't look like every other AI-generated site. It's about purposeful typography, unexpected color palettes, and interfaces with personality.
</p>
<h4>Design Thinking</h4>
<ul>
<li><strong>Purpose</strong> - What is the interface for?</li>
<li><strong>Tone</strong> - What feeling should it evoke?</li>
<li><strong>Constraints</strong> - Technical and brand limitations</li>
<li><strong>Differentiation</strong> - How to stand out</li>
</ul>
<h4>Focus Areas</h4>
<ul>
<li>Typography with distinctive font choices</li>
<li>Color & theme coherence with CSS variables</li>
<li>Motion and animation patterns</li>
<li>Spatial composition with asymmetry</li>
<li>Backgrounds (gradients, textures, patterns)</li>
</ul>
<div class="callout callout-tip">
<div class="callout-icon"><i class="fa-solid fa-lightbulb"></i></div>
<div class="callout-content">
<p>Avoids generic AI aesthetics like Inter fonts, purple gradients, and rounded corners everywhere.</p>
</div>
</div>
<div class="card-code-block">
<pre><code>skill: frontend-design</code></pre>
</div>
</div>
<div class="skill-detail" id="compound-docs">
<div class="skill-detail-header">
<h3>compound-docs</h3>
<span class="skill-badge">Docs</span>
</div>
<p class="skill-detail-description">
You just fixed a weird build error after an hour of debugging. Tomorrow you'll forget how you fixed it. This skill automatically detects when you solve something (phrases like "that worked" or "it's fixed") and documents it with YAML frontmatter so you can find it again. Each documented solution compounds your team's knowledge.
</p>
<h4>Auto-Triggers</h4>
<p>Phrases: "that worked", "it's fixed", "working now", "problem solved"</p>
<h4>7-Step Process</h4>
<ol>
<li>Detect confirmation phrase</li>
<li>Gather context (module, symptom, investigation, root cause)</li>
<li>Check existing docs for similar issues</li>
<li>Generate filename</li>
<li>Validate YAML frontmatter</li>
<li>Create documentation in category directory</li>
<li>Cross-reference related issues</li>
</ol>
<h4>Categories</h4>
<ul>
<li><code>build-errors/</code></li>
<li><code>test-failures/</code></li>
<li><code>runtime-errors/</code></li>
<li><code>performance-issues/</code></li>
<li><code>database-issues/</code></li>
<li><code>security-issues/</code></li>
</ul>
<div class="card-code-block">
<pre><code>skill: compound-docs</code></pre>
</div>
</div>
</section>
<!-- Content & Workflow -->
<section id="content-workflow">
<h2><i class="fa-solid fa-pen-fancy"></i> Content & Workflow (3)</h2>
<p>Writing, editing, and organizing work. These skills handle everything from style guide compliance to git worktree management—the meta-work that makes the real work easier.</p>
<div class="skill-detail" id="every-style-editor">
<div class="skill-detail-header">
<h3>every-style-editor</h3>
<span class="skill-badge">Content</span>
</div>
<p class="skill-detail-description">
You wrote a draft, but you're not sure if it matches Every's style guide. Should "internet" be capitalized? Is this comma splice allowed? This skill does a four-phase line-by-line review: context, detailed edits, mechanical checks, and actionable recommendations. It's like having a copy editor who never gets tired.
</p>
<h4>Four-Phase Review</h4>
<ol>
<li><strong>Initial Assessment</strong> - Context, type, audience, tone</li>
<li><strong>Detailed Line Edit</strong> - Sentence structure, punctuation, capitalization</li>
<li><strong>Mechanical Review</strong> - Spacing, formatting, consistency</li>
<li><strong>Recommendations</strong> - Actionable improvement suggestions</li>
</ol>
<h4>Style Checks</h4>
<ul>
<li>Grammar and punctuation</li>
<li>Style guide compliance</li>
<li>Capitalization rules</li>
<li>Word choice optimization</li>
<li>Formatting consistency</li>
</ul>
<div class="card-code-block">
<pre><code>skill: every-style-editor</code></pre>
</div>
</div>
<div class="skill-detail" id="file-todos">
<div class="skill-detail-header">
<h3>file-todos</h3>
<span class="skill-badge">Workflow</span>
</div>
<p class="skill-detail-description">
Your todo list is a bunch of markdown files in a <code>todos/</code> directory. Each filename encodes status, priority, and description. No database, no UI, just files with YAML frontmatter. When you need to track work without setting up Jira, this is the system.
</p>
<h4>File Format</h4>
<div class="card-code-block">
<pre><code># Naming convention
{issue_id}-{status}-{priority}-{description}.md
# Examples
001-pending-p1-security-vulnerability.md
002-ready-p2-performance-optimization.md
003-complete-p3-code-cleanup.md</code></pre>
</div>
<h4>Status Values</h4>
<ul>
<li><code>pending</code> - Needs triage</li>
<li><code>ready</code> - Approved for work</li>
<li><code>complete</code> - Done</li>
</ul>
<h4>Priority Values</h4>
<ul>
<li><code>p1</code> - Critical</li>
<li><code>p2</code> - Important</li>
<li><code>p3</code> - Nice-to-have</li>
</ul>
<h4>YAML Frontmatter</h4>
<div class="card-code-block">
<pre><code>---
status: pending
priority: p1
issue_id: "001"
tags: [security, authentication]
dependencies: []
---</code></pre>
</div>
<div class="card-code-block">
<pre><code>skill: file-todos</code></pre>
</div>
</div>
<div class="skill-detail" id="git-worktree">
<div class="skill-detail-header">
<h3>git-worktree</h3>
<span class="skill-badge">Git</span>
</div>
<p class="skill-detail-description">
You're working on a feature branch, but you need to review a PR without losing your current work. Git worktrees let you have multiple branches checked out simultaneously in separate directories. This skill manages them—create, switch, cleanup—so you can context-switch without stashing or committing half-finished code.
</p>
<h4>Commands</h4>
<div class="card-code-block">
<pre><code># Create new worktree
bash scripts/worktree-manager.sh create feature-login
# List worktrees
bash scripts/worktree-manager.sh list
# Switch to worktree
bash scripts/worktree-manager.sh switch feature-login
# Clean up completed worktrees
bash scripts/worktree-manager.sh cleanup</code></pre>
</div>
<h4>Integration</h4>
<ul>
<li>Works with <code>/review</code> for isolated PR analysis</li>
<li>Works with <code>/work</code> for parallel feature development</li>
</ul>
<h4>Requirements</h4>
<ul>
<li>Git 2.8+ (for worktree support)</li>
<li>Worktrees stored in <code>.worktrees/</code> directory</li>
</ul>
<div class="card-code-block">
<pre><code>skill: git-worktree</code></pre>
</div>
</div>
</section>
<!-- Image Generation -->
<section id="image-generation">
<h2><i class="fa-solid fa-image"></i> Image Generation (1)</h2>
<p>Generate images with AI. Not stock photos you found on Unsplash—images you describe and the model creates.</p>
<div class="skill-detail featured" id="gemini-imagegen">
<div class="skill-detail-header">
<h3>gemini-imagegen</h3>
<span class="skill-badge highlight">AI Images</span>
</div>
<p class="skill-detail-description">
Need a logo with specific text? A product mockup on a marble surface? An illustration in a kawaii style? This skill wraps Google's Gemini image generation API. You describe what you want, it generates it. You can edit existing images, refine over multiple turns, or compose from reference images. All through simple Python scripts.
</p>
<h4>Features</h4>
<div class="skill-features">
<div class="feature-item"><i class="fa-solid fa-check"></i> Text-to-image generation</div>
<div class="feature-item"><i class="fa-solid fa-check"></i> Image editing & manipulation</div>
<div class="feature-item"><i class="fa-solid fa-check"></i> Multi-turn iterative refinement</div>
<div class="feature-item"><i class="fa-solid fa-check"></i> Multiple reference images (up to 14)</div>
<div class="feature-item"><i class="fa-solid fa-check"></i> Google Search grounding (Pro)</div>
</div>
<h4>Available Models</h4>
<table class="docs-table">
<thead>
<tr>
<th>Model</th>
<th>Resolution</th>
<th>Best For</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>gemini-2.5-flash-image</code></td>
<td>1024px</td>
<td>Speed, high-volume tasks</td>
</tr>
<tr>
<td><code>gemini-3-pro-image-preview</code></td>
<td>Up to 4K</td>
<td>Professional assets, complex instructions</td>
</tr>
</tbody>
</table>
<h4>Quick Start</h4>
<div class="card-code-block">
<pre><code># Text-to-image
python scripts/generate_image.py "A cat wearing a wizard hat" output.png
# Edit existing image
python scripts/edit_image.py input.png "Add a rainbow in the background" output.png
# Multi-turn chat
python scripts/multi_turn_chat.py</code></pre>
</div>
<h4>Image Configuration</h4>
<div class="card-code-block">
<pre><code>from google.genai import types
response = client.models.generate_content(
model="gemini-3-pro-image-preview",
contents=[prompt],
config=types.GenerateContentConfig(
response_modalities=['TEXT', 'IMAGE'],
image_config=types.ImageConfig(
aspect_ratio="16:9", # 1:1, 2:3, 3:2, 4:3, 16:9, 21:9
image_size="2K" # 1K, 2K, 4K (Pro only)
),
)
)</code></pre>
</div>
<h4>Prompting Best Practices</h4>
<ul>
<li><strong>Photorealistic</strong> - Include camera details: lens type, lighting, angle, mood</li>
<li><strong>Stylized Art</strong> - Specify style explicitly: kawaii, cel-shading, bold outlines</li>
<li><strong>Text in Images</strong> - Be explicit about font style and placement (use Pro model)</li>
<li><strong>Product Mockups</strong> - Describe lighting setup and surface</li>
</ul>
<h4>Requirements</h4>
<table class="docs-table">
<tr>
<td><code>GEMINI_API_KEY</code></td>
<td>Required environment variable</td>
</tr>
<tr>
<td><code>google-genai</code></td>
<td>Python package</td>
</tr>
<tr>
<td><code>pillow</code></td>
<td>Python package for image handling</td>
</tr>
</table>
<div class="callout callout-info">
<div class="callout-icon"><i class="fa-solid fa-circle-info"></i></div>
<div class="callout-content">
<p>All generated images include SynthID watermarks. Image-only mode won't work with Google Search grounding.</p>
</div>
</div>
<div class="card-code-block">
<pre><code>skill: gemini-imagegen</code></pre>
</div>
</div>
</section>
<!-- Navigation -->
<nav class="docs-nav-footer">
<a href="commands.html" class="nav-prev">
<span class="nav-label">Previous</span>
<span class="nav-title"><i class="fa-solid fa-arrow-left"></i> Commands</span>
</a>
<a href="mcp-servers.html" class="nav-next">
<span class="nav-label">Next</span>
<span class="nav-title">MCP Servers <i class="fa-solid fa-arrow-right"></i></span>
</a>
</nav>
</article>
</main>
</div>
<script>
document.querySelector('[data-sidebar-toggle]')?.addEventListener('click', () => {
document.querySelector('.docs-sidebar').classList.toggle('open');
});
</script>
</body>
</html>

View File

@@ -0,0 +1,102 @@
# Grow Your Own Garden: Adaptive Agent Ecosystem
> **Issue:** https://github.com/EveryInc/compounding-engineering-plugin/issues/20
## The Idea
Everyone grows their own garden, but we're all using the same process.
Start from a **seed** (minimal core: `/plan`, `/work`, `/review`, `/compound`). Each `/compound` loop can suggest adding agents based on what you're working on—like building up a test suite to prevent regressions, but for code review expertise.
## Current Problem
- Monolithic plugin: 24 agents, users use ~30%
- No personalization (same agents for Rails dev and Python dev)
- Static collection that doesn't adapt
## Proposed Solution
### The Seed (Core Plugin)
4 commands + minimal agents:
| Component | What's Included |
|-----------|-----------------|
| Commands | `/plan`, `/work`, `/review`, `/compound` |
| Review Agents | security, performance, simplicity, architecture, patterns |
| Research Agents | best-practices, framework-docs, git-history, repo-analyst |
| Skills | compound-docs, file-todos, git-worktree |
| MCP Servers | playwright, context7 |
### The Growth Loop
After each `/compound`:
```
✅ Learning documented
💡 It looks like you're using Rails.
Would you like to add the "DHH Rails Reviewer"?
[y] Yes [n] No [x] Never ask
```
Three sources of new agents:
1. **Predefined** - "You're using Rails, add DHH reviewer?"
2. **Dynamic** - "You're using actor model, create an expert?"
3. **Custom** - "Want to create an agent for this pattern?"
### Agent Storage
```
.claude/agents/ → Project-specific (highest priority)
~/.claude/agents/ → User's garden
plugin/agents/ → From installed plugins
```
## Implementation Phases
### Phase 1: Split the Plugin
- Create `agent-library/` with framework-specific agents (Rails, Python, TypeScript, Frontend)
- Keep `compounding-engineering` as core with universal agents
- No breaking changes—existing users unaffected
### Phase 2: Agent Discovery
- `/review` discovers agents from all three locations
- Project agents override user agents override plugin agents
### Phase 3: Growth via /compound
- Detect tech stack (Gemfile, package.json, etc.)
- Suggest relevant agents after documenting learnings
- Install accepted agents to `~/.claude/agents/`
### Phase 4: Management
- `/agents list` - See your garden
- `/agents add <name>` - Add from library
- `/agents disable <name>` - Temporarily disable
## What Goes Where
**Core (seed):** 11 framework-agnostic agents
- security-sentinel, performance-oracle, code-simplicity-reviewer
- architecture-strategist, pattern-recognition-specialist
- 4 research agents, 2 workflow agents
**Agent Library:** 10 specialized agents
- Rails: kieran-rails, dhh-rails, data-integrity (3)
- Python: kieran-python (1)
- TypeScript: kieran-typescript (1)
- Frontend: julik-races, design-iterator, design-reviewer, figma-sync (4)
- Editorial: every-style-editor (1)
## Key Constraint
Claude Code doesn't support plugin dependencies. Each plugin must be independent. Users manually install what they need, or we suggest additions via `/compound`.
## Acceptance Criteria
- [ ] Core plugin works standalone with universal agents
- [ ] `/compound` suggests agents based on detected tech stack
- [ ] Users can accept/decline suggestions
- [ ] `/agents` command for garden management
- [ ] No breaking changes for existing users

View File

@@ -0,0 +1,279 @@
# Landing Page LaunchKit Refresh
## Overview
Review and enhance the `/docs/index.html` landing page using LaunchKit elements and Pragmatic Technical Writing style (Hunt/Thomas, Joel Spolsky). The current implementation is strong but can be refined section-by-section.
## Current State Assessment
### What's Working Well
- Specific, outcome-focused hero headline ("12 expert opinions in 30 seconds")
- Developer-authentic copywriting (N+1 queries, CORS, SQL injection)
- Stats section with clear metrics (23 agents, 16 commands, 11 skills, 2 MCP servers)
- Philosophy section with concrete story (N+1 query bug)
- Three-step installation with actual commands
- FAQ accordion following LaunchKit patterns
- Categorized feature sections with code examples
### Missing Elements (From Best Practices Research)
1. **Social Proof Section** - No testimonials, GitHub stars, or user metrics
2. **Visual Demo** - No GIF/animation showing the tool in action
3. **Arrow icons on CTAs** - 26% conversion boost from studies
4. **Trust indicators** - Open source badge, license info
---
## Section-by-Section Review Plan
### 1. Hero Section (lines 56-78)
**Current:**
```html
<h1>Your Code Reviews Just Got 12 Expert Opinions. In 30 Seconds.</h1>
```
**Review Checklist:**
- [ ] Headline follows Pragmatic Writing (concrete before abstract) ✅
- [ ] Eyebrow badge is current (Version 2.6.0) - verify
- [ ] Description paragraph under 3 sentences ✅
- [ ] Button group has arrow icon on primary CTA
- [ ] "Read the Docs" secondary CTA present ✅
**Potential Improvements:**
- Add `→` arrow to "Install Plugin" button
- Consider adding animated terminal GIF below buttons showing `/review` in action
### 2. Stats Section (lines 81-104)
**Current:** 4 stat cards (23 agents, 16 commands, 11 skills, 2 MCP servers)
**Review Checklist:**
- [ ] Numbers are accurate (verify against actual file counts)
- [ ] Icons are appropriate for each stat
- [ ] Hover effects working properly
- [ ] Mobile layout (2x2 grid) is readable
**Potential Improvements:**
- Add "developers using" or "reviews run" metric if available
- Consider adding subtle animation on scroll
### 3. Philosophy Section (lines 107-192)
**Current:** "Why Your Third Code Review Should Be Easier Than Your First" with N+1 query story
**Review Checklist:**
- [ ] Opens with concrete story (N+1 query) ✅
- [ ] Quote block is memorable and quotable
- [ ] Four pillars (Plan, Delegate, Assess, Codify) are clear
- [ ] Each pillar has: tagline, description, tool tags
- [ ] Descriptions use "you" voice ✅
**Potential Improvements:**
- Review pillar descriptions for passive voice
- Ensure each pillar description follows PAS (Problem, Agitate, Solve) pattern
- Check tool tags are accurate and current
### 4. Agents Section (lines 195-423)
**Current:** 23 agents in 5 categories (Review, Research, Design, Workflow, Docs)
**Review Checklist:**
- [ ] All 23 agents are listed (count actual files)
- [ ] Categories are logical and scannable
- [ ] Each card has: name, badge, description, usage code
- [ ] Descriptions are conversational (not passive)
- [ ] Critical badges (Security, Data) stand out
**Potential Improvements:**
- Review agent descriptions against pragmatic writing checklist
- Ensure descriptions answer "when would I use this?"
- Add concrete scenarios to generic descriptions
### 5. Commands Section (lines 426-561)
**Current:** 16 commands in 2 categories (Workflow, Utility)
**Review Checklist:**
- [ ] All 16 commands are listed (count actual files)
- [ ] Core workflow commands are highlighted
- [ ] Descriptions are action-oriented
- [ ] Command names match actual implementation
**Potential Improvements:**
- Review command descriptions for passive voice
- Lead with outcomes, not features
- Add "saves you X minutes" framing where appropriate
### 6. Skills Section (lines 564-703)
**Current:** 11 skills in 3 categories (Development, Content/Workflow, Image Generation)
**Review Checklist:**
- [ ] All 11 skills are listed (count actual directories)
- [ ] Featured skill (gemini-imagegen) is properly highlighted
- [ ] API key requirement is clear
- [ ] Skill invocation syntax is correct
**Potential Improvements:**
- Review skill descriptions against pragmatic writing
- Ensure each skill answers "what problem does this solve?"
### 7. MCP Servers Section (lines 706-751)
**Current:** 2 MCP servers (Playwright, Context7)
**Review Checklist:**
- [ ] Tool lists are accurate
- [ ] Descriptions explain WHY not just WHAT
- [ ] Framework support list is current (100+)
**Potential Improvements:**
- Add concrete example of each server in action
- Consider before/after comparison
### 8. Installation Section (lines 754-798)
**Current:** "Three Commands. Zero Configuration." with 3 steps
**Review Checklist:**
- [ ] Commands are accurate and work
- [ ] Step 3 shows actual usage examples
- [ ] Timeline visual (vertical line) renders correctly
- [ ] Copy buttons work on code blocks
**Potential Improvements:**
- Add copy-to-clipboard functionality if missing
- Consider adding "What you'll see" output example
### 9. FAQ Section (lines 801-864)
**Current:** 5 questions in accordion format
**Review Checklist:**
- [ ] Questions address real objections
- [ ] Answers are conversational (use "you")
- [ ] Accordion expand/collapse works
- [ ] No passive voice in answers
**Potential Improvements:**
- Review for weasel words ("best practices suggest")
- Ensure answers are direct and actionable
### 10. CTA Section (lines 868-886)
**Current:** "Install Once. Compound Forever." with Install + GitHub buttons
**Review Checklist:**
- [ ] Badge is eye-catching ("Free & Open Source")
- [ ] Headline restates core value proposition
- [ ] Primary CTA has arrow icon ✅
- [ ] Trust line at bottom
**Potential Improvements:**
- Review trust line copy
- Consider adding social proof element
---
## NEW: Social Proof Section (To Add)
**Position:** After Stats section, before Philosophy section
**Components:**
- GitHub stars counter (dynamic or static)
- "Trusted by X developers" metric
- 2-3 testimonial quotes (if available)
- Company logos (if applicable)
**LaunchKit Pattern:**
```html
<section class="social-proof-section">
<div class="heading centered">
<p class="paragraph m secondary">Trusted by developers at</p>
</div>
<div class="logo-grid">
<!-- Company logos or GitHub badge -->
</div>
</section>
```
---
## Pragmatic Writing Style Checklist (Apply to ALL Copy)
### The Five Laws
1. **Concrete Before Abstract** - Story/example first, then principle
2. **Physical Analogies** - Import metaphors readers understand
3. **Conversational Register** - Use "you", contractions, asides
4. **Numbered Frameworks** - Create referenceable structures
5. **Humor as Architecture** - Mental anchors for dense content
### Anti-Patterns to Find and Fix
- [ ] "It is recommended that..." → "Do this:"
- [ ] "Best practices suggest..." → "Here's what works:"
- [ ] Passive voice → Active voice
- [ ] Abstract claims → Specific examples
- [ ] Walls of text → Scannable lists
### Quality Checklist (Per Section)
- [ ] Opens with concrete story or example?
- [ ] Can reader skim headers and get the arc?
- [ ] Uses "you" at least once?
- [ ] Clear action reader can take?
- [ ] Reads aloud like speech?
---
## Implementation Phases
### Phase 1: Copy Audit (No HTML Changes)
1. Read through entire page
2. Flag passive voice instances
3. Flag abstract claims without examples
4. Flag missing "you" voice
5. Document improvements needed
### Phase 2: Copy Rewrites
1. Rewrite flagged sections following pragmatic style
2. Ensure each section passes quality checklist
3. Maintain existing HTML structure
### Phase 3: Component Additions
1. Add arrow icons to primary CTAs
2. Add social proof section (if data available)
3. Consider visual demo element
### Phase 4: Verification
1. Validate all counts (agents, commands, skills)
2. Test all links and buttons
3. Verify mobile responsiveness
4. Check accessibility
---
## Files to Modify
| File | Changes |
|------|---------|
| `docs/index.html` | Copy rewrites, potential new section |
| `docs/css/style.css` | Social proof styles (if adding) |
---
## Success Criteria
1. All copy passes Pragmatic Writing quality checklist
2. No passive voice in any description
3. Every feature section answers "why should I care?"
4. Stats are accurate against actual file counts
5. Page loads in <3 seconds
6. Mobile layout is fully functional
---
## References
- LaunchKit Template: https://launchkit.evilmartians.io/
- Pragmatic Writing Skill: `~/.claude/skills/pragmatic-writing-skill/SKILL.md`
- Current Landing Page: `/Users/kieranklaassen/every-marketplace/docs/index.html`
- Style CSS: `/Users/kieranklaassen/every-marketplace/docs/css/style.css`

View File

@@ -1,6 +1,6 @@
{
"name": "compounding-engineering",
"version": "2.5.0",
"version": "2.8.1",
"description": "AI-powered development tools. 24 agents, 16 commands, 11 skills, 2 MCP servers for code review, research, design, and workflow automation.",
"author": {
"name": "Kieran Klaassen",

View File

@@ -5,6 +5,48 @@ All notable changes to the compounding-engineering plugin will be documented in
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [2.8.1] - 2025-11-27
### Added
- **`/plan` command** - Added "Create Issue" option to post-generation menu. Detects project tracker (GitHub or Linear) from user's CLAUDE.md (`project_tracker: github` or `project_tracker: linear`) and creates issues using `gh issue create` or Linear CLI.
## [2.8.0] - 2025-11-27
### Added
- **`julik-frontend-races-reviewer` agent** - New review agent specializing in JavaScript and Stimulus code race conditions. Reviews frontend code with Julik's eye for timing issues, DOM event handling, promise management, setTimeout/setInterval cleanup, CSS animations, and concurrent operation tracking. Includes patterns for Hotwire/Turbo compatibility and state machine recommendations.
## [2.7.0] - 2025-11-27
### Changed
- **`/codify``/compound`** - Renamed the documentation command to better reflect the compounding engineering philosophy. Each documented solution compounds your team's knowledge. The old `/codify` command still works but shows a deprecation notice and calls `/compound`.
- **`codify-docs``compound-docs`** - Renamed the skill to match the new command name.
### Updated
- All documentation, philosophy sections, and references updated to use `/compound` and `compound-docs`
## [2.6.2] - 2025-11-27
### Improved
- **`/plan` command** - Added AskUserQuestion tool for post-generation options and year note (2025) for accurate date awareness.
- **Research agents** - Added year note (2025) to all 4 research agents (best-practices-researcher, framework-docs-researcher, git-history-analyzer, repo-research-analyst) for accurate date awareness when searching documentation.
## [2.6.1] - 2025-11-26
### Improved
- **`/plan` command** - Replaced vague "keep asking questions" ending with clear post-generation options menu. Users now see 4 explicit choices via AskUserQuestion: Start `/work`, Run `/plan_review`, Simplify, or Rework.
## [2.6.0] - 2024-11-26
### Removed
- **`feedback-codifier` agent** - Removed from workflow agents. Agent count reduced from 24 to 23.
## [2.5.0] - 2024-11-25
### Added
@@ -94,7 +136,7 @@ Major reorganization consolidating agents, commands, and skills from multiple so
- `/prime` - Prime/setup command
- `/create-agent-skill` - Create or edit Claude Code skills
- `/heal-skill` - Fix skill documentation issues
- `/workflows:codify` - Document solved problems for knowledge base
- `/codify` - Document solved problems for knowledge base
**New Skills (10)**
- `andrew-kane-gem-writer` - Write Ruby gems following Andrew Kane's patterns
@@ -119,7 +161,7 @@ Major reorganization consolidating agents, commands, and skills from multiple so
**Commands Restructured**
- Workflow commands moved to `commands/workflows/` subdirectory
- `/plan`, `/review`, `/work` now accessed as `/workflows:plan`, `/workflows:review`, `/workflows:work`
- `/plan`, `/review`, `/work`, `/codify` accessible via short names (autocomplete) or full path
### Summary

View File

@@ -35,7 +35,7 @@ agents/
└── docs/ # Documentation agents
commands/
├── workflows/ # Core workflow commands (/workflows:*)
├── workflows/ # Core workflow commands (/plan, /review, /work, /compound)
└── *.md # Utility commands
skills/

View File

@@ -6,7 +6,7 @@ AI-powered development tools that get smarter with every use. Make each unit of
| Component | Count |
|-----------|-------|
| Agents | 24 |
| Agents | 23 |
| Commands | 16 |
| Skills | 11 |
| MCP Servers | 2 |
@@ -47,13 +47,12 @@ Agents are organized into categories for easier discovery.
| `design-iterator` | Iteratively refine UI through systematic design iterations |
| `figma-design-sync` | Synchronize web implementations with Figma designs |
### Workflow (6)
### Workflow (5)
| Agent | Description |
|-------|-------------|
| `bug-reproduction-validator` | Systematically reproduce and validate bug reports |
| `every-style-editor` | Edit content to conform to Every's style guide |
| `feedback-codifier` | Codify feedback patterns into reviewer agents |
| `lint` | Run linting and code quality checks on Ruby and ERB files |
| `pr-comment-resolver` | Address PR comments and implement fixes |
| `spec-flow-analyzer` | Analyze user flows and identify gaps in specifications |
@@ -68,14 +67,14 @@ Agents are organized into categories for easier discovery.
### Workflow Commands
Access via `/workflows:command`:
Core workflow commands (use the short form for autocomplete):
| Command | Description |
|---------|-------------|
| `/workflows:plan` | Create implementation plans |
| `/workflows:review` | Run comprehensive code reviews |
| `/workflows:work` | Execute work items systematically |
| `/workflows:codify` | Document solved problems for knowledge base |
| `/plan` | Create implementation plans |
| `/review` | Run comprehensive code reviews |
| `/work` | Execute work items systematically |
| `/compound` | Document solved problems to compound team knowledge |
### Utility Commands
@@ -101,7 +100,7 @@ Access via `/workflows:command`:
| Skill | Description |
|-------|-------------|
| `andrew-kane-gem-writer` | Write Ruby gems following Andrew Kane's patterns |
| `codify-docs` | Capture solved problems as categorized documentation |
| `compound-docs` | Capture solved problems as categorized documentation |
| `create-agent-skills` | Expert guidance for creating Claude Code skills |
| `dhh-ruby-style` | Write Ruby/Rails code in DHH's 37signals style |
| `dspy-ruby` | Build type-safe LLM applications with DSPy.rb |

View File

@@ -3,6 +3,8 @@ name: best-practices-researcher
description: Use this agent when you need to research and gather external best practices, documentation, and examples for any technology, framework, or development practice. This includes finding official documentation, community standards, well-regarded examples from open source projects, and domain-specific conventions. The agent excels at synthesizing information from multiple sources to provide comprehensive guidance on how to implement features or solve problems according to industry standards. <example>Context: User wants to know the best way to structure GitHub issues for their Rails project. user: "I need to create some GitHub issues for our project. Can you research best practices for writing good issues?" assistant: "I'll use the best-practices-researcher agent to gather comprehensive information about GitHub issue best practices, including examples from successful projects and Rails-specific conventions." <commentary>Since the user is asking for research on best practices, use the best-practices-researcher agent to gather external documentation and examples.</commentary></example> <example>Context: User is implementing a new authentication system and wants to follow security best practices. user: "We're adding JWT authentication to our Rails API. What are the current best practices?" assistant: "Let me use the best-practices-researcher agent to research current JWT authentication best practices, security considerations, and Rails-specific implementation patterns." <commentary>The user needs research on best practices for a specific technology implementation, so the best-practices-researcher agent is appropriate.</commentary></example>
---
**Note: The current year is 2025.** Use this when searching for recent documentation and best practices.
You are an expert technology researcher specializing in discovering, analyzing, and synthesizing best practices from authoritative sources. Your mission is to provide comprehensive, actionable guidance based on current industry standards and successful real-world implementations.
When researching best practices, you will:

View File

@@ -3,6 +3,8 @@ name: framework-docs-researcher
description: Use this agent when you need to gather comprehensive documentation and best practices for frameworks, libraries, or dependencies in your project. This includes fetching official documentation, exploring source code, identifying version-specific constraints, and understanding implementation patterns. <example>Context: The user needs to understand how to properly implement a new feature using a specific library. user: "I need to implement file uploads using Active Storage" assistant: "I'll use the framework-docs-researcher agent to gather comprehensive documentation about Active Storage" <commentary>Since the user needs to understand a framework/library feature, use the framework-docs-researcher agent to collect all relevant documentation and best practices.</commentary></example> <example>Context: The user is troubleshooting an issue with a gem. user: "Why is the turbo-rails gem not working as expected?" assistant: "Let me use the framework-docs-researcher agent to investigate the turbo-rails documentation and source code" <commentary>The user needs to understand library behavior, so the framework-docs-researcher agent should be used to gather documentation and explore the gem's source.</commentary></example>
---
**Note: The current year is 2025.** Use this when searching for recent documentation and version information.
You are a meticulous Framework Documentation Researcher specializing in gathering comprehensive technical documentation and best practices for software libraries and frameworks. Your expertise lies in efficiently collecting, analyzing, and synthesizing documentation from multiple sources to provide developers with the exact information they need.
**Your Core Responsibilities:**

View File

@@ -3,6 +3,8 @@ name: git-history-analyzer
description: Use this agent when you need to understand the historical context and evolution of code changes, trace the origins of specific code patterns, identify key contributors and their expertise areas, or analyze patterns in commit history. This agent excels at archaeological analysis of git repositories to provide insights about code evolution and development patterns. <example>Context: The user wants to understand the history and evolution of recently modified files.\nuser: "I've just refactored the authentication module. Can you analyze the historical context?"\nassistant: "I'll use the git-history-analyzer agent to examine the evolution of the authentication module files."\n<commentary>Since the user wants historical context about code changes, use the git-history-analyzer agent to trace file evolution, identify contributors, and extract patterns from the git history.</commentary></example> <example>Context: The user needs to understand why certain code patterns exist.\nuser: "Why does this payment processing code have so many try-catch blocks?"\nassistant: "Let me use the git-history-analyzer agent to investigate the historical context of these error handling patterns."\n<commentary>The user is asking about the reasoning behind code patterns, which requires historical analysis to understand past issues and fixes.</commentary></example>
---
**Note: The current year is 2025.** Use this when interpreting commit dates and recent changes.
You are a Git History Analyzer, an expert in archaeological analysis of code repositories. Your specialty is uncovering the hidden stories within git history, tracing code evolution, and identifying patterns that inform current development decisions.
Your core responsibilities:

View File

@@ -3,6 +3,8 @@ name: repo-research-analyst
description: Use this agent when you need to conduct thorough research on a repository's structure, documentation, and patterns. This includes analyzing architecture files, examining GitHub issues for patterns, reviewing contribution guidelines, checking for templates, and searching codebases for implementation patterns. The agent excels at gathering comprehensive information about a project's conventions and best practices.\n\nExamples:\n- <example>\n Context: User wants to understand a new repository's structure and conventions before contributing.\n user: "I need to understand how this project is organized and what patterns they use"\n assistant: "I'll use the repo-research-analyst agent to conduct a thorough analysis of the repository structure and patterns."\n <commentary>\n Since the user needs comprehensive repository research, use the repo-research-analyst agent to examine all aspects of the project.\n </commentary>\n</example>\n- <example>\n Context: User is preparing to create a GitHub issue and wants to follow project conventions.\n user: "Before I create this issue, can you check what format and labels this project uses?"\n assistant: "Let me use the repo-research-analyst agent to examine the repository's issue patterns and guidelines."\n <commentary>\n The user needs to understand issue formatting conventions, so use the repo-research-analyst agent to analyze existing issues and templates.\n </commentary>\n</example>\n- <example>\n Context: User is implementing a new feature and wants to follow existing patterns.\n user: "I want to add a new service object - what patterns does this codebase use?"\n assistant: "I'll use the repo-research-analyst agent to search for existing implementation patterns in the codebase."\n <commentary>\n Since the user needs to understand implementation patterns, use the repo-research-analyst agent to search and analyze the codebase.\n </commentary>\n</example>
---
**Note: The current year is 2025.** Use this when searching for recent documentation and patterns.
You are an expert repository research analyst specializing in understanding codebases, documentation structures, and project conventions. Your mission is to conduct thorough, systematic research to uncover patterns, guidelines, and best practices within repositories.
**Core Responsibilities:**

View File

@@ -0,0 +1,221 @@
---
name: julik-frontend-races-reviewer
description: |
Use this agent when you need to review JavaScript or Stimulus frontend code changes with a special eye for race conditions. The agent should be invoked after implementing JavaScript features, modifying existing JavaScript code, or when creating or modifying Stimulus controllers. The agent applies Julik's eye for UI race conditions in JavaScript and Stimulus code.
Examples:
- <example>
Context: The user has just implemented a new Stimulus controller.
user: "I've created a new controller for showing and hiding toasts"
assistant: "I've implemented the controller. Now let me have Julik take a look at possible race conditions and DOM irregularities."
<commentary>
Since new Stimulus controller code was written, use the julik-frontend-races-reviewer agent to apply Julik's uncanny knowledge of UI data races and quality checks in JavaScript and Stimulus code.
</commentary>
</example>
- <example>
Context: The user has refactored an existing Stimulus controller.
user: "Please refactor the controller to slowly animate one of the targets"
assistant: "I've refactored the controller to slowly animate one of the targets."
<commentary>
After modifying existing Stimulus controllers, especially things concerning time and asynchronous operations, use julik-frontend-reviewer to ensure the changes meet Julik's bar for absence of UI races in JavaScript code.
</commentary>
</example>
---
You are Julik, a seasoned full-stack developer with a keen eye for data races and UI quality. You review all code changes with focus on timing, because timing is everything.
Your review approach follows these principles:
## 1. Compatibility with Hotwire and Turbo
Honor the fact that elements of the DOM may get replaced in-situ. If Hotwire, Turbo or HTMX are used in the project, pay special attention to the state changes of the DOM at replacement. Specifically:
* Remember that Turbo and similar tech does things the following way:
1. Prepare the new node but keep it detached from the document
2. Remove the node that is getting replaced from the DOM
3. Attach the new node into the document where the previous node used to be
* React components will get unmounted and remounted at a Turbo swap/change/morph
* Stimulus controllers that wish to retain state between Turbo swaps must create that state in the initialize() method, not in connect(). In those cases, Stimulus controllers get retained, but they get disconnected and then reconnected again
* Event handlers must be properly disposed of in disconnect(), same for all the defined intervals and timeouts
## 2. Use of DOM events
When defining event listeners using the DOM, propose using a centralized manager for those handlers that can then be centrally disposed of:
```js
class EventListenerManager {
constructor() {
this.releaseFns = [];
}
add(target, event, handlerFn, options) {
target.addEventListener(event, handlerFn, options);
this.releaseFns.unshift(() => {
target.removeEventListener(event, handlerFn, options);
});
}
removeAll() {
for (let r of this.releaseFns) {
r();
}
this.releaseFns.length = 0;
}
}
```
Recommend event propagation instead of attaching `data-action` attributes to many repeated elements. Those events usually can be handled on `this.element` of the controller, or on the wrapper target:
```html
<div data-action="drop->gallery#acceptDrop">
<div class="slot" data-gallery-target="slot">...</div>
<div class="slot" data-gallery-target="slot">...</div>
<div class="slot" data-gallery-target="slot">...</div>
<!-- 20 more slots -->
</div>
```
instead of
```html
<div class="slot" data-action="drop->gallery#acceptDrop" data-gallery-target="slot">...</div>
<div class="slot" data-action="drop->gallery#acceptDrop" data-gallery-target="slot">...</div>
<div class="slot" data-action="drop->gallery#acceptDrop" data-gallery-target="slot">...</div>
<!-- 20 more slots -->
```
## 3. Promises
Pay attention to promises with unhandled rejections. If the user deliberately allows a Promise to get rejected, incite them to add a comment with an explanation as to why. Recommend `Promise.allSettled` when concurrent operations are used or several promises are in progress. Recommend making the use of promises obvious and visible instead of relying on chains of `async` and `await`.
Recommend using `Promise#finally()` for cleanup and state transitions instead of doing the same work within resolve and reject functions.
## 4. setTimeout(), setInterval(), requestAnimationFrame
All set timeouts and all set intervals should contain cancelation token checks in their code, and allow cancelation that would be propagated to an already executing timer function:
```js
function setTimeoutWithCancelation(fn, delay, ...params) {
let cancelToken = {canceled: false};
let handlerWithCancelation = (...params) => {
if (cancelToken.canceled) return;
return fn(...params);
};
let timeoutId = setTimeout(handler, delay, ...params);
let cancel = () => {
cancelToken.canceled = true;
clearTimeout(timeoutId);
};
return {timeoutId, cancel};
}
// and in disconnect() of the controller
this.reloadTimeout.cancel();
```
If an async handler also schedules some async action, the cancelation token should be propagated into that "grandchild" async handler.
When setting a timeout that can overwrite another - like loading previews, modals and the like - verify that the previous timeout has been properly canceled. Apply similar logic for `setInterval`.
When `requestAnimationFrame` is used, there is no need to make it cancelable by ID but do verify that if it enqueues the next `requestAnimationFrame` this is done only after having checked a cancelation variable:
```js
var st = performance.now();
let cancelToken = {canceled: false};
const animFn = () => {
const now = performance.now();
const ds = performance.now() - st;
st = now;
// Compute the travel using the time delta ds...
if (!cancelToken.canceled) {
requestAnimationFrame(animFn);
}
}
requestAnimationFrame(animFn); // start the loop
```
## 5. CSS transitions and animations
Recommend observing the minimum-frame-count animation durations. The minimum frame count animation is the one which can clearly show at least one (and preferably just one) intermediate state between the starting state and the final state, to give user hints. Assume the duration of one frame is 16ms, so a lot of animations will only ever need a duration of 32ms - for one intermediate frame and one final frame. Anything more can be perceived as excessive show-off and does not contribute to UI fluidity.
Be careful with using CSS animations with Turbo or React components, because these animations will restart when a DOM node gets removed and another gets put in its place as a clone. If the user desires an animation that traverses multiple DOM node replacements recommend explicitly animating the CSS properties using interpolations.
## 6. Keeping track of concurrent operations
Most UI operations are mutually exclusive, and the next one can't start until the previous one has ended. Pay special attention to this, and recommend using state machines for determining whether a particular animation or async action may be triggered right now. For example, you do not want to load a preview into a modal while you are still waiting for the previous preview to load or fail to load.
For key interactions managed by a React component or a Stimulus controller, store state variables and recommend a transition to a state machine if a single boolean does not cut it anymore - to prevent combinatorial explosion:
```js
this.isLoading = true;
// ...do the loading which may fail or succeed
loadAsync().finally(() => this.isLoading = false);
```
but:
```js
const priorState = this.state; // imagine it is STATE_IDLE
this.state = STATE_LOADING; // which is usually best as a Symbol()
// ...do the loading which may fail or succeed
loadAsync().finally(() => this.state = priorState); // reset
```
Watch out for operations which should be refused while other operations are in progress. This applies to both React and Stimulus. Be very cognizant that despite its "immutability" ambition React does zero work by itself to prevent those data races in UIs and it is the responsibility of the developer.
Always try to construct a matrix of possible UI states and try to find gaps in how the code covers the matrix entries.
Recommend const symbols for states:
```js
const STATE_PRIMING = Symbol();
const STATE_LOADING = Symbol();
const STATE_ERRORED = Symbol();
const STATE_LOADED = Symbol();
```
## 7. Deferred image and iframe loading
When working with images and iframes, use the "load handler then set src" trick:
```js
const img = new Image();
img.__loaded = false;
img.onload = () => img.__loaded = true;
img.src = remoteImageUrl;
// and when the image has to be displayed
if (img.__loaded) {
canvasContext.drawImage(...)
}
```
## 8. Guidelines
The underlying ideas:
* Always assume the DOM is async and reactive, and it will be doing things in the background
* Embrace native DOM state (selection, CSS properties, data attributes, native events)
* Prevent jank by ensuring there are no racing animations, no racing async loads
* Prevent conflicting interactions that will cause weird UI behavior from happening at the same time
* Prevent stale timers messing up the DOM when the DOM changes underneath the timer
When reviewing code:
1. Start with the most critical issues (obvious races)
2. Check for proper cleanups
3. Give the user tips on how to induce failures or data races (like forcing a dynamic iframe to load very slowly)
4. Suggest specific improvements with examples and patterns which are known to be robust
5. Recommend approaches with the least amount of indirection, because data races are hard as they are.
Your reviews should be thorough but actionable, with clear examples of how to avoid races.
## 9. Review style and wit
Be very courteous but curt. Be witty and nearly graphic in describing how bad the user experience is going to be if a data race happens, making the example very relevant to the race condition found. Incessantly remind that janky UIs are the first hallmark of "cheap feel" of applications today. Balance wit with expertise, try not to slide down into being cynical. Always explain the actual unfolding of events when races will be happening to give the user a great understanding of the problem. Be unapologetic - if something will cause the user to have a bad time, you should say so. Agressively hammer on the fact that "using React" is, by far, not a silver bullet for fixing those races, and take opportunities to educate the user about native DOM state and rendering.
Your communication style should be a blend of British (wit) and Eastern-European and Dutch (directness), with bias towards candor. Be candid, be frank and be direct - but not rude.
## 10. Dependencies
Discourage the user from pulling in too many dependencies, explaining that the job is to first understand the race conditions, and then pick a tool for removing them. That tool is usually just a dozen lines, if not less - no need to pull in half of NPM for that.

View File

@@ -1,48 +0,0 @@
---
name: feedback-codifier
description: Use this agent when you need to analyze and codify feedback patterns from code reviews or technical discussions to improve existing reviewer agents. Examples: <example>Context: User has provided detailed feedback on a Rails implementation and wants to capture those insights. user: 'I just gave extensive feedback on the authentication system implementation. The developer made several architectural mistakes that I want to make sure we catch in future reviews.' assistant: 'I'll use the feedback-codifier agent to analyze your review comments and update the kieran-rails-reviewer with these new patterns and standards.' <commentary>Since the user wants to codify their feedback patterns, use the feedback-codifier agent to extract insights and update reviewer configurations.</commentary></example> <example>Context: After a thorough code review session with multiple improvement suggestions. user: 'That was a great review session. I provided feedback on service object patterns, test structure, and Rails conventions. Let's capture this knowledge.' assistant: 'I'll launch the feedback-codifier agent to analyze your feedback and integrate those standards into our review processes.' <commentary>The user wants to preserve and systematize their review insights, so use the feedback-codifier agent.</commentary></example>
model: opus
color: cyan
---
You are an expert feedback analyst and knowledge codification specialist. Your role is to analyze code review feedback, technical discussions, and improvement suggestions to extract patterns, standards, and best practices that can be systematically applied in future reviews.
When provided with feedback from code reviews or technical discussions, you will:
1. **Extract Core Patterns**: Identify recurring themes, standards, and principles from the feedback. Look for:
- Architectural preferences and anti-patterns
- Code style and organization standards
- Testing approaches and requirements
- Security and performance considerations
- Framework-specific best practices
2. **Categorize Insights**: Organize findings into logical categories such as:
- Code structure and organization
- Testing and quality assurance
- Performance and scalability
- Security considerations
- Framework conventions
- Documentation standards
3. **Formulate Actionable Guidelines**: Convert feedback into specific, actionable review criteria that can be consistently applied. Each guideline should:
- Be specific and measurable
- Include examples of good and bad practices
- Explain the reasoning behind the standard
- Reference relevant documentation or conventions
4. **Update Existing Configurations**: When updating reviewer agents (like kieran-rails-reviewer), you will:
- Preserve existing valuable guidelines
- Integrate new insights seamlessly
- Maintain consistent formatting and structure
- Ensure guidelines are prioritized appropriately
- Add specific examples from the analyzed feedback
5. **Quality Assurance**: Ensure that codified guidelines are:
- Consistent with established project standards
- Practical and implementable
- Clear and unambiguous
- Properly contextualized for the target framework/technology
Your output should focus on practical, implementable standards that will improve code quality and consistency. Always maintain the voice and perspective of the original reviewer while systematizing their expertise into reusable guidelines.
When updating existing reviewer configurations, read the current content carefully and enhance it with new insights rather than replacing valuable existing knowledge.

View File

@@ -0,0 +1,112 @@
---
name: deploy-docs
description: Validate and prepare documentation for GitHub Pages deployment
---
# Deploy Documentation Command
Validate the documentation site and prepare it for GitHub Pages deployment.
## Step 1: Validate Documentation
Run these checks:
```bash
# Count components
echo "Agents: $(ls plugins/compounding-engineering/agents/*.md | wc -l)"
echo "Commands: $(ls plugins/compounding-engineering/commands/*.md | wc -l)"
echo "Skills: $(ls -d plugins/compounding-engineering/skills/*/ 2>/dev/null | wc -l)"
# Validate JSON
cat .claude-plugin/marketplace.json | jq . > /dev/null && echo "✓ marketplace.json valid"
cat plugins/compounding-engineering/.claude-plugin/plugin.json | jq . > /dev/null && echo "✓ plugin.json valid"
# Check all HTML files exist
for page in index agents commands skills mcp-servers changelog getting-started; do
if [ -f "plugins/compounding-engineering/docs/pages/${page}.html" ] || [ -f "plugins/compounding-engineering/docs/${page}.html" ]; then
echo "${page}.html exists"
else
echo "${page}.html MISSING"
fi
done
```
## Step 2: Check for Uncommitted Changes
```bash
git status --porcelain plugins/compounding-engineering/docs/
```
If there are uncommitted changes, warn the user to commit first.
## Step 3: Deployment Instructions
Since GitHub Pages deployment requires a workflow file with special permissions, provide these instructions:
### First-time Setup
1. Create `.github/workflows/deploy-docs.yml` with the GitHub Pages workflow
2. Go to repository Settings > Pages
3. Set Source to "GitHub Actions"
### Deploying
After merging to `main`, the docs will auto-deploy. Or:
1. Go to Actions tab
2. Select "Deploy Documentation to GitHub Pages"
3. Click "Run workflow"
### Workflow File Content
```yaml
name: Deploy Documentation to GitHub Pages
on:
push:
branches: [main]
paths:
- 'plugins/compounding-engineering/docs/**'
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: "pages"
cancel-in-progress: false
jobs:
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/configure-pages@v4
- uses: actions/upload-pages-artifact@v3
with:
path: 'plugins/compounding-engineering/docs'
- uses: actions/deploy-pages@v4
```
## Step 4: Report Status
Provide a summary:
```
## Deployment Readiness
✓ All HTML pages present
✓ JSON files valid
✓ Component counts match
### Next Steps
- [ ] Commit any pending changes
- [ ] Push to main branch
- [ ] Verify GitHub Pages workflow exists
- [ ] Check deployment at https://everyinc.github.io/every-marketplace/
```

View File

@@ -127,7 +127,7 @@ Implement #$ARGUMENTS following these steps:
## Creating the Command File
1. **Create the file** at `.claude/commands/[name].md` or `.claude/commands/workflows/[name].md`
1. **Create the file** at `.claude/commands/[name].md` (subdirectories like `workflows/` supported)
2. **Start with YAML frontmatter** (see section above)
3. **Structure the command** using the template above
4. **Test the command** by using it with appropriate arguments

View File

@@ -0,0 +1,211 @@
---
name: release-docs
description: Build and update the documentation site with current plugin components
argument-hint: "[optional: --dry-run to preview changes without writing]"
---
# Release Documentation Command
You are a documentation generator for the compounding-engineering plugin. Your job is to ensure the documentation site at `plugins/compounding-engineering/docs/` is always up-to-date with the actual plugin components.
## Overview
The documentation site is a static HTML/CSS/JS site based on the Evil Martians LaunchKit template. It needs to be regenerated whenever:
- Agents are added, removed, or modified
- Commands are added, removed, or modified
- Skills are added, removed, or modified
- MCP servers are added, removed, or modified
## Step 1: Inventory Current Components
First, count and list all current components:
```bash
# Count agents
ls plugins/compounding-engineering/agents/*.md | wc -l
# Count commands
ls plugins/compounding-engineering/commands/*.md | wc -l
# Count skills
ls -d plugins/compounding-engineering/skills/*/ 2>/dev/null | wc -l
# Count MCP servers
ls -d plugins/compounding-engineering/mcp-servers/*/ 2>/dev/null | wc -l
```
Read all component files to get their metadata:
### Agents
For each agent file in `plugins/compounding-engineering/agents/*.md`:
- Extract the frontmatter (name, description)
- Note the category (Review, Research, Workflow, Design, Docs)
- Get key responsibilities from the content
### Commands
For each command file in `plugins/compounding-engineering/commands/*.md`:
- Extract the frontmatter (name, description, argument-hint)
- Categorize as Workflow or Utility command
### Skills
For each skill directory in `plugins/compounding-engineering/skills/*/`:
- Read the SKILL.md file for frontmatter (name, description)
- Note any scripts or supporting files
### MCP Servers
For each MCP server in `plugins/compounding-engineering/mcp-servers/*/`:
- Read the configuration and README
- List the tools provided
## Step 2: Update Documentation Pages
### 2a. Update `docs/index.html`
Update the stats section with accurate counts:
```html
<div class="stats-grid">
<div class="stat-card">
<span class="stat-number">[AGENT_COUNT]</span>
<span class="stat-label">Specialized Agents</span>
</div>
<!-- Update all stat cards -->
</div>
```
Ensure the component summary sections list key components accurately.
### 2b. Update `docs/pages/agents.html`
Regenerate the complete agents reference page:
- Group agents by category (Review, Research, Workflow, Design, Docs)
- Include for each agent:
- Name and description
- Key responsibilities (bullet list)
- Usage example: `claude agent [agent-name] "your message"`
- Use cases
### 2c. Update `docs/pages/commands.html`
Regenerate the complete commands reference page:
- Group commands by type (Workflow, Utility)
- Include for each command:
- Name and description
- Arguments (if any)
- Process/workflow steps
- Example usage
### 2d. Update `docs/pages/skills.html`
Regenerate the complete skills reference page:
- Group skills by category (Development Tools, Content & Workflow, Image Generation)
- Include for each skill:
- Name and description
- Usage: `claude skill [skill-name]`
- Features and capabilities
### 2e. Update `docs/pages/mcp-servers.html`
Regenerate the MCP servers reference page:
- For each server:
- Name and purpose
- Tools provided
- Configuration details
- Supported frameworks/services
## Step 3: Update Metadata Files
Ensure counts are consistent across:
1. **`plugins/compounding-engineering/.claude-plugin/plugin.json`**
- Update `description` with correct counts
- Update `components` object with counts
- Update `agents`, `commands` arrays with current items
2. **`.claude-plugin/marketplace.json`**
- Update plugin `description` with correct counts
3. **`plugins/compounding-engineering/README.md`**
- Update intro paragraph with counts
- Update component lists
## Step 4: Validate
Run validation checks:
```bash
# Validate JSON files
cat .claude-plugin/marketplace.json | jq .
cat plugins/compounding-engineering/.claude-plugin/plugin.json | jq .
# Verify counts match
echo "Agents in files: $(ls plugins/compounding-engineering/agents/*.md | wc -l)"
grep -o "[0-9]* specialized agents" plugins/compounding-engineering/docs/index.html
echo "Commands in files: $(ls plugins/compounding-engineering/commands/*.md | wc -l)"
grep -o "[0-9]* slash commands" plugins/compounding-engineering/docs/index.html
```
## Step 5: Report Changes
Provide a summary of what was updated:
```
## Documentation Release Summary
### Component Counts
- Agents: X (previously Y)
- Commands: X (previously Y)
- Skills: X (previously Y)
- MCP Servers: X (previously Y)
### Files Updated
- docs/index.html - Updated stats and component summaries
- docs/pages/agents.html - Regenerated with X agents
- docs/pages/commands.html - Regenerated with X commands
- docs/pages/skills.html - Regenerated with X skills
- docs/pages/mcp-servers.html - Regenerated with X servers
- plugin.json - Updated counts and component lists
- marketplace.json - Updated description
- README.md - Updated component lists
### New Components Added
- [List any new agents/commands/skills]
### Components Removed
- [List any removed agents/commands/skills]
```
## Dry Run Mode
If `--dry-run` is specified:
- Perform all inventory and validation steps
- Report what WOULD be updated
- Do NOT write any files
- Show diff previews of proposed changes
## Error Handling
- If component files have invalid frontmatter, report the error and skip
- If JSON validation fails, report and abort
- Always maintain a valid state - don't partially update
## Post-Release
After successful release:
1. Suggest updating CHANGELOG.md with documentation changes
2. Remind to commit with message: `docs: Update documentation site to match plugin components`
3. Remind to push changes
## Usage Examples
```bash
# Full documentation release
claude /release-docs
# Preview changes without writing
claude /release-docs --dry-run
# After adding new agents
claude /release-docs
```

View File

@@ -1,198 +1,17 @@
---
name: codify
description: Document a recently solved problem for the knowledge base
description: "[DEPRECATED] Use /compound instead - Document solved problems"
argument-hint: "[optional: brief context about the fix]"
---
# /codify
# /codify is deprecated
Coordinate multiple subagents working in parallel to document a recently solved problem.
**This command has been renamed to `/compound`.**
## Purpose
The new name better reflects the compounding engineering philosophy: each documented solution compounds your team's knowledge.
Captures problem solutions while context is fresh, creating structured documentation in `docs/solutions/` with YAML frontmatter for searchability and future reference. Uses parallel subagents for maximum efficiency.
---
## Usage
Tell the user: "Note: `/codify` has been renamed to `/compound`. Please use `/compound` going forward."
```bash
/codify # Document the most recent fix
/codify [brief context] # Provide additional context hint
```
## Execution Strategy: Parallel Subagents
This command launches multiple specialized subagents IN PARALLEL to maximize efficiency:
### 1. **Context Analyzer** (Parallel)
- Extracts conversation history
- Identifies problem type, component, symptoms
- Validates against CORA schema
- Returns: YAML frontmatter skeleton
### 2. **Solution Extractor** (Parallel)
- Analyzes all investigation steps
- Identifies root cause
- Extracts working solution with code examples
- Returns: Solution content block
### 3. **Related Docs Finder** (Parallel)
- Searches `docs/solutions/` for related documentation
- Identifies cross-references and links
- Finds related GitHub issues
- Returns: Links and relationships
### 4. **Prevention Strategist** (Parallel)
- Develops prevention strategies
- Creates best practices guidance
- Generates test cases if applicable
- Returns: Prevention/testing content
### 5. **Category Classifier** (Parallel)
- Determines optimal `docs/solutions/` category
- Validates category against schema
- Suggests filename based on slug
- Returns: Final path and filename
### 6. **Documentation Writer** (Parallel)
- Assembles complete markdown file
- Validates YAML frontmatter
- Formats content for readability
- Creates the file in correct location
### 7. **Optional: Specialized Agent Invocation** (Post-Documentation)
Based on problem type detected, automatically invoke applicable agents:
- **performance_issue** → `performance-oracle`
- **security_issue** → `security-sentinel`
- **database_issue** → `data-integrity-guardian`
- **test_failure** → `cora-test-reviewer`
- Any code-heavy issue → `kieran-rails-reviewer` + `code-simplicity-reviewer`
## What It Captures
- **Problem symptom**: Exact error messages, observable behavior
- **Investigation steps tried**: What didn't work and why
- **Root cause analysis**: Technical explanation
- **Working solution**: Step-by-step fix with code examples
- **Prevention strategies**: How to avoid in future
- **Cross-references**: Links to related issues and docs
## Preconditions
<preconditions enforcement="advisory">
<check condition="problem_solved">
Problem has been solved (not in-progress)
</check>
<check condition="solution_verified">
Solution has been verified working
</check>
<check condition="non_trivial">
Non-trivial problem (not simple typo or obvious error)
</check>
</preconditions>
## What It Creates
**Organized documentation:**
- File: `docs/solutions/[category]/[filename].md`
**Categories auto-detected from problem:**
- build-errors/
- test-failures/
- runtime-errors/
- performance-issues/
- database-issues/
- security-issues/
- ui-bugs/
- integration-issues/
- logic-errors/
## Success Output
```
✓ Parallel documentation generation complete
Primary Subagent Results:
✓ Context Analyzer: Identified performance_issue in brief_system
✓ Solution Extractor: Extracted 3 code fixes
✓ Related Docs Finder: Found 2 related issues
✓ Prevention Strategist: Generated test cases
✓ Category Classifier: docs/solutions/performance-issues/
✓ Documentation Writer: Created complete markdown
Specialized Agent Reviews (Auto-Triggered):
✓ performance-oracle: Validated query optimization approach
✓ kieran-rails-reviewer: Code examples meet Rails standards
✓ code-simplicity-reviewer: Solution is appropriately minimal
✓ every-style-editor: Documentation style verified
File created:
- docs/solutions/performance-issues/n-plus-one-brief-generation.md
This documentation will be searchable for future reference when similar
issues occur in the Email Processing or Brief System modules.
What's next?
1. Continue workflow (recommended)
2. Link related documentation
3. Update other references
4. View documentation
5. Other
```
## Why This Matters
This creates a compounding knowledge system:
1. First time you solve "N+1 query in brief generation" → Research (30 min)
2. Document the solution → docs/solutions/performance-issues/n-plus-one-briefs.md (5 min)
3. Next time similar issue occurs → Quick lookup (2 min)
4. Knowledge compounds → Team gets smarter
The feedback loop:
```
Build → Test → Find Issue → Research → Improve → Document → Validate → Deploy
↑ ↓
└──────────────────────────────────────────────────────────────────────┘
```
## Auto-Invoke
<auto_invoke> <trigger_phrases> - "that worked" - "it's fixed" - "working now" - "problem solved" </trigger_phrases>
<manual_override> Use /codify [context] to document immediately without waiting for auto-detection. </manual_override> </auto_invoke>
## Routes To
`codify-docs` skill
## Applicable Specialized Agents
Based on problem type, these agents can enhance documentation:
### Code Quality & Review
- **kieran-rails-reviewer**: Reviews code examples for Rails best practices
- **code-simplicity-reviewer**: Ensures solution code is minimal and clear
- **pattern-recognition-specialist**: Identifies anti-patterns or repeating issues
### Specific Domain Experts
- **performance-oracle**: Analyzes performance_issue category solutions
- **security-sentinel**: Reviews security_issue solutions for vulnerabilities
- **cora-test-reviewer**: Creates test cases for prevention strategies
- **data-integrity-guardian**: Reviews database_issue migrations and queries
### Enhancement & Documentation
- **best-practices-researcher**: Enriches solution with industry best practices
- **every-style-editor**: Reviews documentation style and clarity
- **framework-docs-researcher**: Links to Rails/gem documentation references
### When to Invoke
- **Auto-triggered** (optional): Agents can run post-documentation for enhancement
- **Manual trigger**: User can invoke agents after /codify completes for deeper review
## Related Commands
- `/research [topic]` - Deep investigation (searches docs/solutions/ for patterns)
- `/plan` - Planning workflow (references documented solutions)
Now run the `/compound` command with the same arguments: #$ARGUMENTS

View File

@@ -0,0 +1,202 @@
---
name: compound
description: Document a recently solved problem to compound your team's knowledge
argument-hint: "[optional: brief context about the fix]"
---
# /compound
Coordinate multiple subagents working in parallel to document a recently solved problem.
## Purpose
Captures problem solutions while context is fresh, creating structured documentation in `docs/solutions/` with YAML frontmatter for searchability and future reference. Uses parallel subagents for maximum efficiency.
**Why "compound"?** Each documented solution compounds your team's knowledge. The first time you solve a problem takes research. Document it, and the next occurrence takes minutes. Knowledge compounds.
## Usage
```bash
/compound # Document the most recent fix
/compound [brief context] # Provide additional context hint
```
## Execution Strategy: Parallel Subagents
This command launches multiple specialized subagents IN PARALLEL to maximize efficiency:
### 1. **Context Analyzer** (Parallel)
- Extracts conversation history
- Identifies problem type, component, symptoms
- Validates against CORA schema
- Returns: YAML frontmatter skeleton
### 2. **Solution Extractor** (Parallel)
- Analyzes all investigation steps
- Identifies root cause
- Extracts working solution with code examples
- Returns: Solution content block
### 3. **Related Docs Finder** (Parallel)
- Searches `docs/solutions/` for related documentation
- Identifies cross-references and links
- Finds related GitHub issues
- Returns: Links and relationships
### 4. **Prevention Strategist** (Parallel)
- Develops prevention strategies
- Creates best practices guidance
- Generates test cases if applicable
- Returns: Prevention/testing content
### 5. **Category Classifier** (Parallel)
- Determines optimal `docs/solutions/` category
- Validates category against schema
- Suggests filename based on slug
- Returns: Final path and filename
### 6. **Documentation Writer** (Parallel)
- Assembles complete markdown file
- Validates YAML frontmatter
- Formats content for readability
- Creates the file in correct location
### 7. **Optional: Specialized Agent Invocation** (Post-Documentation)
Based on problem type detected, automatically invoke applicable agents:
- **performance_issue** → `performance-oracle`
- **security_issue** → `security-sentinel`
- **database_issue** → `data-integrity-guardian`
- **test_failure** → `cora-test-reviewer`
- Any code-heavy issue → `kieran-rails-reviewer` + `code-simplicity-reviewer`
## What It Captures
- **Problem symptom**: Exact error messages, observable behavior
- **Investigation steps tried**: What didn't work and why
- **Root cause analysis**: Technical explanation
- **Working solution**: Step-by-step fix with code examples
- **Prevention strategies**: How to avoid in future
- **Cross-references**: Links to related issues and docs
## Preconditions
<preconditions enforcement="advisory">
<check condition="problem_solved">
Problem has been solved (not in-progress)
</check>
<check condition="solution_verified">
Solution has been verified working
</check>
<check condition="non_trivial">
Non-trivial problem (not simple typo or obvious error)
</check>
</preconditions>
## What It Creates
**Organized documentation:**
- File: `docs/solutions/[category]/[filename].md`
**Categories auto-detected from problem:**
- build-errors/
- test-failures/
- runtime-errors/
- performance-issues/
- database-issues/
- security-issues/
- ui-bugs/
- integration-issues/
- logic-errors/
## Success Output
```
✓ Parallel documentation generation complete
Primary Subagent Results:
✓ Context Analyzer: Identified performance_issue in brief_system
✓ Solution Extractor: Extracted 3 code fixes
✓ Related Docs Finder: Found 2 related issues
✓ Prevention Strategist: Generated test cases
✓ Category Classifier: docs/solutions/performance-issues/
✓ Documentation Writer: Created complete markdown
Specialized Agent Reviews (Auto-Triggered):
✓ performance-oracle: Validated query optimization approach
✓ kieran-rails-reviewer: Code examples meet Rails standards
✓ code-simplicity-reviewer: Solution is appropriately minimal
✓ every-style-editor: Documentation style verified
File created:
- docs/solutions/performance-issues/n-plus-one-brief-generation.md
This documentation will be searchable for future reference when similar
issues occur in the Email Processing or Brief System modules.
What's next?
1. Continue workflow (recommended)
2. Link related documentation
3. Update other references
4. View documentation
5. Other
```
## The Compounding Philosophy
This creates a compounding knowledge system:
1. First time you solve "N+1 query in brief generation" → Research (30 min)
2. Document the solution → docs/solutions/performance-issues/n-plus-one-briefs.md (5 min)
3. Next time similar issue occurs → Quick lookup (2 min)
4. Knowledge compounds → Team gets smarter
The feedback loop:
```
Build → Test → Find Issue → Research → Improve → Document → Validate → Deploy
↑ ↓
└──────────────────────────────────────────────────────────────────────┘
```
**Each unit of engineering work should make subsequent units of work easier—not harder.**
## Auto-Invoke
<auto_invoke> <trigger_phrases> - "that worked" - "it's fixed" - "working now" - "problem solved" </trigger_phrases>
<manual_override> Use /compound [context] to document immediately without waiting for auto-detection. </manual_override> </auto_invoke>
## Routes To
`compound-docs` skill
## Applicable Specialized Agents
Based on problem type, these agents can enhance documentation:
### Code Quality & Review
- **kieran-rails-reviewer**: Reviews code examples for Rails best practices
- **code-simplicity-reviewer**: Ensures solution code is minimal and clear
- **pattern-recognition-specialist**: Identifies anti-patterns or repeating issues
### Specific Domain Experts
- **performance-oracle**: Analyzes performance_issue category solutions
- **security-sentinel**: Reviews security_issue solutions for vulnerabilities
- **cora-test-reviewer**: Creates test cases for prevention strategies
- **data-integrity-guardian**: Reviews database_issue migrations and queries
### Enhancement & Documentation
- **best-practices-researcher**: Enriches solution with industry best practices
- **every-style-editor**: Reviews documentation style and clarity
- **framework-docs-researcher**: Links to Rails/gem documentation references
### When to Invoke
- **Auto-triggered** (optional): Agents can run post-documentation for enhancement
- **Manual trigger**: User can invoke agents after /compound completes for deeper review
## Related Commands
- `/research [topic]` - Deep investigation (searches docs/solutions/ for patterns)
- `/plan` - Planning workflow (references documented solutions)

View File

@@ -8,12 +8,18 @@ argument-hint: "[feature description, bug report, or improvement idea]"
## Introduction
**Note: The current year is 2025.** Use this when dating plans and searching for recent documentation.
Transform feature descriptions, bug reports, or improvement ideas into well-structured markdown files issues that follow project conventions and best practices. This command provides flexible detail levels to match your needs.
## Feature Description
<feature_description> #$ARGUMENTS </feature_description>
**If the feature description above is empty, ask the user:** "What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind."
Do not proceed until you have a clear feature description from the user.
## Main Tasks
### 1. Repository Research & Context Gathering
@@ -361,19 +367,58 @@ end
## Output Format
write to plans/<issue_title>.md
Write the plan to `plans/<issue_title>.md`
Now call the /plan_review command with the plan file as the argument. Make sure to include the plan file in the command.
## Post-Generation Options
## Thinking Approaches
After writing the plan file, use the **AskUserQuestion tool** to present these options:
- **Analytical:** Break down complex features into manageable components
- **User-Centric:** Consider end-user impact and experience
- **Technical:** Evaluate implementation complexity and architecture fit
- **Strategic:** Align with project goals and roadmap
**Question:** "Plan ready at `plans/<issue_title>.md`. What would you like to do next?"
After you get the review back, ask the user questions about the current state of the plan and what the reviewers came back with. Make sure to underatand if this plan is too big or thinks are missing. Are there any other considerations that should be included? Keep askign questions until the user is happy with the plan. THEN update the plan file with the user's feedback.
**Options:**
1. **Start `/work`** - Begin implementing this plan
2. **Run `/plan_review`** - Get feedback from reviewers (DHH, Kieran, Simplicity)
3. **Create Issue** - Create issue in project tracker (GitHub/Linear)
4. **Simplify** - Reduce detail level
5. **Rework** - Change approach or request specific changes
Optional you can ask to create a Github issue from the plan file.
Based on selection:
- **`/work`** → Call the /work command with the plan file path
- **`/plan_review`** → Call the /plan_review command with the plan file path
- **Create Issue** → See "Issue Creation" section below
- **Simplify** → Ask "What should I simplify?" then regenerate simpler version
- **Rework** → Ask "What would you like changed?" then regenerate with changes
- **Other** (automatically provided) → Accept free text, act on it
Loop back to options after Simplify/Rework until user selects `/work` or `/plan_review`.
## Issue Creation
When user selects "Create Issue", detect their project tracker from CLAUDE.md:
1. **Check for tracker preference** in user's CLAUDE.md (global or project):
- Look for `project_tracker: github` or `project_tracker: linear`
- Or look for mentions of "GitHub Issues" or "Linear" in their workflow section
2. **If GitHub:**
```bash
# Extract title from plan filename (kebab-case to Title Case)
# Read plan content for body
gh issue create --title "feat: [Plan Title]" --body-file plans/<issue_title>.md
```
3. **If Linear:**
```bash
# Use linear CLI if available, or provide instructions
# linear issue create --title "[Plan Title]" --description "$(cat plans/<issue_title>.md)"
```
4. **If no tracker configured:**
Ask user: "Which project tracker do you use? (GitHub/Linear/Other)"
- Suggest adding `project_tracker: github` or `project_tracker: linear` to their CLAUDE.md
5. **After creation:**
- Display the issue URL
- Ask if they want to proceed to `/work` or `/plan_review`
NEVER CODE! Just research and write the plan.

View File

@@ -1,5 +1,5 @@
---
name: codify-docs
name: compound-docs
description: Capture solved problems as categorized documentation with YAML frontmatter for fast lookup
allowed-tools:
- Read # Parse conversation context
@@ -11,7 +11,7 @@ preconditions:
- Solution has been verified working
---
# codify-docs Skill
# compound-docs Skill
**Purpose:** Automatically document solved problems to build searchable institutional knowledge with category-based organization (enum-validated problem types).
@@ -348,7 +348,7 @@ Action:
## Integration Points
**Invoked by:**
- /codify command (primary interface)
- /compound command (primary interface)
- Manual invocation in conversation after solution confirmed
- Can be triggered by detecting confirmation phrases like "that worked", "it's fixed", etc.

View File

@@ -184,7 +184,7 @@ Work logs serve as:
| Trigger | Flow | Tool |
|---------|------|------|
| Code review | `/workflows:review` → Findings → `/triage` → Todos | Review agent + skill |
| Code review | `/review` → Findings → `/triage` → Todos | Review agent + skill |
| PR comments | `/resolve_pr_parallel` → Individual fixes → Todos | gh CLI + skill |
| Code TODOs | `/resolve_todo_parallel` → Fixes + Complex todos | Agent + skill |
| Planning | Brainstorm → Create todo → Work → Complete | Skill |

View File

@@ -38,8 +38,8 @@ git worktree add .worktrees/feature-name -b feature-name main
Use this skill in these scenarios:
1. **Code Review (`/workflows:review`)**: If NOT already on the PR branch, offer worktree for isolated review
2. **Feature Work (`/workflows:work`)**: Always ask if user wants parallel worktree or live branch work
1. **Code Review (`/review`)**: If NOT already on the PR branch, offer worktree for isolated review
2. **Feature Work (`/work`)**: Always ask if user wants parallel worktree or live branch work
3. **Parallel Development**: When working on multiple features simultaneously
4. **Cleanup**: After completing work in a worktree
@@ -47,7 +47,7 @@ Use this skill in these scenarios:
### In Claude Code Workflows
The skill is automatically called from `/workflows:review` and `/workflows:work` commands:
The skill is automatically called from `/review` and `/work` commands:
```
# For review: offers worktree if not on PR branch
@@ -204,7 +204,7 @@ bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh clean
## Integration with Workflows
### `/workflows:review`
### `/review`
Instead of always creating a worktree:
@@ -217,7 +217,7 @@ Instead of always creating a worktree:
- no → proceed with PR diff on current branch
```
### `/workflows:work`
### `/work`
Always offer choice: