@dedesfr/prompter 0.8.5 → 0.8.8
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 +48 -0
- package/convex-setup.md +403 -0
- package/dist/cli/index.js +1 -1
- package/package.json +1 -1
- package/skills/design-md/README.md +34 -0
- package/skills/design-md/SKILL.md +172 -0
- package/skills/design-md/examples/DESIGN.md +154 -0
- package/skills/enhance-prompt/README.md +34 -0
- package/skills/enhance-prompt/SKILL.md +204 -0
- package/skills/enhance-prompt/references/KEYWORDS.md +114 -0
- package/skills/feature-planner/SKILL.md +305 -0
- package/skills/feature-planner/assets/implementation-plan-template.md +85 -0
- package/skills/project-orchestrator/SKILL.md +34 -0
- package/skills/project-orchestrator/assets/plan-summary-template.md +38 -4
- package/skills/prompter-workflow/SKILL.md +166 -0
- package/skills/prompter-workflow/evals/evals.json +89 -0
- package/src/cli/index.ts +1 -1
- package/skills/skill-creator/LICENSE.txt +0 -202
- package/skills/skill-creator/SKILL.md +0 -485
- package/skills/skill-creator/agents/analyzer.md +0 -274
- package/skills/skill-creator/agents/comparator.md +0 -202
- package/skills/skill-creator/agents/grader.md +0 -223
- package/skills/skill-creator/assets/eval_review.html +0 -146
- package/skills/skill-creator/eval-viewer/generate_review.py +0 -471
- package/skills/skill-creator/eval-viewer/viewer.html +0 -1325
- package/skills/skill-creator/references/schemas.md +0 -430
- package/skills/skill-creator/scripts/__init__.py +0 -0
- package/skills/skill-creator/scripts/aggregate_benchmark.py +0 -401
- package/skills/skill-creator/scripts/generate_report.py +0 -326
- package/skills/skill-creator/scripts/improve_description.py +0 -247
- package/skills/skill-creator/scripts/package_skill.py +0 -136
- package/skills/skill-creator/scripts/quick_validate.py +0 -103
- package/skills/skill-creator/scripts/run_eval.py +0 -310
- package/skills/skill-creator/scripts/run_loop.py +0 -328
- package/skills/skill-creator/scripts/utils.py +0 -47
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,53 @@
|
|
|
1
1
|
# CHANGELOG
|
|
2
2
|
|
|
3
|
+
## [0.8.8] - 2026-04-10
|
|
4
|
+
|
|
5
|
+
### 🗑️ Removed
|
|
6
|
+
- **skill-creator Agents**: Removed complex agent infrastructure for skill evaluation
|
|
7
|
+
- Deleted analyzer, comparator, and grader agent definitions
|
|
8
|
+
- Simplified skill-creator workflow by removing advanced evaluation agents
|
|
9
|
+
- **Evaluation Infrastructure**: Removed benchmark and evaluation tooling
|
|
10
|
+
- Deleted eval-viewer HTML application and visualization components
|
|
11
|
+
- Removed benchmark aggregation and report generation scripts
|
|
12
|
+
- Removed skill evaluation loop and description optimization scripts
|
|
13
|
+
- Removed JSON schema references for evaluation data structures
|
|
14
|
+
- **Utility Scripts**: Removed support tools and helper modules
|
|
15
|
+
- Deleted packaging, validation, improvement, and utility scripts
|
|
16
|
+
- Cleaned up skill-creator Python script dependencies
|
|
17
|
+
|
|
18
|
+
### 🔄 Changed
|
|
19
|
+
- **skill-creator Skill**: Streamlined to focus on core skill creation workflow
|
|
20
|
+
- Removed evaluation and benchmarking components
|
|
21
|
+
- Simplified to essential skill creation and documentation guidance
|
|
22
|
+
|
|
23
|
+
## [0.8.7] - 2026-04-05
|
|
24
|
+
|
|
25
|
+
### ✨ Added
|
|
26
|
+
- **prompter-workflow Skill**: Guide spec-driven development through Prompter's three-stage workflow
|
|
27
|
+
- Orchestrates **Propose**, **Apply**, and **Archive** stages for safe, traceable changes
|
|
28
|
+
- Includes guardrails for minimal, scoped, and verifiable implementations
|
|
29
|
+
- Integrated with `prompter/changes/` and `prompter/specs/` for change management
|
|
30
|
+
- Supports drafting spec deltas with `ADDED|MODIFIED|REMOVED|RENAMED` requirements
|
|
31
|
+
|
|
32
|
+
## [0.8.6] - 2026-04-04
|
|
33
|
+
|
|
34
|
+
### ✨ Added
|
|
35
|
+
- **Convex Self-Hosted Deployment**: Comprehensive setup guide for self-hosted Convex deployments
|
|
36
|
+
- New `convex-setup.md` documentation covering Docker Compose setup with backend and dashboard containers
|
|
37
|
+
- Step-by-step instructions for admin key generation, schema deployment, and frontend integration
|
|
38
|
+
- Environment variable configuration for both compose stack (`.env.dev`) and CLI/frontend (`.env.local`)
|
|
39
|
+
- Troubleshooting guide and common mistakes reference
|
|
40
|
+
- Verification checklist for successful setup
|
|
41
|
+
|
|
42
|
+
### 🔄 Changed
|
|
43
|
+
- **project-orchestrator Skill**: Added Convex self-hosted deployment options
|
|
44
|
+
- New Convex hosting sub-choice: Cloud (managed) vs Self-Hosted (Docker, full control)
|
|
45
|
+
- Comprehensive Convex Self-Hosted Guidelines including Docker Compose setup, environment variables, and admin key generation
|
|
46
|
+
- Updated plan summary template to include Convex hosting choice and web server configuration
|
|
47
|
+
- Added Convex self-hosted setup commands to project bootstrapping examples
|
|
48
|
+
- Best practices for reserved index names and frontend URL configuration in self-hosted deployments
|
|
49
|
+
- Web Server / Reverse Proxy Guidelines: Always use Caddy for automatic HTTPS in production with zero configuration
|
|
50
|
+
|
|
3
51
|
## [0.8.5] - 2026-03-30
|
|
4
52
|
|
|
5
53
|
### ✨ Added
|
package/convex-setup.md
ADDED
|
@@ -0,0 +1,403 @@
|
|
|
1
|
+
# Convex Self-Hosted Setup Guide
|
|
2
|
+
|
|
3
|
+
This document explains how to set up a self-hosted Convex deployment for this project using the official Convex self-hosted flow.
|
|
4
|
+
|
|
5
|
+
It covers:
|
|
6
|
+
|
|
7
|
+
- the Convex backend container
|
|
8
|
+
- the Convex dashboard container
|
|
9
|
+
- the frontend app connected through `VITE_CONVEX_URL`
|
|
10
|
+
- the Convex CLI workflow for deploying schema and functions to a self-hosted instance
|
|
11
|
+
|
|
12
|
+
## Official self-hosted flow
|
|
13
|
+
|
|
14
|
+
The official Convex self-hosted documentation uses this sequence:
|
|
15
|
+
|
|
16
|
+
1. start the backend and dashboard
|
|
17
|
+
2. generate the admin key from the running backend container
|
|
18
|
+
3. save `CONVEX_SELF_HOSTED_URL` and `CONVEX_SELF_HOSTED_ADMIN_KEY` in `.env.local`
|
|
19
|
+
4. use the Convex CLI to deploy schema and functions
|
|
20
|
+
5. run queries, mutations, imports, or seeds against the self-hosted backend
|
|
21
|
+
|
|
22
|
+
Important:
|
|
23
|
+
|
|
24
|
+
- The CLI admin key is generated from the running backend.
|
|
25
|
+
- Do not assume the Docker env value `CONVEX_ADMIN_KEY` is the same value the CLI expects.
|
|
26
|
+
- Do not use a random `openssl rand -hex 32` string as `CONVEX_SELF_HOSTED_ADMIN_KEY` unless Convex explicitly tells you to do so for your setup.
|
|
27
|
+
|
|
28
|
+
## How this project is wired
|
|
29
|
+
|
|
30
|
+
### Frontend
|
|
31
|
+
|
|
32
|
+
The frontend creates the Convex React client from `VITE_CONVEX_URL`:
|
|
33
|
+
|
|
34
|
+
```ts
|
|
35
|
+
const convex = new ConvexReactClient(import.meta.env.VITE_CONVEX_URL as string);
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
That means:
|
|
39
|
+
|
|
40
|
+
- `VITE_CONVEX_URL` must be reachable by the browser
|
|
41
|
+
- the frontend needs this value during local development
|
|
42
|
+
- when building the Docker image, the same value must be passed as a build argument
|
|
43
|
+
|
|
44
|
+
### Deploy script
|
|
45
|
+
|
|
46
|
+
This project exposes a self-hosted deploy script in `package.json`:
|
|
47
|
+
|
|
48
|
+
```json
|
|
49
|
+
{
|
|
50
|
+
"scripts": {
|
|
51
|
+
"deploy:selfhosted": "convex deploy --url $CONVEX_SELF_HOSTED_URL --admin-key $CONVEX_SELF_HOSTED_ADMIN_KEY"
|
|
52
|
+
}
|
|
53
|
+
}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Prerequisites
|
|
57
|
+
|
|
58
|
+
Install these first:
|
|
59
|
+
|
|
60
|
+
- Node.js 22+
|
|
61
|
+
- npm
|
|
62
|
+
- Docker Desktop or Docker Engine with Compose
|
|
63
|
+
- project dependencies installed with `npm install`
|
|
64
|
+
|
|
65
|
+
If `node` or `npm` are missing from your `PATH`, use the Node 22 install configured for this project:
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
export PATH="$HOME/.nvm/versions/node/v22.17.1/bin:$PATH"
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
## Environment variables used by this project
|
|
72
|
+
|
|
73
|
+
This project uses two different configuration contexts.
|
|
74
|
+
|
|
75
|
+
### 1. Docker Compose environment
|
|
76
|
+
|
|
77
|
+
The compose stack reads values such as:
|
|
78
|
+
|
|
79
|
+
```env
|
|
80
|
+
APP_ENV=dev
|
|
81
|
+
WEB_PORT=8080
|
|
82
|
+
CONVEX_PORT=3220
|
|
83
|
+
CONVEX_DASHBOARD_PORT=3221
|
|
84
|
+
CONVEX_DASHBOARD_UI_PORT=6792
|
|
85
|
+
VITE_CONVEX_URL=http://localhost:3220
|
|
86
|
+
CONVEX_ADMIN_KEY=replace-with-placeholder-if-needed
|
|
87
|
+
CONVEX_CLOUD_ORIGIN=http://localhost:3220
|
|
88
|
+
CONVEX_SITE_ORIGIN=http://localhost:6792
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
Notes:
|
|
92
|
+
|
|
93
|
+
- `CONVEX_ADMIN_KEY` is passed into the backend container.
|
|
94
|
+
- In practice, the Convex CLI should use the admin key generated from the running backend container.
|
|
95
|
+
- `CONVEX_CLOUD_ORIGIN` should point to the backend API origin.
|
|
96
|
+
- `CONVEX_SITE_ORIGIN` should point to the dashboard UI origin.
|
|
97
|
+
|
|
98
|
+
### 2. Local CLI and frontend environment
|
|
99
|
+
|
|
100
|
+
For local development, `.env.local` should contain:
|
|
101
|
+
|
|
102
|
+
```env
|
|
103
|
+
VITE_CONVEX_URL=http://localhost:3220
|
|
104
|
+
CONVEX_SELF_HOSTED_URL=http://localhost:3220
|
|
105
|
+
CONVEX_SELF_HOSTED_ADMIN_KEY=convex-self-hosted|generated-from-container
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
Notes:
|
|
109
|
+
|
|
110
|
+
- `VITE_CONVEX_URL` is used by the frontend.
|
|
111
|
+
- `CONVEX_SELF_HOSTED_URL` and `CONVEX_SELF_HOSTED_ADMIN_KEY` are used by the Convex CLI.
|
|
112
|
+
- `.env.local` should not be committed.
|
|
113
|
+
|
|
114
|
+
## Reference Docker Compose pattern
|
|
115
|
+
|
|
116
|
+
This project uses the same high-level pattern as the official self-hosted documentation: one backend service and one dashboard service.
|
|
117
|
+
|
|
118
|
+
```yaml
|
|
119
|
+
services:
|
|
120
|
+
convex:
|
|
121
|
+
image: ghcr.io/get-convex/convex-backend:latest
|
|
122
|
+
ports:
|
|
123
|
+
- "${CONVEX_PORT:-3210}:3210"
|
|
124
|
+
- "${CONVEX_DASHBOARD_PORT:-3211}:3211"
|
|
125
|
+
volumes:
|
|
126
|
+
- convex-data:/convex/data
|
|
127
|
+
environment:
|
|
128
|
+
CONVEX_ADMIN_KEY: ${CONVEX_ADMIN_KEY}
|
|
129
|
+
CONVEX_CLOUD_ORIGIN: ${CONVEX_CLOUD_ORIGIN}
|
|
130
|
+
CONVEX_SITE_ORIGIN: ${CONVEX_SITE_ORIGIN}
|
|
131
|
+
|
|
132
|
+
convex-dashboard:
|
|
133
|
+
image: ghcr.io/get-convex/convex-dashboard:latest
|
|
134
|
+
depends_on:
|
|
135
|
+
convex:
|
|
136
|
+
condition: service_started
|
|
137
|
+
ports:
|
|
138
|
+
- "${CONVEX_DASHBOARD_UI_PORT:-6791}:6791"
|
|
139
|
+
environment:
|
|
140
|
+
NEXT_PUBLIC_DEPLOYMENT_URL: ${CONVEX_CLOUD_ORIGIN}
|
|
141
|
+
NEXT_PUBLIC_LOAD_MONACO_INTERNALLY: "true"
|
|
142
|
+
|
|
143
|
+
volumes:
|
|
144
|
+
convex-data:
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
In this repository, the actual compose file also includes a `web` service for the frontend.
|
|
148
|
+
|
|
149
|
+
## Step-by-step setup for this project
|
|
150
|
+
|
|
151
|
+
### 1. Install dependencies
|
|
152
|
+
|
|
153
|
+
From the repository root:
|
|
154
|
+
|
|
155
|
+
```bash
|
|
156
|
+
npm install
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
### 2. Create `.env.dev`
|
|
160
|
+
|
|
161
|
+
Copy the development template:
|
|
162
|
+
|
|
163
|
+
```bash
|
|
164
|
+
cp env.dev.example .env.dev
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
Recommended local values:
|
|
168
|
+
|
|
169
|
+
```env
|
|
170
|
+
APP_ENV=dev
|
|
171
|
+
WEB_PORT=8080
|
|
172
|
+
CONVEX_PORT=3220
|
|
173
|
+
CONVEX_DASHBOARD_PORT=3221
|
|
174
|
+
CONVEX_DASHBOARD_UI_PORT=6792
|
|
175
|
+
VITE_CONVEX_URL=http://localhost:3220
|
|
176
|
+
CONVEX_ADMIN_KEY=replace-with-placeholder-if-needed
|
|
177
|
+
CONVEX_CLOUD_ORIGIN=http://localhost:3220
|
|
178
|
+
CONVEX_SITE_ORIGIN=http://localhost:6792
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
Important:
|
|
182
|
+
|
|
183
|
+
- Treat `CONVEX_ADMIN_KEY` here as backend container configuration.
|
|
184
|
+
- Do not copy this value into `CONVEX_SELF_HOSTED_ADMIN_KEY` for CLI usage unless you have confirmed it is the generated self-hosted admin key for your instance.
|
|
185
|
+
|
|
186
|
+
### 3. Create `.env.local`
|
|
187
|
+
|
|
188
|
+
Create the local file with the frontend URL first:
|
|
189
|
+
|
|
190
|
+
```bash
|
|
191
|
+
cat > .env.local <<'EOF'
|
|
192
|
+
VITE_CONVEX_URL=http://localhost:3220
|
|
193
|
+
EOF
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
You will append the self-hosted CLI settings after the backend starts and after you generate the real admin key.
|
|
197
|
+
|
|
198
|
+
### 4. Start the Convex backend and dashboard
|
|
199
|
+
|
|
200
|
+
Run:
|
|
201
|
+
|
|
202
|
+
```bash
|
|
203
|
+
docker compose --env-file .env.dev up -d convex convex-dashboard
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
Check status:
|
|
207
|
+
|
|
208
|
+
```bash
|
|
209
|
+
docker compose --env-file .env.dev ps
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
Expected result:
|
|
213
|
+
|
|
214
|
+
- `convex` is running
|
|
215
|
+
- `convex-dashboard` is running
|
|
216
|
+
|
|
217
|
+
By default for local development in this project:
|
|
218
|
+
|
|
219
|
+
- backend API is available at `http://localhost:3220`
|
|
220
|
+
- backend dashboard/API port is mapped at `http://localhost:3221`
|
|
221
|
+
- dashboard UI is available at `http://localhost:6792`
|
|
222
|
+
|
|
223
|
+
## 5. Generate the real self-hosted admin key
|
|
224
|
+
|
|
225
|
+
After the backend is running, generate the admin key from the live Convex container.
|
|
226
|
+
|
|
227
|
+
Run:
|
|
228
|
+
|
|
229
|
+
```bash
|
|
230
|
+
docker compose --env-file .env.dev exec convex ./generate_admin_key.sh
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
Expected output format:
|
|
234
|
+
|
|
235
|
+
```text
|
|
236
|
+
convex-self-hosted|...
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
Copy that exact value.
|
|
240
|
+
|
|
241
|
+
Now append the self-hosted CLI settings to `.env.local`:
|
|
242
|
+
|
|
243
|
+
```bash
|
|
244
|
+
cat >> .env.local <<'EOF'
|
|
245
|
+
CONVEX_SELF_HOSTED_URL=http://localhost:3220
|
|
246
|
+
CONVEX_SELF_HOSTED_ADMIN_KEY=paste-the-generated-key-here
|
|
247
|
+
EOF
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
Important:
|
|
251
|
+
|
|
252
|
+
- Use the generated key exactly as printed.
|
|
253
|
+
- If you later recreate the backend state, generate the key again.
|
|
254
|
+
- If the backend uses a persistent Docker volume, the instance credentials can persist across restarts.
|
|
255
|
+
|
|
256
|
+
## 6. Deploy schema and functions
|
|
257
|
+
|
|
258
|
+
With `.env.local` configured, deploy the Convex schema and functions:
|
|
259
|
+
|
|
260
|
+
```bash
|
|
261
|
+
npm run deploy:selfhosted
|
|
262
|
+
```
|
|
263
|
+
|
|
264
|
+
Equivalent raw command:
|
|
265
|
+
|
|
266
|
+
```bash
|
|
267
|
+
convex deploy --url "$CONVEX_SELF_HOSTED_URL" --admin-key "$CONVEX_SELF_HOSTED_ADMIN_KEY"
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
If deployment succeeds, the self-hosted backend now has the current Convex schema and functions.
|
|
271
|
+
|
|
272
|
+
### Project-specific warning
|
|
273
|
+
|
|
274
|
+
This repository currently has a known self-hosted compatibility issue in `convex/schema.ts`: reserved index names such as `by_id` can cause deploy to fail on self-hosted Convex.
|
|
275
|
+
|
|
276
|
+
If you see an error like:
|
|
277
|
+
|
|
278
|
+
```text
|
|
279
|
+
IndexNameReserved: In table "agents" cannot name an index "by_id"
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
rename the reserved index names to something non-reserved such as `by_external_id`, then deploy again.
|
|
283
|
+
|
|
284
|
+
## 7. Seed or run commands against the backend
|
|
285
|
+
|
|
286
|
+
Once deploy succeeds, you can run Convex commands against the self-hosted instance.
|
|
287
|
+
|
|
288
|
+
For this project's seed function:
|
|
289
|
+
|
|
290
|
+
```bash
|
|
291
|
+
npx convex run seed:run '{}' \
|
|
292
|
+
--url http://localhost:3220 \
|
|
293
|
+
--admin-key "$CONVEX_SELF_HOSTED_ADMIN_KEY"
|
|
294
|
+
```
|
|
295
|
+
|
|
296
|
+
You can also use other CLI commands after configuration, for example:
|
|
297
|
+
|
|
298
|
+
```bash
|
|
299
|
+
npx convex --help
|
|
300
|
+
```
|
|
301
|
+
|
|
302
|
+
## 8. Run the frontend locally
|
|
303
|
+
|
|
304
|
+
Start the frontend development server:
|
|
305
|
+
|
|
306
|
+
```bash
|
|
307
|
+
npm run dev
|
|
308
|
+
```
|
|
309
|
+
|
|
310
|
+
Open the local Vite URL shown in the terminal, typically:
|
|
311
|
+
|
|
312
|
+
```text
|
|
313
|
+
http://localhost:5173
|
|
314
|
+
```
|
|
315
|
+
|
|
316
|
+
## 9. Optional Dockerized frontend
|
|
317
|
+
|
|
318
|
+
If you want to run the frontend through Docker Compose too:
|
|
319
|
+
|
|
320
|
+
```bash
|
|
321
|
+
docker compose --env-file .env.dev up -d --build
|
|
322
|
+
```
|
|
323
|
+
|
|
324
|
+
This project passes `VITE_CONVEX_URL` as a Docker build argument so the Vite app can be built with the correct public backend URL.
|
|
325
|
+
|
|
326
|
+
## Verification checklist
|
|
327
|
+
|
|
328
|
+
- `npm install` completes successfully
|
|
329
|
+
- `docker compose --env-file .env.dev up -d convex convex-dashboard` succeeds
|
|
330
|
+
- `docker compose --env-file .env.dev exec convex ./generate_admin_key.sh` returns a `convex-self-hosted|...` key
|
|
331
|
+
- `.env.local` contains `VITE_CONVEX_URL`, `CONVEX_SELF_HOSTED_URL`, and the generated `CONVEX_SELF_HOSTED_ADMIN_KEY`
|
|
332
|
+
- `npm run deploy:selfhosted` succeeds
|
|
333
|
+
- any seed or query command against the backend succeeds
|
|
334
|
+
- `npm run dev` starts the frontend successfully
|
|
335
|
+
- the frontend can load data from Convex
|
|
336
|
+
|
|
337
|
+
## Common mistakes
|
|
338
|
+
|
|
339
|
+
- using `.env.dev`'s `CONVEX_ADMIN_KEY` as the CLI admin key without generating the real self-hosted key from the container
|
|
340
|
+
- using a random string as `CONVEX_SELF_HOSTED_ADMIN_KEY`
|
|
341
|
+
- forgetting to deploy schema and functions before running seed commands
|
|
342
|
+
- using a `VITE_CONVEX_URL` that the browser cannot reach
|
|
343
|
+
- assuming changing `.env.dev` automatically updates credentials already persisted in a Docker volume
|
|
344
|
+
- overlooking self-hosted restrictions such as reserved index names during deploy
|
|
345
|
+
|
|
346
|
+
## Troubleshooting
|
|
347
|
+
|
|
348
|
+
### `401 Unauthorized: BadAdminKey`
|
|
349
|
+
|
|
350
|
+
Cause:
|
|
351
|
+
|
|
352
|
+
- the CLI is using the wrong admin key
|
|
353
|
+
|
|
354
|
+
Fix:
|
|
355
|
+
|
|
356
|
+
1. make sure the backend is running
|
|
357
|
+
2. run `docker compose --env-file .env.dev exec convex ./generate_admin_key.sh`
|
|
358
|
+
3. copy the printed `convex-self-hosted|...` value into `.env.local` as `CONVEX_SELF_HOSTED_ADMIN_KEY`
|
|
359
|
+
4. retry deploy or seed
|
|
360
|
+
|
|
361
|
+
### `Could not find function for 'seed:run'`
|
|
362
|
+
|
|
363
|
+
Cause:
|
|
364
|
+
|
|
365
|
+
- deploy has not succeeded yet, so the function is not available on the backend
|
|
366
|
+
|
|
367
|
+
Fix:
|
|
368
|
+
|
|
369
|
+
1. resolve the deploy error first
|
|
370
|
+
2. rerun `npm run deploy:selfhosted`
|
|
371
|
+
3. rerun the seed command
|
|
372
|
+
|
|
373
|
+
### `IndexNameReserved`
|
|
374
|
+
|
|
375
|
+
Cause:
|
|
376
|
+
|
|
377
|
+
- the schema defines a reserved index name such as `by_id`
|
|
378
|
+
|
|
379
|
+
Fix:
|
|
380
|
+
|
|
381
|
+
- rename the reserved index to a non-reserved name such as `by_external_id`
|
|
382
|
+
- redeploy
|
|
383
|
+
|
|
384
|
+
### Frontend fails because `VITE_CONVEX_URL` is missing
|
|
385
|
+
|
|
386
|
+
Cause:
|
|
387
|
+
|
|
388
|
+
- `.env.local` is missing or incomplete
|
|
389
|
+
|
|
390
|
+
Fix:
|
|
391
|
+
|
|
392
|
+
- recreate `.env.local`
|
|
393
|
+
- restart the frontend dev server
|
|
394
|
+
|
|
395
|
+
## Files in this project you can reuse as references
|
|
396
|
+
|
|
397
|
+
- `package.json`
|
|
398
|
+
- `docker-compose.yml`
|
|
399
|
+
- `Dockerfile`
|
|
400
|
+
- `env.dev.example`
|
|
401
|
+
- `env.prod.example`
|
|
402
|
+
- `src/providers/ConvexClientProvider.tsx`
|
|
403
|
+
- `prompter/changes/add-convex-backend/guide.md`
|
package/dist/cli/index.js
CHANGED
|
@@ -16,7 +16,7 @@ const program = new Command();
|
|
|
16
16
|
program
|
|
17
17
|
.name('prompter')
|
|
18
18
|
.description('Enhance prompts directly in your AI coding workflow')
|
|
19
|
-
.version('0.8.
|
|
19
|
+
.version('0.8.8');
|
|
20
20
|
program
|
|
21
21
|
.command('init')
|
|
22
22
|
.description('Initialize Prompter in your project')
|
package/package.json
CHANGED
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Stitch Design System Documentation Skill
|
|
2
|
+
|
|
3
|
+
## Install
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
npx skills add google-labs-code/stitch-skills --skill design-md --global
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
## Example Prompt
|
|
10
|
+
|
|
11
|
+
```text
|
|
12
|
+
Analyze my Furniture Collection project's Home screen and generate a comprehensive DESIGN.md file documenting the design system.
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
## Skill Structure
|
|
16
|
+
|
|
17
|
+
This repository follows the **Agent Skills** open standard. Each skill is self-contained with its own logic, workflow, and reference materials.
|
|
18
|
+
|
|
19
|
+
```text
|
|
20
|
+
design-md/
|
|
21
|
+
├── SKILL.md — Core instructions & workflow
|
|
22
|
+
├── examples/ — Sample DESIGN.md outputs
|
|
23
|
+
└── README.md — This file
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
## How it Works
|
|
27
|
+
|
|
28
|
+
When activated, the agent follows a structured design analysis pipeline:
|
|
29
|
+
|
|
30
|
+
1. **Retrieval**: Uses the Stitch MCP Server to fetch project screens, HTML code, and design metadata.
|
|
31
|
+
2. **Extraction**: Identifies design tokens including colors, typography, spacing, and component patterns.
|
|
32
|
+
3. **Translation**: Converts technical CSS/Tailwind values into descriptive, natural design language.
|
|
33
|
+
4. **Synthesis**: Generates a comprehensive DESIGN.md following the semantic design system format.
|
|
34
|
+
5. **Alignment**: Ensures output follows Stitch Effective Prompting Guide principles for optimal screen generation.
|
|
@@ -0,0 +1,172 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design-md
|
|
3
|
+
description: Analyze Stitch projects and synthesize a semantic design system into DESIGN.md files
|
|
4
|
+
allowed-tools:
|
|
5
|
+
- "stitch*:*"
|
|
6
|
+
- "Read"
|
|
7
|
+
- "Write"
|
|
8
|
+
- "web_fetch"
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Stitch DESIGN.md Skill
|
|
12
|
+
|
|
13
|
+
You are an expert Design Systems Lead. Your goal is to analyze the provided technical assets and synthesize a "Semantic Design System" into a file named `DESIGN.md`.
|
|
14
|
+
|
|
15
|
+
## Overview
|
|
16
|
+
|
|
17
|
+
This skill helps you create `DESIGN.md` files that serve as the "source of truth" for prompting Stitch to generate new screens that align perfectly with existing design language. Stitch interprets design through "Visual Descriptions" supported by specific color values.
|
|
18
|
+
|
|
19
|
+
## Prerequisites
|
|
20
|
+
|
|
21
|
+
- Access to the Stitch MCP Server
|
|
22
|
+
- A Stitch project with at least one designed screen
|
|
23
|
+
- Access to the Stitch Effective Prompting Guide: https://stitch.withgoogle.com/docs/learn/prompting/
|
|
24
|
+
|
|
25
|
+
## The Goal
|
|
26
|
+
|
|
27
|
+
The `DESIGN.md` file will serve as the "source of truth" for prompting Stitch to generate new screens that align perfectly with the existing design language. Stitch interprets design through "Visual Descriptions" supported by specific color values.
|
|
28
|
+
|
|
29
|
+
## Retrieval and Networking
|
|
30
|
+
|
|
31
|
+
To analyze a Stitch project, you must retrieve screen metadata and design assets using the Stitch MCP Server tools:
|
|
32
|
+
|
|
33
|
+
1. **Namespace discovery**: Run `list_tools` to find the Stitch MCP prefix. Use this prefix (e.g., `mcp_stitch:`) for all subsequent calls.
|
|
34
|
+
|
|
35
|
+
2. **Project lookup** (if Project ID is not provided):
|
|
36
|
+
- Call `[prefix]:list_projects` with `filter: "view=owned"` to retrieve all user projects
|
|
37
|
+
- Identify the target project by title or URL pattern
|
|
38
|
+
- Extract the Project ID from the `name` field (e.g., `projects/13534454087919359824`)
|
|
39
|
+
|
|
40
|
+
3. **Screen lookup** (if Screen ID is not provided):
|
|
41
|
+
- Call `[prefix]:list_screens` with the `projectId` (just the numeric ID, not the full path)
|
|
42
|
+
- Review screen titles to identify the target screen (e.g., "Home", "Landing Page")
|
|
43
|
+
- Extract the Screen ID from the screen's `name` field
|
|
44
|
+
|
|
45
|
+
4. **Metadata fetch**:
|
|
46
|
+
- Call `[prefix]:get_screen` with both `projectId` and `screenId` (both as numeric IDs only)
|
|
47
|
+
- This returns the complete screen object including:
|
|
48
|
+
- `screenshot.downloadUrl` - Visual reference of the design
|
|
49
|
+
- `htmlCode.downloadUrl` - Full HTML/CSS source code
|
|
50
|
+
- `width`, `height`, `deviceType` - Screen dimensions and target platform
|
|
51
|
+
- Project metadata including `designTheme` with color and style information
|
|
52
|
+
|
|
53
|
+
5. **Asset download**:
|
|
54
|
+
- Use `web_fetch` or `read_url_content` to download the HTML code from `htmlCode.downloadUrl`
|
|
55
|
+
- Optionally download the screenshot from `screenshot.downloadUrl` for visual reference
|
|
56
|
+
- Parse the HTML to extract Tailwind classes, custom CSS, and component patterns
|
|
57
|
+
|
|
58
|
+
6. **Project metadata extraction**:
|
|
59
|
+
- Call `[prefix]:get_project` with the project `name` (full path: `projects/{id}`) to get:
|
|
60
|
+
- `designTheme` object with color mode, fonts, roundness, custom colors
|
|
61
|
+
- Project-level design guidelines and descriptions
|
|
62
|
+
- Device type preferences and layout principles
|
|
63
|
+
|
|
64
|
+
## Analysis & Synthesis Instructions
|
|
65
|
+
|
|
66
|
+
### 1. Extract Project Identity (JSON)
|
|
67
|
+
- Locate the Project Title
|
|
68
|
+
- Locate the specific Project ID (e.g., from the `name` field in the JSON)
|
|
69
|
+
|
|
70
|
+
### 2. Define the Atmosphere (Image/HTML)
|
|
71
|
+
Evaluate the screenshot and HTML structure to capture the overall "vibe." Use evocative adjectives to describe the mood (e.g., "Airy," "Dense," "Minimalist," "Utilitarian").
|
|
72
|
+
|
|
73
|
+
### 3. Map the Color Palette (Tailwind Config/JSON)
|
|
74
|
+
Identify the key colors in the system. For each color, provide:
|
|
75
|
+
- A descriptive, natural language name that conveys its character (e.g., "Deep Muted Teal-Navy")
|
|
76
|
+
- The specific hex code in parentheses for precision (e.g., "#294056")
|
|
77
|
+
- Its specific functional role (e.g., "Used for primary actions")
|
|
78
|
+
|
|
79
|
+
### 4. Translate Geometry & Shape (CSS/Tailwind)
|
|
80
|
+
Convert technical `border-radius` and layout values into physical descriptions:
|
|
81
|
+
- Describe `rounded-full` as "Pill-shaped"
|
|
82
|
+
- Describe `rounded-lg` as "Subtly rounded corners"
|
|
83
|
+
- Describe `rounded-none` as "Sharp, squared-off edges"
|
|
84
|
+
|
|
85
|
+
### 5. Describe Depth & Elevation
|
|
86
|
+
Explain how the UI handles layers. Describe the presence and quality of shadows (e.g., "Flat," "Whisper-soft diffused shadows," or "Heavy, high-contrast drop shadows").
|
|
87
|
+
|
|
88
|
+
## Output Guidelines
|
|
89
|
+
|
|
90
|
+
- **Language:** Use descriptive design terminology and natural language exclusively
|
|
91
|
+
- **Format:** Generate a clean Markdown file following the structure below
|
|
92
|
+
- **Precision:** Include exact hex codes for colors while using descriptive names
|
|
93
|
+
- **Context:** Explain the "why" behind design decisions, not just the "what"
|
|
94
|
+
|
|
95
|
+
## Output Format (DESIGN.md Structure)
|
|
96
|
+
|
|
97
|
+
```markdown
|
|
98
|
+
# Design System: [Project Title]
|
|
99
|
+
**Project ID:** [Insert Project ID Here]
|
|
100
|
+
|
|
101
|
+
## 1. Visual Theme & Atmosphere
|
|
102
|
+
(Description of the mood, density, and aesthetic philosophy.)
|
|
103
|
+
|
|
104
|
+
## 2. Color Palette & Roles
|
|
105
|
+
(List colors by Descriptive Name + Hex Code + Functional Role.)
|
|
106
|
+
|
|
107
|
+
## 3. Typography Rules
|
|
108
|
+
(Description of font family, weight usage for headers vs. body, and letter-spacing character.)
|
|
109
|
+
|
|
110
|
+
## 4. Component Stylings
|
|
111
|
+
* **Buttons:** (Shape description, color assignment, behavior).
|
|
112
|
+
* **Cards/Containers:** (Corner roundness description, background color, shadow depth).
|
|
113
|
+
* **Inputs/Forms:** (Stroke style, background).
|
|
114
|
+
|
|
115
|
+
## 5. Layout Principles
|
|
116
|
+
(Description of whitespace strategy, margins, and grid alignment.)
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
## Usage Example
|
|
120
|
+
|
|
121
|
+
To use this skill for the Furniture Collection project:
|
|
122
|
+
|
|
123
|
+
1. **Retrieve project information:**
|
|
124
|
+
```
|
|
125
|
+
Use the Stitch MCP Server to get the Furniture Collection project
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
2. **Get the Home page screen details:**
|
|
129
|
+
```
|
|
130
|
+
Retrieve the Home page screen's code, image, and screen object information
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
3. **Reference best practices:**
|
|
134
|
+
```
|
|
135
|
+
Review the Stitch Effective Prompting Guide at:
|
|
136
|
+
https://stitch.withgoogle.com/docs/learn/prompting/
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
4. **Analyze and synthesize:**
|
|
140
|
+
- Extract all relevant design tokens from the screen
|
|
141
|
+
- Translate technical values into descriptive language
|
|
142
|
+
- Organize information according to the DESIGN.md structure
|
|
143
|
+
|
|
144
|
+
5. **Generate the file:**
|
|
145
|
+
- Create `DESIGN.md` in the project directory
|
|
146
|
+
- Follow the prescribed format exactly
|
|
147
|
+
- Ensure all color codes are accurate
|
|
148
|
+
- Use evocative, designer-friendly language
|
|
149
|
+
|
|
150
|
+
## Best Practices
|
|
151
|
+
|
|
152
|
+
- **Be Descriptive:** Avoid generic terms like "blue" or "rounded." Use "Ocean-deep Cerulean (#0077B6)" or "Gently curved edges"
|
|
153
|
+
- **Be Functional:** Always explain what each design element is used for
|
|
154
|
+
- **Be Consistent:** Use the same terminology throughout the document
|
|
155
|
+
- **Be Visual:** Help readers visualize the design through your descriptions
|
|
156
|
+
- **Be Precise:** Include exact values (hex codes, pixel values) in parentheses after natural language descriptions
|
|
157
|
+
|
|
158
|
+
## Tips for Success
|
|
159
|
+
|
|
160
|
+
1. **Start with the big picture:** Understand the overall aesthetic before diving into details
|
|
161
|
+
2. **Look for patterns:** Identify consistent spacing, sizing, and styling patterns
|
|
162
|
+
3. **Think semantically:** Name colors by their purpose, not just their appearance
|
|
163
|
+
4. **Consider hierarchy:** Document how visual weight and importance are communicated
|
|
164
|
+
5. **Reference the guide:** Use language and patterns from the Stitch Effective Prompting Guide
|
|
165
|
+
|
|
166
|
+
## Common Pitfalls to Avoid
|
|
167
|
+
|
|
168
|
+
- ❌ Using technical jargon without translation (e.g., "rounded-xl" instead of "generously rounded corners")
|
|
169
|
+
- ❌ Omitting color codes or using only descriptive names
|
|
170
|
+
- ❌ Forgetting to explain functional roles of design elements
|
|
171
|
+
- ❌ Being too vague in atmosphere descriptions
|
|
172
|
+
- ❌ Ignoring subtle design details like shadows or spacing patterns
|