help

Reflection-first problem solving methodology for Convex development. Use before implementing any solution to ensure proper root cause analysis, 98% code confidence, and minimal change scope.

607 stars

Best use case

help is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Reflection-first problem solving methodology for Convex development. Use before implementing any solution to ensure proper root cause analysis, 98% code confidence, and minimal change scope.

Teams using help should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/help/SKILL.md --create-dirs "https://raw.githubusercontent.com/waynesutton/markdown-site/main/.claude/help/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/help/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How help Compares

Feature / AgenthelpStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Reflection-first problem solving methodology for Convex development. Use before implementing any solution to ensure proper root cause analysis, 98% code confidence, and minimal change scope.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Core Development Guidelines Skill

Deep reflection and problem-solving methodology for full-stack Convex development.

## 1. Reflect deeply before acting

Before implementing any solution, follow this process:

1. **Reflect**: Carefully consider why the current implementation may not be working
2. **Identify**: What's missing, incomplete, or incorrect based on the request
3. **Theorize**: Different possible sources of the problem or areas requiring updates
4. **Distill**: Narrow down to 1-2 most probable root causes or solutions
5. **Proceed**: Only move forward after clear understanding

**Never assume.** If anything is unclear, ask questions and clarify.

## 2. Convex implementation guidelines

### Core principles

**Direct mutation pattern:**
- Use direct mutation calls with plain objects
- Create dedicated mutation functions that map form fields to database fields
- Form field names should exactly match database field names when applicable

**Best practices:**
- Patch directly without reading first
- Use indexed queries for ownership checks (not `ctx.db.get()`)
- Make mutations idempotent with early returns
- Use timestamp-based ordering for new items
- Use `Promise.all()` for parallel independent operations to avoid write conflicts

### Essential documentation

**Functions:**
- Mutations: https://docs.convex.dev/functions/mutation-functions
- Queries: https://docs.convex.dev/functions/query-functions
- Validation: https://docs.convex.dev/functions/validation
- General: https://docs.convex.dev/functions

**Core concepts:**
- Zen of Convex: https://docs.convex.dev/understanding/zen
- TypeScript best practices: https://docs.convex.dev/understanding/best-practices/typescript
- Best practices: https://docs.convex.dev/understanding/best-practices/
- Schema validation: https://docs.convex.dev/database/schemas

**Authentication:**
- WorkOS AuthKit: https://workos.com/docs/authkit/vanilla/nodejs
- WorkOS docs: https://workos.com/docs
- Convex + WorkOS setup: https://docs.convex.dev/auth/authkit/

## 3. Change scope and restrictions

### What to update

- Update Convex schema if needed
- Only update files directly necessary to fix the original request
- When tasks touch changelog.md, changelog page, or files.md:
  - Run `git log --date=short` to check commit history
  - Set release dates to match real commit timeline
  - No placeholders or future months

### What NOT to change

- Do not change UI, layout, design, or color styles unless specifically instructed
- Preserve all admin dashboard sections and frontend components unless explicitly told to update
- Never remove sections, features, or components unless directly requested

## 4. UI/UX guidelines

### Design system compliance

**For pop-ups, alerts, modals, warnings, notifications, and confirmations:**
- Always follow the site's existing design system
- Never use browser default pop-ups
- Use site design system components only

### Follow Vercel guidelines

https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/refs/heads/main/AGENTS.md

## 5. Documentation policy

**IMPORTANT:** Do NOT create documentation files unless explicitly instructed.

**Banned unless requested:**
- README.md
- CONTRIBUTING.md
- SUMMARY.md
- USAGE_GUIDELINES.md

You may include a brief summary in responses, but don't create separate documentation files.

**Formatting rules:**
- Never use emojis in readme or app unless instructed

## 6. Code confidence requirement

**98% confidence rule:**

Don't write any code until you're very confident (98% or more) in what needs to be done.

If unclear, ask for more information.

## Quick reference checklist

Before writing code:
- [ ] Have I reflected on the root cause?
- [ ] Do I understand what's actually broken?
- [ ] Am I 98% confident in the solution?
- [ ] Am I only changing files that need to change?
- [ ] Am I preserving existing UI/features not mentioned?
- [ ] Am I using the site's design system (not browser defaults)?
- [ ] Am I following Convex mutation best practices?
- [ ] Have I checked the relevant docs?

When uncertain:
- [ ] Ask clarifying questions
- [ ] Don't assume
- [ ] Reference documentation
- [ ] Narrow down to 1-2 most likely solutions

Related Skills

migration-helper

607
from waynesutton/markdown-site

Plan and execute Convex schema migrations safely, including adding fields, creating tables, and data transformations. Use when schema changes affect existing data.

Update project docs

607
from waynesutton/markdown-site

Use this skill after completing any feature, fix, or migration to keep the three core project tracking files in sync.

robel-auth

607
from waynesutton/markdown-site

Integrate and maintain Robelest Convex Auth in apps by always checking upstream before implementation. Use when adding auth setup, updating auth wiring, migrating between upstream patterns, or troubleshooting @robelest/convex-auth behavior across projects.

Create a PRD

607
from waynesutton/markdown-site

Use this skill before any multi-file feature, architectural decision, or complex bug fix.

convex-self-hosting

607
from waynesutton/markdown-site

Integrate Convex static self hosting into existing apps using the latest upstream instructions from get-convex/self-hosting every time. Use when setting up upload APIs, HTTP routes, deployment scripts, migration from external hosting, or troubleshooting static deploy issues across React, Vite, Next.js, and other frontends.

convex-return-validators

607
from waynesutton/markdown-site

Guide for when to use and when not to use return validators in Convex functions. Use this skill whenever the user is writing Convex queries, mutations, or actions and needs guidance on return value validation. Also trigger when the user asks about Convex type safety, runtime validation, AI-generated Convex code, Convex AI rules, Convex security best practices, or when they're debugging return type issues in Convex functions. Trigger this skill when users mention "validators", "returns", "return type", or "exact types" in the context of Convex development. Also trigger when writing or reviewing Convex AI rules or prompts that instruct LLMs how to write Convex code.

convex-doctor

607
from waynesutton/markdown-site

Run convex-doctor static analysis, interpret findings, and fix issues across security, performance, correctness, schema, and architecture categories. Use when running convex-doctor, fixing convex-doctor warnings or errors, improving the convex-doctor score, or when asked about Convex code quality, static analysis, or linting Convex functions.

write

607
from waynesutton/markdown-site

Writing style guide for technical content, social media, blog posts, READMEs, git commits, and developer documentation. Optimized to avoid AI detection patterns. Use when writing any content beyond code.

workflow

607
from waynesutton/markdown-site

Project workflow for PRDs, task tracking, changelog sync, and documentation updates. Use for any non-trivial task that spans multiple steps, touches several files, changes architecture, or needs project tracking updates. Also activates with @update to sync task.md, changelog.md, and files.md after completing work.

sec-check

607
from waynesutton/markdown-site

Security review checklist for Convex functions, auth logic, public queries, admin routes, webhooks, uploads, and AI-generated code. Use when reviewing code that touches user data, PII, or access control.

schema-builder

607
from waynesutton/markdown-site

Design and generate Convex database schemas with proper validation, indexes, and relationships. Use when creating schema.ts or modifying table definitions.

real-time-backend

607
from waynesutton/markdown-site

Build reactive, type-safe, production-grade backends. ALWAYS use this skill when the user asks to build, plan, design, or implement backend features, APIs, data models, server logic, database schemas, web apps, full stack apps, or mobile apps. This includes planning and architecture discussions.