modify-feature

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.

Workflow

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

Step 1: Read Local CLAUDE.md File

Read the local CLAUDE.md file in the microservice's directory. It contains microservice-specific instructions that should take precedence over global instructions.

Step 2: Identify the Feature

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

Step 3: Consult the Corresponding "Add" Skill

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.

Step 4: Apply the Change

Edit definition.go and/or service.go according to the kind of change. The generated files are NOT touched here.

• Implementation only - edit the handler body in service.go.
• Property change (route, method, required claims, time budget, load balancing, config default/validation/secret/callback, metric buckets/labels, ticker interval) - edit the corresponding field on the define.* var in definition.go. Add or remove the field's import if its type requires one (e.g. "time").
• Signature change (arguments added, removed, renamed, or retyped) - edit the In/Out structs in 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.
• Rename - rename the 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.

Step 5: Generate the Boilerplate

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.

Step 6: Update the Tests

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.

Step 7: Housekeeping

Follow the housekeeping skill.