john/claude-engineering-plugin
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

feat: migrate repo releases to manual release-please (#293)

Browse Source
This commit is contained in:
Trevin Chow
2026-03-17 17:58:13 -07:00
committed by GitHub
parent 74fb71731a
commit f47f829d81
44 changed files with 1967 additions and 801 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
plugins/compound-engineering/.cursor-plugin/plugin.json
View File

@@ -2,7 +2,7 @@
"name": "compound-engineering",
"displayName": "Compound Engineering",
"version": "2.33.0",
"description": "AI-powered development tools. 28 agents, 22 commands, 19 skills, 1 MCP server for code review, research, design, and workflow automation.",
"description": "AI-powered development tools. 29 agents, 44 skills, 1 MCP server for code review, research, design, and workflow automation.",
"author": {
"name": "Kieran Klaassen",
"email": "kieran@every.to",

46
plugins/compound-engineering/AGENTS.md
View File

@@ -9,13 +9,13 @@ They supplement the repo-root `AGENTS.md`.
**IMPORTANT**: Routine PRs should not cut releases for this plugin.
The repo uses an automatied release process to prepare plugin releases, including version selection and changelog generation. Because multiple PRs may merge before the next release, contributors cannot know the final released version from within an individual PR.
The repo uses an automated release process to prepare plugin releases, including version selection and changelog generation. Because multiple PRs may merge before the next release, contributors cannot know the final released version from within an individual PR.
### Contributor Rules
- Do **not** manually bump `.claude-plugin/plugin.json` version in a normal feature PR.
- Do **not** manually bump `.claude-plugin/marketplace.json` plugin version in a normal feature PR.
- Do **not** cut a release section in `CHANGELOG.md` for a normal feature PR.
- Do **not** cut a release section in the canonical root `CHANGELOG.md` for a normal feature PR.
- Do update substantive docs that are part of the actual change, such as `README.md`, component tables, usage instructions, or counts when they would otherwise become inaccurate.
### Pre-Commit Checklist
@@ -24,7 +24,7 @@ Before committing ANY changes:
- [ ] No manual release-version bump in `.claude-plugin/plugin.json`
- [ ] No manual release-version bump in `.claude-plugin/marketplace.json`
- [ ] No manual release entry added to `CHANGELOG.md`
- [ ] No manual release entry added to the root `CHANGELOG.md`
- [ ] README.md component counts verified
- [ ] README.md tables accurate (agents, commands, skills)
- [ ] plugin.json description matches current counts
@@ -116,42 +116,14 @@ grep -E '`(references|assets|scripts)/[^`]+`' skills/*/SKILL.md
grep -E '^description:' skills/*/SKILL.md
```
## Adding Components
- **New skill:** Create `skills/<name>/SKILL.md` with required YAML frontmatter (`name`, `description`). Reference files go in `skills/<name>/references/`.
- **New agent:** Create `agents/<category>/<name>.md` with frontmatter. Categories: `review`, `research`, `design`, `docs`, `workflow`.
## Beta Skills
Beta skills are experimental versions of core workflow skills, published as separate skills with a `-beta` suffix (e.g., `ce-plan-beta`, `deepen-plan-beta`). They live alongside the stable versions and are invoked directly.
See `docs/solutions/skill-design/beta-skills-framework.md` for the full pattern.
### Beta Skill Rules
- Beta skills use `-beta` suffix in directory name, skill name, and description prefix (`[BETA]`)
- Beta skills set `disable-model-invocation: true` to prevent accidental auto-triggering — users invoke them manually
- Beta skill descriptions should be the intended stable description prefixed with `[BETA]`, so promotion is a simple prefix removal
- Beta skills must reference other beta skills by their beta names (e.g., `/deepen-plan-beta`, not `/deepen-plan`)
- Beta plan output files use `-beta-plan.md` suffix to avoid clobbering stable plan files
- Beta skills are not wired into `lfg`/`slfg` orchestration — invoke them directly
### Beta Skill Validation
After creating or modifying a beta skill, search its SKILL.md for any reference to the stable skill name it replaces. Occurrences of the stable name without `-beta` are missed renames that would cause output collisions or misrouting. Check for:
- Output file paths using the stable naming convention instead of the `-beta` variant
- Cross-skill references pointing to stable names instead of beta counterparts
- User-facing text (questions, confirmations) mentioning stable paths or names
### Promoting Beta to Stable
When replacing a stable skill with its beta version:
- [ ] Replace stable `SKILL.md` content with beta skill content
- [ ] Restore stable frontmatter: remove `[BETA]` prefix from description, restore stable `name:` (e.g., `ce:plan` not `ce:plan-beta`)
- [ ] Remove `disable-model-invocation: true` so the model can auto-trigger the skill
- [ ] Update all internal references back to stable names (`/deepen-plan` not `/deepen-plan-beta`)
- [ ] Restore stable plan file naming (remove `-beta` from `-beta-plan.md` convention)
- [ ] Delete the beta skill directory
- [ ] Update README.md: remove from Beta Skills section, verify counts
- [ ] Verify `lfg`/`slfg` still work with the updated stable skill
- [ ] Verify `ce:work` consumes plans from the promoted skill correctly
Beta skills use a `-beta` suffix and `disable-model-invocation: true` to prevent accidental auto-triggering. See `docs/solutions/skill-design/beta-skills-framework.md` for naming, validation, and promotion rules.
## Documentation

4
plugins/compound-engineering/CHANGELOG.md
View File

@@ -1,5 +1,9 @@
# Changelog
This file is no longer the canonical changelog for compound-engineering releases.
Historical entries are preserved below, but new release history is recorded in the root [`CHANGELOG.md`](../../CHANGELOG.md).
All notable changes to the compound-engineering plugin will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),

2
plugins/compound-engineering/README.md
View File

@@ -244,7 +244,7 @@ Set `CONTEXT7_API_KEY` in your environment to authenticate. Or add it globally i
## Version History
See [CHANGELOG.md](CHANGELOG.md) for detailed version history.
See the repo root [CHANGELOG.md](../../CHANGELOG.md) for canonical release history.
## License

4
plugins/compound-engineering/agents/design/figma-design-sync.md
View File

@@ -65,7 +65,7 @@ You are an expert design-to-code synchronization specialist with deep expertise
- Move any width constraints and horizontal padding to wrapper divs in parent HTML/ERB
- Update component props or configuration
- Adjust layout structures if needed
- Ensure changes follow the project's coding standards from CLAUDE.md
- Ensure changes follow the project's coding standards from AGENTS.md
- Use mobile-first responsive patterns (e.g., `flex-col lg:flex-row`)
- Preserve dark mode support
@@ -163,7 +163,7 @@ Common Tailwind values to prefer:
- **Precision**: Use exact values from Figma (e.g., "16px" not "about 15-17px"), but prefer Tailwind defaults when close enough
- **Completeness**: Address all differences, no matter how minor
- **Code Quality**: Follow CLAUDE.md guidelines for Tailwind, responsive design, and dark mode
- **Code Quality**: Follow AGENTS.md guidance for project-specific frontend conventions
- **Communication**: Be specific about what changed and why
- **Iteration-Ready**: Design your fixes to allow the agent to run again for verification
- **Responsive First**: Always implement mobile-first responsive designs with appropriate breakpoints

4
plugins/compound-engineering/agents/research/repo-research-analyst.md
View File

@@ -32,7 +32,7 @@ You are an expert repository research analyst specializing in understanding code
**Core Responsibilities:**
1. **Architecture and Structure Analysis**
- Examine key documentation files (ARCHITECTURE.md, README.md, CONTRIBUTING.md, CLAUDE.md)
- Examine key documentation files (ARCHITECTURE.md, README.md, CONTRIBUTING.md, AGENTS.md, and CLAUDE.md only if present for compatibility)
- Map out the repository's organizational structure
- Identify architectural patterns and design decisions
- Note any project-specific conventions or standards
@@ -121,7 +121,7 @@ Structure your findings as:
**Important Considerations:**
- Respect any CLAUDE.md or project-specific instructions found
- Respect any AGENTS.md or other project-specific instructions found
- Pay attention to both explicit rules and implicit conventions
- Consider the project's maturity and size when interpreting patterns
- Note any tools or automation mentioned in documentation

2
plugins/compound-engineering/agents/review/pattern-recognition-specialist.md
View File

@@ -69,4 +69,4 @@ When analyzing code:
- Provide actionable recommendations, not just criticism
- Consider the project's maturity and technical debt tolerance
If you encounter project-specific patterns or conventions (especially from CLAUDE.md or similar documentation), incorporate these into your analysis baseline. Always aim to improve code quality while respecting existing architectural decisions.
If you encounter project-specific patterns or conventions (especially from AGENTS.md or similar documentation), incorporate these into your analysis baseline. Always aim to improve code quality while respecting existing architectural decisions.

2
plugins/compound-engineering/agents/workflow/pr-comment-resolver.md
View File

@@ -40,7 +40,7 @@ When you receive a comment or review feedback, you will:
- Maintaining consistency with the existing codebase style and patterns
- Ensuring the change doesn't break existing functionality
- Following any project-specific guidelines from CLAUDE.md
- Following any project-specific guidelines from AGENTS.md (or CLAUDE.md if present only as compatibility context)
- Keeping changes focused and minimal to address only what was requested
4. **Verify the Resolution**: After making changes:

2
plugins/compound-engineering/skills/ce-brainstorm/SKILL.md
View File

@@ -83,7 +83,7 @@ Scan the repo before substantive brainstorming. Match depth to scope:
**Standard and Deep** — Two passes:
*Constraint Check* — Check project instruction files (`AGENTS.md`, `CLAUDE.md`) for workflow, product, or scope constraints that affect the brainstorm. If these add nothing, move on.
*Constraint Check* — Check project instruction files (`AGENTS.md`, and `CLAUDE.md` only if retained as compatibility context) for workflow, product, or scope constraints that affect the brainstorm. If these add nothing, move on.
*Topic Scan* — Search for relevant terms. Read the most relevant existing artifact if one exists (brainstorm, plan, spec, skill, feature doc). Skim adjacent examples covering similar behavior.

2
plugins/compound-engineering/skills/ce-ideate/SKILL.md
View File

@@ -103,7 +103,7 @@ Run agents in parallel in the **foreground** (do not use background dispatch —
1. **Quick context scan** — dispatch a general-purpose sub-agent with this prompt:
> Read the project's CLAUDE.md (or AGENTS.md / README.md if CLAUDE.md is absent), then discover the top-level directory layout using the native file-search/glob tool (e.g., `Glob` with pattern `*` or `*/*` in Claude Code). Return a concise summary (under 30 lines) covering:
> Read the project's AGENTS.md (or CLAUDE.md only as compatibility fallback, then README.md if neither exists), then discover the top-level directory layout using the native file-search/glob tool (e.g., `Glob` with pattern `*` or `*/*` in Claude Code). Return a concise summary (under 30 lines) covering:
> - project shape (language, framework, top-level directory layout)
> - notable patterns or conventions
> - obvious pain points or gaps

6
plugins/compound-engineering/skills/ce-plan-beta/SKILL.md
View File

@@ -150,7 +150,7 @@ Run these agents in parallel:
Collect:
- Existing patterns and conventions to follow
- Relevant files, modules, and tests
- CLAUDE.md or AGENTS.md guidance that materially affects the plan
- AGENTS.md guidance that materially affects the plan, with CLAUDE.md used only as compatibility fallback when present
- Institutional learnings from `docs/solutions/`
#### 1.2 Decide on External Research
@@ -545,7 +545,7 @@ If running with ultrathink enabled, or the platform's reasoning/effort level is
## Issue Creation
When the user selects "Create Issue", detect their project tracker from `CLAUDE.md` or `AGENTS.md`:
When the user selects "Create Issue", detect their project tracker from `AGENTS.md` or, if needed for compatibility, `CLAUDE.md`:
1. Look for `project_tracker: github` or `project_tracker: linear`
2. If GitHub:
@@ -562,7 +562,7 @@ When the user selects "Create Issue", detect their project tracker from `CLAUDE.
4. If no tracker is configured:
- Ask which tracker they use using the platform's blocking question tool when available (see Interaction Method)
- Suggest adding the tracker to `CLAUDE.md` or `AGENTS.md` for future runs
- Suggest adding the tracker to `AGENTS.md` for future runs
After issue creation:
- Display the issue URL

12
plugins/compound-engineering/skills/ce-plan/SKILL.md
View File

@@ -87,7 +87,7 @@ Run these agents **in parallel** to gather local context:
- Task compound-engineering:research:learnings-researcher(feature_description)
**What to look for:**
- **Repo research:** existing patterns, CLAUDE.md guidance, technology familiarity, pattern consistency
- **Repo research:** existing patterns, AGENTS.md guidance, technology familiarity, pattern consistency
- **Learnings:** documented solutions in `docs/solutions/` that might apply (gotchas, patterns, lessons learned)
These findings inform the next step.
@@ -98,7 +98,7 @@ Based on signals from Step 0 and findings from Step 1, decide on external resear
**High-risk topics → always research.** Security, payments, external APIs, data privacy. The cost of missing something is too high. This takes precedence over speed signals.
**Strong local context → skip external research.** Codebase has good patterns, CLAUDE.md has guidance, user knows what they want. External research adds little value.
**Strong local context -> skip external research.** Codebase has good patterns, AGENTS.md has guidance, user knows what they want. External research adds little value.
**Uncertainty or unfamiliar territory → research.** User is exploring, codebase has no examples, new technology. External perspective is valuable.
@@ -125,7 +125,7 @@ After all research steps complete, consolidate findings:
- **Include relevant institutional learnings** from `docs/solutions/` (key insights, gotchas to avoid)
- Note external documentation URLs and best practices (if external research was done)
- List related issues or PRs discovered
- Capture CLAUDE.md conventions
- Capture AGENTS.md conventions
**Optional validation:** Briefly summarize findings and ask if anything looks off or missing before proceeding to planning.
@@ -611,9 +611,9 @@ Loop back to options after Simplify or Other changes until user selects `/ce:wor
## Issue Creation
When user selects "Create Issue", detect their project tracker from CLAUDE.md:
When user selects "Create Issue", detect their project tracker from AGENTS.md:
1. **Check for tracker preference** in user's CLAUDE.md (global or project):
1. **Check for tracker preference** in the user's AGENTS.md (global or project). If AGENTS.md is absent, fall back to CLAUDE.md:
- Look for `project_tracker: github` or `project_tracker: linear`
- Or look for mentions of "GitHub Issues" or "Linear" in their workflow section
@@ -633,7 +633,7 @@ When user selects "Create Issue", detect their project tracker from CLAUDE.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
- Suggest adding `project_tracker: github` or `project_tracker: linear` to their AGENTS.md
5. **After creation:**
- Display the issue URL

4
plugins/compound-engineering/skills/ce-work/SKILL.md
View File

@@ -176,7 +176,7 @@ This command takes a work document (plan, specification, or todo file) and execu
- The plan should reference similar code - read those files first
- Match naming conventions exactly
- Reuse existing components where possible
- Follow project coding standards (see CLAUDE.md)
- Follow project coding standards (see AGENTS.md; use CLAUDE.md only if the repo still keeps a compatibility shim)
- When in doubt, grep for similar implementations
4. **Test Continuously**
@@ -220,7 +220,7 @@ This command takes a work document (plan, specification, or todo file) and execu
# Run full test suite (use project's test command)
# Examples: bin/rails test, npm test, pytest, go test, etc.
# Run linting (per CLAUDE.md)
# Run linting (per AGENTS.md)
# Use linting-agent before pushing to origin
```

4
plugins/compound-engineering/skills/generate_command/SKILL.md
View File

@@ -93,7 +93,7 @@ argument-hint: "[what arguments the command accepts]"
## Tips for Effective Commands
- **Use $ARGUMENTS** placeholder for dynamic inputs
- **Reference CLAUDE.md** patterns and conventions
- **Reference AGENTS.md** patterns and conventions
- **Include verification steps** - tests, linting, visual checks
- **Be explicit about constraints** - don't modify X, use pattern Y
- **Use XML tags** for structured prompts: `<task>`, `<requirements>`, `<constraints>`
@@ -114,7 +114,7 @@ Implement #$ARGUMENTS following these steps:
3. Implement
- Follow existing code patterns (reference specific files)
- Write tests first if doing TDD
- Ensure code follows CLAUDE.md conventions
- Ensure code follows AGENTS.md conventions
4. Verify
- Run tests: `bin/rails test`

10
plugins/compound-engineering/skills/test-browser/SKILL.md
View File

@@ -131,9 +131,10 @@ Determine the dev server port using this priority order:
**Priority 1: Explicit argument**
If the user passed a port number (e.g., `/test-browser 5000` or `/test-browser --port 5000`), use that port directly.
**Priority 2: CLAUDE.md / project instructions**
**Priority 2: AGENTS.md / project instructions**
```bash
# Check CLAUDE.md for port references
# Check AGENTS.md first for port references, then CLAUDE.md as compatibility fallback
grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' AGENTS.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1
grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' CLAUDE.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1
```
@@ -158,7 +159,10 @@ Store the result in a `PORT` variable for use in all subsequent steps.
# Combined detection (run this)
PORT="${EXPLICIT_PORT:-}"
if [ -z "$PORT" ]; then
PORT=$(grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' CLAUDE.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)
PORT=$(grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' AGENTS.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)
if [ -z "$PORT" ]; then
PORT=$(grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' CLAUDE.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)
fi
fi
if [ -z "$PORT" ]; then
PORT=$(grep -Eo '\-\-port[= ]+[0-9]{4,5}' package.json 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)