菜单
Verify that all project services (API and Web) build successfully. Check compilation errors, type errors, and lint warnings. Use before running tests, before deployment, after code changes, and on resume. Trigger when build verification, compilation check, or pre-test validation is needed.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create Domain-Driven Design proposals from product specs or brownfield extraction outputs. Define bounded contexts, ubiquitous language, aggregates, context maps, and Mermaid-based domain and database diagrams. Use when domain boundaries, business rules, or data ownership need to be explicit before planning, implementation, or modernization.
Identify, research, and resolve every technology needed by the application. Evaluate data storage, caching, AI/ML, authentication, real-time, search, infrastructure, and library choices. Use when resolving technology decisions, comparing framework options, or documenting the tech stack before implementation begins.
Write application code to make failing tests pass using contract-driven, slice-based architecture. Implement API slice (Express routes, services), Web slice (Next.js pages, components), and Integration slice (wire API+Web via Aspire). Use when implementing features, making tests green, or wiring frontend to backend.
Generate a Product Requirements Document (PRD) from analyzed codebase extraction data. Reverse-engineer the product vision, user personas, and feature list from what the code actually implements. Used in brownfield workflows to produce a spec2cloud-compatible PRD that drives downstream FRD generation, increment planning, and implementation.
Review PRDs and FRDs through product and technical lenses. Identify gaps, ambiguities, edge cases, and conflicts. Break approved PRDs into FRDs. Use when refining specifications, reviewing PRDs, creating FRDs, or validating spec quality before downstream phases.
Extract API contracts from existing code — routes, endpoints, request/response schemas, authentication patterns. Output in the same OpenAPI-compatible YAML format used by the contract-generation skill. Pure extraction — document the API surface that exists in code without judgment or suggestions.
| name | build-check |
| description | Verify that all project services (API and Web) build successfully. Check compilation errors, type errors, and lint warnings. Use before running tests, before deployment, after code changes, and on resume. Trigger when build verification, compilation check, or pre-test validation is needed. |
Verify builds succeed before proceeding with tests or deployment.
| Service | Source Build | Docker Build |
|---|---|---|
| API (TypeScript) | cd src/api && npm run build | docker build -f src/api/Dockerfile . |
| Web (Next.js) | cd src/web && npm run build | docker build -f src/web/Dockerfile . |
azure.yaml or scan src/ for service directoriesService: <name>
Status: PASS | FAIL
Errors: <count>
Warnings: <count>
Details:
- <file>:<line> <error message>
output: 'standalone' in next.config.tsThe orchestrator MUST verify ALL of the following before marking build-check as complete:
BLOCKING: A build-check with any FAIL or incomplete service means the codebase is not ready for testing or deployment. The orchestrator must fix build errors before proceeding.