openapi-to-application-code
Generate a complete, production-ready application from an OpenAPI specification
Works with
--- name: openapi-to-application-code description: Generate a complete, production-ready application from an OpenAPI specification license: MIT --- # Generate Application from OpenAPI Spec Your goal is to generate a complete, working application from an OpenAPI specification using the active framework's conventions and best practices. ## Input Requirements 1. **OpenAPI Specification**: Provide either: - A URL to the OpenAPI spec (e.g., `https://api.example.com/openapi.json`) - A local file path to the OpenAPI spec - The full OpenAPI specification content pasted directly 2. **Project Details** (if not in spec): - Project name and description - Target framework and version - Package/namespace naming conventions - Authentication method (if not specified in OpenAPI) ## Generation Process ### Step 1: Analyze the OpenAPI Specification - Validate the OpenAPI spec for completeness and correctness - Identify all endpoints, HTTP methods, request/response schemas - Extract authentication requirements and security schemes - Note data model relationships and constraints - Flag any ambiguities or incomplete definitions ### Step 2: Design Application Architecture - Plan directory structure appropriate for the framework - Identify controller/handler grouping by resource or domain - Design service layer organization for business logic - Plan data models and entity relationships - Design configuration and initialization strategy ### Step 3: Generate Application Code - Create project structure with build/package configuration files - Generate models/DTOs from OpenAPI schemas - Generate controllers/handlers with route mappings - Generate service layer with business logic - Generate repository/data access layer if applicable - Add error handling, validation, and logging - Generate configuration and startup code ### Step 4: Add Supporting Files - Generate appropriate unit tests for services and controllers - Create README with setup and running instructions - Add .gitignore and environment configuration templates - Generate API documentation files - Create example requests/integration tests ## Output Structure The generated application will include: ``` project-name/ ├── README.md # Setup and usage instructions ├── [build-config] # Framework-specific build files (pom.xml, build.gradle, package.json, etc.) ├── src/ │ ├── main/ │ │ ├── [language]/ │ │ │ ├── controllers/ # HTTP endpoint handlers │ │ │ ├── services/ # Business logic │ │ │ ├── models/ # Data models and DTOs │ │ │ ├── repositories/ # Data access (if applicable) │ │ │ └── config/ # Application configuration │ │ └── resources/ # Configuration files │ └── test/ │ ├── [language]/ │ │ ├── controllers/ # Controller tests │ │ └── services/ # Service tests │ └── resources/ # Test configuration ├── .gitignore ├── .env.example # Environment variables template └── docker-compose.yml # Optional: Docker setup (if applicable) ``` ## Best Practices Applied - **Framework Conventions**: Follows framework-specific naming, structure, and patterns - **Separation of Concerns**: Clear layers with controllers, services, and repositories - **Error Handling**: Comprehensive error handling with meaningful responses - **Validation**: Input validation and schema validation throughout - **Logging**: Structured logging for debugging and monitoring - **Testing**: Unit tests for services and controllers - **Documentation**: Inline code documentation and setup instructions - **Security**: Implements authentication/authorization from OpenAPI spec - **Scalability**: Design patterns support growth and maintenance ## Next Steps After generation: 1. Review the generated code structure and make customizations as needed 2. Install dependencies according to framework requirements 3. Configure environment variables and database connections 4. Run tests to verify generated code 5. Start the development server 6. Test endpoints using the provided examples ## Questions to Ask if Needed - Should the application include database/ORM setup, or just in-memory/mock data? - Do you want Docker configuration for containerization? - Should authentication be JWT, OAuth2, API keys, or basic auth? - Do you need integration tests or just unit tests? - Any specific database technology preferences? - Should the API include pagination, filtering, and sorting examples?
More API Design skills
lark-event
larksuite/cli
Lark/Feishu real-time event listening / subscribing / consuming: stream events as NDJSON via `lark-cli event consume <EventKey>` (covers IM messages/reactions/chat changes, Approval status changes, Task updates, VC meeting started/joined/ended, Minutes generated, Whiteboard updated, etc.). Use for Lark bots, real-time message processing, long-running subscribers, streaming webhook/push handlers. Supports `--max-events` / `--timeout` bounded runs and a stderr ready-marker contract — designed for AI agents running as subprocesses.
lark-contact
larksuite/cli
飞书 / Lark 通讯录:按姓名 / 邮箱解析成 open_id,或按 open_id 反查姓名 / 部门 / 邮箱 / 联系方式 / 个人状态 / 签名,以及按关键词搜索当前用户可见的机器人 / 智能体(agent)。当用户提到一个名字要下一步发消息 / 排日程,或拿到 open_id 想查具体信息时使用。不负责部门树遍历、按部门列员工、组织架构图,这类需求走原生 OpenAPI。
lark-openapi-explorer
larksuite/cli
飞书/Lark 原生 OpenAPI 探索:从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足,需要查找并调用原生飞书 OpenAPI 时使用。

