agentleFS
aboio-labsaboio-labs/aboio-skills/skills/api-gleam/SKILL.md

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.

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
  1. Very specific:

    Follow references/token-efficiency.md rules: When reviewing or writing API code:

    line 63
  2. Distinctive:

    Use git diff --name-only to scope reviews to changed handler/router files only

    line 66
  3. Distinctive:

    Read targeted line ranges around Grep matches, not entire controllers

    line 67
  4. Very specific:

    Read individual reference files in references/ for detailed explanations and Gleam examples.

    line 71
  5. Distinctive:

    When to apply and edge cases

    line 76

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

REST/JSON API Patterns (Gleam + Wisp)

Design patterns and conventions for building consistent, maintainable REST APIs in Gleam.

Stack Context

LayerToolRole
LanguageGleamBackend application code
HTTP serverMistErlang-based HTTP server
FrameworkWispRequest/response helpers, middleware
JSONgleam/jsonJSON encoding
Decodinggleam/decodeType-safe JSON decoding
Errorserror_responseCentralized 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

PriorityCategoryImpactPrefix
1Route DesignHIGHroute-
2Error HandlingCRITICALerror-
3SerializationHIGHjson-
4PaginationMEDIUMpagination-
5Request DispatchMEDIUMdispatch-
6Router PatternsMEDIUMrouter-

Token Efficiency

Follow references/token-efficiency.md rules. When reviewing or writing API code:

  1. Grep for specific patterns (e.g., error_response.handle, wisp.require_json, hal.page) instead of reading all handler files
  2. Use git diff --name-only to scope reviews to changed handler/router files only
  3. 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.md
  • references/validation-errors.md

Serialization (json-):

  • references/json-serialization.md

Pagination (pagination-):

  • references/pagination-hal.md

Request Dispatch (dispatch-):

  • references/query-dispatch.md
  • references/body-dispatch.md

Router Patterns (router-):

  • references/spa-routing.md
  • references/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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.