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.
110 lines
3.6 KiB
TOML
110 lines
3.6 KiB
TOML
id = "product-spec"
|
||
name = "Product Spec Writer"
|
||
description = "Turn a product idea or feature request into a complete PRD: user stories, acceptance criteria, technical notes, and open questions."
|
||
category = "business"
|
||
tags = ["product", "prd", "planning", "engineering"]
|
||
|
||
[i18n.zh]
|
||
name = "产品需求文档撰写"
|
||
description = "将产品想法或功能需求转化为完整 PRD：用户故事、验收标准、技术备注和待确认事项。"
|
||
|
||
[[parameters]]
|
||
name = "feature_idea"
|
||
description = "Feature idea or problem statement to spec out"
|
||
param_type = "string"
|
||
required = true
|
||
|
||
[[parameters]]
|
||
name = "context"
|
||
description = "Product context, target users, and any constraints"
|
||
param_type = "string"
|
||
required = false
|
||
default = ""
|
||
|
||
[[steps]]
|
||
name = "problem_definition"
|
||
prompt_template = """
|
||
You are a senior product manager. Define the problem clearly:
|
||
1. **Problem statement** — one precise sentence
|
||
2. **Who has this problem** — user segments and their specific pain
|
||
3. **Current workarounds** — how users cope today
|
||
4. **Why now** — why is this worth solving now
|
||
5. **Success looks like** — quantifiable outcomes
|
||
6. **Out of scope** — what this will deliberately not solve
|
||
|
||
Idea: {{feature_idea}}
|
||
Context: {{context}}
|
||
"""
|
||
|
||
[[steps]]
|
||
name = "user_stories"
|
||
prompt_template = """
|
||
Write user stories in the format: As a [user type], I want to [action] so that [outcome].
|
||
|
||
For each story:
|
||
- Given / When / Then acceptance criteria (3-5 criteria)
|
||
- Priority: P0 (must-have) / P1 (should-have) / P2 (nice-to-have)
|
||
- Estimated complexity: S / M / L / XL
|
||
|
||
Write at least 6 user stories covering happy paths, edge cases, and error states.
|
||
|
||
Problem definition:
|
||
{{problem_definition}}
|
||
"""
|
||
depends_on = ["problem_definition"]
|
||
|
||
[[steps]]
|
||
name = "prd"
|
||
prompt_template = """
|
||
Write a complete Product Requirements Document:
|
||
|
||
## Overview
|
||
## Problem Statement
|
||
## Goals & Non-Goals
|
||
## User Stories
|
||
(from above)
|
||
## Functional Requirements
|
||
Numbered list of specific behaviours the system must exhibit.
|
||
## Non-Functional Requirements
|
||
Performance, security, accessibility, internationalisation.
|
||
## Technical Considerations
|
||
Known constraints, integration points, migration needs.
|
||
## Metrics
|
||
How success will be measured (leading and lagging indicators).
|
||
## Open Questions
|
||
Decisions still needed, with suggested owners.
|
||
## Timeline Sketch
|
||
Phases with rough scope.
|
||
|
||
Problem definition:
|
||
{{problem_definition}}
|
||
|
||
User stories:
|
||
{{user_stories}}
|
||
"""
|
||
depends_on = ["problem_definition", "user_stories"]
|
||
|
||
[i18n.zh-TW]
|
||
name = "產品規格撰寫"
|
||
description = "將產品想法或功能需求轉化為完整 PRD：使用者故事、驗收標準、技術備註與待確認事項。"
|
||
|
||
[i18n.ja]
|
||
name = "プロダクトスペックライター"
|
||
description = "製品アイデアや機能要望を完全な PRD に変換：ユーザーストーリー、受け入れ基準、技術メモ、未解決事項。"
|
||
|
||
[i18n.ko]
|
||
name = "제품 스펙 작성"
|
||
description = "제품 아이디어나 기능 요청을 완전한 PRD로 변환: 사용자 스토리, 수락 기준, 기술 노트, 미해결 질문."
|
||
|
||
[i18n.de]
|
||
name = "Product-Spec-Autor"
|
||
description = "Produktidee oder Feature-Anfrage in ein vollständiges PRD verwandeln: User Stories, Akzeptanzkriterien, technische Notizen und offene Fragen."
|
||
|
||
[i18n.es]
|
||
name = "Redactor de especificaciones de producto"
|
||
description = "Convierte una idea o solicitud en un PRD completo: historias de usuario, criterios de aceptación, notas técnicas y preguntas abiertas."
|
||
|
||
[i18n.fr]
|
||
name = "Rédacteur de spec produit"
|
||
description = "Transformer une idée ou une demande en PRD complet : user stories, critères d’acceptation, notes techniques et questions ouvertes."
|