Menu
Apply content-type schemas designed during brainstorming to Strapi via strapi-mcp. Phase 2 execution — no re-design.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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.