aircana 2.0.0 → 3.0.0.rc2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.claude-plugin/plugin.json +7 -0
- data/.rspec_status +184 -187
- data/.rubocop.yml +12 -0
- data/CHANGELOG.md +38 -0
- data/CLAUDE.md +51 -20
- data/README.md +132 -63
- data/agents/apply_feedback.md +92 -0
- data/agents/executor.md +85 -0
- data/agents/jira.md +46 -0
- data/agents/planner.md +64 -0
- data/agents/reviewer.md +95 -0
- data/agents/sub-agent-coordinator.md +91 -0
- data/agents/test-agent/manifest.json +15 -0
- data/commands/air-apply-feedback.md +15 -0
- data/commands/air-ask-expert.md +42 -0
- data/commands/air-execute.md +13 -0
- data/commands/air-plan.md +33 -0
- data/commands/air-record.md +17 -0
- data/commands/air-review.md +12 -0
- data/commands/sample-command.md +1 -0
- data/hooks/hooks.json +31 -0
- data/lib/aircana/cli/app.rb +27 -30
- data/lib/aircana/cli/commands/agents.rb +41 -9
- data/lib/aircana/cli/commands/doctor_checks.rb +2 -3
- data/lib/aircana/cli/commands/generate.rb +0 -11
- data/lib/aircana/cli/commands/hooks.rb +4 -4
- data/lib/aircana/cli/commands/init.rb +266 -0
- data/lib/aircana/cli/commands/plugin.rb +157 -0
- data/lib/aircana/cli/help_formatter.rb +2 -3
- data/lib/aircana/configuration.rb +29 -3
- data/lib/aircana/contexts/manifest.rb +1 -8
- data/lib/aircana/generators/agents_generator.rb +3 -2
- data/lib/aircana/hooks_manifest.rb +189 -0
- data/lib/aircana/plugin_manifest.rb +146 -0
- data/lib/aircana/system_checker.rb +0 -11
- data/lib/aircana/templates/agents/base_agent.erb +2 -2
- data/lib/aircana/templates/hooks/session_start.erb +3 -118
- data/lib/aircana/templates/hooks/user_prompt_submit.erb +0 -6
- data/lib/aircana/version.rb +1 -1
- data/spec_target_1760205040_181/agents/test-agent/manifest.json +15 -0
- data/spec_target_1760205220_486/agents/test-agent/manifest.json +15 -0
- data/spec_target_1760205379_250/agents/test-agent/manifest.json +15 -0
- data/spec_target_1760205601_652/agents/test-agent/manifest.json +15 -0
- data/spec_target_1760205608_135/agents/test-agent/manifest.json +15 -0
- data/spec_target_1760205654_952/agents/test-agent/manifest.json +15 -0
- metadata +29 -7
- data/lib/aircana/cli/commands/install.rb +0 -179
- data/lib/aircana/cli/commands/project.rb +0 -156
- data/lib/aircana/generators/project_config_generator.rb +0 -54
- data/lib/aircana/symlink_manager.rb +0 -158
data/CLAUDE.md
CHANGED
@@ -25,57 +25,88 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
|
|
25
25
|
- `bundle exec rake release` - Release new version (updates version, creates git tag, pushes to rubygems)
|
26
26
|
|
27
27
|
### Aircana CLI Commands
|
28
|
-
|
29
|
-
|
30
|
-
- `aircana
|
31
|
-
- `aircana
|
32
|
-
- `aircana
|
28
|
+
|
29
|
+
**Plugin Management:**
|
30
|
+
- `aircana init [DIRECTORY]` - Initialize a Claude Code plugin in specified directory (defaults to current)
|
31
|
+
- `aircana init --plugin-name NAME` - Initialize with custom plugin name
|
32
|
+
- `aircana plugin info` - Display plugin information
|
33
|
+
- `aircana plugin update` - Update plugin metadata interactively
|
34
|
+
- `aircana plugin version` - Show current version
|
35
|
+
- `aircana plugin version bump [major|minor|patch]` - Bump semantic version
|
36
|
+
- `aircana plugin version set` - Set specific version
|
37
|
+
- `aircana plugin validate` - Validate plugin structure and manifests
|
38
|
+
|
39
|
+
**Agent Management:**
|
33
40
|
- `aircana agents create` - Create a new agent interactively
|
41
|
+
- `aircana agents list` - List all configured agents
|
34
42
|
- `aircana agents refresh <agent>` - Refresh agent knowledge from Confluence and web sources
|
35
43
|
- `aircana agents refresh-all` - Refresh knowledge for all configured agents
|
36
44
|
- `aircana agents add-url <agent> <url>` - Add a web URL to an agent's knowledge base
|
45
|
+
|
46
|
+
**Hook Management:**
|
37
47
|
- `aircana hooks list` - List all available hooks
|
38
48
|
- `aircana hooks enable <hook>` - Enable a specific hook
|
39
49
|
- `aircana hooks disable <hook>` - Disable a specific hook
|
40
50
|
- `aircana hooks create` - Create custom hook
|
41
51
|
- `aircana hooks status` - Show hook configuration status
|
42
52
|
|
53
|
+
**System:**
|
54
|
+
- `aircana doctor` - Check system health and dependencies
|
55
|
+
- `aircana doctor --verbose` - Show detailed dependency information
|
56
|
+
- `aircana generate` - Generate plugin components from templates
|
57
|
+
- `aircana dump-context <agent_name>` - Dump context for specified agent
|
58
|
+
|
43
59
|
## Architecture
|
44
60
|
|
45
61
|
### Core Structure
|
46
|
-
Aircana is a Ruby gem that
|
62
|
+
Aircana is a Ruby gem that creates and manages Claude Code plugins. The main components:
|
47
63
|
|
48
64
|
- **CLI Layer** (`lib/aircana/cli/`): Thor-based command line interface with subcommands
|
49
65
|
- `app.rb`: Main Thor application defining all commands
|
50
66
|
- `subcommand.rb`: Base class for subcommands
|
51
67
|
- `shell_command.rb`: Shell command execution utilities
|
52
68
|
- `commands/`: Individual command implementations
|
53
|
-
-
|
69
|
+
- `init.rb`: Plugin initialization
|
70
|
+
- `plugin.rb`: Plugin metadata management
|
71
|
+
- `agents.rb`: Agent CRUD operations
|
72
|
+
- `hooks.rb`: Hook management
|
73
|
+
- **Plugin Management**:
|
74
|
+
- `plugin_manifest.rb`: Manages `.claude-plugin/plugin.json`
|
75
|
+
- `hooks_manifest.rb`: Manages `hooks/hooks.json`
|
76
|
+
- **Contexts** (`lib/aircana/contexts/`): Manages knowledge sources
|
54
77
|
- `confluence.rb`: Handles Confluence page fetching and caching
|
55
78
|
- `confluence_content.rb`: Processes Confluence content
|
56
79
|
- `web.rb`: Handles web URL fetching and HTML to Markdown conversion
|
57
|
-
- `
|
80
|
+
- `manifest.rb`: Tracks knowledge sources per agent
|
58
81
|
- **Generators** (`lib/aircana/generators/`): Template generation system
|
59
82
|
- `base_generator.rb`: Base class for all generators
|
60
83
|
- `agents_generator.rb`: Generates agent configurations
|
61
|
-
-
|
62
|
-
- **Configuration** (`lib/aircana/configuration.rb`): Centralized configuration management
|
84
|
+
- Command generators: Generate slash commands from templates
|
85
|
+
- **Configuration** (`lib/aircana/configuration.rb`): Centralized configuration management with plugin-aware paths
|
63
86
|
- **Support Classes**:
|
64
87
|
- `human_logger.rb`: User-friendly logging output
|
65
88
|
- `system_checker.rb`: Dependency validation
|
66
|
-
- `agent.rb`: Agent model and persistence
|
67
89
|
|
68
90
|
### Key Concepts
|
69
|
-
- **
|
70
|
-
- **
|
71
|
-
- **
|
91
|
+
- **Plugins**: Distributable Claude Code extensions with manifests, agents, commands, and hooks
|
92
|
+
- **Plugin Manifests**: JSON files defining plugin metadata (`.claude-plugin/plugin.json`)
|
93
|
+
- **Agents**: Domain-specific experts with dedicated knowledge bases and context windows
|
94
|
+
- **Knowledge Bases**: Curated documentation from Confluence and web sources
|
95
|
+
- **Hooks**: Event-driven automation through `hooks/hooks.json`
|
96
|
+
- **Commands**: Custom slash commands for workflow automation
|
72
97
|
|
73
98
|
### File Organization
|
74
|
-
-
|
75
|
-
-
|
76
|
-
-
|
77
|
-
-
|
78
|
-
-
|
99
|
+
- **Plugin Structure**:
|
100
|
+
- `.claude-plugin/plugin.json` - Plugin manifest with metadata and versioning
|
101
|
+
- `agents/` - Agent markdown files and their knowledge directories
|
102
|
+
- `commands/` - Slash command markdown files
|
103
|
+
- `hooks/` - Hook scripts and hooks.json manifest
|
104
|
+
- **Configuration**:
|
105
|
+
- `~/.aircana` - Global Aircana configuration
|
106
|
+
- `~/.aircana/aircana.out` - Generated templates output directory
|
107
|
+
- **Agent Knowledge**:
|
108
|
+
- `agents/<agent_name>/knowledge/` - Cached knowledge base content
|
109
|
+
- `agents/<agent_name>/manifest.json` - Tracks knowledge sources
|
79
110
|
|
80
111
|
### Dependencies
|
81
112
|
- Thor (~> 0.19.1) for CLI framework
|
@@ -106,4 +137,4 @@ Agents can sync knowledge from multiple sources:
|
|
106
137
|
**Unified Management:**
|
107
138
|
- Both sources tracked in manifest.json for each agent
|
108
139
|
- Refresh all sources with `aircana agents refresh <agent>`
|
109
|
-
- Content stored as Markdown files in `.
|
140
|
+
- Content stored as Markdown files in `.claude/agents/<agent>/knowledge/`
|
data/README.md
CHANGED
@@ -5,17 +5,19 @@
|
|
5
5
|
|
6
6
|
## Intro
|
7
7
|
|
8
|
-
Aircana
|
8
|
+
Aircana is a "batteries-included" CLI for creating and managing Claude Code plugins. It provides:
|
9
9
|
|
10
|
-
|
10
|
+
**Plugin Development**: Create distributable Claude Code plugins with proper manifests and structure.
|
11
11
|
|
12
|
-
|
12
|
+
**Knowledge Base Management**: Agent-accessible knowledge bases sourced from Confluence or public websites, with automatic syncing and caching.
|
13
13
|
|
14
|
-
|
14
|
+
**Specialized Agents**: Generate domain-specific agents with dedicated knowledge bases for improved context management.
|
15
15
|
|
16
|
-
Complete
|
16
|
+
**Complete Development Workflow**: Five-phase workflow (plan, record, execute, review, apply-feedback) for systematic feature development.
|
17
17
|
|
18
|
-
|
18
|
+
**Hook Management**: Event-driven automation through Claude Code hooks with support for multiple hook types.
|
19
|
+
|
20
|
+
**Plugin Distribution**: Create plugins that can be shared via Claude Code plugin marketplaces.
|
19
21
|
|
20
22
|
While Aircana includes features beneficial in many agentic contexts (like knowledge base syncing), its primary tools are built on "human-in-the-loop" principles.
|
21
23
|
|
@@ -35,30 +37,70 @@ Verify installation and dependency setup:
|
|
35
37
|
aircana doctor
|
36
38
|
```
|
37
39
|
|
38
|
-
|
40
|
+
### Quick Start
|
41
|
+
|
42
|
+
Create a new Claude Code plugin:
|
39
43
|
|
40
44
|
```bash
|
41
|
-
|
42
|
-
|
45
|
+
# Create a new plugin directory
|
46
|
+
mkdir my-plugin
|
47
|
+
cd my-plugin
|
48
|
+
|
49
|
+
# Initialize the plugin
|
50
|
+
aircana init
|
51
|
+
|
52
|
+
# Or initialize with a custom name
|
53
|
+
aircana init --plugin-name my-custom-plugin
|
43
54
|
```
|
44
55
|
|
45
|
-
|
56
|
+
This creates a plugin structure with:
|
57
|
+
- `.claude-plugin/plugin.json` - Plugin manifest
|
58
|
+
- `agents/` - Specialized agents
|
59
|
+
- `commands/` - Slash commands
|
60
|
+
- `hooks/` - Event hooks
|
46
61
|
|
47
|
-
|
62
|
+
### Next Steps
|
48
63
|
|
64
|
+
**1. Create a specialized agent:**
|
49
65
|
```bash
|
50
|
-
aircana agents
|
66
|
+
aircana agents create
|
51
67
|
```
|
52
68
|
|
53
|
-
|
69
|
+
**2. Add knowledge sources:**
|
70
|
+
```bash
|
71
|
+
# From Confluence (requires configuration)
|
72
|
+
aircana agents refresh my-agent
|
73
|
+
|
74
|
+
# From web URLs
|
75
|
+
aircana agents add-url my-agent https://docs.example.com
|
76
|
+
```
|
77
|
+
|
78
|
+
**3. Manage your plugin:**
|
79
|
+
```bash
|
80
|
+
# View plugin information
|
81
|
+
aircana plugin info
|
82
|
+
|
83
|
+
# Update plugin metadata
|
84
|
+
aircana plugin update
|
85
|
+
|
86
|
+
# Bump version
|
87
|
+
aircana plugin version bump patch
|
88
|
+
|
89
|
+
# Validate plugin structure
|
90
|
+
aircana plugin validate
|
91
|
+
```
|
92
|
+
|
93
|
+
**4. Install plugin in Claude Code:**
|
94
|
+
- Copy your plugin directory to a location Claude Code can access
|
95
|
+
- Use Claude Code's plugin installation commands to enable your plugin
|
54
96
|
|
55
97
|
### Things to try
|
56
98
|
|
57
|
-
- Configure the Confluence integration and create
|
99
|
+
- Configure the Confluence integration and create domain-specific agents
|
58
100
|
|
59
|
-
-
|
101
|
+
- Use the `/air-ask-expert` command to consult multiple specialized agents
|
60
102
|
|
61
|
-
- Set up the
|
103
|
+
- Set up the development workflow with plan, execute, review, and apply-feedback commands
|
62
104
|
|
63
105
|
- Explore other tools by running `aircana --help`
|
64
106
|
|
@@ -166,21 +208,33 @@ This preserves the original commit message while incorporating review improvemen
|
|
166
208
|
|
167
209
|
## Key Concepts
|
168
210
|
|
169
|
-
###
|
211
|
+
### Plugins
|
212
|
+
|
213
|
+
Aircana creates Claude Code plugins - portable, distributable packages that extend Claude Code with custom functionality. Each plugin includes:
|
214
|
+
- **Manifest**: Metadata describing the plugin (name, version, author, etc.)
|
215
|
+
- **Agents**: Specialized domain experts
|
216
|
+
- **Commands**: Custom slash commands
|
217
|
+
- **Hooks**: Event-driven automation
|
170
218
|
|
171
|
-
|
219
|
+
Plugins can be shared with teams or published to plugin marketplaces for broader distribution.
|
172
220
|
|
173
|
-
|
221
|
+
### Specialized Agents
|
174
222
|
|
175
|
-
|
223
|
+
Agents are domain-specific experts to whom Claude Code can delegate tasks and questions. Each agent has:
|
224
|
+
- **Dedicated context window**: Prevents context pollution and maintains focus
|
225
|
+
- **Knowledge base**: Access to curated domain-specific documentation
|
226
|
+
- **Custom configuration**: Model, color, and behavior settings
|
176
227
|
|
177
|
-
|
228
|
+
Claude Code can run agents in parallel, creating a "swarm" of experts that can expedite planning and execution while considering broader context.
|
178
229
|
|
179
230
|
### Knowledge Bases
|
180
231
|
|
181
|
-
Aircana provides each
|
232
|
+
Aircana provides each agent with a human-curated knowledge base stored within the plugin structure. This enables agents to:
|
233
|
+
- Access domain-specific documentation automatically
|
234
|
+
- Stay up-to-date with refreshable sources
|
235
|
+
- Provide more relevant responses with less back-and-forth
|
182
236
|
|
183
|
-
|
237
|
+
Knowledge bases support multiple source types and can be refreshed to pull the latest content.
|
184
238
|
|
185
239
|
#### Confluence
|
186
240
|
|
@@ -198,33 +252,45 @@ Websites are also refreshed when `aircana agent refresh <AGENT>` is used.
|
|
198
252
|
|
199
253
|
#### Structure
|
200
254
|
|
201
|
-
Knowledge bases are stored
|
255
|
+
Knowledge bases are stored within the plugin's agent directory. For example:
|
202
256
|
|
203
257
|
```
|
204
|
-
|
205
|
-
├──
|
206
|
-
│
|
207
|
-
|
208
|
-
│
|
209
|
-
│
|
210
|
-
│
|
258
|
+
my-plugin/
|
259
|
+
├── .claude-plugin/
|
260
|
+
│ └── plugin.json
|
261
|
+
├── agents/
|
262
|
+
│ ├── backend-expert.md
|
263
|
+
│ └── backend-expert/
|
264
|
+
│ ├── knowledge/
|
265
|
+
│ │ ├── API-Design.md
|
266
|
+
│ │ └── Authentication.md
|
267
|
+
│ └── manifest.json
|
268
|
+
├── commands/
|
269
|
+
│ └── ask-expert.md
|
270
|
+
└── hooks/
|
271
|
+
├── hooks.json
|
272
|
+
└── pre_tool_use.sh
|
211
273
|
```
|
212
274
|
|
213
|
-
Agent files in the
|
275
|
+
Agent files and their knowledge bases are co-located in the plugin's `agents/` directory.
|
214
276
|
|
215
|
-
|
216
|
-
|
217
|
-
There may be numerous files in the knowledge base, bloating repository size.
|
277
|
+
**Version Control Considerations:**
|
218
278
|
|
219
|
-
|
279
|
+
In many cases, adding the actual knowledge base to version control is undesirable because:
|
280
|
+
- Knowledge bases may contain numerous files, bloating repository size
|
281
|
+
- Content may include sensitive information not suitable for public repos
|
282
|
+
- Knowledge refreshes would create frequent, large commits
|
220
283
|
|
221
|
-
Aircana manages a per-agent manifest.json file to
|
284
|
+
Aircana manages a per-agent `manifest.json` file to track knowledge sources without committing the actual content. Team members can refresh knowledge bases using `aircana agents refresh`.
|
222
285
|
|
223
|
-
###
|
286
|
+
### Plugin Artifacts
|
224
287
|
|
225
|
-
Aircana
|
288
|
+
Aircana uses ERB templates to generate plugin components consistently:
|
289
|
+
- **Agents**: Domain experts with knowledge base integration
|
290
|
+
- **Commands**: Slash commands with parameter handling
|
291
|
+
- **Hooks**: Event handlers for automation
|
226
292
|
|
227
|
-
These templates promote best practices and help
|
293
|
+
These templates promote best practices and help create effective plugin components without extensive trial and error.
|
228
294
|
|
229
295
|
### SQS Integration (Slack Integration at Instructure)
|
230
296
|
|
@@ -294,7 +360,7 @@ The message template supports `{{message}}` placeholder which gets replaced with
|
|
294
360
|
|
295
361
|
```bash
|
296
362
|
aircana generate
|
297
|
-
aircana
|
363
|
+
aircana init
|
298
364
|
aircana hooks enable notification_sqs
|
299
365
|
```
|
300
366
|
|
@@ -377,39 +443,42 @@ This refreshes both Confluence pages and web URLs associated with the agent.
|
|
377
443
|
|
378
444
|
## All Commands
|
379
445
|
|
380
|
-
###
|
446
|
+
### Plugin Management
|
381
447
|
```bash
|
382
|
-
aircana
|
383
|
-
aircana
|
384
|
-
aircana
|
385
|
-
aircana
|
448
|
+
aircana init [DIRECTORY] # Initialize a new plugin (defaults to current directory)
|
449
|
+
aircana init --plugin-name NAME # Initialize with custom plugin name
|
450
|
+
aircana plugin info # Display plugin information
|
451
|
+
aircana plugin update # Update plugin metadata
|
452
|
+
aircana plugin version # Show current version
|
453
|
+
aircana plugin version bump [TYPE] # Bump version (major, minor, or patch)
|
454
|
+
aircana plugin version set # Set specific version
|
455
|
+
aircana plugin validate # Validate plugin structure
|
386
456
|
```
|
387
457
|
|
388
|
-
###
|
458
|
+
### Agent Management
|
389
459
|
```bash
|
390
|
-
aircana
|
391
|
-
aircana
|
392
|
-
aircana
|
393
|
-
aircana
|
394
|
-
aircana
|
460
|
+
aircana agents create # Create new agent interactively
|
461
|
+
aircana agents refresh [AGENT] # Sync agent knowledge from Confluence and web sources
|
462
|
+
aircana agents refresh-all # Refresh knowledge for all agents
|
463
|
+
aircana agents add-url [AGENT] [URL] # Add a web URL to an agent's knowledge base
|
464
|
+
aircana agents list # List all configured agents
|
395
465
|
```
|
396
466
|
|
397
|
-
###
|
467
|
+
### Hook Management
|
398
468
|
```bash
|
399
|
-
aircana
|
400
|
-
aircana
|
401
|
-
aircana
|
402
|
-
aircana
|
403
|
-
aircana
|
469
|
+
aircana hooks list # List all available and installed hooks
|
470
|
+
aircana hooks enable [HOOK] # Enable a specific hook
|
471
|
+
aircana hooks disable [HOOK] # Disable a specific hook
|
472
|
+
aircana hooks create # Create custom hook
|
473
|
+
aircana hooks status # Show hook configuration status
|
404
474
|
```
|
405
475
|
|
406
476
|
### System
|
407
477
|
```bash
|
408
|
-
aircana generate
|
409
|
-
aircana
|
410
|
-
aircana doctor #
|
411
|
-
aircana
|
412
|
-
aircana dump-context [AGENT] # View current context for agent
|
478
|
+
aircana generate # Generate plugin components from templates
|
479
|
+
aircana doctor # Check system health and dependencies
|
480
|
+
aircana doctor --verbose # Show detailed dependency information
|
481
|
+
aircana dump-context [AGENT] # View current context for agent
|
413
482
|
```
|
414
483
|
|
415
484
|
## Development
|
@@ -0,0 +1,92 @@
|
|
1
|
+
---
|
2
|
+
name: apply-feedback
|
3
|
+
description: Applies code review feedback by making recommended changes and amending the HEAD commit
|
4
|
+
model: inherit
|
5
|
+
color: cyan
|
6
|
+
---
|
7
|
+
|
8
|
+
INSTRUCTIONS IMPORTANT: You are a Code Review Feedback Application Agent that implements recommended changes from code reviews and amends the HEAD commit.
|
9
|
+
|
10
|
+
MANDATORY WORKFLOW:
|
11
|
+
|
12
|
+
STEP 1: CREATE TODO LIST FILE
|
13
|
+
First, create a todo list file with the following tasks enumerated in order:
|
14
|
+
|
15
|
+
1. Parse review feedback from conversation context
|
16
|
+
2. Create prioritized todo list of changes (critical first, then important, then suggestions)
|
17
|
+
3. Present change plan to user for approval
|
18
|
+
4. Apply approved changes using appropriate tools
|
19
|
+
5. Re-run unit tests to verify changes
|
20
|
+
6. Fix any test failures
|
21
|
+
7. Amend HEAD commit with improvements
|
22
|
+
8. Summarize changes made
|
23
|
+
|
24
|
+
STEP 2: EXECUTE EACH TASK IN ORDER
|
25
|
+
Work through each task in the todo list sequentially:
|
26
|
+
- Mark each task as 'in_progress' when you start it
|
27
|
+
- Mark each task as 'completed' when finished
|
28
|
+
- Continue until all tasks are done
|
29
|
+
|
30
|
+
TASK DETAILS:
|
31
|
+
|
32
|
+
1. PARSE FEEDBACK: Extract review feedback from conversation:
|
33
|
+
- Look for review output from previous /air-review command
|
34
|
+
- Parse feedback organized by severity (Critical / Important / Suggestions)
|
35
|
+
- Extract actionable items with file, line, issue, and recommendation
|
36
|
+
- If no review feedback found in context, inform user and exit
|
37
|
+
|
38
|
+
2. CHANGE PLANNING: Create prioritized implementation plan:
|
39
|
+
- List all critical issues to fix (must be addressed)
|
40
|
+
- List all important improvements (should be addressed)
|
41
|
+
- List suggestions (optional, ask user if they want these)
|
42
|
+
- Organize by file for efficient editing
|
43
|
+
- Enter Claude Code planning mode for this step
|
44
|
+
- Create clear, actionable todo items
|
45
|
+
|
46
|
+
3. USER APPROVAL: Present plan and get confirmation:
|
47
|
+
- Show organized list of changes to be made
|
48
|
+
- Ask if user wants to include suggestions or just critical/important
|
49
|
+
- Explicitly ask for approval before proceeding
|
50
|
+
- Wait for user confirmation
|
51
|
+
|
52
|
+
4. APPLY CHANGES: Implement approved feedback:
|
53
|
+
- Use appropriate tools (Read, Edit, Write, Bash)
|
54
|
+
- Work through changes file by file
|
55
|
+
- Mark each change as completed after applying
|
56
|
+
- Preserve existing code style and patterns
|
57
|
+
- Make targeted changes without unnecessary refactoring
|
58
|
+
|
59
|
+
5. TEST EXECUTION: Verify changes don't break tests:
|
60
|
+
- Run project's test command (e.g., bundle exec rspec, npm test, etc.)
|
61
|
+
- Check if all tests pass
|
62
|
+
- If tests pass, proceed to commit
|
63
|
+
|
64
|
+
6. FIX TEST FAILURES: Address any failing tests:
|
65
|
+
- If tests fail, analyze failures
|
66
|
+
- Fix implementation issues causing failures
|
67
|
+
- Re-run tests until all pass
|
68
|
+
- Do not proceed to commit until tests pass
|
69
|
+
|
70
|
+
7. AMEND COMMIT: Update HEAD commit with improvements:
|
71
|
+
- Run: git add -A to stage all changes
|
72
|
+
- Run: git commit --amend --no-edit to amend HEAD commit
|
73
|
+
- This preserves original commit message while incorporating improvements
|
74
|
+
- Verify commit was successfully amended
|
75
|
+
|
76
|
+
8. SUMMARY: Report what was done:
|
77
|
+
- List all changes applied by category (critical/important/suggestions)
|
78
|
+
- Note any feedback items not addressed and why
|
79
|
+
- Confirm HEAD commit was amended with improvements
|
80
|
+
- Mention that commit now includes both implementation and review improvements
|
81
|
+
|
82
|
+
IMPORTANT INSTRUCTIONS:
|
83
|
+
- ALWAYS start by creating the todo list file before doing any other work
|
84
|
+
- Execute tasks in the exact order specified in the todo list
|
85
|
+
- Prioritize critical issues - must be fixed
|
86
|
+
- Get user approval before making changes
|
87
|
+
- Ensure tests pass before amending commit
|
88
|
+
- Use 'git commit --amend --no-edit' to preserve original commit message
|
89
|
+
- Focus on implementing review feedback, not redesigning code
|
90
|
+
|
91
|
+
|
92
|
+
Always check your knowledge base first for code improvement and refactoring best practices.
|
data/agents/executor.md
ADDED
@@ -0,0 +1,85 @@
|
|
1
|
+
---
|
2
|
+
name: executor
|
3
|
+
description: Implementation execution agent that reads plans from Jira and executes them with user approval
|
4
|
+
model: inherit
|
5
|
+
color: green
|
6
|
+
---
|
7
|
+
|
8
|
+
INSTRUCTIONS IMPORTANT: You are an Implementation Execution Agent that reads strategic implementation plans from Jira tickets and executes them with user approval.
|
9
|
+
|
10
|
+
MANDATORY WORKFLOW:
|
11
|
+
|
12
|
+
STEP 1: CREATE TODO LIST FILE
|
13
|
+
First, create a todo list file with the following tasks enumerated in order:
|
14
|
+
|
15
|
+
1. Use Task tool with subagent_type 'jira' to read the implementation plan from the specified Jira ticket
|
16
|
+
2. Review and validate plan structure (should contain frontmatter and todo checklist)
|
17
|
+
3. Enter Claude Code planning mode to create detailed execution todo list from strategic plan
|
18
|
+
4. Present execution plan to user for approval
|
19
|
+
5. Execute approved implementation tasks sequentially
|
20
|
+
6. Write unit tests (delegate to test-writing sub-agent if available)
|
21
|
+
7. Run unit tests to verify implementation
|
22
|
+
8. Create git commit (delegate to git-ops sub-agent if available)
|
23
|
+
|
24
|
+
STEP 2: EXECUTE EACH TASK IN ORDER
|
25
|
+
Work through each task in the todo list sequentially:
|
26
|
+
- Mark each task as 'in_progress' when you start it
|
27
|
+
- Mark each task as 'completed' when finished
|
28
|
+
- Continue until all tasks are done
|
29
|
+
|
30
|
+
TASK DETAILS:
|
31
|
+
|
32
|
+
1. JIRA INTEGRATION: Always delegate Jira operations to the 'jira' sub-agent using Task tool with subagent_type 'jira'. Request the full implementation plan content including:
|
33
|
+
- Plan frontmatter (consulted sub-agents, relevant files)
|
34
|
+
- Strategic implementation steps (todo checklist format)
|
35
|
+
- Any architectural decisions or trade-offs documented
|
36
|
+
|
37
|
+
2. PLAN VALIDATION: Verify the plan contains:
|
38
|
+
- Proper markdown frontmatter with metadata
|
39
|
+
- Implementation steps in todo checklist format using `[ ]`
|
40
|
+
- Clear actionable items
|
41
|
+
- If plan is missing or malformed, inform user and exit
|
42
|
+
|
43
|
+
3. EXECUTION PLANNING: Transform strategic plan into detailed execution todos:
|
44
|
+
- Break down high-level plan steps into specific implementation tasks
|
45
|
+
- Add file paths and line numbers where relevant
|
46
|
+
- Include testing and verification steps
|
47
|
+
- Sequence tasks logically with dependencies
|
48
|
+
- Enter Claude Code planning mode for this step
|
49
|
+
|
50
|
+
4. USER APPROVAL: Present the detailed execution plan and explicitly ask for user approval before proceeding. Wait for confirmation.
|
51
|
+
|
52
|
+
5. IMPLEMENTATION EXECUTION: Once approved, work through execution todos:
|
53
|
+
- Use appropriate tools (Read, Write, Edit, Bash, etc.)
|
54
|
+
- Mark each execution task as completed after finishing
|
55
|
+
- Create commits at logical checkpoints
|
56
|
+
- Focus on implementing the WHAT defined in the strategic plan
|
57
|
+
|
58
|
+
6. TEST WRITING: Write unit tests for the implementation:
|
59
|
+
- Check if a test-writing sub-agent exists (look for agents with 'test' in name/description)
|
60
|
+
- If found, delegate test writing to that sub-agent using Task tool
|
61
|
+
- Provide implementation context: files changed, new functionality added, edge cases to cover
|
62
|
+
- If no test sub-agent exists, write tests directly following project conventions
|
63
|
+
|
64
|
+
7. TEST EXECUTION: Run unit tests to verify implementation:
|
65
|
+
- Use project's test command (e.g., bundle exec rspec, npm test, etc.)
|
66
|
+
- Fix any failing tests
|
67
|
+
- Ensure all tests pass before marking work complete
|
68
|
+
|
69
|
+
8. GIT COMMIT: Create a git commit for the implementation:
|
70
|
+
- Check if a git-ops sub-agent exists (look for agents with 'git' in name/description)
|
71
|
+
- If found, delegate commit creation to that sub-agent using Task tool
|
72
|
+
- Provide context: Jira ticket key, summary of changes, files modified
|
73
|
+
- If no git-ops agent exists, create commit directly using Bash tool
|
74
|
+
- Commit message should reference Jira ticket and describe implementation
|
75
|
+
- After successful commit, suggest user runs '/air-review' command to review changes
|
76
|
+
|
77
|
+
IMPORTANT INSTRUCTIONS:
|
78
|
+
- ALWAYS start by creating the todo list file before doing any other work
|
79
|
+
- Execute tasks in the exact order specified in the todo list
|
80
|
+
- The strategic plan tells you WHAT to do, you determine HOW to do it
|
81
|
+
- Focus on implementation, not redesign - follow the plan's architecture decisions
|
82
|
+
- Get user approval before executing implementation tasks
|
83
|
+
|
84
|
+
|
85
|
+
Always check your knowledge base first for execution-specific guidance and best practices.
|
data/agents/jira.md
ADDED
@@ -0,0 +1,46 @@
|
|
1
|
+
---
|
2
|
+
name: jira
|
3
|
+
description: Specialized agent for Jira MCP tool interactions, handles reading and writing tickets efficiently
|
4
|
+
model: inherit
|
5
|
+
color: blue
|
6
|
+
---
|
7
|
+
|
8
|
+
INSTRUCTIONS IMPORTANT: You are a specialized Jira Integration Agent focused exclusively on Jira MCP tool operations to maximize token efficiency.
|
9
|
+
|
10
|
+
CORE RESPONSIBILITIES:
|
11
|
+
- Read Jira ticket details using mcp__jira__ tools
|
12
|
+
- Create and update Jira tickets
|
13
|
+
- Attach markdown plans to tickets
|
14
|
+
- Search for tickets using JQL
|
15
|
+
- Handle all Jira API interactions
|
16
|
+
|
17
|
+
IMPORTANT INSTRUCTIONS:
|
18
|
+
- Use ONLY the mcp__jira__ prefixed tools for all operations
|
19
|
+
- Be concise in responses - focus on data, not explanations
|
20
|
+
- When reading tickets, ALWAYS limit fields to essential ones only: ["summary", "description", "status", "issuetype"]
|
21
|
+
- When writing plans to tickets, use markdown attachments for better formatting
|
22
|
+
- Always include ticket key/ID in responses for easy reference
|
23
|
+
|
24
|
+
JIRA MCP TOOLS AVAILABLE:
|
25
|
+
- mcp__jira__getJiraIssue - Get ticket details (ALWAYS use fields parameter: ["summary", "description", "status", "issuetype"])
|
26
|
+
- mcp__jira__createJiraIssue - Create new tickets
|
27
|
+
- mcp__jira__editJiraIssue - Update existing tickets
|
28
|
+
- mcp__jira__searchJiraIssuesUsingJql - Search tickets
|
29
|
+
- mcp__jira__addCommentToJiraIssue - Add comments
|
30
|
+
- mcp__jira__transitionJiraIssue - Change ticket status
|
31
|
+
- mcp__jira__getTransitionsForJiraIssue - Get available transitions
|
32
|
+
|
33
|
+
WORKFLOW PATTERNS:
|
34
|
+
1. For ticket reading: ALWAYS use fields=["summary", "description", "status", "issuetype"] to avoid token limits
|
35
|
+
2. For plan writing: Create markdown attachment with frontmatter and structured content
|
36
|
+
3. For ticket creation: Gather required fields first, then create with proper formatting
|
37
|
+
4. Always provide ticket URL when available for easy access
|
38
|
+
|
39
|
+
TOKEN OPTIMIZATION:
|
40
|
+
- CRITICAL: Always specify minimal fields parameter when reading tickets
|
41
|
+
- Provide structured, concise responses
|
42
|
+
- Avoid unnecessary explanations or context
|
43
|
+
- Focus on actionable data and results
|
44
|
+
|
45
|
+
|
46
|
+
Always check your knowledge base first for Jira-specific guidance and best practices.
|