@every-env/compound-plugin 0.1.0

package/docs/solutions/plugin-versioning-requirements.md

@@ -0,0 +1,77 @@
+---
+title: Plugin Versioning and Documentation Requirements
+category: workflow
+tags: [versioning, changelog, readme, plugin, documentation]
+created: 2025-11-24
+severity: process
+component: plugin-development
+---
+
+# Plugin Versioning and Documentation Requirements
+
+## Problem
+
+When making changes to the compound-engineering plugin, documentation can get out of sync with the actual components (agents, commands, skills). This leads to confusion about what's included in each version and makes it difficult to track changes over time.
+
+## Solution
+
+**Every change to the plugin MUST include:**
+
+1. **Version bump in `plugin.json`**
+   - Follow semantic versioning (semver)
+   - MAJOR: Breaking changes or major reorganization
+   - MINOR: New agents, commands, or skills added
+   - PATCH: Bug fixes, documentation updates, minor improvements
+
+2. **CHANGELOG.md update**
+   - Add entry under `## [Unreleased]` or new version section
+   - Use Keep a Changelog format
+   - Categories: Added, Changed, Deprecated, Removed, Fixed, Security
+
+3. **README.md verification**
+   - Verify component counts match actual files
+   - Verify agent/command/skill tables are accurate
+   - Update descriptions if functionality changed
+
+## Checklist for Plugin Changes
+
+```markdown
+Before committing changes to compound-engineering plugin:
+
+- [ ] Version bumped in `.claude-plugin/plugin.json`
+- [ ] CHANGELOG.md updated with changes
+- [ ] README.md component counts verified
+- [ ] README.md tables updated (if adding/removing/renaming)
+- [ ] plugin.json description updated (if component counts changed)
+```
+
+## File Locations
+
+- Version: `.claude-plugin/plugin.json` → `"version": "X.Y.Z"`
+- Changelog: `CHANGELOG.md`
+- Readme: `README.md`
+
+## Example Workflow
+
+When adding a new agent:
+
+1. Create the agent file in `agents/[category]/`
+2. Bump version in `plugin.json` (minor version for new agent)
+3. Add to CHANGELOG under `### Added`
+4. Add row to README agent table
+5. Update README component count
+6. Update plugin.json description with new counts
+
+## Prevention
+
+This documentation serves as a reminder. When Claude Code works on this plugin, it should:
+
+1. Check this doc before committing changes
+2. Follow the checklist above
+3. Never commit partial updates (all three files must be updated together)
+
+## Related Files
+
+- `/Users/kieranklaassen/every-marketplace/plugins/compound-engineering/.claude-plugin/plugin.json`
+- `/Users/kieranklaassen/every-marketplace/plugins/compound-engineering/CHANGELOG.md`
+- `/Users/kieranklaassen/every-marketplace/plugins/compound-engineering/README.md`

package/docs/specs/claude-code.md

@@ -0,0 +1,67 @@
+# Claude Code Plugin Spec
+
+Last verified: 2026-01-21
+
+## Primary sources
+
+```
+https://docs.claude.com/en/docs/claude-code/plugins-reference
+https://docs.claude.com/en/docs/claude-code/hooks
+https://docs.claude.com/en/docs/claude-code/slash-commands
+https://docs.claude.com/en/docs/claude-code/skills
+https://docs.claude.com/en/docs/claude-code/plugin-marketplaces
+```
+
+## Plugin layout and file locations
+
+- A plugin root contains `.claude-plugin/plugin.json` and optional default directories like `commands/`, `agents/`, `skills/`, `hooks/`, plus `.mcp.json` and `.lsp.json` at the plugin root. citeturn2view7
+- The `.claude-plugin/` directory only holds the manifest; component directories (commands/agents/skills/hooks) must be at the plugin root, not inside `.claude-plugin/`. citeturn2view7
+- The reference table lists default locations and notes that `commands/` is the legacy home for skills; new skills should live under `skills/<name>/SKILL.md`. citeturn2view7
+
+## Manifest schema (`.claude-plugin/plugin.json`)
+
+- `name` is required and must be kebab-case with no spaces. citeturn2view8
+- Metadata fields include `version`, `description`, `author`, `homepage`, `repository`, `license`, and `keywords`. citeturn2view8
+- Component path fields include `commands`, `agents`, `skills`, `hooks`, `mcpServers`, `outputStyles`, and `lspServers`. These can be strings or arrays, or inline objects for hooks/MCP/LSP. citeturn2view8turn2view9
+- Custom paths supplement defaults; they do not replace them, and all paths must be relative to the plugin root and start with `./`. citeturn2view9
+
+## Commands (slash commands)
+
+- Command files are Markdown with frontmatter. Supported frontmatter includes `allowed-tools`, `argument-hint`, `description`, `model`, and `disable-model-invocation`, each with documented defaults. citeturn6search0
+
+## Skills (`skills/<name>/SKILL.md`)
+
+- Skills are directories containing `SKILL.md` (plus optional support files). Skills and commands are auto-discovered when the plugin is installed. citeturn2view7
+- Skills can be invoked with `/<skill-name>` and are stored in `~/.claude/skills` or `.claude/skills` (project-level); plugins can also ship skills. citeturn12view0
+- Skill frontmatter examples include `name`, `description`, and optional `allowed-tools`. citeturn12view0
+
+## Agents (`agents/*.md`)
+
+- Agents are markdown files with frontmatter such as `description` and `capabilities`, plus descriptive content for when to invoke the agent. citeturn2view7
+
+## Hooks (`hooks/hooks.json` or inline)
+
+- Hooks can be provided in `hooks/hooks.json` or inline via the manifest. Hooks are organized by event → matcher → hook list. citeturn2view7
+- Plugin hooks are merged with user and project hooks when the plugin is enabled, and matching hooks run in parallel. citeturn1search0
+- Supported events include `PreToolUse`, `PostToolUse`, `PostToolUseFailure`, `PermissionRequest`, `UserPromptSubmit`, `Notification`, `Stop`, `SubagentStart`, `SubagentStop`, `Setup`, `SessionStart`, `SessionEnd`, and `PreCompact`. citeturn2view7
+- Hook types include `command`, `prompt`, and `agent`. citeturn2view7
+- Hooks can use `${CLAUDE_PLUGIN_ROOT}` to reference plugin files. citeturn1search0
+
+## MCP servers
+
+- Plugins can define MCP servers in `.mcp.json` or inline under `mcpServers` in the manifest. Configuration includes `command`, `args`, `env`, and `cwd`. citeturn2view7turn2view10
+- Plugin MCP servers start automatically when enabled and appear as standard MCP tools. citeturn2view10
+
+## LSP servers
+
+- LSP servers can be defined in `.lsp.json` or inline in the manifest. Required fields include `command` and `extensionToLanguage`, with optional settings for transport, args, env, and timeouts. citeturn2view7turn2view10
+
+## Plugin caching and path limits
+
+- Claude Code copies plugin files into a cache directory instead of using them in place. Plugins cannot access paths outside the copied root (for example, `../shared-utils`). citeturn2view12
+- To access external files, use symlinks inside the plugin directory or restructure your marketplace so the plugin root contains shared files. citeturn2view12
+
+## Marketplace schema (`.claude-plugin/marketplace.json`)
+
+- A marketplace JSON file lists plugins and includes fields for marketplace metadata and a `plugins` array. citeturn8view2
+- Each plugin entry includes at least a `name` and `source` and can include additional manifest fields. citeturn8view2

package/docs/specs/codex.md

@@ -0,0 +1,59 @@
+# Codex Spec (Config, Prompts, Skills, MCP)
+
+Last verified: 2026-01-21
+
+## Primary sources
+
+```
+https://developers.openai.com/codex/config-basic
+https://developers.openai.com/codex/config-advanced
+https://developers.openai.com/codex/custom-prompts
+https://developers.openai.com/codex/skills
+https://developers.openai.com/codex/skills/create-skill
+https://developers.openai.com/codex/guides/agents-md
+https://developers.openai.com/codex/mcp
+```
+
+## Config location and precedence
+
+- Codex reads local settings from `~/.codex/config.toml`, shared by the CLI and IDE extension. citeturn2view0
+- Configuration precedence is: CLI flags → profile values → root-level values in `config.toml` → built-in defaults. citeturn2view0
+- Codex stores local state under `CODEX_HOME` (defaults to `~/.codex`) and includes `config.toml` there. citeturn4view0
+
+## Profiles and providers
+
+- Profiles are defined under `[profiles.<name>]` and selected with `codex --profile <name>`. citeturn4view0
+- A top-level `profile = "<name>"` sets the default profile; CLI flags can override it. citeturn4view0
+- Profiles are experimental and not supported in the IDE extension. citeturn4view0
+- Custom model providers can be defined with base URL, wire API, and optional headers, then referenced via `model_provider`. citeturn4view0
+
+## Custom prompts (slash commands)
+
+- Custom prompts are Markdown files stored under `~/.codex/prompts/`. citeturn3view0
+- Custom prompts require explicit invocation and aren’t shared through the repository; use skills to share or auto-invoke. citeturn3view0
+- Prompts are invoked as `/prompts:<name>` in the slash command UI. citeturn3view0
+- Prompt front matter supports `description:` and `argument-hint:`. citeturn3view0turn2view3
+- Prompt arguments support `$1`–`$9`, `$ARGUMENTS`, and named placeholders like `$FILE` provided as `KEY=value`. citeturn2view3
+- Codex ignores non-Markdown files in the prompts directory. citeturn2view3
+
+## AGENTS.md instructions
+
+- Codex reads `AGENTS.md` files before doing any work and builds a combined instruction chain. citeturn3view1
+- Discovery order: global (`~/.codex`, using `AGENTS.override.md` then `AGENTS.md`) then project directory traversal from repo root to CWD, with override > AGENTS > fallback names. citeturn3view1
+- Codex concatenates files from root down; files closer to the working directory appear later and override earlier guidance. citeturn3view1
+
+## Skills (Agent Skills)
+
+- A skill is a folder containing `SKILL.md` plus optional `scripts/`, `references/`, and `assets/`. citeturn3view3turn3view4
+- `SKILL.md` uses YAML front matter and requires `name` and `description`. citeturn3view3turn3view4
+- Required fields are single-line with length limits (name ≤ 100 chars, description ≤ 500 chars). citeturn3view4
+- At startup, Codex loads only each skill’s name/description; full content is injected when invoked. citeturn3view3turn3view4
+- Skills can be repo-scoped in `.codex/skills/` or user-scoped in `~/.codex/skills/`. citeturn3view4
+- Skills can be invoked explicitly using `/skills` or `$skill-name`. citeturn3view3
+
+## MCP (Model Context Protocol)
+
+- MCP configuration lives in `~/.codex/config.toml` and is shared by the CLI and IDE extension. citeturn3view2turn3view5
+- Each server is configured under `[mcp_servers.<server-name>]`. citeturn3view5
+- STDIO servers support `command` (required), `args`, `env`, `env_vars`, and `cwd`. citeturn3view5
+- Streamable HTTP servers support `url` (required), `bearer_token_env_var`, `http_headers`, and `env_http_headers`. citeturn3view5

package/docs/specs/opencode.md

@@ -0,0 +1,57 @@
+# OpenCode Spec (Config, Agents, Plugins)
+
+Last verified: 2026-01-21
+
+## Primary sources
+
+```
+https://opencode.ai/docs/config
+https://opencode.ai/docs/tools
+https://opencode.ai/docs/permissions
+https://opencode.ai/docs/plugins/
+https://opencode.ai/docs/agents/
+https://opencode.ai/config.json
+```
+
+## Config files and precedence
+
+- OpenCode supports JSON and JSONC configs. citeturn10view0
+- Config sources are merged (not replaced), with a defined precedence order from remote → global → custom → project → `.opencode` directories → inline overrides. citeturn10view0
+- Global config is stored at `~/.config/opencode/opencode.json`, and project config is `opencode.json` in the project root. citeturn10view0
+- Custom config file and directory can be provided via `OPENCODE_CONFIG` and `OPENCODE_CONFIG_DIR`. citeturn10view0
+- The `.opencode` and `~/.config/opencode` directories use plural subdirectory names (`agents/`, `commands/`, `modes/`, `plugins/`, `skills/`, `tools/`, `themes/`), but singular names are also supported for backwards compatibility. citeturn10view0
+
+## Core config keys
+
+- `model` and `small_model` set the primary and lightweight models; `provider` configures provider options. citeturn10view0
+- `tools` is still supported but deprecated; permissions are now the canonical control surface. citeturn1search0
+- `permission` controls tool approvals and can be configured globally or per tool, including pattern-based rules. citeturn1search0
+- `mcp`, `instructions`, and `disabled_providers` are supported config sections. citeturn1search5
+- `plugin` can list npm packages to load at startup. citeturn1search2
+
+## Tools
+
+- OpenCode ships with built-in tools, and permissions determine whether each tool runs automatically, requires approval, or is denied. citeturn1search3turn1search0
+- Tools are enabled by default; permissions provide the gating mechanism. citeturn1search3
+
+## Permissions
+
+- Permissions resolve to `allow`, `ask`, or `deny` and can be configured globally or per tool, with pattern-based rules. citeturn1search0
+- Defaults are permissive, with special cases such as `.env` file reads. citeturn1search0
+- Agent-level permissions override the global permission block. citeturn1search1turn1search0
+
+## Agents
+
+- Agents can be configured in `opencode.json` or as markdown files in `~/.config/opencode/agents/` or `.opencode/agents/`. citeturn1search1turn10view0
+- Agent config supports `mode`, `model`, `temperature`, `tools`, and `permission`, and agent configs override global settings. citeturn1search1
+- Model IDs use the `provider/model-id` format. citeturn1search1
+
+## Plugins and events
+
+- Local plugins are loaded from `.opencode/plugin/` (project) and `~/.config/opencode/plugin/` (global). npm plugins can be listed in `plugin` in `opencode.json`. citeturn1search2
+- Plugins are loaded in a defined order across config and plugin directories. citeturn1search2
+- Plugins export a function that returns a map of event handlers; the plugins doc lists supported event categories. citeturn1search2
+
+## Notes for this repository
+
+- Config docs describe plural subdirectory names, while the plugins doc uses `.opencode/plugin/`. This implies singular paths remain accepted for backwards compatibility, but plural paths are the canonical structure. citeturn10view0turn1search2

package/package.json

@@ -0,0 +1,26 @@
+{
+  "name": "@every-env/compound-plugin",
+  "version": "0.1.0",
+  "type": "module",
+  "private": false,
+  "bin": {
+    "compound-plugin": "./src/index.ts"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "dev": "bun run src/index.ts",
+    "convert": "bun run src/index.ts convert",
+    "list": "bun run src/index.ts list",
+    "cli:install": "bun run src/index.ts install",
+    "test": "bun test"
+  },
+  "dependencies": {
+    "citty": "^0.1.6",
+    "js-yaml": "^4.1.0"
+  },
+  "devDependencies": {
+    "bun-types": "^1.0.0"
+  }
+}

package/plans/grow-your-own-garden-plugin-architecture.md

@@ -0,0 +1,102 @@
+# Grow Your Own Garden: Adaptive Agent Ecosystem
+
+> **Issue:** https://github.com/kieranklaassen/compound-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 `compound-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

package/plans/landing-page-launchkit-refresh.md

@@ -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`

package/plugins/coding-tutor/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "coding-tutor",
+  "version": "1.2.1",
+  "description": "Personalized coding tutorials that use your actual codebase for examples with spaced repetition quizzes",
+  "author": {
+    "name": "Nityesh Agarwal"
+  },
+  "keywords": ["coding", "programming", "tutorial", "learning", "spaced-repetition"]
+}