pitch

name: "pitch"

description: "Propose a code change for review before implementation, once its scope is understood."

createdAt: "2026-09-11T18:46:00.191374+00:00"

repoUrl: "https://skillz.supply/skills/did:plc:xbtmt2zjwlrfegqvch7fboei/skills.pitch/SKILL.md"

# pitch

Use this workflow for a requested proposal or a change that needs design agreement.
Inspect the relevant code and resolve material uncertainty before proposing a design.
For an explicit pitch-only request, the proposal is the deliverable; wait for approval
before implementing. Do not insert a new approval gate into work already authorized.

Explain the requested outcome, the current behavior, and the proposed change. Use a
compact call-flow diff when it clarifies the design:

```diff
 POST /widgets
   └─ createWidget()
      ├─ validateInput()
-     ├─ writeLegacyWidget()
+     ├─ widgetRepository.insert()
+     └─ publishWidgetCreated()
```

Show the important contract changes, affected modules, and reasons for new structure.
Reuse existing owners and maintained SDKs; justify replacing their contracts,
transport, or authentication with custom implementations. Scale detail to the change:
reviewers need to assess behavior and tradeoffs, not approve every helper name.

Identify compatibility effects, verification, and what completion means. Keep unrelated
work outside the proposal. During implementation, explain material changes to the
agreed scope; ask again only when they require a new decision or authorization.

Pitch