prototype-to-backend

English | 简体中文

prototype-to-backend is an AI Skill for converting product prototypes and requirement materials into backend development artifacts.

It is designed for backend engineers using Codex. The skill focuses on business meaning, domain modeling, PostgreSQL/Xinchuang-friendly database design, REST API design, workflows, state machines, permissions, development planning, open questions, and design review. It does not generate frontend code by default.

What This Skill Does

• Analyzes Axure HTML prototype packages, online prototype URLs, PRDs, and screenshots.
• Extracts user roles, module trees, menu trees, page inventories, form fields, search conditions, table columns, buttons, and backend operations.
• Produces backend-ready artifacts for system overview, domain model, database schema, API design, state machine, workflow, permissions, delivery plan, and product confirmation questions.
• Uses Chinese-first bilingual templates for Chinese teams, while preserving English technical names for implementation.
• Preserves Chinese business terms and provides English technical names for entities, APIs, permissions, statuses, and tables.
• Treats database table design as a first-class backend initialization artifact.
• Defaults to PostgreSQL/Xinchuang-friendly table design and avoids physical foreign keys unless explicitly requested.
• Can align artifacts to a ts-boot backend project when that stack is specified, including business-module-first package layout, api/application/domain/infrastructure layering, R<T>, PageQuery, PageData<T>, MyBatis-Plus conventions, and ts-boot-project-init readiness.
• Separates schema/project initialization from non-standard CRUD or command API initialization: project-init.yml is for tables and project scaffolding, while api-init.yml is for explicit business actions such as submit, approve, reject, revoke, import, export, sync, and batch operations.
• When the target backend uses ts-boot-project-init, emits standalone project-init.yml and api-init.yml files in the output directory root so they can be used directly by the initializer.
• Generates smart-doc friendly comment sources: table comments, column comments, PostgreSQL COMMENT ON DDL, endpoint descriptions, request field descriptions, and response field descriptions. When smart-doc is used instead of Swagger, prefer Javadoc-ready descriptions and do not require Swagger annotations.
• Builds a Prototype Evidence Index before design so important backend conclusions can be traced to prototype pages, labels, interactions, or PRD sections.
• Separates confirmed facts, assumptions, and unresolved questions.
• Includes a built-in grill-me style review phase. It first generates backend artifacts, then challenges them to find missing APIs, weak data models, incomplete workflows, permission gaps, and ambiguous business rules.

Supported Inputs

• Axure HTML prototype packages.
• Online prototype links.
• Product requirement documents.
• Business process documents.
• Screenshots as a fallback when richer artifacts are unavailable.

Generated Outputs

Templates use Chinese-first bilingual headings and table columns, such as 系统概览 / System Overview and 字段 / Field.

For small prototypes, single-module requests, or quick analysis, the skill uses Backend Init Mode by default:

• 00-prototype-evidence-summary.json
• 01-system-overview.md
• 02-domain-model.md
• 03-database-design.md
• 04-api-design.md
• 09-open-questions.md
• 10-design-review.md

When the target backend uses ts-boot, 03-database-design.md should include table conventions and a project-init.yml draft suitable for tools/ts-boot-project-init, while 02-domain-model.md and 04-api-design.md should align to the module-first package structure. If the prototype contains non-standard CRUD or business command actions, 04-api-design.md should also include an api-init.yml draft and project-init.yml should reference it through apiSpecPath.

For ts-boot-project-init, the skill should also write these standalone files beside the design documents:

• project-init.yml
• api-init.yml when non-standard CRUD or command APIs are identified, or when API skeleton initialization is explicitly requested.

Example output layout:

backend-design/
|-- 00-prototype-evidence-summary.json
|-- 01-system-overview.md
|-- 02-domain-model.md
|-- 03-database-design.md
|-- 04-api-design.md
|-- 09-open-questions.md
|-- 10-design-review.md
|-- project-init.yml
`-- api-init.yml

For large prototypes, formal handoff, or explicit full-analysis requests, it uses Full Mode:

• 00-prototype-evidence-summary.json
• 01-system-overview.md
• 02-domain-model.md
• 03-database-design.md
• 04-api-design.md
• 05-state-machine.md
• 06-workflow.md
• 07-permission-model.md
• 08-development-plan.md
• 09-open-questions.md
• 10-design-review.md

Installation

npx skills@latest add https://github.com/TwistedRiCen/prototype-to-backend --skill prototype-to-backend -g -a codex -y

The -a codex option installs the skill only for Codex, avoiding unrelated agent targets.

Updating

When this repository publishes a new version, the recommended update method is to reinstall the Codex-only global copy:

npx skills@latest add https://github.com/TwistedRiCen/prototype-to-backend --skill prototype-to-backend -g -a codex -y

This overwrites the existing Codex installation and avoids failures caused by old multi-agent installation records.

Useful related commands:

# Check installed skills
npx skills@latest list

# Check for available updates
npx skills@latest check

# Optional: try the generic global updater
npx skills@latest update -g prototype-to-backend

# Optional: update all global skills
npx skills@latest update -g

If npx skills@latest update -g prototype-to-backend fails with a generic Failed to update prototype-to-backend message, use the recommended Codex-only reinstall command above.

Codex usually detects skill changes automatically. If the updated skill does not appear, restart Codex.

Uninstalling

To remove the Codex global installation:

npx skills@latest remove prototype-to-backend -g -a codex -y

If you previously installed this skill for multiple agents, remove only the Codex copy with the command above, or replace codex with the agent name you want to remove.

Usage Examples

Use prototype-to-backend to analyze the Axure HTML package in ./prototype. Use Backend Init Mode unless the scope clearly requires full output. Generate Chinese-first bilingual backend artifacts for system overview, domain model, PostgreSQL/Xinchuang-friendly database design without physical foreign keys, API design, open questions, and design review. Do not generate frontend code.

Use prototype-to-backend to analyze this prototype for a ts-boot backend project. Prioritize project-initialization-ready database table design for PostgreSQL, avoid physical foreign keys, use ts-boot convention columns (`deleted`, `tenant_id`, `create_time`, `update_time`, `create_by`, `update_by`), and align domain/API artifacts to `<module>.api`, `<module>.application`, `<module>.domain`, and `<module>.infrastructure.persistence`. Generate both the Markdown design and a standalone project-init.yml file for ts-boot-project-init.

Use prototype-to-backend to analyze this approval prototype for ts-boot. Generate PostgreSQL table design and a standalone project-init.yml file for schema initialization. Also identify non-standard CRUD actions such as submit, approve, reject, revoke, transfer, import, and export, then generate a standalone api-init.yml file, include the same draft in 04-api-design.md, and reference it from project-init.yml through apiSpecPath. Put uncertain status, permission, idempotency, and transaction rules into Open Questions.

Analyze this Chinese OA approval PRD from a backend perspective. Preserve Chinese business terms, add English technical names, and separate confirmed facts from assumptions and open questions.

The prototype URL is https://example.com/prototype. Inspect the sitemap, pages, forms, tables, buttons, interactions, and notes, then produce a full backend handoff with all 10 artifacts for Spring Boot REST implementation.

Recommended Workflow

1. Provide the richest available source material, preferably an Axure HTML package or prototype URL.
2. Ask the agent to inventory pages, menus, forms, lists, buttons, statuses, and interactions first.
3. Use Backend Init Mode by default; switch to Full Mode for large prototypes or explicit full-analysis requests.
4. If the target stack is ts-boot, provide the project constraints or reference paths so the agent can align table conventions, packages, DTOs, services, and generated-code expectations.
5. For ts-boot-project-init, review 03-database-design.md and the standalone project-init.yml; review 04-api-design.md and the standalone api-init.yml. Use project-init.yml for schema/project initialization and api-init.yml for non-standard CRUD or command API skeletons.
6. Generate the selected backend artifacts.
7. Run the built-in grill-me style review phase and generate 10-design-review.md.
8. Review 09-open-questions.md and 10-design-review.md with product owners, business stakeholders, and backend engineers.
9. Update the artifacts after answers and design fixes are confirmed.
10. Use 08-development-plan.md to split backend implementation tasks when Full Mode is used.

Repository Structure

prototype-to-backend/
|-- README.md
|-- README.zh-CN.md
|-- LICENSE
`-- skills/
    `-- prototype-to-backend/
        |-- SKILL.md
        |-- agents/
        |   `-- openai.yaml
        |-- templates/
        |   |-- 01-system-overview-template.md
        |   |-- 02-domain-model-template.md
        |   |-- 03-database-design-template.md
        |   |-- 04-api-design-template.md
        |   |-- 05-state-machine-template.md
        |   |-- 06-workflow-template.md
        |   |-- 07-permission-model-template.md
        |   |-- 08-development-plan-template.md
        |   |-- 09-open-questions-template.md
        |   `-- 10-design-review-template.md
        `-- examples/
            |-- axure-html-package-example.md
            |-- oa-approval-example.md
            |-- procurement-system-example.md
            `-- design-review-example.md

Limitations

• The skill cannot infer hidden business rules that are not present in the prototype or requirement materials.
• Ambiguous rules must be documented as assumptions or open questions.
• Screenshot-only analysis is less reliable than HTML prototype or PRD analysis.
• Generated database and API designs are implementation-ready drafts, not final business approval.
• The design review phase finds risks from the available artifacts; unresolved product or business rules still require stakeholder confirmation.

License

MIT License. See LICENSE.