Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

tech-stack-design

Estrellas1

Forks0

Actualizado3 de junio de 2026 a las 01:02

Produce evidence-backed technology stack options and architecture decision records for Java Spring Boot and frontend projects. Use when selecting JDK, Spring Boot, Spring Cloud, Spring Cloud Alibaba, database, cache, messaging, API documentation, frontend framework, build tools, logging, exception handling, validation, ORM, migration, observability, code quality tools, or when validating dependency/version compatibility.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

liuqi1024

liuqi1024/matrix-boot

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

Explorador de archivos

3 archivos

SKILL.md

readonly

Más de este repositorio

mismo repositorio

project-guide

liuqi1024/matrix-boot

Guide a software project through staged engineering delivery from business discovery to architecture, technology selection, detailed requirements, API/database design, integration testing, performance testing, and release readiness. Use when a user wants project lifecycle guidance, staged delivery governance, engineering process coaching, or wants an agent to decide what project artifact or review gate should come next.

2026-06-031

architecture-design

liuqi1024/matrix-boot

Design business architecture and technical architecture for staged software projects, including Mermaid diagrams, module boundaries, data flows, deployment view, integration points, project structure, and architecture risks. Use when moving from business context to architecture, when documenting module/service boundaries, or when reviewing whether architecture is ready for API/database design and implementation.

2026-06-031

implementation-verification

liuqi1024/matrix-boot

Verify generated or modified application code with reproducible build, test, runtime, browser, API, console, and network checks. Use after code generation or bug fixes, especially for web UI login flows, forms, dashboards, frontend/backend integration, local dev servers, and claims that implementation is complete or tested.

2026-06-031

integration-test-guide

liuqi1024/matrix-boot

Guide integration testing, performance testing, release readiness, and quality gates for staged software projects. Use when planning or reviewing integration tests, test data, environment dependencies, API test collections, performance tests, release checks, rollback plans, or project acceptance gates.

2026-06-031

api-db-design

liuqi1024/matrix-boot

Guide API contract and database design for staged software projects. Use when designing REST APIs, OpenAPI plans, database tables, SQL migration direction, seed data, initial data, error codes, pagination, permissions, audit fields, API documentation, or when reviewing whether API/database artifacts are ready for development.

2026-06-021

frontend-design-guide

liuqi1024/matrix-boot

Guide frontend user experience and visual design before code generation. Use when choosing UI style, generating DESIGN.md, adapting external design references such as awesome-design-md, selecting layout density, component behavior, design tokens, frontend page standards, or preventing generic AI-looking web pages.

2026-06-021

name

tech-stack-design

description

Tech Stack Design

Purpose

Use this skill to produce a defensible technology stack decision. The output must be based on project constraints plus Context7 or official documentation, not model memory.

Preconditions

Before recommending a stack, confirm that the project has at least:

Business domain and target users.
System type: internal admin, public web, mobile/client, integration service, batch/data processing, API platform, or microservice system.
Rough functional scope.
Rough non-functional needs: scale, concurrency, latency, availability, data volume, security, compliance.
Enterprise constraints: existing JDK, Spring Boot line, database, middleware, deployment platform, team skill, legacy integration.

If these are missing, ask clarification questions first.

Evidence Rules

First use Context7 for current official or versioned documentation.
If Context7 cannot resolve the library, use official documentation via web search.
If neither source is available, mark the option as needs-confirmation and do not present it as a recommendation.
For every recommended version, record the evidence source, compatibility constraints, and risk.
Do not recommend the newest version by default. Prefer supported, mature, ecosystem-compatible versions.
Do not select JDK 17, JDK 21, Spring Boot 3.x, Spring Boot 4.x, or any major version just because it is common or modern. Present supported options and ask the user to confirm enterprise constraints.
Do not collapse technology selection into one pre-filled stack. Present choices by dimension, with a recommended default and alternatives.
Native choice widgets are client-dependent. When asking the user to choose between stack options, show a numbered list and ask for the number or option name if no structured choice UI is available.

Selection Workflow

Identify project type and business scale.
Identify runtime and organizational constraints: JDK baseline, deployment platform, database, middleware, compliance, team familiarity, release timeline.
Build a compatibility matrix before recommending:
- JDK.
- Spring Boot.
- Spring Framework.
- Spring Cloud.
- Spring Cloud Alibaba.
- MyBatis Plus or other data access library.
- springdoc-openapi or API documentation tooling.
- frontend framework and build tool.
Identify component-level choices and present options before finalizing:
- Build tool and dependency management.
- Web model.
- Logging and trace correlation.
- Global exception handling.
- Validation.
- ORM/data access.
- Connection pool.
- Database migration.
- Cache.
- Messaging.
- Registry/discovery and config center.
- Gateway/API entry.
- Resilience/circuit breaking.
- Security/authentication.
- Observability.
- Code quality and architecture checks.
Produce 2-3 viable stack baselines, then ask the user to confirm the recommended path if enterprise constraints are uncertain. Use numbered options in non-UI clients.
Output an ADR-style decision record.

Choice Fallback Format

When presenting stack candidates, use a fallback like:

Choose a stack option:
1. Legacy-compatible baseline - only when enterprise constraints require older versions
2. Conservative supported baseline - mature Spring Boot line with broad ecosystem compatibility
3. Current major baseline - Spring Boot 4.x or latest major only when ecosystem compatibility is proven

Reply with a number or option name.

Never hard-code Spring Boot 3.x in the option label unless the compatibility matrix has already shown why 3.x is the recommended line for this project.

Java Stack Decision Points

For Java/Spring projects, cover at least:

JDK: supported LTS options and enterprise baseline, such as 17, 21, or newer runtime-supported options.
Spring Boot: supported stable lines and ecosystem compatibility. Include Spring Boot 4.x as a candidate when official support and dependency compatibility can be proven.
Spring Cloud: only if distributed service patterns are actually needed.
Spring Cloud Alibaba: only when Nacos/Sentinel/Seata/Alibaba ecosystem is required.
Web framework: Spring MVC or WebFlux, based on actual concurrency and programming model needs.
Build tool: Maven or Gradle.
Data access: MyBatis Plus, MyBatis, Spring Data JPA, jOOQ, or direct SQL, based on team and domain complexity.
Connection pool: HikariCP default, Druid when monitoring or enterprise convention requires it, or team-standard pool.
Database migration: Flyway, Liquibase, or team-standard migration process.
API documentation: springdoc-openapi and optional Apifox collaboration.
Validation: Jakarta Bean Validation.
Exception model: global error response and business error code standard.
Logging: SLF4J with Logback default, Log4j2 when enterprise policy requires it, trace id, and structured logging needs.
Security: Spring Security, gateway auth, SSO/OIDC, JWT, or enterprise IAM.
Registry/discovery: Nacos, Consul, Eureka, Kubernetes service discovery, or none.
Config center: Nacos Config, Spring Cloud Config, Kubernetes ConfigMap/Secret, or none.
Gateway/API entry: Spring Cloud Gateway, Apache APISIX, Nginx, Kong, or none.
Resilience: Sentinel, Resilience4j, or team-standard policy.
Distributed transaction: Seata only when distributed transaction requirements justify it.
Observability: Actuator, metrics, tracing, log aggregation.
Testing: JUnit, Spring Boot Test, Testcontainers where applicable.
Quality: formatter, Checkstyle/PMD/SpotBugs, ArchUnit.
Upgrade governance: OpenRewrite where useful.

Java Component Selection Checklist

Before final ADR, present a compact component checklist:

Confirm Java stack components:
1. Build tool: Maven / Gradle
2. JDK line: 17 / 21 / newer supported runtime
3. Spring Boot line: 3.5.x / 4.x / existing enterprise line
4. Architecture style: monolith / modular monolith / microservices
5. Web model: Spring MVC / WebFlux
6. Data access: MyBatis Plus / MyBatis / Spring Data JPA / jOOQ / direct SQL
7. Connection pool: HikariCP / Druid / team standard
8. Migration: Flyway / Liquibase / manual/team process
9. API docs: springdoc-openapi / Apifox collaboration / none
10. Logging: SLF4J+Logback / Log4j2 / team standard
11. Security: Spring Security / SSO-OIDC / JWT / gateway auth / none for prototype
12. Cache: Redis / none / team standard
13. Messaging: Kafka / RocketMQ / RabbitMQ / none
14. Registry/config: Nacos / Consul / Eureka / Kubernetes / none
15. Gateway: Spring Cloud Gateway / APISIX / Nginx / Kong / none
16. Resilience: Sentinel / Resilience4j / none
17. Observability: Actuator+Micrometer / OpenTelemetry / log-only / team standard
18. Quality: formatter / Checkstyle / PMD / SpotBugs / ArchUnit

Reply with changes, constraints, or "use recommended defaults".

Compatibility Gate

Before finalizing, explicitly check known compatibility risks:

Spring Boot major version versus third-party autoconfigure APIs.
MyBatis Plus compatibility with the selected Spring Boot line.
Spring Cloud and Spring Cloud Alibaba version mapping.
Java baseline required by Spring Boot and dependencies.
Jakarta EE namespace changes for Spring Boot 3+.
Native image or AOT constraints if requested.

If any key dependency is incompatible, reject that stack option.

Project Structure Decision

Project structure is primarily owned by architecture-design. When it is missing, ask the user to confirm or route back to architecture before implementation.

Confirm or reference:

Repository mode: default backend + frontend monorepo for V1.
Backend root path, default backend/.
Frontend root path, default frontend/.
Java groupId and basePackage; both require user confirmation.
Service/module naming.
Documentation path, default docs/.
Database script path, default scripts/db/.
Database migration path, default scripts/db/migration/.
Seed data path, default scripts/db/seed/.
Integration test script path, default scripts/test/integration/.
Performance test script path, default scripts/perf/.
Deployment/config path, default scripts/deploy/.
Raw verification output path, default reports/verification/.
Raw integration test output path, default reports/integration/.
Raw performance test output path, default reports/performance/.
Root README and .gitignore expectations.

Record this in docs/01-architecture/project-structure.md or the equivalent legacy artifact.

Output Format

Produce:

Context summary.
Candidate stack table.
Compatibility matrix.
Recommended stack.
Component selection table.
Project structure reference or unresolved structure decisions.
Evidence sources.
Rejected alternatives and why.
Risks and mitigations.
Follow-up decisions.

Use references/java-stack-evidence.md for the evidence checklist.

After producing the technology stack decision or ADR, stop and request explicit user review. Do not proceed to detailed requirements, API/database design, dependency scaffolding, or code generation until the user approves the decision.