api-design

REST API design best practices. Use when designing APIs, choosing status codes, or creating endpoints.

Repository: Tibsfox/gsd-skill-creator
Letzte Quellaktivität: 25. April 2026 um 21:14
Erkannte Sprache von SKILL.md: Englisch
Sterne: 69
Forks: 9

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.

npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill api-design

Der Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.

Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md

Quellanweisungen · Schreibgeschützte Vorschau

Zurück zur Suche Zurück zur Installation

goal-ambiguity-gate

Use the moment a request is underspecified and you are about to act on an ASSUMED goal. Enumerate the candidate goals the request could mean, project the action or artifact each one implies, and check whether they diverge: if two or more plausible goals lead to materially different actions or artifacts, ask exactly ONE targeted clarifying question; otherwise proceed on the most-likely goal and state the assumption in one line. Clarification is an evidence-producing action, not a delay — but one question, never an interrogation. Distinct from gsd-spec-phase (GSD-phase-bound, emits a heavy SPEC.md) and intent-router (fetch strategy, not goal disambiguation). Backed by agent goal-state inference (arxiv 2606.16813v1). Triggers on acting under an assumed goal when the request admits more than one materially different reading.

2026-07-19

memory-hubness-gate

Use at write time to vector/embedding memory — Grove content-addressed insertion, chroma/pgvector upserts, memory-consolidation promoting session traces to MEMORY.md, or embedding externally-ingested content. Scores each candidate record against a fixed panel of sentinel queries and quarantines any record that would become the nearest neighbor of too many unrelated queries — a hub — whether from adversarial poisoning or accidental over-generality. This is the memory-record-side sibling of skill-injection-guardian (file-side) and the write-side complement of memory-use-warrant (read-side). Quarantine, never silently drop; a human reviews. Backed by the admission-time hubness gate (arxiv 2606.19692v1). Triggers on inserting into vector memory, consolidating memory, and embedding stranger content.

2026-07-19

memory-use-warrant

Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response.

2026-07-19

Alle aus diesem Repository ansehen

name	api-design
description	REST API design best practices. Use when designing APIs, choosing status codes, or creating endpoints.
version	1.0.0
format	"2025-10-02T00:00:00.000Z"
triggers	["designing APIs, choosing status codes, or creating endpoints"]
updated	"2026-04-25T00:00:00.000Z"
status	ACTIVE

REST API Design

Endpoint Rules

Nouns, not verbs: /users not /getUsers — HTTP method is the verb
Plural nouns: /users, /orders — consistent collections
Kebab-case: /user-profiles not /user_profiles
Max 2 levels nesting: /users/{id}/orders — deeper use query params
No trailing slashes, no extensions

HTTP Methods

Method	Purpose	Idempotent
GET	Retrieve	Yes
POST	Create	No
PUT	Replace entire resource	Yes
PATCH	Partial update	No
DELETE	Remove	Yes

Status Codes

Code	Use When
200	Success with body
201	Resource created (+ Location header)
204	Success, no body (DELETE)
400	Malformed request
401	Not authenticated
403	Authenticated but forbidden
404	Not found
409	Conflict (duplicate)
422	Valid syntax, invalid semantics
429	Rate limited

Error Format

{"error": {"code": "VALIDATION_ERROR", "message": "...", "details": [], "request_id": "req_..."}}

Key Rules

Always paginate lists (cursor-based preferred, max page size enforced)
Never expose sequential IDs — use UUIDs
Auth credentials in headers, never URLs
Return 400 for unknown parameters (catch typos)
Include request_id in every response

api-design

Quellinformationen

Installationsoptionen

Quelldateien prüfen

Mehr aus diesem Repository

REST API Design

Endpoint Rules

HTTP Methods

Status Codes

Error Format

Key Rules

Mehr aus diesem Repository

REST API Design

Endpoint Rules

HTTP Methods

Status Codes

Error Format

Key Rules