@musashishao/agent-kit 1.0.0 → 1.1.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.
Potentially problematic release.
This version of @musashishao/agent-kit might be problematic. Click here for more details.
- package/.agent/ARCHITECTURE.md +4 -2
- package/.agent/FEATURE_ROADMAP.md +5 -5
- package/.agent/skills/context-engineering/SKILL.md +74 -0
- package/.agent/skills/context-engineering/examples/advanced_code_request.md +73 -0
- package/.agent/skills/context-engineering/scripts/repo_mapper.py +27 -0
- package/.agent/skills/context-engineering/scripts/token_counter.py +65 -0
- package/.agent/skills/context-engineering/strategies/context-caching.md +50 -0
- package/.agent/skills/context-engineering/strategies/few-shot-examples.md +56 -0
- package/.agent/skills/context-engineering/strategies/skeleton-code.md +59 -0
- package/.agent/skills/context-engineering/strategies/xml-framing.md +57 -0
- package/.agent/skills/mcp-builder/SKILL.md +583 -97
- package/.agent/skills/mcp-builder/python-template.md +522 -0
- package/.agent/skills/mcp-builder/tool-patterns.md +642 -0
- package/.agent/skills/mcp-builder/typescript-template.md +361 -0
- package/.agent/skills/problem-solving/SKILL.md +556 -0
- package/.agent/skills/problem-solving/collision-zone-thinking.md +285 -0
- package/.agent/skills/problem-solving/inversion-exercise.md +205 -0
- package/.agent/skills/problem-solving/meta-pattern-recognition.md +313 -0
- package/.agent/skills/problem-solving/scale-game.md +300 -0
- package/.agent/skills/problem-solving/simplification-cascades.md +321 -0
- package/.agent/skills/problem-solving/when-stuck.md +146 -0
- package/.agent/workflows/context.md +47 -0
- package/package.json +1 -1
|
@@ -0,0 +1,321 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: simplification-cascades
|
|
3
|
+
parent: problem-solving
|
|
4
|
+
description: Find one insight that eliminates multiple components. "If this is true, we don't need X, Y, or Z."
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Simplification Cascades
|
|
8
|
+
|
|
9
|
+
> The best solution is the one that makes other solutions unnecessary.
|
|
10
|
+
|
|
11
|
+
## When to Use
|
|
12
|
+
|
|
13
|
+
- Solution feels overcomplicated
|
|
14
|
+
- Too many edge cases to handle
|
|
15
|
+
- Architecture is getting messy
|
|
16
|
+
- "Spaghetti" feeling
|
|
17
|
+
- Looking for elegant solutions
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## The Process
|
|
22
|
+
|
|
23
|
+
### Step 1: Map Current Complexity
|
|
24
|
+
|
|
25
|
+
List all components of your current solution:
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
Feature: User Permissions System
|
|
29
|
+
|
|
30
|
+
Components:
|
|
31
|
+
├── Role definitions (5 files)
|
|
32
|
+
├── Permission checks (23 places in code)
|
|
33
|
+
├── Role assignment UI (3 screens)
|
|
34
|
+
├── Role inheritance logic
|
|
35
|
+
├── Permission caching layer
|
|
36
|
+
├── Audit logging
|
|
37
|
+
├── Admin override system
|
|
38
|
+
├── Permission migration scripts
|
|
39
|
+
├── Role hierarchy validation
|
|
40
|
+
└── Permission conflict resolution
|
|
41
|
+
|
|
42
|
+
Count: 10+ components
|
|
43
|
+
Files: 15+
|
|
44
|
+
Complexity: HIGH
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
### Step 2: Ask "What If" Questions
|
|
48
|
+
|
|
49
|
+
Challenge the need for each component:
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
"What if there were only 2 roles?"
|
|
53
|
+
├── Most systems really need: Admin vs Member
|
|
54
|
+
├── 90% of role complexity goes unused
|
|
55
|
+
└── Would we still need inheritance? NO
|
|
56
|
+
|
|
57
|
+
"What if permissions were at resource level?"
|
|
58
|
+
├── Instead of: user → role → permission
|
|
59
|
+
├── Just: user → resource (access/no access)
|
|
60
|
+
└── Would we still need the matrix? NO
|
|
61
|
+
|
|
62
|
+
"What if we removed inheritance?"
|
|
63
|
+
├── Explicit beats implicit
|
|
64
|
+
├── Copy permissions instead of inherit
|
|
65
|
+
└── Would we still need conflict resolution? NO
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
### Step 3: Find the Cascade Effect
|
|
69
|
+
|
|
70
|
+
One insight that eliminates multiple things:
|
|
71
|
+
|
|
72
|
+
```
|
|
73
|
+
WINNING INSIGHT: "We only need 2 roles"
|
|
74
|
+
|
|
75
|
+
ELIMINATION CASCADE:
|
|
76
|
+
┌────────────────────────────────────────────────────────┐
|
|
77
|
+
│ Insight: Only 2 roles (Admin, Member) │
|
|
78
|
+
├────────────────────────────────────────────────────────┤
|
|
79
|
+
│ ✅ ELIMINATE: Role inheritance logic │
|
|
80
|
+
│ ✅ ELIMINATE: Complex permission matrix │
|
|
81
|
+
│ ✅ ELIMINATE: Role hierarchy validation │
|
|
82
|
+
│ ✅ ELIMINATE: Permission conflict resolution │
|
|
83
|
+
│ ✅ SIMPLIFY: Role UI → simple dropdown │
|
|
84
|
+
│ ✅ SIMPLIFY: Permission checks → isAdmin() helper │
|
|
85
|
+
│ ✅ SIMPLIFY: Audit → just log role changes │
|
|
86
|
+
│ ⚠️ KEEP: Resource-level exceptions (rare) │
|
|
87
|
+
└────────────────────────────────────────────────────────┘
|
|
88
|
+
|
|
89
|
+
RESULT:
|
|
90
|
+
├── Components: 10 → 3 (70% reduction)
|
|
91
|
+
├── Files: 15 → 5 (67% reduction)
|
|
92
|
+
├── Maintenance: almost eliminated
|
|
93
|
+
└── New developer onboarding: "Admins can do everything"
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
### Step 4: Validate the Simplification
|
|
97
|
+
|
|
98
|
+
```
|
|
99
|
+
VALIDATION CHECKLIST:
|
|
100
|
+
|
|
101
|
+
□ Does this cover 90% of use cases?
|
|
102
|
+
→ YES, most users are just "members"
|
|
103
|
+
|
|
104
|
+
□ What's lost?
|
|
105
|
+
→ Granular permissions (used by 0.1% of orgs)
|
|
106
|
+
|
|
107
|
+
□ Can we add back if needed?
|
|
108
|
+
→ YES, as a "Pro plan" feature
|
|
109
|
+
|
|
110
|
+
□ What's the migration path?
|
|
111
|
+
→ Map all existing roles to Admin/Member
|
|
112
|
+
→ Exceptions become explicit resource access
|
|
113
|
+
|
|
114
|
+
□ Is this reversible?
|
|
115
|
+
→ YES, we keep the data, just simplify logic
|
|
116
|
+
|
|
117
|
+
DECISION: ✅ PROCEED
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
---
|
|
121
|
+
|
|
122
|
+
## Simplification Patterns
|
|
123
|
+
|
|
124
|
+
### Pattern 1: Reduce Options
|
|
125
|
+
|
|
126
|
+
```
|
|
127
|
+
BEFORE: 5 notification channels
|
|
128
|
+
├── Email, SMS, Push, Slack, Webhook
|
|
129
|
+
├── Each needs: setup, templates, testing, monitoring
|
|
130
|
+
└── Complexity: 5x everything
|
|
131
|
+
|
|
132
|
+
ASK: "What percentage use each?"
|
|
133
|
+
├── Email: 95%
|
|
134
|
+
├── Push: 70%
|
|
135
|
+
├── Others: <10% each
|
|
136
|
+
|
|
137
|
+
AFTER: 2 notification channels
|
|
138
|
+
├── Email + Push only
|
|
139
|
+
├── Others get Webhook (DIY)
|
|
140
|
+
└── Complexity: 2x + simple webhook
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
### Pattern 2: Remove Flexibility
|
|
144
|
+
|
|
145
|
+
```
|
|
146
|
+
BEFORE: Configurable everything
|
|
147
|
+
├── Custom fields
|
|
148
|
+
├── Custom workflows
|
|
149
|
+
├── Custom permissions
|
|
150
|
+
├── Custom integrations
|
|
151
|
+
└── Complexity: INFINITE edge cases
|
|
152
|
+
|
|
153
|
+
ASK: "What if nothing was configurable?"
|
|
154
|
+
├── Opinionated: We decide the best way
|
|
155
|
+
├── Simpler: No config UI needed
|
|
156
|
+
├── Faster: No "how do I configure X?" support
|
|
157
|
+
└── Better: Our way is well-tested
|
|
158
|
+
|
|
159
|
+
AFTER: Opinionated defaults
|
|
160
|
+
├── 3 fixed workflows (most common)
|
|
161
|
+
├── 5 standard permissions
|
|
162
|
+
├── Official integrations only
|
|
163
|
+
└── Complexity: FINITE, tested, documented
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
### Pattern 3: Make It Manual
|
|
167
|
+
|
|
168
|
+
```
|
|
169
|
+
BEFORE: Automated sync system
|
|
170
|
+
├── Real-time sync
|
|
171
|
+
├── Conflict resolution
|
|
172
|
+
├── Retry logic
|
|
173
|
+
├── Status monitoring
|
|
174
|
+
├── Failure alerts
|
|
175
|
+
└── Complexity: distributed systems hard
|
|
176
|
+
|
|
177
|
+
ASK: "What if users just clicked refresh?"
|
|
178
|
+
├── Sync on demand
|
|
179
|
+
├── User can see if outdated
|
|
180
|
+
├── Simple "last updated" timestamp
|
|
181
|
+
├── No background jobs
|
|
182
|
+
└── No conflict scenarios
|
|
183
|
+
|
|
184
|
+
AFTER: Manual refresh
|
|
185
|
+
├── "Sync Now" button
|
|
186
|
+
├── Last synced timestamp
|
|
187
|
+
└── Complexity: almost zero
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
### Pattern 4: Accept Tradeoffs
|
|
191
|
+
|
|
192
|
+
```
|
|
193
|
+
BEFORE: Handle all edge cases
|
|
194
|
+
├── 50 edge cases identified
|
|
195
|
+
├── Each needs handling logic
|
|
196
|
+
├── Each needs testing
|
|
197
|
+
├── Each needs documentation
|
|
198
|
+
└── Complexity: grows forever
|
|
199
|
+
|
|
200
|
+
ASK: "What if we just didn't handle rare cases?"
|
|
201
|
+
├── Focus on 80% of users
|
|
202
|
+
├── Edge cases get manual process
|
|
203
|
+
├── Support handles exceptions
|
|
204
|
+
└── Document known limitations
|
|
205
|
+
|
|
206
|
+
AFTER: Graceful limitations
|
|
207
|
+
├── "For large imports, contact support"
|
|
208
|
+
├── "Bulk operations limited to 100 items"
|
|
209
|
+
├── Edge cases: 5 clear limitations
|
|
210
|
+
└── Complexity: bounded, maintained
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## Simplification Questions
|
|
216
|
+
|
|
217
|
+
| When you see... | Ask... |
|
|
218
|
+
|-----------------|--------|
|
|
219
|
+
| Multiple similar components | "Can we consolidate to one?" |
|
|
220
|
+
| Configurable options | "What if we picked for them?" |
|
|
221
|
+
| Real-time sync | "What if it was on-demand?" |
|
|
222
|
+
| Edge case handling | "What if we documented limitations instead?" |
|
|
223
|
+
| Inheritance/hierarchy | "What if everything was flat?" |
|
|
224
|
+
| Caching layer | "What if we just made it fast?" |
|
|
225
|
+
| Background jobs | "What if it was synchronous?" |
|
|
226
|
+
| Role-based access | "What if there were only 2 roles?" |
|
|
227
|
+
| Flexible schema | "What if schema was fixed?" |
|
|
228
|
+
| Multiple auth methods | "What if we only supported one?" |
|
|
229
|
+
|
|
230
|
+
---
|
|
231
|
+
|
|
232
|
+
## The Cascade Effect Template
|
|
233
|
+
|
|
234
|
+
```
|
|
235
|
+
INSIGHT: [Your simplifying insight]
|
|
236
|
+
|
|
237
|
+
If this is true, we can:
|
|
238
|
+
├── ELIMINATE: [Component 1]
|
|
239
|
+
├── ELIMINATE: [Component 2]
|
|
240
|
+
├── SIMPLIFY: [Component 3] → [Simple version]
|
|
241
|
+
├── SIMPLIFY: [Component 4] → [Simple version]
|
|
242
|
+
└── KEEP: [Only what's truly needed]
|
|
243
|
+
|
|
244
|
+
REDUCTION:
|
|
245
|
+
├── Components: [X] → [Y] ([Z]% reduction)
|
|
246
|
+
├── Complexity: [Description of improvement]
|
|
247
|
+
└── Maintenance: [Description of improvement]
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
---
|
|
251
|
+
|
|
252
|
+
## Practice Exercise
|
|
253
|
+
|
|
254
|
+
### Your Complex System:
|
|
255
|
+
> _______________________________________________
|
|
256
|
+
|
|
257
|
+
### Current Components (list all):
|
|
258
|
+
1. _______________________________________________
|
|
259
|
+
2. _______________________________________________
|
|
260
|
+
3. _______________________________________________
|
|
261
|
+
4. _______________________________________________
|
|
262
|
+
5. _______________________________________________
|
|
263
|
+
6. _______________________________________________
|
|
264
|
+
|
|
265
|
+
### Simplification Questions:
|
|
266
|
+
- What if we only supported 2 options?
|
|
267
|
+
- What if users did it manually?
|
|
268
|
+
- What if we didn't handle edge cases?
|
|
269
|
+
- What if nothing was configurable?
|
|
270
|
+
|
|
271
|
+
### Your Winning Insight:
|
|
272
|
+
> _______________________________________________
|
|
273
|
+
|
|
274
|
+
### What Gets Eliminated:
|
|
275
|
+
1. _______________________________________________
|
|
276
|
+
2. _______________________________________________
|
|
277
|
+
3. _______________________________________________
|
|
278
|
+
|
|
279
|
+
### Reduction:
|
|
280
|
+
- Components: ___ → ___
|
|
281
|
+
- Estimated complexity reduction: ___%
|
|
282
|
+
|
|
283
|
+
---
|
|
284
|
+
|
|
285
|
+
## Quick Reference
|
|
286
|
+
|
|
287
|
+
```
|
|
288
|
+
SIMPLIFICATION IN 60 SECONDS:
|
|
289
|
+
|
|
290
|
+
1. List all components:
|
|
291
|
+
→ "This system has [A], [B], [C], [D]..."
|
|
292
|
+
|
|
293
|
+
2. Challenge each with "What if...":
|
|
294
|
+
→ "What if we only had 2 options?"
|
|
295
|
+
→ "What if users did this themselves?"
|
|
296
|
+
|
|
297
|
+
3. Find the cascade:
|
|
298
|
+
→ "If [insight], then we don't need [X, Y, Z]"
|
|
299
|
+
|
|
300
|
+
4. Validate:
|
|
301
|
+
→ "Does this cover 90% of cases?"
|
|
302
|
+
→ "Is what we lose acceptable?"
|
|
303
|
+
|
|
304
|
+
5. Execute:
|
|
305
|
+
→ Remove the complexity with confidence
|
|
306
|
+
```
|
|
307
|
+
|
|
308
|
+
---
|
|
309
|
+
|
|
310
|
+
## Warning Signs You Need Simplification
|
|
311
|
+
|
|
312
|
+
- "It's complicated, but necessary"
|
|
313
|
+
- "We need a diagram to explain it"
|
|
314
|
+
- "Only [person] understands how it works"
|
|
315
|
+
- "We'll document it later"
|
|
316
|
+
- "This edge case requires..."
|
|
317
|
+
- Adding more code to fix bugs in complexity
|
|
318
|
+
|
|
319
|
+
---
|
|
320
|
+
|
|
321
|
+
> **Remember:** The goal isn't to oversimplify—it's to find the insight that makes complexity unnecessary. Often the best code is the code you don't have to write.
|
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: when-stuck
|
|
3
|
+
parent: problem-solving
|
|
4
|
+
description: Dispatcher to route you to the right problem-solving technique based on your specific type of stuck-ness.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# When Stuck - Problem Dispatcher
|
|
8
|
+
|
|
9
|
+
> Use this when you don't know which problem-solving technique to use.
|
|
10
|
+
|
|
11
|
+
## Quick Assessment
|
|
12
|
+
|
|
13
|
+
Answer honestly: **What type of stuck am I?**
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Decision Tree
|
|
18
|
+
|
|
19
|
+
```
|
|
20
|
+
START HERE
|
|
21
|
+
│
|
|
22
|
+
▼
|
|
23
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
24
|
+
│ "I don't know where to start" │
|
|
25
|
+
│ │
|
|
26
|
+
│ → INVERSION EXERCISE │
|
|
27
|
+
│ Start from the end goal, work backwards │
|
|
28
|
+
│ Question: "What does success look like?" │
|
|
29
|
+
│ Then: "What's the step right before success?" │
|
|
30
|
+
└─────────────────────────────────────────────────────────────┘
|
|
31
|
+
│ (not this)
|
|
32
|
+
▼
|
|
33
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
34
|
+
│ "I've tried everything, nothing works" │
|
|
35
|
+
│ │
|
|
36
|
+
│ → COLLISION ZONE THINKING │
|
|
37
|
+
│ Force unrelated concepts together │
|
|
38
|
+
│ Question: "What if this worked like [random domain]?" │
|
|
39
|
+
│ Pick: restaurants, video games, airports, theme parks │
|
|
40
|
+
└─────────────────────────────────────────────────────────────┘
|
|
41
|
+
│ (not this)
|
|
42
|
+
▼
|
|
43
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
44
|
+
│ "The solution is getting too complex" │
|
|
45
|
+
│ │
|
|
46
|
+
│ → SIMPLIFICATION CASCADES │
|
|
47
|
+
│ Find the one insight that eliminates complexity │
|
|
48
|
+
│ Question: "What single change removes 3+ components?" │
|
|
49
|
+
│ Start: List all components, find the linchpin │
|
|
50
|
+
└─────────────────────────────────────────────────────────────┘
|
|
51
|
+
│ (not this)
|
|
52
|
+
▼
|
|
53
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
54
|
+
│ "I can't see the full picture" │
|
|
55
|
+
│ │
|
|
56
|
+
│ → META-PATTERN RECOGNITION │
|
|
57
|
+
│ Find patterns that appear in 3+ domains │
|
|
58
|
+
│ Question: "What domains have solved similar problems?" │
|
|
59
|
+
│ Look: Nature, business, physics, biology │
|
|
60
|
+
└─────────────────────────────────────────────────────────────┘
|
|
61
|
+
│ (not this)
|
|
62
|
+
▼
|
|
63
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
64
|
+
│ "My assumptions might be wrong" │
|
|
65
|
+
│ │
|
|
66
|
+
│ → INVERSION EXERCISE │
|
|
67
|
+
│ Flip every assumption and explore │
|
|
68
|
+
│ Question: "What if the opposite were true?" │
|
|
69
|
+
│ Start: List 5 assumptions, invert each │
|
|
70
|
+
└─────────────────────────────────────────────────────────────┘
|
|
71
|
+
│ (not this)
|
|
72
|
+
▼
|
|
73
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
74
|
+
│ "I need to validate my approach" │
|
|
75
|
+
│ │
|
|
76
|
+
│ → SCALE GAME │
|
|
77
|
+
│ Test at extreme scales to reveal hidden constraints │
|
|
78
|
+
│ Question: "What happens at 1000x? At 0.001x?" │
|
|
79
|
+
│ Check: What breaks? What's revealed? │
|
|
80
|
+
└─────────────────────────────────────────────────────────────┘
|
|
81
|
+
│ (not this)
|
|
82
|
+
▼
|
|
83
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
84
|
+
│ "I'm blocked by external factors" │
|
|
85
|
+
│ │
|
|
86
|
+
│ → SEPARATE: Constraints vs Assumptions │
|
|
87
|
+
│ Real constraint: Cannot be changed (physics, law) │
|
|
88
|
+
│ Assumed constraint: "We've always done it this way" │
|
|
89
|
+
│ Question: "Who decided this rule?" │
|
|
90
|
+
└─────────────────────────────────────────────────────────────┘
|
|
91
|
+
│ (not this)
|
|
92
|
+
▼
|
|
93
|
+
┌─────────────────────────────────────────────────────────────┐
|
|
94
|
+
│ "I'm overthinking this" │
|
|
95
|
+
│ │
|
|
96
|
+
│ → SIMPLE ACTION │
|
|
97
|
+
│ Take the smallest possible action │
|
|
98
|
+
│ Question: "What's a 5-minute experiment?" │
|
|
99
|
+
│ Do: Build the smallest thing that teaches you │
|
|
100
|
+
└─────────────────────────────────────────────────────────────┘
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
---
|
|
104
|
+
|
|
105
|
+
## Quick Protocol
|
|
106
|
+
|
|
107
|
+
### Step 1: Name Your Block
|
|
108
|
+
Write ONE sentence about why you're stuck:
|
|
109
|
+
> "I'm stuck because _______________"
|
|
110
|
+
|
|
111
|
+
### Step 2: Match to Type
|
|
112
|
+
Look at the decision tree above. Which resonates?
|
|
113
|
+
|
|
114
|
+
### Step 3: Apply Framework
|
|
115
|
+
Go to that framework and follow its process.
|
|
116
|
+
|
|
117
|
+
### Step 4: Time-box
|
|
118
|
+
Give yourself 15-30 minutes with one framework. If still stuck, try the next one.
|
|
119
|
+
|
|
120
|
+
---
|
|
121
|
+
|
|
122
|
+
## Emergency Unstuck (2 minutes)
|
|
123
|
+
|
|
124
|
+
If you don't have time for a full framework:
|
|
125
|
+
|
|
126
|
+
1. **Write down the problem** in one sentence
|
|
127
|
+
2. **Invert it:** What if the opposite were true?
|
|
128
|
+
3. **Scale it:** What if this was 1000x bigger? 1000x smaller?
|
|
129
|
+
4. **Random collision:** What if this worked like a restaurant?
|
|
130
|
+
5. **Pick the most interesting insight** and explore for 5 minutes
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
## Framework Quick Links
|
|
135
|
+
|
|
136
|
+
| Framework | Best For | Time Needed |
|
|
137
|
+
|-----------|----------|-------------|
|
|
138
|
+
| [Inversion](inversion-exercise.md) | Wrong assumptions, no starting point | 15 min |
|
|
139
|
+
| [Collision Zone](collision-zone-thinking.md) | Need creativity, tried everything | 20 min |
|
|
140
|
+
| [Scale Game](scale-game.md) | Validation, hidden constraints | 15 min |
|
|
141
|
+
| [Pattern Recognition](meta-pattern-recognition.md) | Complex systems, wisdom needed | 30 min |
|
|
142
|
+
| [Simplification](simplification-cascades.md) | Overcomplicated, need elegance | 20 min |
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
> **Pro Tip:** Keep a "stuck journal." Every time you get stuck and unstuck, note which framework helped. You'll learn your patterns.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Auto-generate optimized context for complex tasks using Context Engineering strategies.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Context Optimization Workflow
|
|
6
|
+
|
|
7
|
+
This workflow automates the "Context Engineering" process. It analyzes your request, maps the project structure, summarizes relevant files, and wraps everything in a high-performance XML prompt structure for the AI.
|
|
8
|
+
|
|
9
|
+
**Trigger:** `/context [your task description]`
|
|
10
|
+
|
|
11
|
+
## Steps
|
|
12
|
+
|
|
13
|
+
1. **Analyze Intent:**
|
|
14
|
+
Take the user's task description ("{{task_description}}") and identify key domains (e.g., frontend, auth, database).
|
|
15
|
+
|
|
16
|
+
2. **Generate Repo Map:**
|
|
17
|
+
// turbo
|
|
18
|
+
Run the repo mapper to see the current structure.
|
|
19
|
+
`python3 .agent/skills/context-engineering/scripts/repo_mapper.py .`
|
|
20
|
+
|
|
21
|
+
3. **Construct Optimized Prompt:**
|
|
22
|
+
Based on the repo map and task, construct the following `Advanced Context` block.
|
|
23
|
+
|
|
24
|
+
**(Internal Instruction to AI):**
|
|
25
|
+
> You must now act as a Context Engineer. Do NOT just answer the user yet.
|
|
26
|
+
> Instead, OUTPUT a structured plan and code analysis using the gathered context.
|
|
27
|
+
> Use the `<thinking>` tag to analyze the Repo Map below.
|
|
28
|
+
> If the user's task matches specific files in the map, read them using `view_file`.
|
|
29
|
+
|
|
30
|
+
**Structure to enforce:**
|
|
31
|
+
```xml
|
|
32
|
+
<system_role>Senior Architect</system_role>
|
|
33
|
+
<project_context>
|
|
34
|
+
[Insert Output from Step 2 here]
|
|
35
|
+
</project_context>
|
|
36
|
+
<user_task>
|
|
37
|
+
{{task_description}}
|
|
38
|
+
</user_task>
|
|
39
|
+
<instruction>
|
|
40
|
+
1. Analyze the project structure above.
|
|
41
|
+
2. Identify ensuring files that need to be read or modified.
|
|
42
|
+
3. Proceed with solving the user's task using Chain-of-Thought (<thinking> tags).
|
|
43
|
+
</instruction>
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
4. **Execute:**
|
|
47
|
+
Proceed to solve the user's request using the heightened context awareness.
|