菜单
TRIGGER when user asks to remove, delete, or drop an endpoint, config, metric, ticker, or event from a microservice.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | remove-feature |
| description | TRIGGER when user asks to remove, delete, or drop an endpoint, config, metric, ticker, or event from a microservice. |
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.
CRITICAL: A feature lives by hand in myserviceapi/definition.go (its define.* var and In/Out structs), service.go (its handler), and service_test.go (its test). Remove it from those, then run cmd/genservice.
Copy this checklist and track your progress:
Removing a feature of a microservice:
- [ ] Step 1: Remove the declaration from definition.go
- [ ] Step 2: Remove the handler from service.go
- [ ] Step 3: Remove the test from service_test.go
- [ ] Step 4: Remove unused custom types
- [ ] Step 5: Generate the boilerplate
- [ ] Step 6: Housekeeping
Search for MARKER: FeatureName within the microservice's directory to locate the feature's hand-written code. The markers in the generated files can be ignored - those files are regenerated in Step 5.
definition.goDelete the feature's define.* var (the whole var FeatureName = define.X{ ... } block) and its In/Out struct types from myserviceapi/definition.go. These all carry // MARKER: FeatureName.
service.goDelete the feature's handler in service.go (carrying // MARKER: FeatureName):
OnChangedFeatureName method; an observable metric has an OnObserveFeatureName method.service.go; also remove any call sites that trigger the event or record the metric.service_test.goDelete the feature's test function (e.g. TestMyService_FeatureName) from service_test.go.
If the removed feature used non-primitive custom types defined in the myserviceapi directory, and those types are no longer used elsewhere by the microservice, remove their definitions.
From the microservice's directory, run the generator. It regenerates client.go, intermediate.go, mock.go, mock_test.go, and manifest.yaml without the removed feature.
go run github.com/microbus-io/fabric/cmd/genservice .
Then verify the microservice compiles with go vet ./... from the project root.
Follow the housekeeping skill.
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.