Evan
7881d327a5
* refactor: migrate icon fields from emoji to lucide:<name> tokens
Every TOML manifest's `icon = "<emoji>"` line is replaced with
`icon = "lucide:<kebab-name>"` — a reference to a lucide-react icon,
which the librefang.ai site and dashboard render as crisp SVG. Reasons
for the switch:
- Emoji render very differently across OS/browser/font stacks; the
registry catalog looked inconsistent from one row to the next.
- Five manifests (clip / creator / linkedin / reddit / twitter) had
their icons stored as literal Python-style escape strings
("\\U0001F3AC") because the TOML parser upstream never decoded
them. Switching away from emoji drops that class of bug entirely.
- As a drive-by, also decode the \\uXXXX accent escapes in the
[i18n.fr] block of hands/creator/HAND.toml so "Créateur" shows
up correctly.
87 files touched. example manifests left untouched (still "TODO").
* fix: backfill i18n name + drop the single-member email category
- Every existing [i18n.<lang>] block now has a `name` field. 60 files
previously translated description but kept the English name
implicitly — which rendered as "some English some Chinese" in the
registry UI. Fill in the missing name from the English brand (or a
known localized equivalent: DingTalk→钉钉, Feishu→飞书, Email→
电子邮件 / メール / E-Mail / Correo / Courriel, and a handful of
hands that have Chinese product names like 视频剪辑 Hand).
- channels/email.toml was the only item under category="email";
reclassify it as "messaging" so the sub-category filter chip list
on the category page isn't littered with singletons.
* feat(i18n): localize 76 agents/integrations/plugins into 7 languages
Adds full [i18n.zh], [i18n.zh-TW], [i18n.ja], [i18n.ko], [i18n.de],
[i18n.es], [i18n.fr] blocks with name + description to every manifest
that previously shipped English-only.
Coverage:
- 32 agents (academic-researcher, analyst, architect, assistant,
code-reviewer, coder, customer-support, data-scientist, debugger,
devops-lead, doc-writer, email-assistant, health-tracker,
hello-world, home-automation, legal-assistant, meeting-assistant,
ops, orchestrator, personal-finance, planner, recipe-assistant,
recruiter, researcher, sales-assistant, security-auditor,
social-media, test-engineer, translator, travel-planner, tutor,
writer)
- 33 integrations (AWS, Azure, Bitbucket, Brave Search, Discord,
Dropbox, Elasticsearch, Exa Search, Fetch, Filesystem, GCP, Git,
GitHub, GitLab, Gmail, Google Calendar, Google Drive, Google Maps,
Jira, Linear, Memory, MongoDB, Notion, PostgreSQL, Puppeteer, Redis,
Sentry, Sequential Thinking, Slack, SQLite, Teams, Time, Todoist) —
brand names kept as-is across all locales, only descriptions
translated.
- 11 plugins (auto-summarizer, context-decay, conversation-logger,
episodic-memory, guardrails, keyword-memory, mempalace-indexer,
sentiment-tracker, todo-tracker, topic-memory, user-profile)
The descriptions are one-line summaries — hand-translated rather than
machine-generated, so technical terms (MCP, PR, CI/CD, etc.) stay
consistent across locales.
* feat(i18n): close remaining per-lang gaps for channels, workflows, devteam
Third pass on i18n coverage. Every non-example manifest now carries a
full set of [i18n.zh], [i18n.zh-TW], [i18n.ja], [i18n.ko], [i18n.de],
[i18n.es], [i18n.fr] blocks.
- 44 channel adapters: added French descriptions (zh/zh-TW/ja/ko/de/es
were already present). Brand names kept as-is in all locales so users
recognize Discord / Slack / LINE / etc. consistently.
- 22 workflows: filled zh-TW / ja / ko / de / es / fr blocks. Each
translation mirrors the existing zh one in structure and tone so the
catalog reads consistently across locales.
- hands/devteam/HAND.toml: added the four langs that were missing
(zh-TW, de, es, fr).
Only the 6 templates under examples/ are left without i18n blocks on
purpose — they still contain "TODO:" placeholders.
95 lines
3.1 KiB
TOML
95 lines
3.1 KiB
TOML
id = "api-design"
|
|
name = "API Design & Specification"
|
|
description = "Design a REST API from requirements: endpoints, request/response schemas, auth, error handling, and OpenAPI spec."
|
|
category = "engineering"
|
|
tags = ["api", "design", "openapi", "engineering"]
|
|
|
|
[i18n.zh]
|
|
name = "API 设计与规范"
|
|
description = "从需求出发设计 REST API：端点、请求/响应结构、认证、错误处理，输出 OpenAPI 规范。"
|
|
|
|
[[parameters]]
|
|
name = "requirements"
|
|
description = "Feature or product requirements the API needs to satisfy"
|
|
param_type = "string"
|
|
required = true
|
|
|
|
[[parameters]]
|
|
name = "tech_stack"
|
|
description = "Technology stack and any existing API conventions"
|
|
param_type = "string"
|
|
required = false
|
|
default = ""
|
|
|
|
[[steps]]
|
|
name = "resource_model"
|
|
prompt_template = """
|
|
You are an API architect. From the requirements below, identify the core resources and their relationships:
|
|
1. List every resource (noun)
|
|
2. Define attributes and types for each
|
|
3. Map relationships (one-to-many, many-to-many)
|
|
4. Identify which resources need CRUD vs. action-oriented endpoints
|
|
|
|
Requirements:
|
|
{{requirements}}
|
|
|
|
Tech stack / conventions:
|
|
{{tech_stack}}
|
|
"""
|
|
|
|
[[steps]]
|
|
name = "endpoint_design"
|
|
prompt_template = """
|
|
Design the full set of REST endpoints based on the resource model. For each endpoint specify:
|
|
- Method + path
|
|
- Path/query parameters
|
|
- Request body schema (JSON)
|
|
- Success response schema + status code
|
|
- Error responses (4xx, 5xx)
|
|
- Auth requirement
|
|
- Idempotency and side-effect notes
|
|
|
|
Resource model:
|
|
{{resource_model}}
|
|
"""
|
|
depends_on = ["resource_model"]
|
|
|
|
[[steps]]
|
|
name = "openapi_spec"
|
|
prompt_template = """
|
|
Write a complete OpenAPI 3.1 YAML specification for the API designed above. Include:
|
|
- info block with title, version, description
|
|
- All paths with operations
|
|
- Reusable schemas in components/schemas
|
|
- Security schemes
|
|
- Example request/response bodies
|
|
|
|
Endpoint design:
|
|
{{endpoint_design}}
|
|
"""
|
|
depends_on = ["endpoint_design"]
|
|
|
|
[i18n.zh-TW]
|
|
name = "API 設計與規格"
|
|
description = "從需求出發設計 REST API：端點、請求/回應結構、認證、錯誤處理，輸出 OpenAPI 規格。"
|
|
|
|
[i18n.ja]
|
|
name = "API 設計と仕様策定"
|
|
description = "要件から REST API を設計：エンドポイント、リクエスト/レスポンススキーマ、認証、エラー処理、OpenAPI 仕様を出力。"
|
|
|
|
[i18n.ko]
|
|
name = "API 설계 및 명세"
|
|
description = "요구사항에서 REST API 설계: 엔드포인트, 요청/응답 스키마, 인증, 오류 처리, OpenAPI 명세 생성."
|
|
|
|
[i18n.de]
|
|
name = "API-Design & Spezifikation"
|
|
description = "REST-API aus Anforderungen entwerfen: Endpunkte, Request-/Response-Schemas, Auth, Fehlerbehandlung, OpenAPI-Spezifikation."
|
|
|
|
[i18n.es]
|
|
name = "Diseño y especificación de API"
|
|
description = "Diseña una API REST a partir de requisitos: endpoints, esquemas de petición/respuesta, autenticación, errores y especificación OpenAPI."
|
|
|
|
[i18n.fr]
|
|
name = "Conception et spécification d'API"
|
|
description = "Concevoir une API REST à partir des besoins : endpoints, schémas requête/réponse, auth, gestion des erreurs et spécification OpenAPI."
|