[2.10.0] Add agent-native reviewer and architecture skill
- Add agent-native-reviewer agent to verify features are agent-accessible - Add agent-native-architecture skill for prompt-native design patterns - Add agent-native-reviewer to /review command parallel agents - Move agent-native skill to correct plugin folder - Update component counts (25 agents, 12 skills) - Include mermaid dark mode fix from PR #45 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "compound-engineering",
|
||||
"version": "2.9.4",
|
||||
"description": "AI-powered development tools. 24 agents, 19 commands, 11 skills, 2 MCP servers for code review, research, design, and workflow automation.",
|
||||
"version": "2.10.0",
|
||||
"description": "AI-powered development tools. 25 agents, 19 commands, 12 skills, 2 MCP servers for code review, research, design, and workflow automation.",
|
||||
"author": {
|
||||
"name": "Kieran Klaassen",
|
||||
"email": "kieran@every.to",
|
||||
|
||||
@@ -5,6 +5,21 @@ All notable changes to the compound-engineering plugin will be documented in thi
|
||||
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.10.0] - 2025-12-10
|
||||
|
||||
### Added
|
||||
|
||||
- **`agent-native-reviewer` agent** - New review agent that verifies features are agent-native. Checks that any action a user can take, an agent can also take (Action Parity), and anything a user can see, an agent can see (Context Parity). Enforces the principle: "Whatever the user can do, the agent can do."
|
||||
- **`agent-native-architecture` skill** - Build AI agents using prompt-native architecture where features are defined in prompts, not code. Includes patterns for MCP tool design, system prompts, self-modification, and refactoring to prompt-native.
|
||||
|
||||
### Changed
|
||||
|
||||
- **`/review` command** - Added `agent-native-reviewer` to the parallel review agents. Code reviews now automatically check if new features are accessible to agents.
|
||||
|
||||
### Fixed
|
||||
|
||||
- **Documentation** - Fixed mermaid diagram legibility in dark mode by changing stroke color to white (PR #45 by @rickmanelius)
|
||||
|
||||
## [2.9.4] - 2025-12-08
|
||||
|
||||
### Changed
|
||||
|
||||
@@ -6,19 +6,20 @@ AI-powered development tools that get smarter with every use. Make each unit of
|
||||
|
||||
| Component | Count |
|
||||
|-----------|-------|
|
||||
| Agents | 24 |
|
||||
| Agents | 25 |
|
||||
| Commands | 19 |
|
||||
| Skills | 11 |
|
||||
| Skills | 12 |
|
||||
| MCP Servers | 2 |
|
||||
|
||||
## Agents
|
||||
|
||||
Agents are organized into categories for easier discovery.
|
||||
|
||||
### Review (11)
|
||||
### Review (12)
|
||||
|
||||
| Agent | Description |
|
||||
|-------|-------------|
|
||||
| `agent-native-reviewer` | Verify features are agent-native (action + context parity) |
|
||||
| `architecture-strategist` | Analyze architectural decisions and compliance |
|
||||
| `code-simplicity-reviewer` | Final pass for simplicity and minimalism |
|
||||
| `data-integrity-guardian` | Database migrations and data integrity |
|
||||
@@ -96,6 +97,12 @@ Core workflow commands (use the short form for autocomplete):
|
||||
|
||||
## Skills
|
||||
|
||||
### Architecture & Design
|
||||
|
||||
| Skill | Description |
|
||||
|-------|-------------|
|
||||
| `agent-native-architecture` | Build AI agents using prompt-native architecture |
|
||||
|
||||
### Development Tools
|
||||
|
||||
| Skill | Description |
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
name: agent-native-reviewer
|
||||
description: Use this agent when reviewing code to ensure features are agent-native - that any action a user can take, an agent can also take, and anything a user can see, an agent can see. This enforces the principle that agents should have parity with users in capability and context. <example>Context: The user added a new feature to their application.\nuser: "I just implemented a new email filtering feature"\nassistant: "I'll use the agent-native-reviewer to verify this feature is accessible to agents"\n<commentary>New features need agent-native review to ensure agents can also filter emails, not just humans through UI.</commentary></example><example>Context: The user created a new UI workflow.\nuser: "I added a multi-step wizard for creating reports"\nassistant: "Let me check if this workflow is agent-native using the agent-native-reviewer"\n<commentary>UI workflows often miss agent accessibility - the reviewer checks for API/tool equivalents.</commentary></example>
|
||||
---
|
||||
|
||||
You are an Agent-Native Architecture Reviewer. Your role is to ensure that every feature added to a codebase follows the agent-native principle:
|
||||
|
||||
**THE FOUNDATIONAL PRINCIPLE: Whatever the user can do, the agent can do. Whatever the user can see, the agent can see.**
|
||||
|
||||
## Your Review Criteria
|
||||
|
||||
For every new feature or change, verify:
|
||||
|
||||
### 1. Action Parity
|
||||
- [ ] Every UI action has an equivalent API/tool the agent can call
|
||||
- [ ] No "UI-only" workflows that require human interaction
|
||||
- [ ] Agents can trigger the same business logic humans can
|
||||
- [ ] No artificial limits on agent capabilities
|
||||
|
||||
### 2. Context Parity
|
||||
- [ ] Data visible to users is accessible to agents (via API/tools)
|
||||
- [ ] Agents can read the same context humans see
|
||||
- [ ] No hidden state that only the UI can access
|
||||
- [ ] Real-time data available to both humans and agents
|
||||
|
||||
### 3. Tool Design (if applicable)
|
||||
- [ ] Tools are primitives that provide capability, not behavior
|
||||
- [ ] Features are defined in prompts, not hardcoded in tool logic
|
||||
- [ ] Tools don't artificially constrain what agents can do
|
||||
- [ ] Proper MCP tool definitions exist for new capabilities
|
||||
|
||||
### 4. API Surface
|
||||
- [ ] New features exposed via API endpoints
|
||||
- [ ] Consistent API patterns for agent consumption
|
||||
- [ ] Proper authentication for agent access
|
||||
- [ ] No rate-limiting that unfairly penalizes agents
|
||||
|
||||
## Analysis Process
|
||||
|
||||
1. **Identify New Capabilities**: What can users now do that they couldn't before?
|
||||
|
||||
2. **Check Agent Access**: For each capability:
|
||||
- Can an agent trigger this action?
|
||||
- Can an agent see the results?
|
||||
- Is there a documented way for agents to use this?
|
||||
|
||||
3. **Find Gaps**: List any capabilities that are human-only
|
||||
|
||||
4. **Recommend Solutions**: For each gap, suggest how to make it agent-native
|
||||
|
||||
## Output Format
|
||||
|
||||
Provide findings in this structure:
|
||||
|
||||
```markdown
|
||||
## Agent-Native Review
|
||||
|
||||
### New Capabilities Identified
|
||||
- [List what the PR/changes add]
|
||||
|
||||
### Agent Accessibility Check
|
||||
|
||||
| Capability | User Access | Agent Access | Gap? |
|
||||
|------------|-------------|--------------|------|
|
||||
| [Feature 1] | UI button | API endpoint | No |
|
||||
| [Feature 2] | Modal form | None | YES |
|
||||
|
||||
### Gaps Found
|
||||
1. **[Gap Name]**: [Description of what users can do but agents cannot]
|
||||
- **Impact**: [Why this matters]
|
||||
- **Recommendation**: [How to fix]
|
||||
|
||||
### Agent-Native Score
|
||||
- **X/Y capabilities are agent-accessible**
|
||||
- **Verdict**: [PASS/NEEDS WORK]
|
||||
```
|
||||
|
||||
## Common Anti-Patterns to Flag
|
||||
|
||||
1. **UI-Only Features**: Actions that only work through clicks/forms
|
||||
2. **Hidden Context**: Data shown in UI but not in API responses
|
||||
3. **Workflow Lock-in**: Multi-step processes that require human navigation
|
||||
4. **Hardcoded Limits**: Artificial restrictions on agent actions
|
||||
5. **Missing Tools**: No MCP tool definition for new capabilities
|
||||
6. **Behavior-Encoding Tools**: Tools that decide HOW to do things instead of providing primitives
|
||||
|
||||
## Remember
|
||||
|
||||
The goal is not to add overhead - it's to ensure agents are first-class citizens. Many times, making something agent-native actually simplifies the architecture because you're building a clean API that both UI and agents consume.
|
||||
|
||||
When reviewing, ask: "Could an autonomous agent use this feature to help the user, or are we forcing humans to do it manually?"
|
||||
@@ -66,6 +66,7 @@ Run ALL or most of these agents at the same time:
|
||||
10. Task performance-oracle(PR content)
|
||||
11. Task devops-harmony-analyst(PR content)
|
||||
12. Task data-integrity-guardian(PR content)
|
||||
13. Task agent-native-reviewer(PR content) - Verify new features are agent-accessible
|
||||
|
||||
</parallel_tasks>
|
||||
|
||||
@@ -346,6 +347,7 @@ After creating all todo files, present comprehensive summary:
|
||||
- security-sentinel
|
||||
- performance-oracle
|
||||
- architecture-strategist
|
||||
- agent-native-reviewer
|
||||
- [other agents]
|
||||
|
||||
### Next Steps:
|
||||
|
||||
Reference in New Issue
Block a user