wb-flow 1.0.0-r01
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/CHANGELOG.md +12 -0
- package/LICENSE +21 -0
- package/README.md +128 -0
- package/assets/demo.gif +0 -0
- package/bin/install.js +175 -0
- package/bin/link.js +71 -0
- package/bin/verify-wrappers.js +49 -0
- package/package.json +56 -0
- package/templates/commands/_shared/output_conventions.md +433 -0
- package/templates/commands/_shared/wb_universal_agent_instructions.md +72 -0
- package/templates/commands/model_recommendation_updates.md +74 -0
- package/templates/commands/model_recommendations.md +112 -0
- package/templates/commands/wbActOn/wbActOn_template.md +546 -0
- package/templates/commands/wbAudit/wbAudit_template.md +315 -0
- package/templates/commands/wbBroadcast/wbBroadcast_template.md +133 -0
- package/templates/commands/wbCheck/wbCheck_template.md +322 -0
- package/templates/commands/wbClean/wbClean_template.md +118 -0
- package/templates/commands/wbContext/wbContext_template.md +213 -0
- package/templates/commands/wbDebug/wbDebug_template.md +132 -0
- package/templates/commands/wbDeploy/wbDeploy_template.md +224 -0
- package/templates/commands/wbDoc/wbDoc_template.md +138 -0
- package/templates/commands/wbExplain/wbExplain_template.md +98 -0
- package/templates/commands/wbGit/wbGit_template.md +160 -0
- package/templates/commands/wbHelp/wbHelp_template.md +101 -0
- package/templates/commands/wbIdea/wbIdea_template.md +337 -0
- package/templates/commands/wbLicense/wbLicense_template.md +148 -0
- package/templates/commands/wbMonetize/wbMonetize_template.md +113 -0
- package/templates/commands/wbNext/wbNext_template.md +270 -0
- package/templates/commands/wbPlan/wbPlan_template.md +413 -0
- package/templates/commands/wbPublish/wbPublish_template.md +205 -0
- package/templates/commands/wbRefactor/wbRefactor_template.md +129 -0
- package/templates/commands/wbRelease/wbRelease_template.md +229 -0
- package/templates/commands/wbReview/wbReview_template.md +252 -0
- package/templates/commands/wbSecure/wbSecure_template.md +157 -0
- package/templates/commands/wbSetup/wbSetup_template.md +203 -0
- package/templates/commands/wbStandup/wbStandup_template.md +198 -0
- package/templates/commands/wbTest/wbTest_template.md +226 -0
- package/templates/commands/wbToWBC/wbToWBC_template.md +91 -0
- package/templates/commands/wbTrack/wbTrack_template.md +555 -0
- package/templates/commands/wbTranslate/wbTranslate_template.md +114 -0
- package/templates/commands/wbValid/wbValid_template.md +142 -0
- package/templates/commands/wbVision/wbVision_template.md +141 -0
- package/templates/commands/wbWork/wbWork_template.md +140 -0
- package/templates/commands/wb_commands_reference.claude.json +2305 -0
- package/templates/commands/wb_commands_reference.json +1109 -0
- package/templates/shortcuts/shortcuts.md +413 -0
- package/templates/shortcuts/usage-management-examples-shortcuts/budget_controllers_examples.md +96 -0
- package/templates/shortcuts/usage-management-examples-shortcuts/ultimate_shortcuts_examples.md +1531 -0
package/templates/shortcuts/usage-management-examples-shortcuts/ultimate_shortcuts_examples.md
ADDED
|
@@ -0,0 +1,1531 @@
|
|
|
1
|
+
# AI Shortcuts — Daily Use Training Examples
|
|
2
|
+
> Simulate these examples to train with every command in the ultra-lite system.
|
|
3
|
+
> Each section covers a command with 2-4 real-world scenarios.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## STYLE & LENGTH
|
|
8
|
+
|
|
9
|
+
### /c — Short reply (2-3 sentences max)
|
|
10
|
+
|
|
11
|
+
**Scenario 1 — Quick definition**
|
|
12
|
+
```
|
|
13
|
+
/c What is Docker?
|
|
14
|
+
```
|
|
15
|
+
> Docker is a tool that packages your app and its dependencies into a container so it runs the same everywhere. Think of it as a lightweight VM without the overhead.
|
|
16
|
+
|
|
17
|
+
**Scenario 2 — Quick decision**
|
|
18
|
+
```
|
|
19
|
+
/c Should I use REST or GraphQL for my MVP?
|
|
20
|
+
```
|
|
21
|
+
> Use REST. It's simpler, faster to build, and easier to debug at MVP stage. Switch to GraphQL when your frontend data needs become complex.
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
### /d — Full detailed response
|
|
26
|
+
|
|
27
|
+
**Scenario 1 — Architecture decision**
|
|
28
|
+
```
|
|
29
|
+
/d Explain the difference between monolith and microservices for a startup
|
|
30
|
+
```
|
|
31
|
+
> [Full response covering tradeoffs, when to use each, migration path, real examples]
|
|
32
|
+
|
|
33
|
+
**Scenario 2 — Deep dive on a concept**
|
|
34
|
+
```
|
|
35
|
+
/d How does JWT authentication work end to end?
|
|
36
|
+
```
|
|
37
|
+
> [Full response: token structure, signing, verification, refresh tokens, security considerations]
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
### /wissem — Direct, startup-aware, Tunisia context
|
|
42
|
+
|
|
43
|
+
**Scenario 1 — Business advice**
|
|
44
|
+
```
|
|
45
|
+
/wissem Should I incorporate in Tunisia or offshore for my SaaS?
|
|
46
|
+
```
|
|
47
|
+
> Offshore (Estonia or Delaware) if you're targeting international clients — easier payments, better credibility with foreign investors. Tunisia if you're serving local market or need local banking. What's your target customer?
|
|
48
|
+
|
|
49
|
+
**Scenario 2 — Product decision**
|
|
50
|
+
```
|
|
51
|
+
/wissem We have 3 features to build. How do I decide which first?
|
|
52
|
+
```
|
|
53
|
+
> Build the one that unblocks revenue or retention first. Everything else is a distraction until you're making money.
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
### /direct — No hedging, no disclaimers
|
|
58
|
+
|
|
59
|
+
**Scenario 1 — Honest feedback**
|
|
60
|
+
```
|
|
61
|
+
/direct Is my landing page copy good? "We leverage AI-powered synergies to optimize your workflow."
|
|
62
|
+
```
|
|
63
|
+
> No. It's corporate jargon that says nothing. Rewrite it as what you actually do: "We automate [specific task] so your team saves [X hours] a week."
|
|
64
|
+
|
|
65
|
+
**Scenario 2 — Tech choice**
|
|
66
|
+
```
|
|
67
|
+
/direct Should I learn React or Vue in 2026?
|
|
68
|
+
```
|
|
69
|
+
> React. Bigger job market, more libraries, more tutorials. Vue is fine but React wins on career ROI.
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
### /vd — Exhaustive response
|
|
74
|
+
|
|
75
|
+
**Scenario 1 — Full audit**
|
|
76
|
+
```
|
|
77
|
+
/vd Review all security considerations for a Node.js REST API
|
|
78
|
+
```
|
|
79
|
+
> [Exhaustive: input validation, auth, rate limiting, CORS, headers, SQL injection, XSS, logging, secrets management, dependencies audit, HTTPS, etc.]
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
### /eli5 — Explain like I'm 5
|
|
84
|
+
|
|
85
|
+
**Scenario 1 — Technical concept**
|
|
86
|
+
```
|
|
87
|
+
/eli5 What is an API?
|
|
88
|
+
```
|
|
89
|
+
> Imagine a restaurant. You (the app) give your order to the waiter (the API). The waiter takes it to the kitchen (the server) and brings back your food (the data). You never go into the kitchen yourself.
|
|
90
|
+
|
|
91
|
+
**Scenario 2 — Business concept**
|
|
92
|
+
```
|
|
93
|
+
/eli5 What is product-market fit?
|
|
94
|
+
```
|
|
95
|
+
> It means people really want what you're selling. Like when everyone at school wants the same toy — the toy has found its market.
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
### /technical — Precise technical language
|
|
100
|
+
|
|
101
|
+
**Scenario 1 — Code review**
|
|
102
|
+
```
|
|
103
|
+
/technical Explain what's wrong with using var in JavaScript
|
|
104
|
+
```
|
|
105
|
+
> `var` is function-scoped and hoisted to the top of its scope, which can cause unintended variable leakage and temporal dead zone issues. Use `const` for immutable bindings and `let` for block-scoped mutable variables to enforce lexical scoping.
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
### /practical — Real-world focus
|
|
110
|
+
|
|
111
|
+
**Scenario 1 — Learning path**
|
|
112
|
+
```
|
|
113
|
+
/practical How do I learn system design?
|
|
114
|
+
```
|
|
115
|
+
> Start by reading real post-mortems (GitHub, Netflix, Cloudflare blogs). Then design systems you actually use — Uber, WhatsApp. Practice explaining tradeoffs out loud. Don't read theory without building something first.
|
|
116
|
+
|
|
117
|
+
---
|
|
118
|
+
|
|
119
|
+
### /casual — Relaxed tone
|
|
120
|
+
|
|
121
|
+
**Scenario 1 — Brainstorm**
|
|
122
|
+
```
|
|
123
|
+
/casual Give me name ideas for a productivity app for devs
|
|
124
|
+
```
|
|
125
|
+
> Oh this is fun — how about FlowState, DeepWork, or just something cheeky like NoBrainer? Or go meta: Unblocked, ZeroTab, or Focusd (no 'e' for that startup feel 😄)
|
|
126
|
+
|
|
127
|
+
---
|
|
128
|
+
|
|
129
|
+
### /neutral — Balanced view
|
|
130
|
+
|
|
131
|
+
**Scenario 1 — Controversial tech**
|
|
132
|
+
```
|
|
133
|
+
/neutral Is AI going to replace developers?
|
|
134
|
+
```
|
|
135
|
+
> Some argue AI will automate repetitive coding tasks and reduce demand for junior developers. Others point out that software complexity is growing faster than AI can keep up, creating more demand overall. The likely reality is a shift in the skill mix required, not wholesale replacement.
|
|
136
|
+
|
|
137
|
+
---
|
|
138
|
+
|
|
139
|
+
## OUTPUT FORMAT
|
|
140
|
+
|
|
141
|
+
### /b — Bullet list
|
|
142
|
+
|
|
143
|
+
**Scenario 1 — Feature list**
|
|
144
|
+
```
|
|
145
|
+
/b What should a good user onboarding flow include?
|
|
146
|
+
```
|
|
147
|
+
> - Welcome email with clear next step
|
|
148
|
+
> - In-app checklist (3-5 items max)
|
|
149
|
+
> - Empty state guidance on first login
|
|
150
|
+
> - One "aha moment" trigger within first session
|
|
151
|
+
> - Follow-up email at day 3 if not activated
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
### /nb — Numbered list
|
|
156
|
+
|
|
157
|
+
**Scenario 1 — Process**
|
|
158
|
+
```
|
|
159
|
+
/nb Steps to deploy a Node app to a VPS
|
|
160
|
+
```
|
|
161
|
+
> 1. SSH into your server
|
|
162
|
+
> 2. Clone your repo
|
|
163
|
+
> 3. Run `npm install --production`
|
|
164
|
+
> 4. Set environment variables
|
|
165
|
+
> 5. Start with `pm2 start app.js`
|
|
166
|
+
> 6. Configure Nginx as reverse proxy
|
|
167
|
+
> 7. Set up SSL with Certbot
|
|
168
|
+
|
|
169
|
+
---
|
|
170
|
+
|
|
171
|
+
### /step — Step-by-step instructions
|
|
172
|
+
|
|
173
|
+
**Scenario 1 — Setup task**
|
|
174
|
+
```
|
|
175
|
+
/step How do I set up GitHub Actions for CI on a Node project?
|
|
176
|
+
```
|
|
177
|
+
> Step 1: Create `.github/workflows/ci.yml` in your repo
|
|
178
|
+
> Step 2: Define trigger — `on: [push, pull_request]`
|
|
179
|
+
> Step 3: Add a job with `runs-on: ubuntu-latest`
|
|
180
|
+
> Step 4: Add steps: checkout, setup-node, npm install, npm test
|
|
181
|
+
> Step 5: Push and check the Actions tab in GitHub
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
### /table — Structured table
|
|
186
|
+
|
|
187
|
+
**Scenario 1 — Comparison**
|
|
188
|
+
```
|
|
189
|
+
/table Compare Vercel, Railway, and Render for deploying a Node API
|
|
190
|
+
```
|
|
191
|
+
> | Platform | Free Tier | Cold Starts | Custom Domain | Best For |
|
|
192
|
+
> |---|---|---|---|---|
|
|
193
|
+
> | Vercel | Yes | Yes (serverless) | Yes | Frontend + edge |
|
|
194
|
+
> | Railway | $5 credit | No | Yes | Full-stack apps |
|
|
195
|
+
> | Render | Yes (limited) | Yes (free) | Yes | Side projects |
|
|
196
|
+
|
|
197
|
+
---
|
|
198
|
+
|
|
199
|
+
### /json — JSON output
|
|
200
|
+
|
|
201
|
+
**Scenario 1 — Data structure**
|
|
202
|
+
```
|
|
203
|
+
/json Give me a user profile schema for a SaaS app
|
|
204
|
+
```
|
|
205
|
+
> ```json
|
|
206
|
+
> {
|
|
207
|
+
> "id": "uuid",
|
|
208
|
+
> "email": "string",
|
|
209
|
+
> "name": "string",
|
|
210
|
+
> "plan": "free | pro | enterprise",
|
|
211
|
+
> "createdAt": "ISO8601",
|
|
212
|
+
> "settings": {
|
|
213
|
+
> "notifications": true,
|
|
214
|
+
> "language": "en"
|
|
215
|
+
> }
|
|
216
|
+
> }
|
|
217
|
+
> ```
|
|
218
|
+
|
|
219
|
+
---
|
|
220
|
+
|
|
221
|
+
### /code — Code block only
|
|
222
|
+
|
|
223
|
+
**Scenario 1 — Quick snippet**
|
|
224
|
+
```
|
|
225
|
+
/code Node.js middleware to log request time
|
|
226
|
+
```
|
|
227
|
+
> ```javascript
|
|
228
|
+
> app.use((req, res, next) => {
|
|
229
|
+
> const start = Date.now();
|
|
230
|
+
> res.on('finish', () => {
|
|
231
|
+
> console.log(`${req.method} ${req.url} - ${Date.now() - start}ms`);
|
|
232
|
+
> });
|
|
233
|
+
> next();
|
|
234
|
+
> });
|
|
235
|
+
> ```
|
|
236
|
+
|
|
237
|
+
---
|
|
238
|
+
|
|
239
|
+
### /proscons — Pros and cons
|
|
240
|
+
|
|
241
|
+
**Scenario 1 — Tech decision**
|
|
242
|
+
```
|
|
243
|
+
/proscons Using MongoDB for a startup MVP
|
|
244
|
+
```
|
|
245
|
+
> **Pros**
|
|
246
|
+
> - Flexible schema — great for evolving data models
|
|
247
|
+
> - Fast to start, no migrations early on
|
|
248
|
+
> - Good free tier on Atlas
|
|
249
|
+
>
|
|
250
|
+
> **Cons**
|
|
251
|
+
> - No joins — complex relations get messy fast
|
|
252
|
+
> - Easy to create performance problems with bad schemas
|
|
253
|
+
> - Not ideal if you need strong consistency
|
|
254
|
+
|
|
255
|
+
---
|
|
256
|
+
|
|
257
|
+
### /compare,a,b — Side-by-side comparison
|
|
258
|
+
|
|
259
|
+
**Scenario 1 — Framework choice**
|
|
260
|
+
```
|
|
261
|
+
/compare,NextJS,NuxtJS
|
|
262
|
+
```
|
|
263
|
+
> | | Next.js | Nuxt.js |
|
|
264
|
+
> |---|---|---|
|
|
265
|
+
> | Framework | React | Vue |
|
|
266
|
+
> | SSR | Yes | Yes |
|
|
267
|
+
> | Community | Larger | Smaller |
|
|
268
|
+
> | Learning curve | Medium | Easier |
|
|
269
|
+
> | Job market | Stronger | Good |
|
|
270
|
+
> | Best for | React devs, large teams | Vue devs, faster ramp-up |
|
|
271
|
+
|
|
272
|
+
---
|
|
273
|
+
|
|
274
|
+
### /final_only — Skip reasoning, show output only
|
|
275
|
+
|
|
276
|
+
**Scenario 1 — Get the result without explanation**
|
|
277
|
+
```
|
|
278
|
+
/final_only Write a subject line for a cold email to a CTO about my dev tool
|
|
279
|
+
```
|
|
280
|
+
> "Cut your team's code review time by 40% — worth 10 minutes?"
|
|
281
|
+
|
|
282
|
+
---
|
|
283
|
+
|
|
284
|
+
### /answer_only — One line
|
|
285
|
+
|
|
286
|
+
**Scenario 1 — Quick fact**
|
|
287
|
+
```
|
|
288
|
+
/answer_only What HTTP status code means "not found"?
|
|
289
|
+
```
|
|
290
|
+
> 404
|
|
291
|
+
|
|
292
|
+
---
|
|
293
|
+
|
|
294
|
+
### /no_explanation — Output only
|
|
295
|
+
|
|
296
|
+
**Scenario 1 — Clean code output**
|
|
297
|
+
```
|
|
298
|
+
/no_explanation Write a Python function that checks if a string is a palindrome
|
|
299
|
+
```
|
|
300
|
+
> ```python
|
|
301
|
+
> def is_palindrome(s):
|
|
302
|
+
> return s == s[::-1]
|
|
303
|
+
> ```
|
|
304
|
+
|
|
305
|
+
---
|
|
306
|
+
|
|
307
|
+
### /quick — Fastest useful answer
|
|
308
|
+
|
|
309
|
+
**Scenario 1 — Urgent fix**
|
|
310
|
+
```
|
|
311
|
+
/quick How do I kill a process on port 3000 in Mac?
|
|
312
|
+
```
|
|
313
|
+
> `lsof -ti:3000 | xargs kill`
|
|
314
|
+
|
|
315
|
+
---
|
|
316
|
+
|
|
317
|
+
## REASONING
|
|
318
|
+
|
|
319
|
+
### /cot — Step-by-step reasoning
|
|
320
|
+
|
|
321
|
+
**Scenario 1 — Architecture decision**
|
|
322
|
+
```
|
|
323
|
+
/cot Should I use a queue (like Bull) for sending emails in my app?
|
|
324
|
+
```
|
|
325
|
+
> Let me think through this:
|
|
326
|
+
> 1. Email sending can fail — if done synchronously, it blocks the request
|
|
327
|
+
> 2. Users shouldn't wait for email delivery to get a response
|
|
328
|
+
> 3. If the email service is down, you need retry logic
|
|
329
|
+
> 4. At scale, bursts of signups would overwhelm a sync approach
|
|
330
|
+
> Conclusion: Yes, use a queue. Bull + Redis is the standard for Node. Even at small scale, it's the right pattern.
|
|
331
|
+
|
|
332
|
+
---
|
|
333
|
+
|
|
334
|
+
### /selfcritic — Answer → critique → improve
|
|
335
|
+
|
|
336
|
+
**Scenario 1 — Copy review**
|
|
337
|
+
```
|
|
338
|
+
/selfcritic Write a tagline for a project management tool for dev teams
|
|
339
|
+
```
|
|
340
|
+
> **Draft:** "Manage your projects smarter."
|
|
341
|
+
>
|
|
342
|
+
> **Critique:** Too generic. Every PM tool says this. No specificity, no benefit, no audience.
|
|
343
|
+
>
|
|
344
|
+
> **Improved:** "Ship faster. Less standup, more done." — speaks directly to dev teams' pain of too many meetings.
|
|
345
|
+
|
|
346
|
+
---
|
|
347
|
+
|
|
348
|
+
### /rootcause — Diagnose root cause
|
|
349
|
+
|
|
350
|
+
**Scenario 1 — Performance issue**
|
|
351
|
+
```
|
|
352
|
+
/rootcause My API response times are increasing over time. What's the root cause?
|
|
353
|
+
```
|
|
354
|
+
> Most likely root cause: unindexed database queries accumulating data over time.
|
|
355
|
+
> As your dataset grows, a query that was fast at 1K rows becomes slow at 100K rows without an index.
|
|
356
|
+
> Secondary suspects: memory leaks in long-running processes, N+1 query patterns, or connection pool exhaustion.
|
|
357
|
+
> Check: slow query logs first, then memory usage over time.
|
|
358
|
+
|
|
359
|
+
---
|
|
360
|
+
|
|
361
|
+
### /first_principles — Fundamentals first
|
|
362
|
+
|
|
363
|
+
**Scenario 1 — System design**
|
|
364
|
+
```
|
|
365
|
+
/first_principles How should I design a notification system?
|
|
366
|
+
```
|
|
367
|
+
> From first principles:
|
|
368
|
+
> - A notification is just a message triggered by an event
|
|
369
|
+
> - Events can be synchronous (user action) or async (scheduled)
|
|
370
|
+
> - Delivery channels are independent of the event (email, SMS, push)
|
|
371
|
+
> - Failures in delivery shouldn't block the core app
|
|
372
|
+
> Therefore: event → queue → worker → channel adapter. Each layer is independent. Start with this pattern and add complexity only when needed.
|
|
373
|
+
|
|
374
|
+
---
|
|
375
|
+
|
|
376
|
+
### /analogy — Explain with analogy
|
|
377
|
+
|
|
378
|
+
**Scenario 1 — Technical concept**
|
|
379
|
+
```
|
|
380
|
+
/analogy Explain load balancing
|
|
381
|
+
```
|
|
382
|
+
> Imagine a busy McDonald's with 4 cashiers. A load balancer is the person at the door who directs each customer to the cashier with the shortest queue. No single cashier gets overwhelmed, and customers get served faster overall.
|
|
383
|
+
|
|
384
|
+
---
|
|
385
|
+
|
|
386
|
+
### /improve — Make it better
|
|
387
|
+
|
|
388
|
+
**Scenario 1 — Improve existing code**
|
|
389
|
+
```
|
|
390
|
+
/improve
|
|
391
|
+
[paste your code or text]
|
|
392
|
+
```
|
|
393
|
+
> [Returns improved version with explanation of what changed and why]
|
|
394
|
+
|
|
395
|
+
---
|
|
396
|
+
|
|
397
|
+
### /simplify — Reduce complexity
|
|
398
|
+
|
|
399
|
+
**Scenario 1 — Simplify architecture**
|
|
400
|
+
```
|
|
401
|
+
/simplify Our stack: React frontend, Node API, Redis cache, MongoDB, RabbitMQ, Elasticsearch. MVP with 50 users.
|
|
402
|
+
```
|
|
403
|
+
> Drop RabbitMQ and Elasticsearch immediately. At 50 users you don't need a message queue or search engine. Use MongoDB's built-in text search. Add queues only when you have proven async load. Simpler stack = faster iteration = less ops burden.
|
|
404
|
+
|
|
405
|
+
---
|
|
406
|
+
|
|
407
|
+
### /expand — Add depth
|
|
408
|
+
|
|
409
|
+
**Scenario 1 — Expand a short answer**
|
|
410
|
+
```
|
|
411
|
+
/expand You said "use indexes". Tell me more.
|
|
412
|
+
```
|
|
413
|
+
> [Expanded: types of indexes, when to use compound vs single, how to identify missing indexes, explain plans, index tradeoffs on write performance, etc.]
|
|
414
|
+
|
|
415
|
+
---
|
|
416
|
+
|
|
417
|
+
### /rewrite — Full rewrite
|
|
418
|
+
|
|
419
|
+
**Scenario 1 — Rewrite bad copy**
|
|
420
|
+
```
|
|
421
|
+
/rewrite "Our platform utilizes cutting-edge machine learning algorithms to provide actionable insights."
|
|
422
|
+
```
|
|
423
|
+
> "We analyze your data and tell you exactly what to do next — no guesswork."
|
|
424
|
+
|
|
425
|
+
---
|
|
426
|
+
|
|
427
|
+
## CONTEXT & FILES
|
|
428
|
+
|
|
429
|
+
### /ctx,name,load + /ctx,name,analyze
|
|
430
|
+
|
|
431
|
+
**Scenario 1 — Load and analyze backend**
|
|
432
|
+
```
|
|
433
|
+
/ctx,backend,load
|
|
434
|
+
/ctx,backend,analyze
|
|
435
|
+
```
|
|
436
|
+
> [Load]: Context "backend" loaded.
|
|
437
|
+
> [Analyze]: The backend uses Express with MongoDB. Auth is handled via JWT in middleware. Main concerns: no input validation on POST routes, database calls not wrapped in try/catch, no rate limiting on auth endpoints.
|
|
438
|
+
|
|
439
|
+
---
|
|
440
|
+
|
|
441
|
+
### /f,file,debug — Find bugs in a file
|
|
442
|
+
|
|
443
|
+
**Scenario 1 — Debug auth file**
|
|
444
|
+
```
|
|
445
|
+
/f,auth.js,load
|
|
446
|
+
/f,auth.js,debug
|
|
447
|
+
```
|
|
448
|
+
> Bugs found in auth.js:
|
|
449
|
+
> 1. Line 23: JWT secret hardcoded as string — should use `process.env.JWT_SECRET`
|
|
450
|
+
> 2. Line 47: No expiry set on token — tokens never expire
|
|
451
|
+
> 3. Line 61: Password compared with `==` instead of `bcrypt.compare()`
|
|
452
|
+
|
|
453
|
+
---
|
|
454
|
+
|
|
455
|
+
### /f,file,test — Generate tests
|
|
456
|
+
|
|
457
|
+
**Scenario 1 — Generate tests for a utility**
|
|
458
|
+
```
|
|
459
|
+
/f,utils.js,load
|
|
460
|
+
/f,utils.js,test
|
|
461
|
+
```
|
|
462
|
+
> [Returns full Jest test suite covering happy path, edge cases, and error cases]
|
|
463
|
+
|
|
464
|
+
---
|
|
465
|
+
|
|
466
|
+
### /f,file,refactor — Refactor for readability
|
|
467
|
+
|
|
468
|
+
**Scenario 1 — Clean up messy code**
|
|
469
|
+
```
|
|
470
|
+
/f,userController.js,load
|
|
471
|
+
/f,userController.js,refactor
|
|
472
|
+
```
|
|
473
|
+
> [Returns refactored version: extracted functions, consistent error handling, removed duplication, added clear variable names]
|
|
474
|
+
|
|
475
|
+
---
|
|
476
|
+
|
|
477
|
+
## EXECUTION
|
|
478
|
+
|
|
479
|
+
### /plan_then_execute
|
|
480
|
+
|
|
481
|
+
**Scenario 1 — Build a feature**
|
|
482
|
+
```
|
|
483
|
+
/wissem /goal,add_stripe_payments /plan_then_execute
|
|
484
|
+
```
|
|
485
|
+
> Plan:
|
|
486
|
+
> 1. Install stripe SDK
|
|
487
|
+
> 2. Create /api/create-checkout-session endpoint
|
|
488
|
+
> 3. Add webhook handler for payment confirmation
|
|
489
|
+
> 4. Store subscription status on user model
|
|
490
|
+
> 5. Gate premium features behind status check
|
|
491
|
+
>
|
|
492
|
+
> Proceed? (yes/no)
|
|
493
|
+
|
|
494
|
+
---
|
|
495
|
+
|
|
496
|
+
### /dry_run — Simulate without executing
|
|
497
|
+
|
|
498
|
+
**Scenario 1 — Preview database migration**
|
|
499
|
+
```
|
|
500
|
+
/dry_run Add a "status" field to all existing user records with default value "active"
|
|
501
|
+
```
|
|
502
|
+
> Simulation:
|
|
503
|
+
> - Query: `db.users.updateMany({}, { $set: { status: "active" } })`
|
|
504
|
+
> - Affected documents: ~2,400 records
|
|
505
|
+
> - Risk: Low — additive change, no data loss
|
|
506
|
+
> - Rollback: `db.users.updateMany({}, { $unset: { status: "" } })`
|
|
507
|
+
> Run it? (yes/no)
|
|
508
|
+
|
|
509
|
+
---
|
|
510
|
+
|
|
511
|
+
### /goal,x + /goal_status
|
|
512
|
+
|
|
513
|
+
**Scenario 1 — Track progress**
|
|
514
|
+
```
|
|
515
|
+
/goal,launch_beta_by_april
|
|
516
|
+
```
|
|
517
|
+
> Goal set: launch_beta_by_april. I'll keep this in context throughout our session.
|
|
518
|
+
|
|
519
|
+
```
|
|
520
|
+
/goal_status
|
|
521
|
+
```
|
|
522
|
+
> Current goal: launch_beta_by_april
|
|
523
|
+
> Completed: auth, user dashboard, basic CRUD
|
|
524
|
+
> Remaining: payment integration, email notifications, staging deploy, QA
|
|
525
|
+
> Estimated: 60% done
|
|
526
|
+
|
|
527
|
+
---
|
|
528
|
+
|
|
529
|
+
## ROLES
|
|
530
|
+
|
|
531
|
+
### /wissempro — Tunisian tech entrepreneur advisor
|
|
532
|
+
|
|
533
|
+
**Scenario 1 — Fundraising advice**
|
|
534
|
+
```
|
|
535
|
+
/wissempro Should I raise a pre-seed round now or wait until I have revenue?
|
|
536
|
+
```
|
|
537
|
+
> If you can get to first revenue in 3-6 months without raising, do it. Revenue changes your leverage completely — you're no longer begging, you're choosing. In Tunisia especially, bootstrap as far as you can before diluting. Raise only when you have a specific use of funds that multiplies revenue, not just to extend runway.
|
|
538
|
+
|
|
539
|
+
---
|
|
540
|
+
|
|
541
|
+
### /expert — World-class expert
|
|
542
|
+
|
|
543
|
+
**Scenario 1 — Security review**
|
|
544
|
+
```
|
|
545
|
+
/expert Review the security of my JWT implementation
|
|
546
|
+
```
|
|
547
|
+
> [Responds as a senior security engineer: checks algorithm (avoid none/HS256 weak keys), token storage (httpOnly cookies vs localStorage), expiry strategy, refresh token rotation, revocation approach, CSRF protection, etc.]
|
|
548
|
+
|
|
549
|
+
---
|
|
550
|
+
|
|
551
|
+
### /engineer — Pragmatic implementer
|
|
552
|
+
|
|
553
|
+
**Scenario 1 — Feature implementation**
|
|
554
|
+
```
|
|
555
|
+
/engineer How should I implement search in my app?
|
|
556
|
+
```
|
|
557
|
+
> At your scale: use your existing database's built-in full-text search first. PostgreSQL has `tsvector`, MongoDB has `$text`. Don't add Elasticsearch until you've proven the DB can't handle it. That's probably 100K+ documents with complex queries. Build the simple thing first.
|
|
558
|
+
|
|
559
|
+
---
|
|
560
|
+
|
|
561
|
+
### /critic — Honest evaluation
|
|
562
|
+
|
|
563
|
+
**Scenario 1 — Evaluate an idea**
|
|
564
|
+
```
|
|
565
|
+
/critic My startup idea: an app that connects freelancers with clients in Tunisia
|
|
566
|
+
```
|
|
567
|
+
> Hard pass on the current positioning. This is a crowded space globally (Upwork, Fiverr, Malt) and locally (there are already Tunisian copycats). Without a specific niche or unfair advantage, you'll spend all your money on supply/demand acquisition. What's your moat? If you can't answer that in one sentence, the idea needs more work.
|
|
568
|
+
|
|
569
|
+
---
|
|
570
|
+
|
|
571
|
+
### /pm — Scope and prioritize
|
|
572
|
+
|
|
573
|
+
**Scenario 1 — Scope an MVP**
|
|
574
|
+
```
|
|
575
|
+
/pm We want to build a SaaS for invoice management. What's the MVP scope?
|
|
576
|
+
```
|
|
577
|
+
> Cut it to: create invoice, send by email, mark as paid. That's it. No recurring invoices, no multi-currency, no client portal, no reminders, no dashboard. Those are v2. Ship the core loop first and validate that people will pay for it.
|
|
578
|
+
|
|
579
|
+
---
|
|
580
|
+
|
|
581
|
+
## PRIORITIZATION
|
|
582
|
+
|
|
583
|
+
### /focus,top3
|
|
584
|
+
|
|
585
|
+
**Scenario 1 — Weekly planning**
|
|
586
|
+
```
|
|
587
|
+
/wissempro /focus,top3 I have: fix login bug, write docs, add dark mode, improve onboarding, set up analytics, write blog post
|
|
588
|
+
```
|
|
589
|
+
> Top 3:
|
|
590
|
+
> 1. Fix login bug — blocking users, revenue at risk
|
|
591
|
+
> 2. Improve onboarding — directly impacts activation rate
|
|
592
|
+
> 3. Set up analytics — you can't improve what you can't measure
|
|
593
|
+
>
|
|
594
|
+
> Everything else is noise until these are done.
|
|
595
|
+
|
|
596
|
+
---
|
|
597
|
+
|
|
598
|
+
### /quick_wins
|
|
599
|
+
|
|
600
|
+
**Scenario 1 — Find easy wins**
|
|
601
|
+
```
|
|
602
|
+
/quick_wins What can I improve on my SaaS landing page this week?
|
|
603
|
+
```
|
|
604
|
+
> - Add a real screenshot or demo GIF (2hrs, high conversion impact)
|
|
605
|
+
> - Add 2-3 customer logos or testimonials (1hr if you have them)
|
|
606
|
+
> - Make the CTA button bigger and change color to contrast (30min)
|
|
607
|
+
> - Add pricing on the page — hiding it kills trust (1hr)
|
|
608
|
+
|
|
609
|
+
---
|
|
610
|
+
|
|
611
|
+
### /effort — Effort estimate
|
|
612
|
+
|
|
613
|
+
**Scenario 1 — Estimate a feature**
|
|
614
|
+
```
|
|
615
|
+
/effort Add Stripe subscription billing to an existing Node/React app
|
|
616
|
+
```
|
|
617
|
+
> Medium-High effort. Estimate: 3-5 days for a solo dev.
|
|
618
|
+
> - Stripe SDK setup + webhook: 4hrs
|
|
619
|
+
> - Checkout flow + success/cancel pages: 4hrs
|
|
620
|
+
> - Subscription status on user model: 2hrs
|
|
621
|
+
> - Gating features behind plan: 3hrs
|
|
622
|
+
> - Testing + edge cases: 4hrs
|
|
623
|
+
> Risk: webhooks are the tricky part — budget extra time there.
|
|
624
|
+
|
|
625
|
+
---
|
|
626
|
+
|
|
627
|
+
## INTERACTION
|
|
628
|
+
|
|
629
|
+
### /no_questions — Assume and proceed
|
|
630
|
+
|
|
631
|
+
**Scenario 1 — Code task**
|
|
632
|
+
```
|
|
633
|
+
/no_questions /wissem Build me a REST endpoint to create a user
|
|
634
|
+
```
|
|
635
|
+
> [Proceeds immediately with best assumptions: Node/Express, MongoDB, bcrypt password hashing, JWT response, input validation — no clarifying questions asked]
|
|
636
|
+
|
|
637
|
+
---
|
|
638
|
+
|
|
639
|
+
### /checklist — Actionable checklist
|
|
640
|
+
|
|
641
|
+
**Scenario 1 — Launch prep**
|
|
642
|
+
```
|
|
643
|
+
/checklist What do I need before launching my SaaS publicly?
|
|
644
|
+
```
|
|
645
|
+
> - [ ] Payment flow tested end-to-end
|
|
646
|
+
> - [ ] Error monitoring set up (Sentry)
|
|
647
|
+
> - [ ] Basic analytics in place
|
|
648
|
+
> - [ ] Terms of Service and Privacy Policy live
|
|
649
|
+
> - [ ] Transactional emails working (welcome, password reset)
|
|
650
|
+
> - [ ] Custom domain + SSL configured
|
|
651
|
+
> - [ ] Load tested with expected traffic
|
|
652
|
+
> - [ ] Support email or chat widget active
|
|
653
|
+
> - [ ] Backup strategy for database
|
|
654
|
+
|
|
655
|
+
---
|
|
656
|
+
|
|
657
|
+
### /fix — Fix and explain
|
|
658
|
+
|
|
659
|
+
**Scenario 1 — Fix a bug**
|
|
660
|
+
```
|
|
661
|
+
/fix
|
|
662
|
+
async function getUser(id) {
|
|
663
|
+
const user = await User.findById(id)
|
|
664
|
+
return user.name
|
|
665
|
+
}
|
|
666
|
+
```
|
|
667
|
+
> **Bug:** If `user` is null (ID not found), `user.name` throws `TypeError: Cannot read property 'name' of null`.
|
|
668
|
+
>
|
|
669
|
+
> **Fix:**
|
|
670
|
+
> ```javascript
|
|
671
|
+
> async function getUser(id) {
|
|
672
|
+
> const user = await User.findById(id);
|
|
673
|
+
> if (!user) throw new Error(`User ${id} not found`);
|
|
674
|
+
> return user.name;
|
|
675
|
+
> }
|
|
676
|
+
> ```
|
|
677
|
+
|
|
678
|
+
---
|
|
679
|
+
|
|
680
|
+
### /explain_error — Plain-language error explanation
|
|
681
|
+
|
|
682
|
+
**Scenario 1 — Node error**
|
|
683
|
+
```
|
|
684
|
+
/explain_error ECONNREFUSED 127.0.0.1:5432
|
|
685
|
+
```
|
|
686
|
+
> Your app is trying to connect to a PostgreSQL database on your local machine (port 5432) but nothing is running there. Either PostgreSQL isn't started, it's running on a different port, or your connection string is pointing to localhost when it should point to a remote host (like your Docker container or cloud DB).
|
|
687
|
+
|
|
688
|
+
---
|
|
689
|
+
|
|
690
|
+
## META
|
|
691
|
+
|
|
692
|
+
### /help — Explain a shortcut
|
|
693
|
+
|
|
694
|
+
**Scenario 1**
|
|
695
|
+
```
|
|
696
|
+
/help /selfcritic
|
|
697
|
+
```
|
|
698
|
+
> `/selfcritic` makes me generate an answer, then immediately critique it for weaknesses, then produce an improved version. Use it when you want higher quality output, not just a first draft — especially useful for copy, strategy, or architecture decisions.
|
|
699
|
+
|
|
700
|
+
---
|
|
701
|
+
|
|
702
|
+
### /style — Show current active settings
|
|
703
|
+
|
|
704
|
+
**Scenario 1**
|
|
705
|
+
```
|
|
706
|
+
/style
|
|
707
|
+
```
|
|
708
|
+
> Current active settings:
|
|
709
|
+
> - Tone: /wissem (direct, startup-aware)
|
|
710
|
+
> - Length: /d (full detail)
|
|
711
|
+
> - Output: /final_only
|
|
712
|
+
> - Goal: launch_beta_by_april
|
|
713
|
+
> - Mode: /no_questions
|
|
714
|
+
|
|
715
|
+
---
|
|
716
|
+
|
|
717
|
+
### /business — ROI framing
|
|
718
|
+
|
|
719
|
+
**Scenario 1 — Tech decision**
|
|
720
|
+
```
|
|
721
|
+
/business Should we rewrite our frontend in TypeScript?
|
|
722
|
+
```
|
|
723
|
+
> Business case: TypeScript reduces bugs that reach production, which means less time spent on customer-reported issues and faster onboarding for new devs. Typical teams report 15-30% fewer runtime errors. Cost: 2-4 weeks of migration depending on codebase size. ROI breakeven: ~3-6 months. Recommend: yes, but incrementally — don't stop shipping to do it.
|
|
724
|
+
|
|
725
|
+
---
|
|
726
|
+
|
|
727
|
+
## POWER CHAINS — Full Workflow Examples
|
|
728
|
+
|
|
729
|
+
### Chain 1 — Debug and fix a file
|
|
730
|
+
```
|
|
731
|
+
/wissem /no_questions /engineer /f,auth.js,load /f,auth.js,debug /fix /final_only
|
|
732
|
+
```
|
|
733
|
+
> [Loads file → finds bugs → fixes them → shows final fixed code only, no commentary]
|
|
734
|
+
|
|
735
|
+
---
|
|
736
|
+
|
|
737
|
+
### Chain 2 — Plan a feature from scratch
|
|
738
|
+
```
|
|
739
|
+
/wissempro /goal,add_notifications /plan_then_execute /no_questions /step
|
|
740
|
+
```
|
|
741
|
+
> [Sets goal → shows step-by-step plan → waits for approval → executes]
|
|
742
|
+
|
|
743
|
+
---
|
|
744
|
+
|
|
745
|
+
### Chain 3 — Write and improve copy
|
|
746
|
+
```
|
|
747
|
+
/direct /selfcritic Write a cold email subject line for a dev tool targeting CTOs
|
|
748
|
+
```
|
|
749
|
+
> Draft → Critique → Improved version
|
|
750
|
+
|
|
751
|
+
---
|
|
752
|
+
|
|
753
|
+
### Chain 4 — Quick startup decision
|
|
754
|
+
```
|
|
755
|
+
/wissempro /c /direct Should I hire a junior dev or a senior dev first?
|
|
756
|
+
```
|
|
757
|
+
> Hire senior first if you need architecture decisions made right. Hire junior if the foundation is solid and you need execution speed at lower cost. At pre-revenue: senior. Post-revenue with traction: junior to scale output.
|
|
758
|
+
|
|
759
|
+
---
|
|
760
|
+
|
|
761
|
+
### Chain 5 — Full session launcher
|
|
762
|
+
```
|
|
763
|
+
## AI Shortcuts — Ultra Trim
|
|
764
|
+
|
|
765
|
+
STYLE: /wissem=direct+startup+Tunisia | /direct=no hedging | /c=short | /d=full
|
|
766
|
+
OUTPUT: /b=bullets | /step=step-by-step | /final_only | /cot | /selfcritic
|
|
767
|
+
WORKFLOW: /no_questions | /goal,x | /execute | /plan_then_execute | /fix
|
|
768
|
+
Always remember active /goal until /reset.
|
|
769
|
+
|
|
770
|
+
⚡ START: /wissem /no_questions /goal,launch_mvp /plan_then_execute /final_only
|
|
771
|
+
```
|
|
772
|
+
> [Paste this → Claude loads all shortcuts + sets goal + starts planning immediately]
|
|
773
|
+
|
|
774
|
+
---
|
|
775
|
+
|
|
776
|
+
*End of training examples. Practice 2-3 scenarios per day until chains feel natural.*
|
|
777
|
+
|
|
778
|
+
|
|
779
|
+
## CONTEXT & FILE MANAGEMENT (Section 15)
|
|
780
|
+
|
|
781
|
+
### /ctx,foldA,load — Load full content of a folder (paste immediately after). AI confirms with one-line summary.
|
|
782
|
+
|
|
783
|
+
**Scenario 1**
|
|
784
|
+
```
|
|
785
|
+
/ctx,backend,load
|
|
786
|
+
[paste entire backend folder code here]
|
|
787
|
+
```
|
|
788
|
+
|
|
789
|
+
> ✓ Context backend loaded — FastAPI app with auth, users, payments (8 files, 2,847 LOC, PostgreSQL + Redis).
|
|
790
|
+
|
|
791
|
+
---
|
|
792
|
+
|
|
793
|
+
### /ctx,foldA,set, — Define what the folder contains without pasting full code.
|
|
794
|
+
|
|
795
|
+
**Scenario 1**
|
|
796
|
+
```
|
|
797
|
+
`/ctx,frontend,set,React + Tailwind dashboard with 5 pages and API hooks`
|
|
798
|
+
```
|
|
799
|
+
|
|
800
|
+
> ✓ Context frontend set — React + Tailwind dashboard (5 pages, API hooks, no full code pasted).
|
|
801
|
+
|
|
802
|
+
---
|
|
803
|
+
|
|
804
|
+
### /ctx,foldA,scope, — Narrow focus inside an already loaded folder.
|
|
805
|
+
|
|
806
|
+
**Scenario 1**
|
|
807
|
+
```
|
|
808
|
+
`/ctx,backend,scope,auth_module`
|
|
809
|
+
```
|
|
810
|
+
|
|
811
|
+
> Scope narrowed to auth_module only (JWT, refresh tokens, rate limiting).
|
|
812
|
+
|
|
813
|
+
---
|
|
814
|
+
|
|
815
|
+
### /ctx,foldA,reset — Clear a context slot.
|
|
816
|
+
|
|
817
|
+
**Scenario 1**
|
|
818
|
+
```
|
|
819
|
+
`/ctx,backend,reset`
|
|
820
|
+
```
|
|
821
|
+
|
|
822
|
+
> ✓ Context backend cleared.
|
|
823
|
+
|
|
824
|
+
---
|
|
825
|
+
|
|
826
|
+
### /ctx,list — Show all active context slots.
|
|
827
|
+
|
|
828
|
+
**Scenario 1**
|
|
829
|
+
```
|
|
830
|
+
`/ctx,list`
|
|
831
|
+
```
|
|
832
|
+
|
|
833
|
+
> Active contexts:
|
|
834
|
+
> • backend (loaded)
|
|
835
|
+
> • frontend (set)
|
|
836
|
+
> • auth.py (loaded)
|
|
837
|
+
|
|
838
|
+
---
|
|
839
|
+
|
|
840
|
+
### /f,file.py,load — Load single file content.
|
|
841
|
+
|
|
842
|
+
**Scenario 1**
|
|
843
|
+
```
|
|
844
|
+
/f,auth.py,load
|
|
845
|
+
[paste full auth.py here]
|
|
846
|
+
```
|
|
847
|
+
|
|
848
|
+
> ✓ File auth.py loaded — 412 LOC, FastAPI auth endpoints + dependency injection.
|
|
849
|
+
|
|
850
|
+
---
|
|
851
|
+
|
|
852
|
+
### /f,file.py,set, — Define file without full paste.
|
|
853
|
+
|
|
854
|
+
**Scenario 1**
|
|
855
|
+
```
|
|
856
|
+
`/f,utils.py,set,helper functions for validation and logging`
|
|
857
|
+
```
|
|
858
|
+
|
|
859
|
+
> ✓ File utils.py set.
|
|
860
|
+
>
|
|
861
|
+
|
|
862
|
+
---
|
|
863
|
+
|
|
864
|
+
### /ctx,foldA,overview — High-level one-paragraph summary.
|
|
865
|
+
|
|
866
|
+
**Scenario 1**
|
|
867
|
+
```
|
|
868
|
+
/ctx,foldA,overview
|
|
869
|
+
```
|
|
870
|
+
|
|
871
|
+
> Backend folder contains a production-ready FastAPI service with clean architecture (routers, services, repositories). Total 8 modules, main entrypoint main.py.
|
|
872
|
+
|
|
873
|
+
---
|
|
874
|
+
|
|
875
|
+
### /ctx,foldA,analyze — Deep structural + logic analysis.
|
|
876
|
+
|
|
877
|
+
**Scenario 1**
|
|
878
|
+
```
|
|
879
|
+
/ctx,foldA,analyze
|
|
880
|
+
```
|
|
881
|
+
|
|
882
|
+
> Structural analysis: 3 layers (routers → services → repositories). Circular dependency detected between payments and users. Logic gaps in error handling for 429 rate limits.
|
|
883
|
+
|
|
884
|
+
---
|
|
885
|
+
|
|
886
|
+
### /ctx,foldA,document — Generate full documentation.
|
|
887
|
+
|
|
888
|
+
**Scenario 1**
|
|
889
|
+
```
|
|
890
|
+
/ctx,foldA,document
|
|
891
|
+
```
|
|
892
|
+
|
|
893
|
+
> # Backend Documentation
|
|
894
|
+
> ## Endpoints
|
|
895
|
+
> • POST /auth/login → returns JWT
|
|
896
|
+
> ...
|
|
897
|
+
|
|
898
|
+
---
|
|
899
|
+
|
|
900
|
+
### /ctx,foldA,improve — Suggest quality improvements.
|
|
901
|
+
|
|
902
|
+
**Scenario 1**
|
|
903
|
+
```
|
|
904
|
+
/ctx,foldA,improve
|
|
905
|
+
```
|
|
906
|
+
|
|
907
|
+
> Recommendations: 1. Add pydantic v2 models 2. Replace print() with structured logging 3. Add OpenAPI tags.
|
|
908
|
+
|
|
909
|
+
---
|
|
910
|
+
|
|
911
|
+
### /ctx,foldA,refactor — Refactor for clarity/maintainability.
|
|
912
|
+
|
|
913
|
+
**Scenario 1**
|
|
914
|
+
```
|
|
915
|
+
/ctx,foldA,refactor
|
|
916
|
+
```
|
|
917
|
+
|
|
918
|
+
> Refactored structure proposed + diff view of all files.
|
|
919
|
+
|
|
920
|
+
---
|
|
921
|
+
|
|
922
|
+
### /ctx,foldA,debug — Find bugs and issues.
|
|
923
|
+
|
|
924
|
+
**Scenario 1**
|
|
925
|
+
```
|
|
926
|
+
/ctx,foldA,debug
|
|
927
|
+
```
|
|
928
|
+
|
|
929
|
+
> Critical: unhandled exception in payment webhook (line 142). Warning: SQL injection risk in raw query (users.py:89).
|
|
930
|
+
|
|
931
|
+
---
|
|
932
|
+
|
|
933
|
+
### /ctx,foldA,secure — Security audit.
|
|
934
|
+
|
|
935
|
+
**Scenario 1**
|
|
936
|
+
```
|
|
937
|
+
/ctx,foldA,secure
|
|
938
|
+
```
|
|
939
|
+
|
|
940
|
+
> Vulnerabilities found: 1. Missing rate-limit on login 2. Exposed stack traces in prod 3. Hard-coded secrets.
|
|
941
|
+
|
|
942
|
+
---
|
|
943
|
+
|
|
944
|
+
### /ctx,foldA,optimize — Performance improvements.
|
|
945
|
+
|
|
946
|
+
**Scenario 1**
|
|
947
|
+
```
|
|
948
|
+
/ctx,foldA,optimize
|
|
949
|
+
```
|
|
950
|
+
|
|
951
|
+
> Optimizations: Add Redis caching to user service → -65% DB load. Use async SQLAlchemy. Index on payments.created_at.
|
|
952
|
+
|
|
953
|
+
---
|
|
954
|
+
|
|
955
|
+
### /ctx,foldA,test — Generate test cases.
|
|
956
|
+
|
|
957
|
+
**Scenario 1**
|
|
958
|
+
```
|
|
959
|
+
/ctx,foldA,test
|
|
960
|
+
```
|
|
961
|
+
|
|
962
|
+
> Generated 28 pytest cases (unit + integration) for the entire folder.
|
|
963
|
+
|
|
964
|
+
---
|
|
965
|
+
|
|
966
|
+
### /ctx,foldA,map — Visual text-based map of structure.
|
|
967
|
+
|
|
968
|
+
**Scenario 1**
|
|
969
|
+
```
|
|
970
|
+
/ctx,foldA,map
|
|
971
|
+
```
|
|
972
|
+
|
|
973
|
+
```
|
|
974
|
+
> backend/
|
|
975
|
+
> ├── routers/
|
|
976
|
+
> ├── services/
|
|
977
|
+
> ├── repositories/
|
|
978
|
+
> └── main.py (entry)
|
|
979
|
+
```
|
|
980
|
+
|
|
981
|
+
---
|
|
982
|
+
|
|
983
|
+
### /ctx,foldA,explain — Plain-language explanation.
|
|
984
|
+
|
|
985
|
+
**Scenario 1**
|
|
986
|
+
```
|
|
987
|
+
/ctx,foldA,explain
|
|
988
|
+
```
|
|
989
|
+
|
|
990
|
+
> This folder is the complete backend API that handles user authentication, payments, and profile management.
|
|
991
|
+
|
|
992
|
+
---
|
|
993
|
+
|
|
994
|
+
### /ctx,foldA,dependencies — List internal + external dependencies.
|
|
995
|
+
|
|
996
|
+
**Scenario 1**
|
|
997
|
+
```
|
|
998
|
+
/ctx,foldA,dependencies
|
|
999
|
+
```
|
|
1000
|
+
|
|
1001
|
+
> Internal: auth → users → payments
|
|
1002
|
+
> External: fastapi, sqlalchemy, redis, stripe.
|
|
1003
|
+
|
|
1004
|
+
---
|
|
1005
|
+
|
|
1006
|
+
### /ctx,foldA,entrypoints — Identify all entry points.
|
|
1007
|
+
|
|
1008
|
+
**Scenario 1**
|
|
1009
|
+
```
|
|
1010
|
+
/ctx,foldA,entrypoints
|
|
1011
|
+
```
|
|
1012
|
+
|
|
1013
|
+
> • main.py:uvicorn
|
|
1014
|
+
> • routers/auth.py
|
|
1015
|
+
> • webhooks/stripe.py
|
|
1016
|
+
|
|
1017
|
+
---
|
|
1018
|
+
|
|
1019
|
+
### /ctx,foldA,architecture — Describe architectural pattern.
|
|
1020
|
+
|
|
1021
|
+
**Scenario 1**
|
|
1022
|
+
```
|
|
1023
|
+
/ctx,foldA,architecture
|
|
1024
|
+
```
|
|
1025
|
+
|
|
1026
|
+
> Clean Architecture + Repository pattern. Layers are strictly separated.
|
|
1027
|
+
|
|
1028
|
+
---
|
|
1029
|
+
|
|
1030
|
+
### /ctx,foldA,dataflow — Trace data flow.
|
|
1031
|
+
|
|
1032
|
+
**Scenario 1**
|
|
1033
|
+
```
|
|
1034
|
+
/ctx,foldA,dataflow
|
|
1035
|
+
```
|
|
1036
|
+
|
|
1037
|
+
> Request → Router → Service → Repository → DB → Response (with caching layer).
|
|
1038
|
+
|
|
1039
|
+
---
|
|
1040
|
+
|
|
1041
|
+
### /ctx,foldA,public_docs — Public-facing documentation.
|
|
1042
|
+
|
|
1043
|
+
**Scenario 1**
|
|
1044
|
+
```
|
|
1045
|
+
/ctx,foldA,public_docs
|
|
1046
|
+
```
|
|
1047
|
+
|
|
1048
|
+
> Ready-to-publish README + Swagger description.
|
|
1049
|
+
|
|
1050
|
+
---
|
|
1051
|
+
|
|
1052
|
+
### /ctx,foldA,expose — Show exposed vs internal.
|
|
1053
|
+
|
|
1054
|
+
**Scenario 1**
|
|
1055
|
+
```
|
|
1056
|
+
/ctx,foldA,expose
|
|
1057
|
+
```
|
|
1058
|
+
|
|
1059
|
+
> Public API: 12 endpoints. Internal only: 8 repository classes.
|
|
1060
|
+
|
|
1061
|
+
---
|
|
1062
|
+
|
|
1063
|
+
### /ctx,foldA,summary — Fast condensed overview.
|
|
1064
|
+
|
|
1065
|
+
**Scenario 1**
|
|
1066
|
+
```
|
|
1067
|
+
/ctx,foldA,summary
|
|
1068
|
+
```
|
|
1069
|
+
|
|
1070
|
+
> Backend: FastAPI + PostgreSQL, 8 modules, auth + payments core.
|
|
1071
|
+
|
|
1072
|
+
---
|
|
1073
|
+
|
|
1074
|
+
### /ctx,foldA,todos — Extract all TODO/FIXME/HACK.
|
|
1075
|
+
|
|
1076
|
+
**Scenario 1**
|
|
1077
|
+
```
|
|
1078
|
+
/ctx,foldA,todos
|
|
1079
|
+
```
|
|
1080
|
+
|
|
1081
|
+
> • TODO: implement email verification (auth.py:67)
|
|
1082
|
+
> • HACK: temporary stripe test key (payments.py:22)
|
|
1083
|
+
|
|
1084
|
+
---
|
|
1085
|
+
|
|
1086
|
+
### /ctx,foldA,lint — Flag style/quality issues.
|
|
1087
|
+
|
|
1088
|
+
**Scenario 1**
|
|
1089
|
+
```
|
|
1090
|
+
/ctx,foldA,lint
|
|
1091
|
+
```
|
|
1092
|
+
|
|
1093
|
+
> 23 issues: 12 missing type hints, 7 long functions, 4 unused imports.
|
|
1094
|
+
|
|
1095
|
+
---
|
|
1096
|
+
|
|
1097
|
+
### /ctx,foldA,changelog — Summarize changes (when diffs provided).
|
|
1098
|
+
|
|
1099
|
+
**Scenario 1**
|
|
1100
|
+
```
|
|
1101
|
+
/ctx,foldA,changelog
|
|
1102
|
+
```
|
|
1103
|
+
|
|
1104
|
+
> Changelog summary: Added webhook handler, refactored auth service, bumped FastAPI 0.110 → 0.115.
|
|
1105
|
+
>
|
|
1106
|
+
|
|
1107
|
+
---
|
|
1108
|
+
|
|
1109
|
+
### /ctx_multi,foldA,foldB,compare —
|
|
1110
|
+
|
|
1111
|
+
**Scenario 1**
|
|
1112
|
+
```
|
|
1113
|
+
`/ctx_multi,backend,frontend,compare`
|
|
1114
|
+
```
|
|
1115
|
+
|
|
1116
|
+
> Comparison table: tech stack, file count, coupling level, etc.
|
|
1117
|
+
|
|
1118
|
+
---
|
|
1119
|
+
|
|
1120
|
+
### /ctx_merge,foldA,foldB —
|
|
1121
|
+
|
|
1122
|
+
**Scenario 1**
|
|
1123
|
+
```
|
|
1124
|
+
`/ctx_merge,backend,frontend`
|
|
1125
|
+
```
|
|
1126
|
+
|
|
1127
|
+
> Merged context active — full-stack view now available.
|
|
1128
|
+
|
|
1129
|
+
---
|
|
1130
|
+
|
|
1131
|
+
### /ctx_diff,foldA,foldB —
|
|
1132
|
+
|
|
1133
|
+
**Scenario 1**
|
|
1134
|
+
```
|
|
1135
|
+
`/ctx_diff,backend_v1,backend_v2`
|
|
1136
|
+
```
|
|
1137
|
+
|
|
1138
|
+
> Diff summary: +3 files, -124 LOC, new payment module added.
|
|
1139
|
+
>
|
|
1140
|
+
|
|
1141
|
+
---
|
|
1142
|
+
|
|
1143
|
+
### /f,file.py,explain —
|
|
1144
|
+
|
|
1145
|
+
**Scenario 1**
|
|
1146
|
+
```
|
|
1147
|
+
/f,file.py,explain
|
|
1148
|
+
```
|
|
1149
|
+
|
|
1150
|
+
> auth.py implements JWT login, refresh, and dependency injection for protected routes.
|
|
1151
|
+
|
|
1152
|
+
---
|
|
1153
|
+
|
|
1154
|
+
### /f,file.py,refactor —
|
|
1155
|
+
|
|
1156
|
+
**Scenario 1**
|
|
1157
|
+
```
|
|
1158
|
+
/f,file.py,refactor
|
|
1159
|
+
```
|
|
1160
|
+
|
|
1161
|
+
> Refactored version with better separation + diff.
|
|
1162
|
+
|
|
1163
|
+
---
|
|
1164
|
+
|
|
1165
|
+
### /f,file.py,debug —
|
|
1166
|
+
|
|
1167
|
+
**Scenario 1**
|
|
1168
|
+
```
|
|
1169
|
+
/f,file.py,debug
|
|
1170
|
+
```
|
|
1171
|
+
|
|
1172
|
+
> Bug found: missing await on async DB call (line 134).
|
|
1173
|
+
|
|
1174
|
+
---
|
|
1175
|
+
|
|
1176
|
+
### /f,file.py,document —
|
|
1177
|
+
|
|
1178
|
+
**Scenario 1**
|
|
1179
|
+
```
|
|
1180
|
+
/f,file.py,document
|
|
1181
|
+
```
|
|
1182
|
+
|
|
1183
|
+
> Added full docstrings + module-level docs.
|
|
1184
|
+
|
|
1185
|
+
---
|
|
1186
|
+
|
|
1187
|
+
### /f,file.py,optimize —
|
|
1188
|
+
|
|
1189
|
+
**Scenario 1**
|
|
1190
|
+
```
|
|
1191
|
+
/f,file.py,optimize
|
|
1192
|
+
```
|
|
1193
|
+
|
|
1194
|
+
> Performance improved: cached query, reduced DB calls by 40%.
|
|
1195
|
+
|
|
1196
|
+
---
|
|
1197
|
+
|
|
1198
|
+
### /f,file.py,test —
|
|
1199
|
+
|
|
1200
|
+
**Scenario 1**
|
|
1201
|
+
```
|
|
1202
|
+
/f,file.py,test
|
|
1203
|
+
```
|
|
1204
|
+
|
|
1205
|
+
> Generated 12 pytest functions covering all paths.
|
|
1206
|
+
|
|
1207
|
+
---
|
|
1208
|
+
|
|
1209
|
+
### /f,file.py,review —
|
|
1210
|
+
|
|
1211
|
+
**Scenario 1**
|
|
1212
|
+
```
|
|
1213
|
+
/f,file.py,review
|
|
1214
|
+
```
|
|
1215
|
+
|
|
1216
|
+
> Code review: 9/10. Suggestions: add logging, improve error messages.
|
|
1217
|
+
|
|
1218
|
+
---
|
|
1219
|
+
|
|
1220
|
+
### /f,file.py,convert,lang —
|
|
1221
|
+
|
|
1222
|
+
**Scenario 1**
|
|
1223
|
+
```
|
|
1224
|
+
`/f,auth.py,convert,typescript`
|
|
1225
|
+
```
|
|
1226
|
+
|
|
1227
|
+
> Full conversion to TypeScript + NestJS style.
|
|
1228
|
+
|
|
1229
|
+
---
|
|
1230
|
+
|
|
1231
|
+
### /f,file.py,improve —
|
|
1232
|
+
|
|
1233
|
+
**Scenario 1**
|
|
1234
|
+
```
|
|
1235
|
+
/f,file.py,improve
|
|
1236
|
+
```
|
|
1237
|
+
|
|
1238
|
+
> General improvements applied (type hints, error handling, tests).
|
|
1239
|
+
|
|
1240
|
+
---
|
|
1241
|
+
|
|
1242
|
+
### /f,file.py,secure —
|
|
1243
|
+
|
|
1244
|
+
**Scenario 1**
|
|
1245
|
+
```
|
|
1246
|
+
/f,file.py,secure
|
|
1247
|
+
```
|
|
1248
|
+
|
|
1249
|
+
> Security audit passed except one minor issue (fixed version attached).
|
|
1250
|
+
|
|
1251
|
+
---
|
|
1252
|
+
|
|
1253
|
+
### /f,file.py,summary —
|
|
1254
|
+
|
|
1255
|
+
**Scenario 1**
|
|
1256
|
+
```
|
|
1257
|
+
/f,file.py,summary
|
|
1258
|
+
```
|
|
1259
|
+
|
|
1260
|
+
> One-paragraph summary of the file.
|
|
1261
|
+
|
|
1262
|
+
---
|
|
1263
|
+
|
|
1264
|
+
### /f,file.py,trace, —
|
|
1265
|
+
|
|
1266
|
+
**Scenario 1**
|
|
1267
|
+
```
|
|
1268
|
+
`/f,auth.py,trace,login_function`
|
|
1269
|
+
```
|
|
1270
|
+
|
|
1271
|
+
> Step-by-step execution trace of login_function.
|
|
1272
|
+
|
|
1273
|
+
---
|
|
1274
|
+
|
|
1275
|
+
### /f,file.py,mock —
|
|
1276
|
+
|
|
1277
|
+
**Scenario 1**
|
|
1278
|
+
```
|
|
1279
|
+
/f,file.py,mock
|
|
1280
|
+
```
|
|
1281
|
+
|
|
1282
|
+
> Complete mock/stub file generated.
|
|
1283
|
+
|
|
1284
|
+
---
|
|
1285
|
+
|
|
1286
|
+
### /f,file.py,diff,file2.py —
|
|
1287
|
+
|
|
1288
|
+
**Scenario 1**
|
|
1289
|
+
```
|
|
1290
|
+
/f,file.py,diff,file2.py
|
|
1291
|
+
```
|
|
1292
|
+
|
|
1293
|
+
> Side-by-side diff between the two files.
|
|
1294
|
+
>
|
|
1295
|
+
|
|
1296
|
+
---
|
|
1297
|
+
|
|
1298
|
+
### /p,projectX,health —
|
|
1299
|
+
|
|
1300
|
+
**Scenario 1**
|
|
1301
|
+
```
|
|
1302
|
+
/p,projectX,health
|
|
1303
|
+
```
|
|
1304
|
+
|
|
1305
|
+
> Project health: 92/100 (strong architecture, 3 minor tech debt items).
|
|
1306
|
+
|
|
1307
|
+
---
|
|
1308
|
+
|
|
1309
|
+
### /p,projectX,roadmap —
|
|
1310
|
+
|
|
1311
|
+
**Scenario 1**
|
|
1312
|
+
```
|
|
1313
|
+
/p,projectX,roadmap
|
|
1314
|
+
```
|
|
1315
|
+
|
|
1316
|
+
> Suggested 3-month roadmap with priorities.
|
|
1317
|
+
|
|
1318
|
+
---
|
|
1319
|
+
|
|
1320
|
+
### /p,projectX,risks —
|
|
1321
|
+
|
|
1322
|
+
**Scenario 1**
|
|
1323
|
+
```
|
|
1324
|
+
/p,projectX,risks
|
|
1325
|
+
```
|
|
1326
|
+
|
|
1327
|
+
> Technical risks: DB scaling at 10k users. Business risks: payment provider dependency.
|
|
1328
|
+
|
|
1329
|
+
---
|
|
1330
|
+
|
|
1331
|
+
### /p,projectX,scalability —
|
|
1332
|
+
|
|
1333
|
+
**Scenario 1**
|
|
1334
|
+
```
|
|
1335
|
+
/p,projectX,scalability
|
|
1336
|
+
```
|
|
1337
|
+
|
|
1338
|
+
> Scalability assessment: ready for 50k users with current design.
|
|
1339
|
+
|
|
1340
|
+
---
|
|
1341
|
+
|
|
1342
|
+
### /p,projectX,readiness —
|
|
1343
|
+
|
|
1344
|
+
**Scenario 1**
|
|
1345
|
+
```
|
|
1346
|
+
/p,projectX,readiness
|
|
1347
|
+
```
|
|
1348
|
+
|
|
1349
|
+
> Production readiness: 85% — needs observability + CI/CD finalised.
|
|
1350
|
+
|
|
1351
|
+
---
|
|
1352
|
+
|
|
1353
|
+
### /p,projectX,architecture —
|
|
1354
|
+
|
|
1355
|
+
**Scenario 1**
|
|
1356
|
+
```
|
|
1357
|
+
/p,projectX,architecture
|
|
1358
|
+
```
|
|
1359
|
+
|
|
1360
|
+
> Full architectural review + diagrams (text).
|
|
1361
|
+
>
|
|
1362
|
+
|
|
1363
|
+
---
|
|
1364
|
+
|
|
1365
|
+
### /save — Format current output for saving.
|
|
1366
|
+
|
|
1367
|
+
**Scenario 1**
|
|
1368
|
+
```
|
|
1369
|
+
/save
|
|
1370
|
+
```
|
|
1371
|
+
|
|
1372
|
+
|
|
1373
|
+
|
|
1374
|
+
---
|
|
1375
|
+
|
|
1376
|
+
### /save_as,file.md —
|
|
1377
|
+
|
|
1378
|
+
**Scenario 1**
|
|
1379
|
+
```
|
|
1380
|
+
/save_as,file.md
|
|
1381
|
+
```
|
|
1382
|
+
|
|
1383
|
+
|
|
1384
|
+
|
|
1385
|
+
---
|
|
1386
|
+
|
|
1387
|
+
### /save_to,foldA,file.md —
|
|
1388
|
+
|
|
1389
|
+
**Scenario 1**
|
|
1390
|
+
```
|
|
1391
|
+
/save_to,foldA,file.md
|
|
1392
|
+
```
|
|
1393
|
+
|
|
1394
|
+
|
|
1395
|
+
|
|
1396
|
+
---
|
|
1397
|
+
|
|
1398
|
+
### /export,markdown —
|
|
1399
|
+
|
|
1400
|
+
**Scenario 1**
|
|
1401
|
+
```
|
|
1402
|
+
/export,markdown
|
|
1403
|
+
```
|
|
1404
|
+
|
|
1405
|
+
|
|
1406
|
+
|
|
1407
|
+
---
|
|
1408
|
+
|
|
1409
|
+
### /export_to,foldA,file.md —
|
|
1410
|
+
|
|
1411
|
+
**Scenario 1**
|
|
1412
|
+
```
|
|
1413
|
+
/export_to,foldA,file.md
|
|
1414
|
+
```
|
|
1415
|
+
|
|
1416
|
+
>
|
|
1417
|
+
> ---
|
|
1418
|
+
>
|
|
1419
|
+
> ### How the full version integrates (all other commands covered via real chains)
|
|
1420
|
+
>
|
|
1421
|
+
> Here are ready-to-copy chains that use **every category** from the full v4.3:
|
|
1422
|
+
>
|
|
1423
|
+
> 1. **Style + Tone + Format + Reasoning**
|
|
1424
|
+
> `/d /wissem /engineer /cot /table /ctx,backend,load [paste] /ctx,backend,analyze /final_only`
|
|
1425
|
+
>
|
|
1426
|
+
> 2. **Deep file work**
|
|
1427
|
+
> `/f,auth.py,load [paste] /f,auth.py,debug /f,auth.py,secure /f,auth.py,refactor /selfcritic /final_only`
|
|
1428
|
+
>
|
|
1429
|
+
> 3. **Project level**
|
|
1430
|
+
> `/p,projectX,load [paste all] /p,projectX,health /p,projectX,roadmap /p,projectX,risks /swot /goal,launch_mvp /execute`
|
|
1431
|
+
>
|
|
1432
|
+
> 4. **Multi-context + compare**
|
|
1433
|
+
> `/ctx_multi,backend,frontend,compare /ctx_diff,backend,backend_v2 /vd /proscons`
|
|
1434
|
+
>
|
|
1435
|
+
> 5. **Creative + goal driven**
|
|
1436
|
+
> `/creative /goal,build_api /ctx,api,load [paste] /ctx,api,optimize /brainstorm,5 /ep,optimize`
|
|
1437
|
+
>
|
|
1438
|
+
> Just paste the universal prefix once at the start of any new chat, then use any of the above chains + the file commands in this guide.
|
|
1439
|
+
>
|
|
1440
|
+
> You now have **complete, exhaustive, copy-paste-ready examples** for every single command in the full version. Save the file and you’re done.
|
|
1441
|
+
>
|
|
1442
|
+
> Ready when you are — drop your first context and let’s go.
|
|
1443
|
+
|
|
1444
|
+
---
|
|
1445
|
+
|
|
1446
|
+
|
|
1447
|
+
|
|
1448
|
+
## BUDGET & TOKEN MANAGEMENT (Section 22)
|
|
1449
|
+
|
|
1450
|
+
|
|
1451
|
+
|
|
1452
|
+
---
|
|
1453
|
+
|
|
1454
|
+
|
|
1455
|
+
**Use Case:** You are about to run a massive refactor across 15 files and want to avoid an accidental $5.00 API charge.
|
|
1456
|
+
|
|
1457
|
+
```
|
|
1458
|
+
/quote Refactor the entire authentication module in src/auth/ to use JWT instead of sessions.```
|
|
1459
|
+
> **Token Estimation:**
|
|
1460
|
+
> - Input context: ~45,000 tokens
|
|
1461
|
+
> - Expected output: ~8,000 tokens across 5 files
|
|
1462
|
+
> - **Estimated Cost:** $0.85
|
|
1463
|
+
>
|
|
1464
|
+
> *Type "Approve" to proceed with the execution.*
|
|
1465
|
+
|
|
1466
|
+
---
|
|
1467
|
+
|
|
1468
|
+
|
|
1469
|
+
**Use Case:** You want the AI to do a task, but only if it's cheap. If it's an expensive task, you want to do it yourself using a guided prompt.
|
|
1470
|
+
|
|
1471
|
+
```
|
|
1472
|
+
/le,10 Generate a comprehensive test suite for the dashboard components.`
|
|
1473
|
+
|
|
1474
|
+
**AI Behavior (Scenario A - Under 10%):**
|
|
1475
|
+
> *Task requires ~5% of token limit. Executing...*
|
|
1476
|
+
> [Outputs the test suite code immediately]
|
|
1477
|
+
|
|
1478
|
+
**AI Behavior (Scenario B - Over 10%):**
|
|
1479
|
+
> *Task rejected. Estimated token usage (35%) exceeds your 10% limit.*
|
|
1480
|
+
>
|
|
1481
|
+
> **Do-It-Yourself Execution Prompt:**
|
|
1482
|
+
> "Please copy and paste the following prompt into your terminal or a cheaper AI session to generate the tests file-by-file:
|
|
1483
|
+
> *'Read `src/dashboard/Chart.vue` and generate Vitest unit tests covering mounting and data-fetching. Save it to `tests/Chart.spec.js`.'* (Repeat for each component)."
|
|
1484
|
+
|
|
1485
|
+
---
|
|
1486
|
+
|
|
1487
|
+
|
|
1488
|
+
**Use Case:** You are running an ongoing task and want to pause periodically to review the cost and approve the next chunk.
|
|
1489
|
+
|
|
1490
|
+
```
|
|
1491
|
+
/usage,15 Migrate all old Vue 2 syntax to Vue 3 Composition API in the components folder.```
|
|
1492
|
+
> *Executing chunk 1...*
|
|
1493
|
+
> [Migrates 3 files]
|
|
1494
|
+
>
|
|
1495
|
+
> **⏸️ Token Limit Paused**
|
|
1496
|
+
> I have reached your 15% token usage threshold (Estimated cost spent: $0.45).
|
|
1497
|
+
> **Remaining work:** 7 files left.
|
|
1498
|
+
> **Estimated remaining cost:** $1.10 (approx. 35% more token usage).
|
|
1499
|
+
>
|
|
1500
|
+
> *Do you approve continuing for a custom chunk of 20%?*
|
|
1501
|
+
|
|
1502
|
+
---
|
|
1503
|
+
|
|
1504
|
+
|
|
1505
|
+
**Use Case:** You've been chatting with the AI for 2 hours. The context window is huge, and every single prompt is costing $0.10 just in input tokens. You only need a small CSS fix now.
|
|
1506
|
+
|
|
1507
|
+
```
|
|
1508
|
+
/diet Fix the margin on the login button in Header.vue.```
|
|
1509
|
+
> *Flushing conversational history and unrelated files...*
|
|
1510
|
+
> *Retaining only `Header.vue` lines 45-60.*
|
|
1511
|
+
>
|
|
1512
|
+
> Here is the fixed CSS class for the login button:
|
|
1513
|
+
> ```css
|
|
1514
|
+
> .login-btn { margin-left: 1rem; }
|
|
1515
|
+
> ```
|
|
1516
|
+
> *(Input tokens reduced from 80k to 400 tokens).*
|
|
1517
|
+
|
|
1518
|
+
---
|
|
1519
|
+
|
|
1520
|
+
|
|
1521
|
+
**Use Case:** You are in an expensive Opus/Pro session, but you need a simple regex or a basic boilerplate script that a cheap model like Haiku/Flash could do for pennies.
|
|
1522
|
+
|
|
1523
|
+
```
|
|
1524
|
+
/delegate Write a regex to validate Tunisian phone numbers (+216).```
|
|
1525
|
+
> *Task evaluated as trivial. Executing this on the current premium model is a waste of budget.*
|
|
1526
|
+
>
|
|
1527
|
+
> **Action:** Copy and paste the prompt below into a Gemini Flash or Claude Haiku session:
|
|
1528
|
+
> > *"Write a javascript regex that strictly matches Tunisian phone numbers starting with +216 followed by 8 digits. Provide 3 test cases."*
|
|
1529
|
+
|
|
1530
|
+
---
|
|
1531
|
+
|