Menu
Apply content-type schemas designed during brainstorming to Strapi via strapi-mcp. Phase 2 execution — no re-design.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Execute page designs from the design doc — compose shadcn components and wire to generated API types. Phase 4 execution, no re-design.
Use when you have a spec or requirements for a multi-step task, before touching code
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
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.
| name | backend-schema |
| description | Apply content-type schemas designed during brainstorming to Strapi via strapi-mcp. Phase 2 execution — no re-design. |
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.
cd backend && npm run develop)STRAPI_BASE_URL, STRAPI_API_TOKEN, STRAPI_ADMIN_EMAIL, STRAPI_ADMIN_PASSWORDdocs/metaforge/specs/ with a complete content type specstrapi-mcp uses a two-phase staging pattern for all schema changes. Never skip the staging phase.
schema_readschema_write (action: create/update/delete)schema_stash viewschema_stash discard and re-stageschema_commit to apply all staged changes in one batchschema_read that all types are applied correctlyRead the design doc from docs/metaforge/specs/. Extract the content type spec: display names, API IDs, fields with types, relations, components, and descriptions.
Call strapi-mcp schema_read with resource: "content-type" to see existing types. Identify what needs to be created vs. what already exists.
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.
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?
Call schema_commit. Strapi will restart. Wait for confirmation.
schema_read to confirm all types are present and correcthttp://localhost:1337/adminAll files under backend/ are managed by strapi-mcp. Never edit them directly. Always use strapi-mcp tools for schema changes.
If npx gitnexus analyze has been run on the project, the risk analysis gates in executing-plans will check schema change impact before commit.