Menú
Use when a microservice's generated files are corrupted, outdated, or need to be rebuilt from scratch.
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.
TRIGGER when the user asks to upgrade the project to a newer or the latest version of Microbus, or to update the framework. Each Microbus release ships this one self-contained skill; it applies that release's single-version migration, then chains to the next release's copy of this skill until the target version is reached.
TRIGGER when user asks to create, scaffold, or initialize a new microservice.
How to choose the hostname of a new Microbus microservice. Referenced by the add-microservice and add-sql-microservice scaffolding skills (and, through their delegation to add-microservice, by add-python-microservice and import-openapi-microservice). Consult it whenever a microservice's hostname is being chosen.
Performs an architectural review of a microservice-based system built on the Microbus framework. Covers only cross-cutting, cross-microservice concerns - service boundaries, the dependency graph, coupling, cross-service consistency, data ownership, workflow composition, edge security, and system operations. Anything judgeable inside a single microservice directory belongs to the review-microservice skill and is out of scope here. Produces a structured report with findings and recommendations.
Reviews the microservices touched by a set of changes - by default the whole current feature branch versus its merge-base with main, plus any uncommitted work. Runs the review-microservice skill on each changed microservice and the review-architecture skill scoped to those microservices and their graph neighbors, then consolidates one report. Use before merging a branch or before committing working-tree changes.
Performs a thorough review of a single Microbus microservice. Checks for completeness, framework compliance, code quality, security, test coverage, documentation, API design, and data access performance. Produces a structured report with findings and recommendations.
Basado en la clasificación ocupacional SOC
| name | regenerate-boilerplate |
| description | Use when a microservice's generated files are corrupted, outdated, or need to be rebuilt from scratch. |
CRITICAL: Read and analyze this microservice before starting. Do NOT explore or analyze other microservices. The instructions in this skill are self-contained to this microservice.
The generated boilerplate is a pure projection of myserviceapi/definition.go. Rebuilding it is a single deterministic command - there is nothing to reconstruct by hand. The hand-written source (definition.go, sibling type files, service.go, service_test.go, resources/embed.go) is the source of truth and is never overwritten.
Copy this checklist and track your progress:
Regenerating boilerplate:
- [ ] Step 1: Read local CLAUDE.md file
- [ ] Step 2: Regenerate the boilerplate
- [ ] Step 3: Vet and test
CLAUDE.md FileRead the local CLAUDE.md file in the microservice's directory. It contains microservice-specific instructions that should take precedence over global instructions.
Confirm the hand-written source is intact: myserviceapi/definition.go (the spec), service.go (the handlers), and resources/embed.go. If resources/embed.go is missing, recreate it per the add-microservice skill. If definition.go itself is corrupted or missing, this skill cannot help - the boilerplate is derived from it, not the other way around.
From the microservice's directory, run the generator. It overwrites myserviceapi/client.go, intermediate.go, mock.go, mock_test.go, and manifest.yaml from definition.go, regardless of their prior state.
go run github.com/microbus-io/fabric/cmd/genservice .
Run go vet ./... from the project root to verify the microservice compiles, then go test ./... (or the microservice's own package) to verify its tests pass. Fix any issues before finishing.