mapify-cli 1.0.0__py3-none-any.whl
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.
- mapify_cli/__init__.py +1946 -0
- mapify_cli/playbook_manager.py +517 -0
- mapify_cli/recitation_manager.py +551 -0
- mapify_cli/semantic_search.py +405 -0
- mapify_cli/templates/agents/CHANGELOG.md +108 -0
- mapify_cli/templates/agents/MCP-PATTERNS.md +343 -0
- mapify_cli/templates/agents/README.md +183 -0
- mapify_cli/templates/agents/actor.md +650 -0
- mapify_cli/templates/agents/curator.md +1155 -0
- mapify_cli/templates/agents/documentation-reviewer.md +1282 -0
- mapify_cli/templates/agents/evaluator.md +843 -0
- mapify_cli/templates/agents/monitor.md +977 -0
- mapify_cli/templates/agents/predictor.md +965 -0
- mapify_cli/templates/agents/reflector.md +1048 -0
- mapify_cli/templates/agents/task-decomposer.md +1169 -0
- mapify_cli/templates/agents/test-generator.md +1175 -0
- mapify_cli/templates/commands/map-debug.md +315 -0
- mapify_cli/templates/commands/map-feature.md +454 -0
- mapify_cli/templates/commands/map-refactor.md +317 -0
- mapify_cli/templates/commands/map-review.md +29 -0
- mapify_cli/templates/hooks/README.md +55 -0
- mapify_cli/templates/hooks/validate-agent-templates.sh +94 -0
- mapify_cli/templates/settings.hooks.json +20 -0
- mapify_cli/workflow_logger.py +411 -0
- mapify_cli-1.0.0.dist-info/METADATA +310 -0
- mapify_cli-1.0.0.dist-info/RECORD +28 -0
- mapify_cli-1.0.0.dist-info/WHEEL +4 -0
- mapify_cli-1.0.0.dist-info/entry_points.txt +2 -0
|
@@ -0,0 +1,343 @@
|
|
|
1
|
+
# Common MCP Tool Patterns Reference
|
|
2
|
+
|
|
3
|
+
This document provides reference implementations of common MCP tool usage patterns used across MAP agent templates.
|
|
4
|
+
|
|
5
|
+
## Purpose
|
|
6
|
+
|
|
7
|
+
Agent templates intentionally duplicate certain MCP tool descriptions because:
|
|
8
|
+
1. **Agent Independence**: Each agent is invoked independently and needs complete context
|
|
9
|
+
2. **Self-Containment**: Agents cannot access external includes during invocation
|
|
10
|
+
3. **Context Clarity**: Full descriptions in each template prevent ambiguity
|
|
11
|
+
|
|
12
|
+
## Common MCP Tools
|
|
13
|
+
|
|
14
|
+
### 1. cipher_memory_search
|
|
15
|
+
|
|
16
|
+
**Purpose**: Search for existing patterns, solutions, and knowledge
|
|
17
|
+
|
|
18
|
+
**Query Patterns**:
|
|
19
|
+
- `"implementation pattern [feature_type]"` - Find similar implementations
|
|
20
|
+
- `"error solution [error_type]"` - Learn from past error fixes
|
|
21
|
+
- `"best practice [technology]"` - Get established patterns
|
|
22
|
+
- `"code review issue [pattern_type]"` - Find common review issues
|
|
23
|
+
- `"security vulnerability [code_pattern]"` - Security-specific searches
|
|
24
|
+
|
|
25
|
+
**When to Use**:
|
|
26
|
+
- Before implementing new features (Actor, Monitor)
|
|
27
|
+
- When curating knowledge (Curator)
|
|
28
|
+
- During reflection analysis (Reflector)
|
|
29
|
+
- Before adding playbook bullets (avoid duplicates)
|
|
30
|
+
|
|
31
|
+
**Typical Usage**:
|
|
32
|
+
```
|
|
33
|
+
mcp__cipher__cipher_memory_search({
|
|
34
|
+
query: "implementation pattern JWT authentication",
|
|
35
|
+
top_k: 5,
|
|
36
|
+
similarity_threshold: 0.3
|
|
37
|
+
})
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
### 2. context7 (resolve-library-id + get-library-docs)
|
|
41
|
+
|
|
42
|
+
**Purpose**: Get current, up-to-date library/framework documentation
|
|
43
|
+
|
|
44
|
+
**Two-Step Process**:
|
|
45
|
+
1. `resolve-library-id`: Find the Context7-compatible library ID
|
|
46
|
+
2. `get-library-docs`: Retrieve documentation for specific topics
|
|
47
|
+
|
|
48
|
+
**When to Use**:
|
|
49
|
+
- Implementing features with external libraries (Actor)
|
|
50
|
+
- Verifying API usage in code review (Monitor)
|
|
51
|
+
- Creating TOOL_USAGE playbook bullets (Curator)
|
|
52
|
+
- Testing library-dependent code (Test Generator)
|
|
53
|
+
|
|
54
|
+
**Query Examples**:
|
|
55
|
+
- Library names: "Next.js", "React", "Django", "FastAPI", "SQLAlchemy"
|
|
56
|
+
- Topics: "hooks", "routing", "authentication", "error handling", "testing"
|
|
57
|
+
|
|
58
|
+
**Typical Usage**:
|
|
59
|
+
```
|
|
60
|
+
# Step 1: Resolve library ID
|
|
61
|
+
mcp__context7__resolve-library-id({
|
|
62
|
+
libraryName: "Next.js"
|
|
63
|
+
})
|
|
64
|
+
# Returns: "/vercel/next.js"
|
|
65
|
+
|
|
66
|
+
# Step 2: Get docs
|
|
67
|
+
mcp__context7__get-library-docs({
|
|
68
|
+
context7CompatibleLibraryID: "/vercel/next.js",
|
|
69
|
+
topic: "routing",
|
|
70
|
+
tokens: 5000
|
|
71
|
+
})
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
**Rationale**: Training data may be outdated. Current docs prevent using deprecated APIs.
|
|
75
|
+
|
|
76
|
+
### 3. codex-bridge (consult_codex)
|
|
77
|
+
|
|
78
|
+
**Purpose**: Generate optimized code for complex algorithms
|
|
79
|
+
|
|
80
|
+
**Query Format**: `"Generate [language] code for [specific_task]"`
|
|
81
|
+
|
|
82
|
+
**When to Use**:
|
|
83
|
+
- Complex algorithm implementation (Actor)
|
|
84
|
+
- Unfamiliar API usage
|
|
85
|
+
- Batch processing logic
|
|
86
|
+
- Advanced async patterns
|
|
87
|
+
|
|
88
|
+
**Query Examples**:
|
|
89
|
+
- "Generate Python code for batch processing with exponential backoff"
|
|
90
|
+
- "Generate TypeScript code for debounced search input with cancellation"
|
|
91
|
+
- "Generate Python code for LRU cache with TTL expiration"
|
|
92
|
+
|
|
93
|
+
**Typical Usage**:
|
|
94
|
+
```
|
|
95
|
+
mcp__codex-bridge__consult_codex({
|
|
96
|
+
query: "Generate Python code for batch processing with exponential backoff",
|
|
97
|
+
directory: "/path/to/project",
|
|
98
|
+
format: "code",
|
|
99
|
+
timeout: 60
|
|
100
|
+
})
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
### 4. deepwiki (read_wiki_structure + ask_question)
|
|
104
|
+
|
|
105
|
+
**Purpose**: Learn from production code in popular repositories
|
|
106
|
+
|
|
107
|
+
**Two-Step Process**:
|
|
108
|
+
1. `read_wiki_structure`: See available documentation topics
|
|
109
|
+
2. `ask_question`: Query specific implementation patterns
|
|
110
|
+
|
|
111
|
+
**When to Use**:
|
|
112
|
+
- Learning architectural patterns (Actor, Monitor)
|
|
113
|
+
- Validating security approaches (Monitor)
|
|
114
|
+
- Understanding production best practices (Curator)
|
|
115
|
+
- Researching testing strategies (Test Generator)
|
|
116
|
+
|
|
117
|
+
**Query Examples**:
|
|
118
|
+
- "How does [popular_repo] handle authentication?"
|
|
119
|
+
- "What are common mistakes when implementing websockets?"
|
|
120
|
+
- "How do production systems prevent N+1 queries?"
|
|
121
|
+
|
|
122
|
+
**Typical Usage**:
|
|
123
|
+
```
|
|
124
|
+
# Step 1: Read structure
|
|
125
|
+
mcp__deepwiki__read_wiki_structure({
|
|
126
|
+
repoName: "facebook/react"
|
|
127
|
+
})
|
|
128
|
+
|
|
129
|
+
# Step 2: Ask question
|
|
130
|
+
mcp__deepwiki__ask_question({
|
|
131
|
+
repoName: "facebook/react",
|
|
132
|
+
question: "How does React handle error boundaries in production?"
|
|
133
|
+
})
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
### 5. claude-reviewer (request_review)
|
|
137
|
+
|
|
138
|
+
**Purpose**: Get professional AI code review
|
|
139
|
+
|
|
140
|
+
**When to Use**:
|
|
141
|
+
- After Actor implementation (Monitor)
|
|
142
|
+
- Before marking code as valid (Monitor)
|
|
143
|
+
- Systematic quality baseline (Monitor)
|
|
144
|
+
|
|
145
|
+
**Focus Areas**: "security", "performance", "testing", "architecture", "error-handling"
|
|
146
|
+
|
|
147
|
+
**Typical Usage**:
|
|
148
|
+
```
|
|
149
|
+
mcp__claude-reviewer__request_review({
|
|
150
|
+
summary: "User authentication endpoint with JWT token generation",
|
|
151
|
+
focus_areas: ["security", "error-handling", "testing"],
|
|
152
|
+
test_command: "pytest tests/auth/"
|
|
153
|
+
})
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
### 6. cipher_extract_and_operate_memory
|
|
157
|
+
|
|
158
|
+
**Purpose**: Store successful patterns for future reference
|
|
159
|
+
|
|
160
|
+
**When to Use**:
|
|
161
|
+
- AFTER Monitor validates solution (Actor)
|
|
162
|
+
- After successful task completion (all agents)
|
|
163
|
+
- When reflecting on outcomes (Reflector)
|
|
164
|
+
|
|
165
|
+
**What to Store**:
|
|
166
|
+
- Pattern name
|
|
167
|
+
- Code snippet (working implementation)
|
|
168
|
+
- Context (when to use, prerequisites)
|
|
169
|
+
- Trade-offs (pros/cons vs alternatives)
|
|
170
|
+
|
|
171
|
+
**Typical Usage**:
|
|
172
|
+
```
|
|
173
|
+
mcp__cipher__cipher_extract_and_operate_memory({
|
|
174
|
+
interaction: "Implemented JWT authentication with refresh tokens. Pattern: [description]. Trade-offs: [analysis].",
|
|
175
|
+
memoryMetadata: {
|
|
176
|
+
projectId: "project-123",
|
|
177
|
+
domain: "security"
|
|
178
|
+
},
|
|
179
|
+
options: {
|
|
180
|
+
useLLMDecisions: false, // Use predictable similarity-based logic
|
|
181
|
+
similarityThreshold: 0.85, // Only 85%+ similar memories trigger UPDATE
|
|
182
|
+
confidenceThreshold: 0.7 // Minimum confidence for operations
|
|
183
|
+
}
|
|
184
|
+
})
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
## Decision Framework Template
|
|
188
|
+
|
|
189
|
+
Use this template for systematic MCP tool selection:
|
|
190
|
+
|
|
191
|
+
```
|
|
192
|
+
BEFORE [task], ask yourself:
|
|
193
|
+
|
|
194
|
+
1. Have we solved something similar before?
|
|
195
|
+
→ Use cipher_memory_search
|
|
196
|
+
|
|
197
|
+
2. Do I need current library/framework docs?
|
|
198
|
+
→ Use context7 (resolve-library-id → get-library-docs)
|
|
199
|
+
|
|
200
|
+
3. Is this a complex algorithm I'm unfamiliar with?
|
|
201
|
+
→ Use codex-bridge (consult_codex)
|
|
202
|
+
|
|
203
|
+
4. How do popular projects handle this?
|
|
204
|
+
→ Use deepwiki (read_wiki_structure → ask_question)
|
|
205
|
+
|
|
206
|
+
5. Do I need professional code review?
|
|
207
|
+
→ Use claude-reviewer (request_review)
|
|
208
|
+
|
|
209
|
+
6. Did my solution work successfully?
|
|
210
|
+
→ Use cipher_extract_and_operate_memory (store pattern)
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
## Agent-Specific MCP Usage
|
|
214
|
+
|
|
215
|
+
### Actor (Implementation)
|
|
216
|
+
- **Primary**: cipher_memory_search (find patterns), context7 (verify APIs)
|
|
217
|
+
- **Secondary**: codex-bridge (complex algorithms), deepwiki (architectural patterns)
|
|
218
|
+
- **Always**: cipher_extract_and_operate_memory (after Monitor approval)
|
|
219
|
+
|
|
220
|
+
### Monitor (Code Review)
|
|
221
|
+
- **Primary**: claude-reviewer (baseline review), cipher_memory_search (known issues)
|
|
222
|
+
- **Secondary**: context7 (verify library usage), deepwiki (compare with production patterns)
|
|
223
|
+
|
|
224
|
+
### Curator (Knowledge Management)
|
|
225
|
+
- **Primary**: cipher_memory_search (avoid duplicates)
|
|
226
|
+
- **Required**: context7 (verify TOOL_USAGE bullets)
|
|
227
|
+
- **Recommended**: deepwiki (ground recommendations in production code)
|
|
228
|
+
|
|
229
|
+
### Task Decomposer
|
|
230
|
+
- **Primary**: cipher_memory_search (find similar decompositions)
|
|
231
|
+
- **Recommended**: deepwiki (learn task breakdown patterns)
|
|
232
|
+
|
|
233
|
+
### Evaluator
|
|
234
|
+
- **Primary**: cipher_memory_search (find quality metrics)
|
|
235
|
+
- **Recommended**: context7 (verify scoring criteria)
|
|
236
|
+
|
|
237
|
+
### Predictor
|
|
238
|
+
- **Primary**: cipher_memory_search (find similar impact patterns)
|
|
239
|
+
- **Recommended**: deepwiki (learn dependency patterns)
|
|
240
|
+
|
|
241
|
+
### Reflector
|
|
242
|
+
- **Primary**: cipher_memory_search (find similar reflections)
|
|
243
|
+
- **Always**: Store insights via cipher_extract_and_operate_memory
|
|
244
|
+
|
|
245
|
+
### Test Generator
|
|
246
|
+
- **Primary**: cipher_memory_search (find test patterns)
|
|
247
|
+
- **Required**: context7 (verify test framework APIs)
|
|
248
|
+
- **Recommended**: deepwiki (learn testing strategies)
|
|
249
|
+
|
|
250
|
+
### Documentation Reviewer
|
|
251
|
+
- **Primary**: Fetch (validate external URLs/dependencies)
|
|
252
|
+
- **Required**: Read/Glob (find source of truth documents)
|
|
253
|
+
- **Recommended**: cipher_memory_search (find documentation anti-patterns)
|
|
254
|
+
|
|
255
|
+
## Best Practices
|
|
256
|
+
|
|
257
|
+
### 1. Search Before Implementing
|
|
258
|
+
Always search cipher before creating new code or knowledge:
|
|
259
|
+
```
|
|
260
|
+
Before: cipher_memory_search
|
|
261
|
+
During: Implementation
|
|
262
|
+
After: cipher_extract_and_operate_memory (if successful)
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
### 2. Verify Library APIs
|
|
266
|
+
Training data may be outdated. Always use context7 for external libraries:
|
|
267
|
+
```
|
|
268
|
+
Actor uses context7 → Gets current API
|
|
269
|
+
Monitor verifies → Catches deprecated usage
|
|
270
|
+
Curator references → Adds to playbook with current syntax
|
|
271
|
+
```
|
|
272
|
+
|
|
273
|
+
### 3. Learn from Production
|
|
274
|
+
Don't rely on theoretical examples. Use deepwiki to see battle-tested code:
|
|
275
|
+
```
|
|
276
|
+
Architectural decision needed → deepwiki
|
|
277
|
+
Security pattern needed → deepwiki (compare multiple repos)
|
|
278
|
+
Testing strategy needed → deepwiki (see what works in production)
|
|
279
|
+
```
|
|
280
|
+
|
|
281
|
+
### 4. Store Successful Patterns
|
|
282
|
+
Build institutional memory by storing what works:
|
|
283
|
+
```
|
|
284
|
+
Pattern works (Monitor approved) → cipher_extract_and_operate_memory
|
|
285
|
+
Future task similar → cipher_memory_search finds it
|
|
286
|
+
Avoid reinventing → Reuse proven pattern
|
|
287
|
+
```
|
|
288
|
+
|
|
289
|
+
## Common Anti-Patterns
|
|
290
|
+
|
|
291
|
+
### ❌ Don't: Skip cipher_memory_search
|
|
292
|
+
```
|
|
293
|
+
Actor: "Let me implement JWT authentication..."
|
|
294
|
+
(implements from scratch, misses existing pattern)
|
|
295
|
+
```
|
|
296
|
+
|
|
297
|
+
### ✅ Do: Search first
|
|
298
|
+
```
|
|
299
|
+
Actor: "Let me search for JWT patterns..."
|
|
300
|
+
cipher_memory_search("implementation pattern JWT authentication")
|
|
301
|
+
(finds existing pattern with security best practices)
|
|
302
|
+
```
|
|
303
|
+
|
|
304
|
+
### ❌ Don't: Assume training data is current
|
|
305
|
+
```
|
|
306
|
+
Actor: "I'll use jwt.encode(payload, secret)..."
|
|
307
|
+
(uses deprecated API from training data)
|
|
308
|
+
```
|
|
309
|
+
|
|
310
|
+
### ✅ Do: Verify with context7
|
|
311
|
+
```
|
|
312
|
+
Actor: "Let me verify JWT API..."
|
|
313
|
+
context7.resolve-library-id("PyJWT")
|
|
314
|
+
context7.get-library-docs("/pyjwt/pyjwt", "authentication")
|
|
315
|
+
(discovers algorithm parameter is now required)
|
|
316
|
+
```
|
|
317
|
+
|
|
318
|
+
### ❌ Don't: Store patterns without validation
|
|
319
|
+
```
|
|
320
|
+
Actor: "I'll store this pattern..."
|
|
321
|
+
(stores before Monitor review, pattern may be flawed)
|
|
322
|
+
```
|
|
323
|
+
|
|
324
|
+
### ✅ Do: Store only validated patterns
|
|
325
|
+
```
|
|
326
|
+
Monitor: valid=true (approved)
|
|
327
|
+
Actor: cipher_extract_and_operate_memory(pattern)
|
|
328
|
+
(stores only proven, reviewed patterns)
|
|
329
|
+
```
|
|
330
|
+
|
|
331
|
+
## Template Maintenance
|
|
332
|
+
|
|
333
|
+
When updating agent templates:
|
|
334
|
+
1. Keep MCP sections consistent with this reference
|
|
335
|
+
2. Update this file when adding new tools
|
|
336
|
+
3. Use linter to verify MCP descriptions include expected keywords
|
|
337
|
+
4. Maintain agent independence (don't assume includes)
|
|
338
|
+
|
|
339
|
+
## See Also
|
|
340
|
+
|
|
341
|
+
- `.claude/agents/CHANGELOG.md` - Template version history
|
|
342
|
+
- `scripts/lint-agent-templates.py` - Consistency validation
|
|
343
|
+
- `README.md` - MAP framework overview
|
|
@@ -0,0 +1,183 @@
|
|
|
1
|
+
# MAP Agent Architecture
|
|
2
|
+
|
|
3
|
+
This directory contains agent prompts for the MAP (Modular Agentic Planner) framework.
|
|
4
|
+
|
|
5
|
+
## ⚠️ CRITICAL: Template Variables
|
|
6
|
+
|
|
7
|
+
**DO NOT REMOVE Handlebars template syntax!**
|
|
8
|
+
|
|
9
|
+
Agent files use **Handlebars templating** (`{{variable}}`, `{{#if}}...{{/if}}`) for runtime context injection by the Orchestrator agent.
|
|
10
|
+
|
|
11
|
+
### Why Template Variables Exist
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
┌─────────────────┐
|
|
15
|
+
│ Orchestrator │ Fills in context at runtime
|
|
16
|
+
└────────┬────────┘
|
|
17
|
+
│ {{language}} = "python"
|
|
18
|
+
│ {{project_name}} = "my-api"
|
|
19
|
+
│ {{#if playbook_bullets}} = [patterns from Curator]
|
|
20
|
+
│ {{#if feedback}} = [corrections from Monitor]
|
|
21
|
+
↓
|
|
22
|
+
┌─────────────────┐
|
|
23
|
+
│ Actor Agent │ Receives fully-populated prompt
|
|
24
|
+
└─────────────────┘
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
### Template Variables by Category
|
|
28
|
+
|
|
29
|
+
#### Context Injection (Orchestrator → All Agents)
|
|
30
|
+
- `{{language}}` - Project programming language (python, go, javascript, etc.)
|
|
31
|
+
- `{{framework}}` - Framework in use (FastAPI, Django, React, etc.)
|
|
32
|
+
- `{{project_name}}` - Current project name
|
|
33
|
+
- `{{standards_url}}` - Link to coding standards
|
|
34
|
+
- `{{branch}}` - Current git branch
|
|
35
|
+
- `{{related_files}}` - Files relevant to the task
|
|
36
|
+
|
|
37
|
+
#### Task Specification (TaskDecomposer → Actor)
|
|
38
|
+
- `{{subtask_description}}` - The specific subtask to implement
|
|
39
|
+
- `{{allowed_scope}}` - Files/directories Actor is allowed to modify
|
|
40
|
+
|
|
41
|
+
#### ACE Learning System (Curator → Actor)
|
|
42
|
+
- `{{#if playbook_bullets}}...{{/if}}` - Proven patterns from past successes
|
|
43
|
+
- This is how the system learns and improves over time
|
|
44
|
+
- Curator analyzes successful implementations and adds to playbook
|
|
45
|
+
- Actor gets relevant patterns automatically injected
|
|
46
|
+
|
|
47
|
+
#### Feedback Loops (Monitor → Actor)
|
|
48
|
+
- `{{#if feedback}}...{{/if}}` - Corrections from Monitor after failed attempt
|
|
49
|
+
- Enables iterative refinement: Actor → Monitor → Actor (with feedback)
|
|
50
|
+
- Critical for quality assurance
|
|
51
|
+
|
|
52
|
+
### What Happens If You Remove Them
|
|
53
|
+
|
|
54
|
+
| Removed | Impact | Severity |
|
|
55
|
+
|---------|--------|----------|
|
|
56
|
+
| `{{language}}` | Actor doesn't know what language to use | 🔴 Critical |
|
|
57
|
+
| `{{project_name}}` | Generic code, doesn't match project style | 🟡 Major |
|
|
58
|
+
| `{{#if playbook_bullets}}` | **Breaks ACE learning system** | 🔴 Critical |
|
|
59
|
+
| `{{#if feedback}}` | **Breaks Monitor → Actor retry** | 🔴 Critical |
|
|
60
|
+
| `{{subtask_description}}` | Actor doesn't know what to implement | 🔴 Critical |
|
|
61
|
+
|
|
62
|
+
### How to Safely Customize Agents
|
|
63
|
+
|
|
64
|
+
✅ **Safe modifications:**
|
|
65
|
+
```markdown
|
|
66
|
+
# Add new MCP tools
|
|
67
|
+
6. **mcp__my-tool__my-function** - Custom functionality
|
|
68
|
+
- Use for specific use cases
|
|
69
|
+
- Example: my_tool(param="value")
|
|
70
|
+
|
|
71
|
+
# Add domain-specific instructions
|
|
72
|
+
# SECURITY REQUIREMENTS
|
|
73
|
+
- All inputs must be validated
|
|
74
|
+
- Use parameterized queries for SQL
|
|
75
|
+
- Never log sensitive data
|
|
76
|
+
|
|
77
|
+
# Adjust output format
|
|
78
|
+
# OUTPUT FORMAT (extended)
|
|
79
|
+
5. **Security Analysis**: List potential vulnerabilities
|
|
80
|
+
6. **Performance Impact**: Expected performance characteristics
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
❌ **Unsafe modifications:**
|
|
84
|
+
```markdown
|
|
85
|
+
# ❌ Removing template variables
|
|
86
|
+
-{{language}} # DON'T DO THIS
|
|
87
|
+
-{{project_name}} # DON'T DO THIS
|
|
88
|
+
|
|
89
|
+
# ❌ Removing conditional blocks
|
|
90
|
+
-{{#if playbook_bullets}} # DON'T DO THIS
|
|
91
|
+
-{{/if}}
|
|
92
|
+
|
|
93
|
+
# ❌ Simplifying "verbose" sections
|
|
94
|
+
-# PLAYBOOK CONTEXT (ACE) # This is critical infrastructure!
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
## Git Pre-commit Hook
|
|
98
|
+
|
|
99
|
+
A pre-commit hook at `.git/hooks/pre-commit` validates that critical template variables are present before allowing commits.
|
|
100
|
+
|
|
101
|
+
**Required patterns checked:**
|
|
102
|
+
- `{{language}}`
|
|
103
|
+
- `{{project_name}}`
|
|
104
|
+
- `{{#if playbook_bullets}}`
|
|
105
|
+
- `{{#if feedback}}`
|
|
106
|
+
- `{{subtask_description}}`
|
|
107
|
+
|
|
108
|
+
**To bypass (not recommended):**
|
|
109
|
+
```bash
|
|
110
|
+
git commit --no-verify
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
## Testing Agent Modifications
|
|
114
|
+
|
|
115
|
+
After modifying an agent, test the **full workflow**, not just the agent in isolation:
|
|
116
|
+
|
|
117
|
+
```bash
|
|
118
|
+
# ❌ Wrong: Test agent standalone
|
|
119
|
+
claude --agents '{"actor": {"prompt": "$(cat .claude/agents/actor.md)"}}' --print "implement feature"
|
|
120
|
+
|
|
121
|
+
# ✅ Right: Test via Orchestrator (full MAP workflow)
|
|
122
|
+
/map-feature implement simple calculator with add/subtract
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
The Orchestrator workflow ensures:
|
|
126
|
+
1. TaskDecomposer breaks down the task
|
|
127
|
+
2. Orchestrator fills in all template variables
|
|
128
|
+
3. Actor receives fully-populated prompt with context
|
|
129
|
+
4. Monitor validates the output
|
|
130
|
+
5. Feedback loops work correctly
|
|
131
|
+
|
|
132
|
+
## Understanding Handlebars Syntax
|
|
133
|
+
|
|
134
|
+
If you see these patterns in agent files, **they are NOT comments**:
|
|
135
|
+
|
|
136
|
+
```handlebars
|
|
137
|
+
{{variable}} → Replaced with actual value
|
|
138
|
+
{{#if condition}}...{{/if}} → Conditional block (included if condition true)
|
|
139
|
+
{{#each items}}...{{/each}} → Loop over items
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
**Example:**
|
|
143
|
+
|
|
144
|
+
Before (in agent file):
|
|
145
|
+
```markdown
|
|
146
|
+
Project: {{project_name}}
|
|
147
|
+
Language: {{language}}
|
|
148
|
+
|
|
149
|
+
{{#if feedback}}
|
|
150
|
+
FEEDBACK FROM PREVIOUS ATTEMPT:
|
|
151
|
+
{{feedback}}
|
|
152
|
+
{{/if}}
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
After (when Orchestrator invokes Actor):
|
|
156
|
+
```markdown
|
|
157
|
+
Project: my-api
|
|
158
|
+
Language: python
|
|
159
|
+
|
|
160
|
+
FEEDBACK FROM PREVIOUS ATTEMPT:
|
|
161
|
+
The function is missing error handling for invalid inputs.
|
|
162
|
+
Please add try/except blocks.
|
|
163
|
+
```
|
|
164
|
+
|
|
165
|
+
## Need Help?
|
|
166
|
+
|
|
167
|
+
- **Question:** "Can I simplify this verbose agent prompt?"
|
|
168
|
+
- **Answer:** Check if it contains `{{templates}}` first. If yes, **DO NOT remove**.
|
|
169
|
+
|
|
170
|
+
- **Question:** "Why is the playbook section so long?"
|
|
171
|
+
- **Answer:** It's dynamically filled by Curator. It's empty initially, grows with learning.
|
|
172
|
+
|
|
173
|
+
- **Question:** "Can I remove unused template variables?"
|
|
174
|
+
- **Answer:** No. They're used by Orchestrator even if they look unused in the file.
|
|
175
|
+
|
|
176
|
+
- **Question:** "The agent works fine without templates in my test."
|
|
177
|
+
- **Answer:** You tested it standalone. Test via `/map-feature` (Orchestrator workflow).
|
|
178
|
+
|
|
179
|
+
## References
|
|
180
|
+
|
|
181
|
+
- [MAP Framework Paper](https://github.com/Shanka123/MAP)
|
|
182
|
+
- [ACE Framework Paper](https://arxiv.org/abs/2510.04618v1)
|
|
183
|
+
- [Handlebars Documentation](https://handlebarsjs.com/)
|