Generate a fully-typed TypeScript API client from Strapi content-type schemas and route contracts. Use after backend-schema when you need to create or regenerate the frontend API layer.

2026-05-132

executing-plans

LeonardoTan19/metaforge

Use when you have a written implementation plan to execute in a separate session with review checkpoints

2026-05-132

frontend-page

LeonardoTan19/metaforge

Execute page designs from the design doc — compose shadcn components and wire to generated API types. Phase 4 execution, no re-design.

2026-05-132

writing-plans

LeonardoTan19/metaforge

Use when you have a spec or requirements for a multi-step task, before touching code

2026-05-132

requesting-code-review

LeonardoTan19/metaforge

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

2026-05-122

scaffold-project

LeonardoTan19/metaforge

Scaffold a new fullstack project using scaffold-mcp. Use when the user wants to create a new Strapi+React project or start building a fullstack application.

2026-05-122

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

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

Phase B: Commit

Run schema_commit to apply all staged changes in one batch
Strapi restarts automatically — wait for confirmation
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.