api-gleam
Skill3 starsChanged 9 months agoMITView on GitHub
REST/JSON API design patterns for Gleam + Wisp + Mist. Use this skill when designing routes, error responses, pagination, request dispatch, or middleware composition.
In this repository7 other files it gives its agents.
- skills/pg-gleam/CLAUDE.mdCLAUDE.md
- frontend-testingSkill
- gleam-backendSkill
- gleamSkill
- lustreSkill
- pg-gleamSkill
- tddSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 63
Follow
references/token-efficiency.mdrules: When reviewing or writing API code: - Distinctive: line 66
Use git diff --name-only to scope reviews to changed handler/router files only
- Distinctive: line 67
Read targeted line ranges around Grep matches, not entire controllers
- Very specific: line 71
Read individual reference files in references/ for detailed explanations and Gleam examples.
- Distinctive: line 76
When to apply and edge cases
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
REST/JSON API Patterns (Gleam + Wisp)
Design patterns and conventions for building consistent, maintainable REST APIs in Gleam.
Stack Context
| Layer | Tool | Role |
| Language | Gleam | Backend application code |
| HTTP server | Mist | Erlang-based HTTP server |
| Framework | Wisp | Request/response helpers, middleware |
| JSON | gleam/json | JSON encoding |
| Decoding | gleam/decode | Type-safe JSON decoding |
| Errors | error_response | Centralized error → HTTP response |
Core Principles
- REST nouns, not verbs — routes use plural nouns and sub-resources
- Canonical error shape — every error response uses
{"error": "Kind", "message": "text"} - Centralized error handling — never build ad-hoc JSON error responses in handlers
- Consistent serialization — shared helpers for timestamps, metadata, optional fields
- Middleware as closures — auth → rate limit → handler, each layer wraps the next
When to Apply
Reference these patterns when:
- Designing new API routes or renaming existing ones
- Returning error responses from handlers or middleware
- Implementing paginated list endpoints
- Serializing domain types to JSON
- Consolidating multiple GET or POST endpoints
- Handling validation errors vs decode errors
- Setting up SPA routing alongside API routes
- Composing middleware (auth, rate limiting, usage tracking)
Reference Categories by Priority
| Priority | Category | Impact | Prefix |
| 1 | Route Design | HIGH | route- |
| 2 | Error Handling | CRITICAL | error- |
| 3 | Serialization | HIGH | json- |
| 4 | Pagination | MEDIUM | pagination- |
| 5 | Request Dispatch | MEDIUM | dispatch- |
| 6 | Router Patterns | MEDIUM | router- |
Token Efficiency
Follow references/token-efficiency.md rules. When reviewing or writing API code:
- Grep for specific patterns (e.g.,
error_response.handle,wisp.require_json,hal.page) instead of reading all handler files - Use
git diff --name-onlyto scope reviews to changed handler/router files only - Read targeted line ranges around Grep matches, not entire controllers
How to Use
Read individual reference files in references/ for detailed explanations and Gleam examples. Each reference contains:
- Brief explanation of the pattern and why it matters
- Incorrect example showing the anti-pattern
- Correct example showing the recommended approach
- When to apply and edge cases
Available References
Route Design (route-):
references/route-naming.md
Error Handling (error-, validation-):
references/error-responses.mdreferences/validation-errors.md
Serialization (json-):
references/json-serialization.md
Pagination (pagination-):
references/pagination-hal.md
Request Dispatch (dispatch-):
references/query-dispatch.mdreferences/body-dispatch.md
Router Patterns (router-):
references/spa-routing.mdreferences/middleware-composition.md
Decision Tree
"I need to..."
- ...name a new route →
route-naming.md - ...return an error from a handler →
error-responses.md - ...distinguish 400 vs 422 →
validation-errors.md - ...add pagination to a list endpoint →
pagination-hal.md - ...serialize timestamps or metadata →
json-serialization.md - ...merge multiple GET endpoints →
query-dispatch.md - ...dispatch POST by body type →
body-dispatch.md - ...serve SPA alongside API →
spa-routing.md - ...compose auth + rate limiting →
middleware-composition.md
9 reference files across 6 categories
References
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

