菜单
TRIGGER when user asks to change the signature, route, method, arguments, or return type of an existing endpoint, config, metric, or ticker.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | modify-feature |
| description | TRIGGER when user asks to change the signature, route, method, arguments, or return type of an existing endpoint, config, metric, or ticker. |
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 is declared in myserviceapi/definition.go (its define.* var, plus In/Out structs for endpoints) and implemented in service.go (its handler). Edit those, then run cmd/genservice.
CRITICAL: Keep the // MARKER: MyFunction comments when editing.
Copy this checklist and track your progress:
Modifying a feature of a microservice:
- [ ] Step 1: Read local CLAUDE.md file
- [ ] Step 2: Identify the feature
- [ ] Step 3: Consult the corresponding "add" skill
- [ ] Step 4: Apply the change
- [ ] Step 5: Generate the boilerplate
- [ ] Step 6: Update the tests
- [ ] Step 7: Housekeeping
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.
Find the feature's define.* var in myserviceapi/definition.go. Its type determines which "add" skill governs its shape:
define.* kind | Feature type | Corresponding skill |
|---|---|---|
define.Function | Functional endpoint | add-function |
define.Web | Web handler | add-web |
define.Config | Configuration property | add-config |
define.Ticker | Ticker | add-ticker |
define.Metric | Metric | add-metric |
define.OutboundEvent | Outbound event | add-outbound-event |
define.InboundEvent | Inbound event | add-inbound-event |
define.Task | Task endpoint | add-task |
define.Workflow | Workflow graph | add-workflow |
Read the SKILL.md of the corresponding "add" skill identified in the previous step. It defines what the define.* var, the In/Out structs, and the handler should look like. Use it as your reference throughout.
Edit definition.go and/or service.go according to the kind of change. The generated files are NOT touched here.
service.go.define.* var in definition.go. Add or remove the field's import if its type requires one (e.g. "time").definition.go (add/remove fields and their jsonschema tags), add or remove sibling complex-type files in the api package as needed, and update the handler signature in service.go.define.* var, its In/Out structs, and their // MARKER comments in definition.go; rename the handler and its // MARKER in service.go. The generated files pick up the new name on regeneration.These scopes can overlap; handle a rename-plus-signature change in a single pass.
From the microservice's directory, run the generator. It regenerates client.go, intermediate.go, mock.go, mock_test.go, and manifest.yaml from the updated definition.go.
go run github.com/microbus-io/fabric/cmd/genservice .
Then verify the microservice compiles with go vet ./... from the project root.
Update service_test.go to match the change: edit test cases that call the feature with the old signature, behavior, or name, and rename the test function (e.g. TestMyService_MyFunction becomes TestMyService_NewName) on a rename.
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.