backend-schema

name	backend-schema
description	Apply content-type schemas designed during brainstorming to Strapi via strapi-mcp. Phase 2 execution — no re-design.

Backend Schema Execution

Apply the schema specification from the design doc to Strapi using strapi-mcp.

This skill EXECUTES. It does NOT design. Load the design doc from `docs/metaforge/specs/` first. Only ask the user about gaps or ambiguities in the spec — never re-design content types, fields, or relations that are already specified.

When to Use

• Phase 2 of a fullstack feature cycle — after scaffold-project, before api-client-gen
• User asks to apply or sync schema changes defined in a design doc

Prerequisites

• Strapi dev server running (cd backend && npm run develop)
• Environment variables: STRAPI_BASE_URL, STRAPI_API_TOKEN, STRAPI_ADMIN_EMAIL, STRAPI_ADMIN_PASSWORD
• Design doc exists at docs/metaforge/specs/ with a complete content type spec
• Project scaffolded via scaffold-project

Two-Phase Staging Model

strapi-mcp uses a two-phase staging pattern for all schema changes. Never skip the staging phase.

Phase A: Stage

1. Read the current schema with schema_read
2. Parse the content type spec from the design doc
3. Stage each change with schema_write (action: create/update/delete)
4. Review staged changes with schema_stash view
5. If anything looks wrong, discard with schema_stash discard and re-stage

Phase B: Commit

1. Run schema_commit to apply all staged changes in one batch
2. Strapi restarts automatically — wait for confirmation
3. Verify with schema_read that all types are applied correctly

Process

Step 1: Load Design Doc

Read the design doc from docs/metaforge/specs/. Extract the content type spec: display names, API IDs, fields with types, relations, components, and descriptions.

Step 2: Read Current Schema

Call strapi-mcp schema_read with resource: "content-type" to see existing types. Identify what needs to be created vs. what already exists.

Step 3: Stage All Changes

For each content type, relation, or field change in the spec, call schema_write with the appropriate action. Stage everything before committing — schema changes often have interdependencies.

Step 4: Review Staged Changes

Call schema_stash with operation: "view" to see everything that's pending. Validate against the design doc: are all fields present? Types match? Relations correct?

Step 5: Commit

Call schema_commit. Strapi will restart. Wait for confirmation.

Step 6: Verify

• Call schema_read to confirm all types are present and correct
• Check that all descriptions are filled
• Verify Strapi admin panel loads at http://localhost:1337/admin

File Protection

All files under backend/ are managed by strapi-mcp. Never edit them directly. Always use strapi-mcp tools for schema changes.

GitNexus

If npx gitnexus analyze has been run on the project, the risk analysis gates in executing-plans will check schema change impact before commit.