---
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`.

```shell
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.