dust-tt/dust
Overview
This skill enforces a critical rule: never introduce breaking changes to the private API without explicit user approval. It warns the user, explains what will break, and pauses to request confirmation before any breaking modification proceeds. The skill also suggests backwards-compatible alternatives when possible.
How this skill works
The skill inspects edits to API-related code and type schemas, focusing on route handlers, exported request/response types, validation schemas, and middleware that affects API behavior. If a change would alter response shapes, authentication, HTTP methods, headers, or error formats in a way that forces consumers to change their code, the skill halts the change and emits a clear warning message describing the impact. Implementation proceeds only after the user explicitly approves the breaking change.
When to use it
- Any edits under front/pages/api/** or front/app/api/**
- Modifying exported request/response type definitions used by routes
- Changing validation schemas (Zod, etc.) used by API handlers
- Refactoring middleware that affects API contracts or authentication
- Altering HTTP methods, status codes, headers, or error formats
Best practices
- Always ask: will this require existing consumers to update their code?
- Prefer additive changes (add optional fields) over destructive ones
- If a rename or type change is needed, keep the old field and add the new one, then deprecate the old one
- Provide clear impact statements listing affected endpoints and required consumer updates
- Never proceed with an identified breaking change until you receive explicit user approval
Example use cases
- Changing a response type field from string to number — skill detects break and requests approval
- Removing or renaming an endpoint — skill warns and lists affected routes
- Updating authentication requirements — skill halts and asks for explicit consent
- Altering a validation schema to require a previously optional field — skill suggests default values or deprecation
- Adding a new optional field — skill allows the change as backwards-compatible
FAQ
Any modification that forces existing API consumers to update code: removing/renaming endpoints or fields, changing field types or required-ness, changing auth rules, HTTP methods, status codes, headers, or error formats.
Can I make additive changes without approval?
Yes. Additive, backwards-compatible changes (for example adding optional response fields) are allowed and do not require explicit approval.
What should the warning message include?
A clear notice that a breaking change was detected, a concise explanation of what specifically breaks, a list of impacted endpoints and consumer changes required, and options to proceed, find an alternative, or cancel.
2 skills
This skill prevents breaking private API changes by enforcing explicit user approval and guiding safe, backwards-compatible alternatives.
This skill helps you access Dust agents to read, create, and manage information and tasks across projects, Slack, Notion, or Drive.
