@massa-ai/codex-plugin 1.27.0 → 1.29.0
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.
- package/.codex-plugin/plugin.json +1 -1
- package/agent-profiles/balanced/massa-ai-judge.toml +2 -2
- package/agent-profiles/cheap/massa-ai-judge.toml +2 -2
- package/agent-profiles/heavy/massa-ai-judge.toml +2 -2
- package/agent-profiles/home/massa-ai-judge.toml +2 -2
- package/agent-profiles/work/massa-ai-judge.toml +2 -2
- package/agents/massa-ai-judge.toml +2 -2
- package/install.sh +32 -0
- package/package.json +1 -1
- package/skills/agents/judge/SKILL.md +3 -3
- package/skills/massa-ai/SKILL.md +5 -1
- package/skills/massa-ai/references/agent-orchestration.md +1 -1
- package/skills/massa-ai/references/coding-guidelines.md +67 -0
- package/skills/massa-ai/references/skill-architect/examples.md +256 -0
- package/skills/massa-ai/references/skill-architect/patterns.md +317 -0
- package/skills/massa-ai/references/skill-architect/quality-checklist.md +70 -0
- package/skills/massa-ai/scripts/validate_skill.ts +364 -0
- package/skills/massa-ai/workflows/skill-architect.md +393 -0
- package/skills/massa-ai/workflows/to-prd.md +81 -0
|
@@ -0,0 +1,317 @@
|
|
|
1
|
+
# Skill Patterns Reference
|
|
2
|
+
|
|
3
|
+
This document details the five proven patterns for skill architecture.
|
|
4
|
+
Read this when deciding how to structure a skill's workflow during the
|
|
5
|
+
Architecture phase.
|
|
6
|
+
|
|
7
|
+
## Table of Contents
|
|
8
|
+
|
|
9
|
+
1. Sequential Workflow Orchestration (line ~20)
|
|
10
|
+
2. Multi-MCP Coordination (line ~70)
|
|
11
|
+
3. Iterative Refinement (line ~120)
|
|
12
|
+
4. Context-Aware Tool Selection (line ~170)
|
|
13
|
+
5. Domain-Specific Intelligence (line ~210)
|
|
14
|
+
6. Choosing Between Patterns (line ~250)
|
|
15
|
+
7. Combining Patterns (line ~280)
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## 1. Sequential Workflow Orchestration
|
|
20
|
+
|
|
21
|
+
**Use when:** Users need multi-step processes executed in a specific order,
|
|
22
|
+
where each step depends on the previous one.
|
|
23
|
+
|
|
24
|
+
**Problem-first framing:** "I need to onboard a new customer" → Skill
|
|
25
|
+
orchestrates the right calls in the right sequence.
|
|
26
|
+
|
|
27
|
+
**Key characteristics:**
|
|
28
|
+
|
|
29
|
+
- Explicit step ordering with dependencies between steps
|
|
30
|
+
- Validation gates between steps (don't proceed if step N fails)
|
|
31
|
+
- Rollback instructions for failures
|
|
32
|
+
- Data flows from earlier steps to later ones
|
|
33
|
+
|
|
34
|
+
**Structure template:**
|
|
35
|
+
|
|
36
|
+
```markdown
|
|
37
|
+
## Workflow: [Name]
|
|
38
|
+
|
|
39
|
+
### Step 1: [Action]
|
|
40
|
+
Call tool: `tool_name`
|
|
41
|
+
Parameters: [what's needed]
|
|
42
|
+
Validation: [how to know it succeeded]
|
|
43
|
+
On failure: [what to do]
|
|
44
|
+
|
|
45
|
+
### Step 2: [Action]
|
|
46
|
+
Depends on: Step 1 (uses [specific output])
|
|
47
|
+
Call tool: `tool_name`
|
|
48
|
+
Parameters: [include output from Step 1]
|
|
49
|
+
Validation: [check]
|
|
50
|
+
|
|
51
|
+
### Step 3: [Action]
|
|
52
|
+
...
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
**When to choose this pattern:**
|
|
56
|
+
|
|
57
|
+
- The workflow has a natural linear order
|
|
58
|
+
- Steps have clear dependencies
|
|
59
|
+
- Skipping a step would break the workflow
|
|
60
|
+
- Users currently do these steps manually in sequence
|
|
61
|
+
|
|
62
|
+
**Watch out for:**
|
|
63
|
+
|
|
64
|
+
- Rigid ordering when some steps could be parallel
|
|
65
|
+
- Missing rollback logic (what if step 3 fails after step 1 and 2 succeeded?)
|
|
66
|
+
- Not validating between steps
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## 2. Multi-MCP Coordination
|
|
71
|
+
|
|
72
|
+
**Use when:** Workflows span multiple external services, each connected
|
|
73
|
+
via its own MCP server.
|
|
74
|
+
|
|
75
|
+
**Key characteristics:**
|
|
76
|
+
|
|
77
|
+
- Clear phase separation by service
|
|
78
|
+
- Data passing between MCP servers
|
|
79
|
+
- Validation before moving to next phase
|
|
80
|
+
- Centralized error handling across services
|
|
81
|
+
|
|
82
|
+
**Structure template:**
|
|
83
|
+
|
|
84
|
+
```markdown
|
|
85
|
+
## Workflow: [Name]
|
|
86
|
+
|
|
87
|
+
### Phase 1: [Service A] ([MCP name])
|
|
88
|
+
1. [Action using Service A tools]
|
|
89
|
+
2. [Action using Service A tools]
|
|
90
|
+
Output: [data needed by Phase 2]
|
|
91
|
+
|
|
92
|
+
### Phase 2: [Service B] ([MCP name])
|
|
93
|
+
Input: [data from Phase 1]
|
|
94
|
+
1. [Action using Service B tools]
|
|
95
|
+
2. [Action using Service B tools]
|
|
96
|
+
Output: [data needed by Phase 3]
|
|
97
|
+
|
|
98
|
+
### Phase 3: [Service C] ([MCP name])
|
|
99
|
+
...
|
|
100
|
+
|
|
101
|
+
## Error Handling
|
|
102
|
+
- If Phase 1 fails: [action]
|
|
103
|
+
- If Phase 2 fails but Phase 1 succeeded: [action]
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
**When to choose this pattern:**
|
|
107
|
+
|
|
108
|
+
- The workflow crosses service boundaries
|
|
109
|
+
- Multiple MCP servers are involved
|
|
110
|
+
- Data needs to flow between services
|
|
111
|
+
- Users currently switch between tools manually
|
|
112
|
+
|
|
113
|
+
**Watch out for:**
|
|
114
|
+
|
|
115
|
+
- Assuming all MCPs are connected (check availability first)
|
|
116
|
+
- Not handling partial failures (Phase 2 fails but Phase 1 already ran)
|
|
117
|
+
- Tight coupling between phases (prefer passing data explicitly)
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## 3. Iterative Refinement
|
|
122
|
+
|
|
123
|
+
**Use when:** Output quality improves through multiple review-and-fix cycles.
|
|
124
|
+
|
|
125
|
+
**Key characteristics:**
|
|
126
|
+
|
|
127
|
+
- Initial draft generation
|
|
128
|
+
- Quality check against explicit criteria
|
|
129
|
+
- Refinement loop with clear stopping conditions
|
|
130
|
+
- Finalization step
|
|
131
|
+
|
|
132
|
+
**Structure template:**
|
|
133
|
+
|
|
134
|
+
```markdown
|
|
135
|
+
## Workflow: [Name]
|
|
136
|
+
|
|
137
|
+
### Initial Draft
|
|
138
|
+
1. Gather input data
|
|
139
|
+
2. Generate first version
|
|
140
|
+
3. Save to working file
|
|
141
|
+
|
|
142
|
+
### Quality Check
|
|
143
|
+
Run validation: `scripts/[check_quality].py`
|
|
144
|
+
Criteria:
|
|
145
|
+
- [Criterion 1]: [how to check]
|
|
146
|
+
- [Criterion 2]: [how to check]
|
|
147
|
+
- [Criterion 3]: [how to check]
|
|
148
|
+
|
|
149
|
+
### Refinement Loop
|
|
150
|
+
For each issue found:
|
|
151
|
+
1. Identify the specific problem
|
|
152
|
+
2. Fix it
|
|
153
|
+
3. Re-validate
|
|
154
|
+
|
|
155
|
+
STOP when:
|
|
156
|
+
- All criteria pass, OR
|
|
157
|
+
- 3 iterations completed (diminishing returns), OR
|
|
158
|
+
- User signals satisfaction
|
|
159
|
+
|
|
160
|
+
### Finalization
|
|
161
|
+
1. Apply final formatting
|
|
162
|
+
2. Generate summary of changes
|
|
163
|
+
3. Save final version
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
**When to choose this pattern:**
|
|
167
|
+
|
|
168
|
+
- Output quality is subjective or multi-dimensional
|
|
169
|
+
- First drafts are usually "close but not quite"
|
|
170
|
+
- Users currently review and ask for revisions manually
|
|
171
|
+
- There are explicit quality criteria to check against
|
|
172
|
+
|
|
173
|
+
**Watch out for:**
|
|
174
|
+
|
|
175
|
+
- Infinite loops (always define stopping conditions)
|
|
176
|
+
- Over-polishing (3 iterations is usually enough)
|
|
177
|
+
- Vague quality criteria (make them checkable)
|
|
178
|
+
|
|
179
|
+
---
|
|
180
|
+
|
|
181
|
+
## 4. Context-Aware Tool Selection
|
|
182
|
+
|
|
183
|
+
**Use when:** The same goal can be achieved with different tools depending
|
|
184
|
+
on the input or context.
|
|
185
|
+
|
|
186
|
+
**Key characteristics:**
|
|
187
|
+
|
|
188
|
+
- Decision tree based on input properties
|
|
189
|
+
- Fallback options when primary choice isn't available
|
|
190
|
+
- Transparency about why a particular path was chosen
|
|
191
|
+
|
|
192
|
+
**Structure template:**
|
|
193
|
+
|
|
194
|
+
```markdown
|
|
195
|
+
## Workflow: [Name]
|
|
196
|
+
|
|
197
|
+
### Analyze Input
|
|
198
|
+
Check: [what properties to examine]
|
|
199
|
+
- Property A: [value range or type]
|
|
200
|
+
- Property B: [value range or type]
|
|
201
|
+
|
|
202
|
+
### Decision Tree
|
|
203
|
+
IF [condition 1]:
|
|
204
|
+
→ Use [Tool/Approach A]
|
|
205
|
+
Rationale: [why this is better for this case]
|
|
206
|
+
ELIF [condition 2]:
|
|
207
|
+
→ Use [Tool/Approach B]
|
|
208
|
+
Rationale: [why]
|
|
209
|
+
ELSE:
|
|
210
|
+
→ Use [Tool/Approach C] (default)
|
|
211
|
+
|
|
212
|
+
### Execute
|
|
213
|
+
Based on decision, execute using the selected approach.
|
|
214
|
+
|
|
215
|
+
### Explain Choice
|
|
216
|
+
Tell the user which approach was selected and why.
|
|
217
|
+
```
|
|
218
|
+
|
|
219
|
+
**When to choose this pattern:**
|
|
220
|
+
|
|
221
|
+
- Multiple valid approaches exist for the same goal
|
|
222
|
+
- The "best" approach depends on input characteristics
|
|
223
|
+
- Users don't know (or shouldn't need to know) which tool is optimal
|
|
224
|
+
|
|
225
|
+
**Watch out for:**
|
|
226
|
+
|
|
227
|
+
- Decision criteria that overlap (ambiguous routing)
|
|
228
|
+
- Missing fallback for edge cases
|
|
229
|
+
- Not explaining the choice to the user
|
|
230
|
+
|
|
231
|
+
---
|
|
232
|
+
|
|
233
|
+
## 5. Domain-Specific Intelligence
|
|
234
|
+
|
|
235
|
+
**Use when:** The skill's value comes from specialized knowledge, not just
|
|
236
|
+
tool orchestration.
|
|
237
|
+
|
|
238
|
+
**Key characteristics:**
|
|
239
|
+
|
|
240
|
+
- Domain rules and constraints embedded in logic
|
|
241
|
+
- Compliance or validation checks before action
|
|
242
|
+
- Comprehensive audit trails
|
|
243
|
+
- Expert-level decision making
|
|
244
|
+
|
|
245
|
+
**Structure template:**
|
|
246
|
+
|
|
247
|
+
```markdown
|
|
248
|
+
## Workflow: [Name]
|
|
249
|
+
|
|
250
|
+
### Pre-Check ([Domain] Rules)
|
|
251
|
+
Before proceeding, verify:
|
|
252
|
+
1. [Domain rule 1]: [how to check]
|
|
253
|
+
2. [Domain rule 2]: [how to check]
|
|
254
|
+
3. [Domain rule 3]: [how to check]
|
|
255
|
+
|
|
256
|
+
IF any rule fails:
|
|
257
|
+
→ [Escalation or alternative path]
|
|
258
|
+
→ Document the failure
|
|
259
|
+
|
|
260
|
+
### Execute
|
|
261
|
+
Only if pre-checks pass:
|
|
262
|
+
1. [Action with domain context]
|
|
263
|
+
2. [Action with domain context]
|
|
264
|
+
|
|
265
|
+
### Audit Trail
|
|
266
|
+
Log:
|
|
267
|
+
- All checks performed and results
|
|
268
|
+
- Decisions made and rationale
|
|
269
|
+
- Actions taken
|
|
270
|
+
```
|
|
271
|
+
|
|
272
|
+
**When to choose this pattern:**
|
|
273
|
+
|
|
274
|
+
- The skill needs expert knowledge to execute correctly
|
|
275
|
+
- There are compliance, safety, or quality rules to enforce
|
|
276
|
+
- Getting it wrong has significant consequences
|
|
277
|
+
- Users benefit from the skill's "expertise" more than its automation
|
|
278
|
+
|
|
279
|
+
**Watch out for:**
|
|
280
|
+
|
|
281
|
+
- Outdated domain knowledge (plan for updates)
|
|
282
|
+
- Over-encoding rules that change frequently (reference external docs instead)
|
|
283
|
+
- Not documenting the reasoning for decisions
|
|
284
|
+
|
|
285
|
+
---
|
|
286
|
+
|
|
287
|
+
## 6. Choosing Between Patterns
|
|
288
|
+
|
|
289
|
+
| Signal | Suggested Pattern |
|
|
290
|
+
|--------|------------------|
|
|
291
|
+
| "Do A, then B, then C" | Sequential Workflow |
|
|
292
|
+
| "Get data from X, send to Y, notify in Z" | Multi-MCP Coordination |
|
|
293
|
+
| "Make it good, then review and improve" | Iterative Refinement |
|
|
294
|
+
| "Handle PDFs differently from CSVs" | Context-Aware Selection |
|
|
295
|
+
| "Follow our compliance rules" | Domain-Specific Intelligence |
|
|
296
|
+
| Steps have no dependencies | Consider parallel execution |
|
|
297
|
+
| User says "it depends" a lot | Context-Aware Selection |
|
|
298
|
+
| Quality is subjective | Iterative Refinement |
|
|
299
|
+
|
|
300
|
+
---
|
|
301
|
+
|
|
302
|
+
## 7. Combining Patterns
|
|
303
|
+
|
|
304
|
+
Most real skills combine patterns. Common combinations:
|
|
305
|
+
|
|
306
|
+
- **Sequential + Domain Intelligence:** Follow steps in order, but embed
|
|
307
|
+
expert checks at critical points (e.g., compliance check before payment)
|
|
308
|
+
- **Multi-MCP + Iterative:** Coordinate across services, then refine the
|
|
309
|
+
combined output
|
|
310
|
+
- **Context-Aware + Sequential:** Choose the right tool first, then follow
|
|
311
|
+
a sequential workflow specific to that tool
|
|
312
|
+
- **Domain Intelligence + Iterative:** Apply domain rules, generate output,
|
|
313
|
+
review against domain criteria, refine
|
|
314
|
+
|
|
315
|
+
When combining, identify the PRIMARY pattern (the one that shapes the
|
|
316
|
+
overall flow) and SECONDARY patterns (the ones that apply within specific
|
|
317
|
+
steps).
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# Quality Checklist
|
|
2
|
+
|
|
3
|
+
Use this checklist at the end of the Validate phase to ensure the skill
|
|
4
|
+
meets all quality criteria before delivery.
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Structural Checks (Pass/Fail)
|
|
9
|
+
|
|
10
|
+
These are hard requirements. Any failure must be fixed.
|
|
11
|
+
|
|
12
|
+
- [ ] SKILL.md exists with exact casing
|
|
13
|
+
- [ ] YAML frontmatter has opening and closing `---` delimiters
|
|
14
|
+
- [ ] `name` field is present and kebab-case
|
|
15
|
+
- [ ] `name` matches the folder name
|
|
16
|
+
- [ ] `description` field is present
|
|
17
|
+
- [ ] `description` is under 1024 characters
|
|
18
|
+
- [ ] `description` contains no XML angle brackets (< >)
|
|
19
|
+
- [ ] `name` does not contain "claude" or "anthropic"
|
|
20
|
+
- [ ] No README.md inside the skill folder
|
|
21
|
+
- [ ] Folder name is kebab-case (no spaces, no capitals, no underscores)
|
|
22
|
+
|
|
23
|
+
## Description Quality (Score 1-5)
|
|
24
|
+
|
|
25
|
+
Rate each and target 4+ on all:
|
|
26
|
+
|
|
27
|
+
- [ ] **Specificity (1-5):** Does it describe a concrete capability?
|
|
28
|
+
- [ ] **Trigger clarity (1-5):** Would the agent know when to load this?
|
|
29
|
+
- [ ] **User language (1-5):** Does it use phrases a user would actually say?
|
|
30
|
+
- [ ] **Scope boundaries (1-5):** Is it clear what this skill does NOT do?
|
|
31
|
+
- [ ] **Pushiness (1-5):** Is it assertive enough to avoid undertriggering?
|
|
32
|
+
|
|
33
|
+
## Instruction Quality (Score 1-5)
|
|
34
|
+
|
|
35
|
+
- [ ] **Actionability (1-5):** Can the agent follow every step without ambiguity?
|
|
36
|
+
- [ ] **Specificity (1-5):** Are instructions concrete (not "validate properly")?
|
|
37
|
+
- [ ] **Examples (1-5):** Are there realistic input/output examples?
|
|
38
|
+
- [ ] **Error handling (1-5):** Are common failures addressed?
|
|
39
|
+
- [ ] **Progressive disclosure (1-5):** Is SKILL.md focused, with details in refs?
|
|
40
|
+
- [ ] **Composability (1-5):** Does it play well with other skills?
|
|
41
|
+
|
|
42
|
+
## Trigger Testing
|
|
43
|
+
|
|
44
|
+
### Should trigger (test 3-5 phrases)
|
|
45
|
+
|
|
46
|
+
1. [ ] "[Obvious request]" → triggers? Y/N
|
|
47
|
+
2. [ ] "[Paraphrased request]" → triggers? Y/N
|
|
48
|
+
3. [ ] "[Informal request]" → triggers? Y/N
|
|
49
|
+
|
|
50
|
+
### Should NOT trigger (test 3-5 phrases)
|
|
51
|
+
|
|
52
|
+
1. [ ] "[Unrelated task]" → stays silent? Y/N
|
|
53
|
+
2. [ ] "[Similar but different scope]" → stays silent? Y/N
|
|
54
|
+
3. [ ] "[Generic question]" → stays silent? Y/N
|
|
55
|
+
|
|
56
|
+
## Performance Targets
|
|
57
|
+
|
|
58
|
+
Aspirational benchmarks (adapt to your skill):
|
|
59
|
+
|
|
60
|
+
- [ ] Triggers on ≥90% of relevant queries
|
|
61
|
+
- [ ] Completes workflow without user correction
|
|
62
|
+
- [ ] Consistent results across separate sessions
|
|
63
|
+
- [ ] No failed tool/API calls per workflow
|
|
64
|
+
- [ ] Users don't need to prompt the agent about next steps
|
|
65
|
+
|
|
66
|
+
## Final Sign-Off
|
|
67
|
+
|
|
68
|
+
- [ ] User has reviewed the skill
|
|
69
|
+
- [ ] Test phrases produce expected behavior
|
|
70
|
+
- [ ] Skill is packaged and ready for upload
|