RonanCodes/skills/create-crm

Create CRM

The CRM-domain generator. Two halves, matching Brian Casel's method:

1. Shape — produce a PRD with the real-estate CRM entity model, pipeline stages, roles, and compliance tables already filled in. Mostly confirm-or-correct, not a blank-slate interview, because the domain is known. The value of this skill over generic /ro:write-a-prd is that the Dutch real-estate model in reference.md is pre-loaded.
2. Build — slice the PRD into dependency-ordered milestones and drive the build through the local factory, keeping Casel's per-milestone log discipline.

This is a component. /ro:brief-to-live is the umbrella; it calls create-crm in its build phase when the brief is a CRM. create-crm also runs standalone.

Internal-tool stance (the load-bearing product call)

Casel's core idea: an internal tool can hard-code the fields and pipeline stages it needs instead of building a configuration UI for them. So create-crm hard-codes the real-estate stages and the dossier field set (see reference.md). It does NOT build a generic field-builder or per-tenant pipeline editor. A customer who needs a variant gets a code change in their deployment, not a settings screen. (Open: if Makely's own customers each want their own pipeline, that becomes per-deployment hard-coding, still not a multi-tenant field UI. Confirm before assuming multi-tenant.)

First question: greenfield or brownfield

This branch changes everything downstream, so resolve it first (ask if --mode not given).

• Greenfield — a fresh project from /ro:new-app or /ro:new-tanstack-app. The dossier-first schema is written clean from reference.md. No migration.
• Brownfield — an existing app with a contact-centric spine (this is Makely, the dress-rehearsal case). The work is a migration + extension, not a build from zero. First step before any schema change: reconcile the live schema. Run /ro:supabase reconcile (drizzle-kit pull) to introspect the live DB into schema.ts, because CRM tables were often applied via direct-host DDL and never entered the repo. Also read any crm_rebuild_* / sync RPCs (they live only in the DB). Only then plan the dossier migration as a normal reviewable drizzle-kit generate.

Phase: shape (the PRD)

Run Casel's shape steps, each a confirm-or-correct loop. Pre-fill every step from reference.md so Ronan is editing a strong draft, not answering from scratch. Use AskUserQuestion per decision; loop until each is locked.

1. Overview — restate the CRM in one paragraph; confirm the internal-tool stance.
2. In-scope feature list — the buyer-backbone set (see reference.md): dossier 360, pipeline/kanban, activity timeline, tasks/follow-ups, document vault, mortgage / insurance / notary tracking, multi-channel intake, CRM-as-tools.
3. Out-of-scope list — write it explicitly. This is what stops the build dreaming up extras. Default out: generic field-builder, multi-tenant pipeline editor, anything gated on a paid resource (see the repo's blockers), BSN storage.
4. Internal-vs-SaaS calls — confirm hard-coded stages + dossier fields.
5. Data model — name the headline entities only, dossier-first. In brownfield, the model section MUST start from the reconciled live schema, not the idealized model; map each idealized entity onto the existing table it extends (reference.md has the mapping for Makely).
6. Compliance baked in day one — append-only audit_events, document-vault blob/meta split (BSN-free), per-source external-ID map, consent tracking. Retrofitting these is painful, so they go in the PRD's data model, not a later milestone.
7. Per-feature drill-down — cycle each feature, decide granular in/out.
8. Milestones — break into ~5 buildable milestones in dependency order (schema + dossier migration → dossier 360 → pipeline → timeline/tasks → document vault → compliance/cases). Can't build the board before deals; can't build the timeline before its source rows carry the dossier id.

Output the PRD. Default to /ro:write-a-prd (GitHub parent issue per feature) so it plugs into the factory. If Ronan prefers Casel's exact artefact, also write _build_plan/PRD.html (visual, scannable) and treat _build_plan/ as deletable scaffolding once shipped.

Phase: build

1. Slice — /ro:slice-into-issues turns each parent into vertical-slice child issues (one PR each, ready-for-agent), in milestone/dependency order.
2. Build — hand to the factory: /ro:ultracode (the brief-to-live build engine), or /ro:planner-worker / /ro:ralph for a smaller drain. Each slice gets a fresh context, opens one PR, is reviewed, merged, deployed.
3. Milestone-log discipline — keep Casel's per-milestone log as the close-with-summary comment on each shipped issue (Shipped / Decisions made during implementation that weren't pre-specified / Tests + suite result / Follow-ups). The next slice's fresh agent reads it as the baton.
4. Regression gate — the repo's pre-push gate (forced build + lint + test) is the "all green before moving on" rule. Don't move to the next milestone on a red gate.

Reuse what already exists (brownfield, esp. Makely)

reference.md documents the existing plumbing so the build extends it instead of rebuilding it: the single tools.ts tool layer (CRM ops become ToolSpec entries that work across chat + voice + MCP for free), role guards, and the append-only activities timeline. New dossier tools follow the existing ToolSpec + ROLE_TOOLS pattern.

State + resume

Write phase state alongside the PRD so --resume re-enters mid-flow (shape decisions locked so far, the greenfield/brownfield call, which milestone the build reached).

Related

• /ro:brief-to-live — the umbrella that calls this for CRM briefs.
• /ro:supabase reconcile — the brownfield first step (drizzle-kit pull).
• /ro:write-a-prd, /ro:slice-into-issues, /ro:ultracode — the factory this hands to.
• reference.md — the baked-in Dutch real-estate dossier-first domain model.