@waynesutton/convex-skills 1.0.2 → 1.0.4
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/AGENTS.md +12 -0
- package/README.md +18 -0
- package/bin/cli.js +35 -15
- package/index.js +2 -1
- package/package.json +1 -1
- package/skills/avoid-feature-creep/SKILL.md +307 -0
- package/skills/convex/SKILL.md +62 -0
- package/skills/convex-agents/SKILL.md +2 -1
- package/skills/convex-best-practices/SKILL.md +2 -1
- package/skills/convex-component-authoring/SKILL.md +2 -1
- package/skills/convex-cron-jobs/SKILL.md +2 -1
- package/skills/convex-file-storage/SKILL.md +2 -1
- package/skills/convex-functions/SKILL.md +2 -1
- package/skills/convex-http-actions/SKILL.md +2 -1
- package/skills/convex-migrations/SKILL.md +2 -1
- package/skills/convex-realtime/SKILL.md +2 -1
- package/skills/convex-schema-validator/SKILL.md +2 -1
- package/skills/convex-security-audit/SKILL.md +2 -1
- package/skills/convex-security-check/SKILL.md +2 -1
package/AGENTS.md
CHANGED
|
@@ -77,6 +77,18 @@ Create a cron job to clean up expired sessions
|
|
|
77
77
|
Add a Stripe webhook endpoint
|
|
78
78
|
```
|
|
79
79
|
|
|
80
|
+
### Slash Command (OpenCode)
|
|
81
|
+
|
|
82
|
+
Use the `/convex` slash command for contextual guidance:
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
/convex create a schema with users and posts
|
|
86
|
+
/convex set up file uploads
|
|
87
|
+
/convex add a Stripe webhook endpoint
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
The command file is located at `command/convex.md`.
|
|
91
|
+
|
|
80
92
|
## Key Convex Concepts
|
|
81
93
|
|
|
82
94
|
### Function Types
|
package/README.md
CHANGED
|
@@ -77,6 +77,22 @@ Codex will auto-discover `SKILL.md` files in that directory on the next start.
|
|
|
77
77
|
|
|
78
78
|
OpenCode discovers skills from `~/.claude/skills/<name>/SKILL.md` automatically. See OpenCode Skills docs for more details.
|
|
79
79
|
|
|
80
|
+
#### Slash Command
|
|
81
|
+
|
|
82
|
+
This repo includes a `/convex` slash command for OpenCode. Install the command by copying `command/convex.md` to your OpenCode commands directory:
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
# Copy the slash command
|
|
86
|
+
cp command/convex.md ~/.opencode/command/
|
|
87
|
+
|
|
88
|
+
# Usage in OpenCode
|
|
89
|
+
/convex create a schema with users and posts
|
|
90
|
+
/convex set up file uploads
|
|
91
|
+
/convex add a Stripe webhook endpoint
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
The slash command provides decision trees to route to the appropriate skill based on your task.
|
|
95
|
+
|
|
80
96
|
### Manual Installation
|
|
81
97
|
|
|
82
98
|
Copy the desired skill's `SKILL.md` file to your project's `.claude/skills/` directory.
|
|
@@ -110,6 +126,8 @@ convex-skills/
|
|
|
110
126
|
│ ├── convex-cron-jobs/
|
|
111
127
|
│ │ └── SKILL.md
|
|
112
128
|
│ └── ...
|
|
129
|
+
├── command/ # Slash command definitions (OpenCode)
|
|
130
|
+
│ └── convex.md # /convex command entrypoint
|
|
113
131
|
├── templates/ # Templates for forking developers
|
|
114
132
|
│ ├── CLAUDE.md # Project context template
|
|
115
133
|
│ └── skills/ # Claude Code skill templates
|
package/bin/cli.js
CHANGED
|
@@ -2,14 +2,22 @@
|
|
|
2
2
|
|
|
3
3
|
import { fileURLToPath } from "url";
|
|
4
4
|
import { dirname, join, resolve } from "path";
|
|
5
|
-
import {
|
|
5
|
+
import {
|
|
6
|
+
readFileSync,
|
|
7
|
+
writeFileSync,
|
|
8
|
+
mkdirSync,
|
|
9
|
+
existsSync,
|
|
10
|
+
copyFileSync,
|
|
11
|
+
readdirSync,
|
|
12
|
+
} from "fs";
|
|
6
13
|
|
|
7
14
|
const __filename = fileURLToPath(import.meta.url);
|
|
8
15
|
const __dirname = dirname(__filename);
|
|
9
16
|
const packageRoot = join(__dirname, "..");
|
|
10
17
|
|
|
11
18
|
const SKILLS = {
|
|
12
|
-
"convex-best-practices":
|
|
19
|
+
"convex-best-practices":
|
|
20
|
+
"Guidelines for building production-ready Convex apps",
|
|
13
21
|
"convex-functions": "Writing queries, mutations, actions, and HTTP actions",
|
|
14
22
|
"convex-realtime": "Patterns for building reactive applications",
|
|
15
23
|
"convex-schema-validator": "Database schema definition and validation",
|
|
@@ -50,7 +58,9 @@ EXAMPLES:
|
|
|
50
58
|
convex-skills show convex-functions
|
|
51
59
|
|
|
52
60
|
AVAILABLE SKILLS:
|
|
53
|
-
${Object.entries(SKILLS)
|
|
61
|
+
${Object.entries(SKILLS)
|
|
62
|
+
.map(([name, desc]) => ` ${name.padEnd(30)} ${desc}`)
|
|
63
|
+
.join("\n")}
|
|
54
64
|
`);
|
|
55
65
|
}
|
|
56
66
|
|
|
@@ -64,18 +74,24 @@ function listSkills() {
|
|
|
64
74
|
|
|
65
75
|
function installSkill(skillName, targetDir) {
|
|
66
76
|
const skillsPath = join(packageRoot, "skills", skillName, "SKILL.md");
|
|
67
|
-
|
|
77
|
+
|
|
68
78
|
if (!existsSync(skillsPath)) {
|
|
69
79
|
console.error(`Error: Skill not found: ${skillName}`);
|
|
70
80
|
console.log("Run 'convex-skills list' to see available skills.");
|
|
71
81
|
process.exit(1);
|
|
72
82
|
}
|
|
73
83
|
|
|
74
|
-
const targetPath = join(
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
84
|
+
const targetPath = join(
|
|
85
|
+
targetDir,
|
|
86
|
+
".claude",
|
|
87
|
+
"skills",
|
|
88
|
+
skillName,
|
|
89
|
+
"SKILL.md",
|
|
90
|
+
);
|
|
91
|
+
const targetSkillDir = dirname(targetPath);
|
|
92
|
+
|
|
93
|
+
if (!existsSync(targetSkillDir)) {
|
|
94
|
+
mkdirSync(targetSkillDir, { recursive: true });
|
|
79
95
|
}
|
|
80
96
|
|
|
81
97
|
copyFileSync(skillsPath, targetPath);
|
|
@@ -94,12 +110,14 @@ function installAllSkills(targetDir) {
|
|
|
94
110
|
installSkill(skillName, targetDir);
|
|
95
111
|
});
|
|
96
112
|
|
|
97
|
-
console.log(
|
|
113
|
+
console.log(
|
|
114
|
+
`\nDone! Installed ${skills.length} skills to ${join(targetDir, ".claude", "skills")}`,
|
|
115
|
+
);
|
|
98
116
|
}
|
|
99
117
|
|
|
100
118
|
function installTemplates(targetDir) {
|
|
101
119
|
const templatesDir = join(packageRoot, "templates");
|
|
102
|
-
|
|
120
|
+
|
|
103
121
|
// Install CLAUDE.md template
|
|
104
122
|
const claudeTemplate = join(templatesDir, "CLAUDE.md");
|
|
105
123
|
if (existsSync(claudeTemplate)) {
|
|
@@ -115,9 +133,11 @@ function installTemplates(targetDir) {
|
|
|
115
133
|
// Install skill templates
|
|
116
134
|
const skillTemplatesDir = join(templatesDir, "skills");
|
|
117
135
|
if (existsSync(skillTemplatesDir)) {
|
|
118
|
-
const templates = readdirSync(skillTemplatesDir).filter((f) =>
|
|
136
|
+
const templates = readdirSync(skillTemplatesDir).filter((f) =>
|
|
137
|
+
f.endsWith(".md"),
|
|
138
|
+
);
|
|
119
139
|
const targetSkillsDir = join(targetDir, ".claude", "skills");
|
|
120
|
-
|
|
140
|
+
|
|
121
141
|
if (!existsSync(targetSkillsDir)) {
|
|
122
142
|
mkdirSync(targetSkillsDir, { recursive: true });
|
|
123
143
|
}
|
|
@@ -139,7 +159,7 @@ function installTemplates(targetDir) {
|
|
|
139
159
|
|
|
140
160
|
function showSkill(skillName) {
|
|
141
161
|
const skillsPath = join(packageRoot, "skills", skillName, "SKILL.md");
|
|
142
|
-
|
|
162
|
+
|
|
143
163
|
if (!existsSync(skillsPath)) {
|
|
144
164
|
console.error(`Error: Skill not found: ${skillName}`);
|
|
145
165
|
process.exit(1);
|
|
@@ -151,7 +171,7 @@ function showSkill(skillName) {
|
|
|
151
171
|
|
|
152
172
|
function printSkillPath(skillName) {
|
|
153
173
|
const skillsPath = join(packageRoot, "skills", skillName, "SKILL.md");
|
|
154
|
-
|
|
174
|
+
|
|
155
175
|
if (!existsSync(skillsPath)) {
|
|
156
176
|
console.error(`Error: Skill not found: ${skillName}`);
|
|
157
177
|
process.exit(1);
|
package/index.js
CHANGED
|
@@ -52,7 +52,8 @@ export function getSkillPath(skillName) {
|
|
|
52
52
|
* Available skills with descriptions
|
|
53
53
|
*/
|
|
54
54
|
export const SKILLS = {
|
|
55
|
-
"convex-best-practices":
|
|
55
|
+
"convex-best-practices":
|
|
56
|
+
"Guidelines for building production-ready Convex apps",
|
|
56
57
|
"convex-functions": "Writing queries, mutations, actions, and HTTP actions",
|
|
57
58
|
"convex-realtime": "Patterns for building reactive applications",
|
|
58
59
|
"convex-schema-validator": "Database schema definition and validation",
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@waynesutton/convex-skills",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.4",
|
|
4
4
|
"description": "Agent skills for building production-ready Convex applications. Includes best practices, functions, realtime patterns, schema validation, file storage, security audits, and more.",
|
|
5
5
|
"author": "Wayne Sutton",
|
|
6
6
|
"license": "Apache-2.0",
|
|
@@ -0,0 +1,307 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: avoid-feature-creep
|
|
3
|
+
description: Prevent feature creep when building software, apps, and AI-powered products. Use this skill when planning features, reviewing scope, building MVPs, managing backlogs, or when a user says "just one more feature." Helps developers and AI agents stay focused, ship faster, and avoid bloated products.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Avoid Feature Creep for Agents
|
|
7
|
+
|
|
8
|
+
Stop building features nobody needs. This skill helps you ship products that solve real problems without drowning in unnecessary complexity.
|
|
9
|
+
|
|
10
|
+
Feature creep kills products. It delays launches, burns budgets, exhausts teams, and creates software nobody wants to use. The most successful products do fewer things well.
|
|
11
|
+
|
|
12
|
+
## The Core Problem
|
|
13
|
+
|
|
14
|
+
Feature creep is the gradual accumulation of features beyond what your product needs to deliver value. It happens slowly, then all at once.
|
|
15
|
+
|
|
16
|
+
**Warning signs you're in trouble:**
|
|
17
|
+
- Release scope keeps growing without clear user value
|
|
18
|
+
- You're copying competitor features without validating need
|
|
19
|
+
- Stakeholders keep adding "just one more thing"
|
|
20
|
+
- The codebase is getting harder to maintain
|
|
21
|
+
- Users complain the product is confusing or bloated
|
|
22
|
+
- You haven't shipped in months
|
|
23
|
+
|
|
24
|
+
**What it costs:**
|
|
25
|
+
- Development time on features 80% of users never touch
|
|
26
|
+
- Increased bug surface area
|
|
27
|
+
- Team burnout and context switching
|
|
28
|
+
- Delayed time-to-market
|
|
29
|
+
- Technical debt that compounds
|
|
30
|
+
- User confusion and abandonment
|
|
31
|
+
|
|
32
|
+
## Decision Framework
|
|
33
|
+
|
|
34
|
+
Before adding ANY feature, run through this checklist:
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
1. VALIDATE THE PROBLEM
|
|
38
|
+
□ Does this solve a real, validated user pain point?
|
|
39
|
+
□ Have we talked to actual users about this need?
|
|
40
|
+
□ What evidence supports building this?
|
|
41
|
+
|
|
42
|
+
2. CHECK ALIGNMENT
|
|
43
|
+
□ Does this support the core product vision?
|
|
44
|
+
□ Would this delay our current release?
|
|
45
|
+
□ What are we NOT building if we build this?
|
|
46
|
+
|
|
47
|
+
3. MEASURE IMPACT
|
|
48
|
+
□ How will we know if this feature succeeds?
|
|
49
|
+
□ What KPIs will change?
|
|
50
|
+
□ Can we quantify the value (time saved, revenue, retention)?
|
|
51
|
+
|
|
52
|
+
4. ASSESS COMPLEXITY
|
|
53
|
+
□ What's the true cost (build + test + maintain + document)?
|
|
54
|
+
□ Does this add dependencies or technical debt?
|
|
55
|
+
□ Can we ship a simpler version first?
|
|
56
|
+
|
|
57
|
+
5. FINAL GUT CHECK
|
|
58
|
+
□ Would we delay launch by a month for this feature?
|
|
59
|
+
□ Is this a differentiator or just table stakes?
|
|
60
|
+
□ Would removing this harm the core experience?
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
If you can't answer YES to questions 1-3 with evidence, do not build the feature.
|
|
64
|
+
|
|
65
|
+
## Scope Management Rules
|
|
66
|
+
|
|
67
|
+
**Rule 1: Define and Defend Your MVP**
|
|
68
|
+
|
|
69
|
+
Write down exactly what "done" means before you start. Document what you're NOT building. Reference this constantly.
|
|
70
|
+
|
|
71
|
+
```markdown
|
|
72
|
+
## MVP Scope Document Template
|
|
73
|
+
|
|
74
|
+
### Core Problem
|
|
75
|
+
[One sentence describing the user problem]
|
|
76
|
+
|
|
77
|
+
### Success Criteria
|
|
78
|
+
[How we know we've solved it]
|
|
79
|
+
|
|
80
|
+
### In Scope (v1)
|
|
81
|
+
- Feature A: [brief description]
|
|
82
|
+
- Feature B: [brief description]
|
|
83
|
+
|
|
84
|
+
### Explicitly Out of Scope
|
|
85
|
+
- Feature X: Deferred to v2
|
|
86
|
+
- Feature Y: Will not build unless [condition]
|
|
87
|
+
- Feature Z: Not our problem to solve
|
|
88
|
+
|
|
89
|
+
### Non-Negotiables
|
|
90
|
+
- Ship by [date]
|
|
91
|
+
- Budget: [hours/dollars]
|
|
92
|
+
- Core user: [specific persona]
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
**Rule 2: Use Version Control for Scope**
|
|
96
|
+
|
|
97
|
+
Treat scope like code. Track changes. Require approval for additions.
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
# Create a scope document and track it
|
|
101
|
+
git add SCOPE.md
|
|
102
|
+
git commit -m "Initial MVP scope definition"
|
|
103
|
+
|
|
104
|
+
# Any scope changes require explicit commits
|
|
105
|
+
git commit -m "SCOPE CHANGE: Added feature X - approved by [stakeholder] - impact: +2 weeks"
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
**Rule 3: The 48-Hour Rule**
|
|
109
|
+
|
|
110
|
+
When someone requests a new feature, wait 48 hours before adding it to the backlog. Most "urgent" requests feel less urgent after reflection.
|
|
111
|
+
|
|
112
|
+
**Rule 4: Budget-Based Scoping**
|
|
113
|
+
|
|
114
|
+
Every feature has a cost. When something new comes in, something else must go out.
|
|
115
|
+
|
|
116
|
+
"Yes, we can add that. Which of these three features should we cut to make room?"
|
|
117
|
+
|
|
118
|
+
## Saying No
|
|
119
|
+
|
|
120
|
+
Saying no to features is a skill. Here are templates:
|
|
121
|
+
|
|
122
|
+
**To stakeholders:**
|
|
123
|
+
> "That's an interesting idea. Based on our user research, it doesn't solve our core user's top three problems. Let's add it to the v2 consideration list and revisit after we validate the MVP."
|
|
124
|
+
|
|
125
|
+
**To executives:**
|
|
126
|
+
> "I understand the value this could bring. If we add this, we'll delay launch by [X weeks] and deprioritize [Y feature]. Here are the trade-offs - which path should we take?"
|
|
127
|
+
|
|
128
|
+
**To users:**
|
|
129
|
+
> "Thanks for the feedback. We're focused on [core problem] right now. I've logged this for future consideration. Can you tell me more about why this would be valuable?"
|
|
130
|
+
|
|
131
|
+
**To yourself:**
|
|
132
|
+
> "Is this scratching my own itch or solving a real user problem? Would I bet the release date on this?"
|
|
133
|
+
|
|
134
|
+
**To AI agents (Claude, Opus, Codex, Ralph, Cursor):**
|
|
135
|
+
> "Stop. Before we add this feature, answer: Does this solve the core user problem we defined at the start of this session? If not, add it to a DEFERRED.md file and stay focused on the current scope."
|
|
136
|
+
|
|
137
|
+
When working with AI coding agents:
|
|
138
|
+
- State your scope constraints at the start of every session
|
|
139
|
+
- Agents will suggest improvements. Most are out of scope.
|
|
140
|
+
- Treat agent suggestions like stakeholder requests: apply the 48-hour rule
|
|
141
|
+
- If an agent keeps pushing a feature, ask "Why?" three times to find the real need
|
|
142
|
+
|
|
143
|
+
## AI-Specific Guidelines
|
|
144
|
+
|
|
145
|
+
When building AI-powered products, feature creep has extra risks:
|
|
146
|
+
|
|
147
|
+
**AI Feature Creep Red Flags:**
|
|
148
|
+
- Adding AI because "everyone else is"
|
|
149
|
+
- Building AI summaries without validating users want them
|
|
150
|
+
- Multiple AI features without clear differentiation
|
|
151
|
+
- AI capabilities that don't connect to core user workflows
|
|
152
|
+
|
|
153
|
+
**AI Feature Discipline:**
|
|
154
|
+
1. One AI feature at a time
|
|
155
|
+
2. Validate the use case with users first
|
|
156
|
+
3. Measure actual usage, not just availability
|
|
157
|
+
4. Question: "Does the AI make the core task faster or better?"
|
|
158
|
+
|
|
159
|
+
**Before adding any AI feature, answer:**
|
|
160
|
+
- What specific task does this automate?
|
|
161
|
+
- How is this better than the non-AI alternative?
|
|
162
|
+
- What happens when the AI is wrong?
|
|
163
|
+
- Can we ship without this AI feature?
|
|
164
|
+
|
|
165
|
+
## Backlog Hygiene
|
|
166
|
+
|
|
167
|
+
A messy backlog enables feature creep. Clean it ruthlessly.
|
|
168
|
+
|
|
169
|
+
**Monthly Backlog Audit:**
|
|
170
|
+
```
|
|
171
|
+
For each item older than 30 days:
|
|
172
|
+
1. Has anyone asked about this since it was added?
|
|
173
|
+
2. Does it still align with current product vision?
|
|
174
|
+
3. If we never built this, would anyone notice?
|
|
175
|
+
|
|
176
|
+
If the answer to all three is "no" → Delete it.
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
**Priority Framework (MoSCoW):**
|
|
180
|
+
- **Must Have**: Product doesn't work without it
|
|
181
|
+
- **Should Have**: Important but not critical for launch
|
|
182
|
+
- **Could Have**: Nice but can wait
|
|
183
|
+
- **Won't Have**: Explicitly out of scope
|
|
184
|
+
|
|
185
|
+
Be honest: Most "Should Haves" are actually "Could Haves" in disguise.
|
|
186
|
+
|
|
187
|
+
## AI Session Discipline
|
|
188
|
+
|
|
189
|
+
**Session Start Check:**
|
|
190
|
+
Before coding with any AI assistant (Claude, Cursor, OpenCode), state:
|
|
191
|
+
- What specific feature you're building
|
|
192
|
+
- What's explicitly out of scope for this session
|
|
193
|
+
- When you'll stop and ship
|
|
194
|
+
|
|
195
|
+
**Mid-Session Check:**
|
|
196
|
+
Every 30-60 minutes, ask your AI:
|
|
197
|
+
"Are we building the right thing today, or are we adding scope?"
|
|
198
|
+
|
|
199
|
+
If the answer is "adding scope," stop. Commit what you have. Start fresh.
|
|
200
|
+
|
|
201
|
+
**Session End Check:**
|
|
202
|
+
Before closing an AI coding session:
|
|
203
|
+
- What did we actually build vs. what we planned?
|
|
204
|
+
- Did scope expand? Why?
|
|
205
|
+
- What should we defer to the next session?
|
|
206
|
+
|
|
207
|
+
**Daily AI Check:**
|
|
208
|
+
At the end of each day working with AI assistants:
|
|
209
|
+
```
|
|
210
|
+
1. Features completed today: [list]
|
|
211
|
+
2. Scope additions today: [list]
|
|
212
|
+
3. Was each addition validated? [yes/no]
|
|
213
|
+
4. Tomorrow's focus: [single item]
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
**Sprint Planning Guard Rails:**
|
|
217
|
+
- No new features mid-sprint without removing something
|
|
218
|
+
- Capacity for bug fixes and debt paydown (20% minimum)
|
|
219
|
+
- Clear definition of done for each item
|
|
220
|
+
|
|
221
|
+
**Stakeholder Management:**
|
|
222
|
+
Create a single source of truth for scope decisions:
|
|
223
|
+
|
|
224
|
+
```markdown
|
|
225
|
+
## Scope Decision Log
|
|
226
|
+
|
|
227
|
+
| Date | Request | Source | Decision | Rationale | Trade-off |
|
|
228
|
+
|------|---------|--------|----------|-----------|-----------|
|
|
229
|
+
| 2025-01-15 | Add export to PDF | PM | Deferred v2 | Not core to MVP | Would delay launch 2 weeks |
|
|
230
|
+
| 2025-01-16 | Dark mode | User feedback | Approved | User research shows demand | Removed social sharing |
|
|
231
|
+
| 2025-01-17 | Add caching layer | Claude | Deferred | Premature optimization | Stay focused on core feature |
|
|
232
|
+
| 2025-01-17 | Refactor to hooks | Cursor | Rejected | Works fine as is | Technical scope creep |
|
|
233
|
+
```
|
|
234
|
+
|
|
235
|
+
**Agents as Stakeholders:**
|
|
236
|
+
AI coding agents are now stakeholders in your project. They have opinions. They make suggestions. Treat them like any other stakeholder:
|
|
237
|
+
|
|
238
|
+
- **Log agent suggestions** in your scope decision log with the agent name as source
|
|
239
|
+
- **Apply the same rigor** you would to a PM or executive request
|
|
240
|
+
- **Agents optimize for different things** (code quality, patterns, completeness) than you might need right now
|
|
241
|
+
- **"The agent suggested it" is not a valid reason** to add a feature
|
|
242
|
+
|
|
243
|
+
Common agent-driven scope creep patterns:
|
|
244
|
+
- "Let me also add error handling for edge cases you haven't hit yet"
|
|
245
|
+
- "This would be cleaner with a refactor"
|
|
246
|
+
- "You should probably add tests for this"
|
|
247
|
+
- "Let me add TypeScript types for these additional scenarios"
|
|
248
|
+
|
|
249
|
+
Each of these might be good ideas. None of them are your current scope unless you decide they are.
|
|
250
|
+
|
|
251
|
+
## Recovery: You're Already Bloated
|
|
252
|
+
|
|
253
|
+
If feature creep has already happened:
|
|
254
|
+
|
|
255
|
+
**Step 1: Audit Current Features**
|
|
256
|
+
- List every feature
|
|
257
|
+
- Check usage data for each
|
|
258
|
+
- Identify features with <5% engagement
|
|
259
|
+
|
|
260
|
+
**Step 2: Categorize**
|
|
261
|
+
- Core: Users can't accomplish their goal without it
|
|
262
|
+
- Supporting: Makes core better
|
|
263
|
+
- Peripheral: Nice but not necessary
|
|
264
|
+
- Bloat: Nobody uses it
|
|
265
|
+
|
|
266
|
+
**Step 3: Remove or Hide**
|
|
267
|
+
- Deprecate bloat with warning period
|
|
268
|
+
- Move peripheral features behind advanced settings
|
|
269
|
+
- Communicate changes clearly to users
|
|
270
|
+
|
|
271
|
+
**Step 4: Prevent Recurrence**
|
|
272
|
+
- Add feature creep checks to your PR/code review process
|
|
273
|
+
- Require usage metrics before features graduate from beta
|
|
274
|
+
- Build feature flags so you can easily remove experiments
|
|
275
|
+
|
|
276
|
+
## Quick Reference Commands
|
|
277
|
+
|
|
278
|
+
When reviewing any feature request, ask:
|
|
279
|
+
|
|
280
|
+
```
|
|
281
|
+
1. "What user problem does this solve?"
|
|
282
|
+
2. "What's the smallest version we could ship?"
|
|
283
|
+
3. "What are we NOT building to make room for this?"
|
|
284
|
+
4. "How will we measure success?"
|
|
285
|
+
5. "What happens if we never build this?"
|
|
286
|
+
```
|
|
287
|
+
|
|
288
|
+
If you can't answer these clearly → Do not proceed.
|
|
289
|
+
|
|
290
|
+
## The Golden Rule
|
|
291
|
+
|
|
292
|
+
**Ship something small that works. Then iterate based on real usage data.**
|
|
293
|
+
|
|
294
|
+
Users don't remember features. They remember whether your product solved their problem.
|
|
295
|
+
|
|
296
|
+
Every feature you don't build is:
|
|
297
|
+
- Time you get back
|
|
298
|
+
- Bugs you don't have to fix
|
|
299
|
+
- Documentation you don't have to write
|
|
300
|
+
- Code you don't have to maintain
|
|
301
|
+
- Confusion you don't add
|
|
302
|
+
|
|
303
|
+
The best products aren't the ones with the most features. They're the ones that do the right things exceptionally well.
|
|
304
|
+
|
|
305
|
+
---
|
|
306
|
+
|
|
307
|
+
*"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."* - Antoine de Saint-Exupéry
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: convex
|
|
3
|
+
displayName: Convex Development
|
|
4
|
+
description: Umbrella skill for all Convex development patterns. Routes to specific skills like convex-functions, convex-realtime, convex-agents, etc.
|
|
5
|
+
version: 1.0.0
|
|
6
|
+
author: Convex
|
|
7
|
+
tags: [convex, backend, database, realtime]
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Convex Development Skills
|
|
11
|
+
|
|
12
|
+
This is an index skill for Convex development. Use specific skills for detailed guidance:
|
|
13
|
+
|
|
14
|
+
## Core Development
|
|
15
|
+
|
|
16
|
+
| Skill | Command | Use When |
|
|
17
|
+
|-------|---------|----------|
|
|
18
|
+
| Functions | `/convex-functions` | Writing queries, mutations, actions |
|
|
19
|
+
| Schema | `/convex-schema-validator` | Defining database schemas and validators |
|
|
20
|
+
| Realtime | `/convex-realtime` | Building reactive subscriptions |
|
|
21
|
+
| HTTP Actions | `/convex-http-actions` | Webhooks and HTTP endpoints |
|
|
22
|
+
|
|
23
|
+
## Data & Storage
|
|
24
|
+
|
|
25
|
+
| Skill | Command | Use When |
|
|
26
|
+
|-------|---------|----------|
|
|
27
|
+
| File Storage | `/convex-file-storage` | File uploads, serving, storage |
|
|
28
|
+
| Migrations | `/convex-migrations` | Schema evolution, data backfills |
|
|
29
|
+
|
|
30
|
+
## Advanced Patterns
|
|
31
|
+
|
|
32
|
+
| Skill | Command | Use When |
|
|
33
|
+
|-------|---------|----------|
|
|
34
|
+
| Agents | `/convex-agents` | Building AI agents with tools |
|
|
35
|
+
| Cron Jobs | `/convex-cron-jobs` | Scheduled background tasks |
|
|
36
|
+
| Components | `/convex-component-authoring` | Reusable Convex packages |
|
|
37
|
+
|
|
38
|
+
## Security
|
|
39
|
+
|
|
40
|
+
| Skill | Command | Use When |
|
|
41
|
+
|-------|---------|----------|
|
|
42
|
+
| Security Check | `/convex-security-check` | Quick security audit checklist |
|
|
43
|
+
| Security Audit | `/convex-security-audit` | Deep security review |
|
|
44
|
+
|
|
45
|
+
## Guidelines
|
|
46
|
+
|
|
47
|
+
| Skill | Command | Use When |
|
|
48
|
+
|-------|---------|----------|
|
|
49
|
+
| Best Practices | `/convex-best-practices` | General patterns and guidelines |
|
|
50
|
+
|
|
51
|
+
## Quick Start
|
|
52
|
+
|
|
53
|
+
For most tasks:
|
|
54
|
+
1. Start with `/convex-best-practices` for general patterns
|
|
55
|
+
2. Use `/convex-functions` for writing backend logic
|
|
56
|
+
3. Use `/convex-schema-validator` for data modeling
|
|
57
|
+
4. Use specific skills as needed for your use case
|
|
58
|
+
|
|
59
|
+
## Documentation
|
|
60
|
+
|
|
61
|
+
- Primary: https://docs.convex.dev
|
|
62
|
+
- LLM-optimized: https://docs.convex.dev/llms.txt
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-agents
|
|
3
|
+
displayName: Convex Agents
|
|
3
4
|
description: Building AI agents with the Convex Agent component including thread management, tool integration, streaming responses, RAG patterns, and workflow orchestration
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-best-practices
|
|
3
|
+
displayName: Convex Best Practices
|
|
3
4
|
description: Guidelines for building production-ready Convex apps covering function organization, query patterns, validation, TypeScript usage, error handling, and the Zen of Convex design philosophy
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-component-authoring
|
|
3
|
+
displayName: Convex Component Authoring
|
|
3
4
|
description: How to create, structure, and publish self-contained Convex components with proper isolation, exports, and dependency management
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-cron-jobs
|
|
3
|
+
displayName: Convex Cron Jobs
|
|
3
4
|
description: Scheduled function patterns for background tasks including interval scheduling, cron expressions, job monitoring, retry strategies, and best practices for long-running tasks
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-file-storage
|
|
3
|
+
displayName: Convex File Storage
|
|
3
4
|
description: Complete file handling including upload flows, serving files via URL, storing generated files from actions, deletion, and accessing file metadata from system tables
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-functions
|
|
3
|
+
displayName: Convex Functions
|
|
3
4
|
description: Writing queries, mutations, actions, and HTTP actions with proper argument validation, error handling, internal functions, and runtime considerations
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-http-actions
|
|
3
|
+
displayName: Convex HTTP Actions
|
|
3
4
|
description: External API integration and webhook handling including HTTP endpoint routing, request/response handling, authentication, CORS configuration, and webhook signature validation
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-migrations
|
|
3
|
+
displayName: Convex Migrations
|
|
3
4
|
description: Schema migration strategies for evolving applications including adding new fields, backfilling data, removing deprecated fields, index migrations, and zero-downtime migration patterns
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-realtime
|
|
3
|
+
displayName: Convex Realtime
|
|
3
4
|
description: Patterns for building reactive apps including subscription management, optimistic updates, cache behavior, and paginated queries with cursor-based loading
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-schema-validator
|
|
3
|
+
displayName: Convex Schema Validator
|
|
3
4
|
description: Defining and validating database schemas with proper typing, index configuration, optional fields, unions, and migration strategies for schema changes
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-security-audit
|
|
3
|
+
displayName: Convex Security Audit
|
|
3
4
|
description: Deep security review patterns for authorization logic, data access boundaries, action isolation, rate limiting, and protecting sensitive operations
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|
|
@@ -1,5 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name:
|
|
2
|
+
name: convex-security-check
|
|
3
|
+
displayName: Convex Security Check
|
|
3
4
|
description: Quick security audit checklist covering authentication, function exposure, argument validation, row-level access control, and environment variable handling
|
|
4
5
|
version: 1.0.0
|
|
5
6
|
author: Convex
|