# 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.

- Skill: `waynesutton/help` (Agent Skill)
- Install (CLI): `npx skillmds@latest add waynesutton/help`
- Raw SKILL.md: https://api.skillmd.com/api/skills/waynesutton/help/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: waynesutton (https://skillmd.com/u/waynesutton)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/waynesutton/help

---


# 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