Menu
Use when a microservice's generated files are corrupted, outdated, or need to be rebuilt from scratch.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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.
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.