* feat: skills i18n 改造 — schemaVersion 1.1,零向后兼容
把 21 个 skills + 1 个 agent + manifest/categories 全量迁移到 schemaVersion 1.1
的 i18n 结构,配套 CI AI 翻译流水线(GitHub Models)与本地工具链。
## 关键变更
### 数据结构(破坏性,schemaVersion 1.0 → 1.1)
- SKILL.md: 顶层 name 改为 ASCII slug(== 目录名,符合 agentskills.io 规范);
中文显示名/short_desc/description 全部迁入 metadata.i18n.<locale>
- agents/<id>/agent.json: shortDesc/fullDesc/tags/persona.{role,traits} 迁入
i18n.<locale>;changelog[].changes 改为 { <locale>: string[] } 对象
- categories.json: 每个分类的 label/description 迁入 i18n.<locale>,顶层只剩
color/icon
- manifest.json: 加 supportedLocales / defaultLocale;顶层 description 迁入
i18n.<locale>
### Body 文件结构
- 根 SKILL.md = frontmatter + default_locale (en-US) body
- SKILL.<locale>.md = 各 locale 的 markdown body(首行 <!-- locale: xx --> 自校验)
### 工具链(scripts/i18n/)
- glossary.json: zh→en 术语表 + do_not_translate 白名单
- schema/skill-frontmatter.schema.json: i18n frontmatter JSON Schema
- validate-i18n.py: 8 条校验规则(name 合规 / locale 完整性 / hash 一致性等)
- translate.py: GitHub Models / Anthropic 双 backend,sha256 增量翻译
- migrate.py: 一次性迁移脚本(旧格式 → i18n 结构)
### CI(.github/workflows/)
- i18n-validate.yml: PR 触发跑 validate + translate --check
- i18n-translate.yml: PR 触发用 GitHub Models(默认 openai/gpt-5-mini)翻译缺失
locale,自动追加 commit;可切到 ANTHROPIC_API_KEY 走 Claude
### 文档
- docs/I18N.md: 作者贡献指南(schema 说明 / 提交流程 / 常见问题)
- README.md: 加多语言段落
## 验证
- uv run scripts/i18n/validate-i18n.py: OK,49 文件 0 错误
- uv run scripts/i18n/translate.py --check: 0 stale locale
- 21 skills 标题数 zh-CN == en-US 严格对齐(最大 66=66)
- skills-ref 规范校验:全部通过(顶层 name ASCII slug + description 单字段)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(i18n): 修复 PR #1 review 反馈的 6 项问题
- schema: translated_by 正则放宽为 ^(human|ai:[A-Za-z0-9._:/-]+)$,接受
'ai:github:openai/gpt-5-mini' 这类 backend:model 形式(CI 翻译输出格式)
- README + docs/I18N.md: 修正"CI 用 Claude API"误导描述,正确说明默认是
GitHub Models(openai/gpt-5-mini)+ GITHUB_TOKEN,可选切到 Anthropic
- skills/minimax-tts/SKILL.md & SKILL.zh-CN.md: 删除多余的 ``` 闭合,避免
Markdown 后续渲染错乱
- skills/docx/SKILL.md: 翻译时丢失的 • Unicode escape 示例已恢复,
与 zh-CN 版本对齐
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
14 KiB
name, description, version, type, risk_level, status, disable-model-invocation, tags, metadata, market
| name | description | version | type | risk_level | status | disable-model-invocation | tags | metadata | market | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| create-agent | 通过多轮对话收集需求,调用 HTTP API 创建新的 AgentFS v2 智能体,支持自定义 persona 和 principles。Use when 用户要求创建新智能体、培养某领域助手、或快速基于模板生成可治理 Agent。 | 2.4.2 | meta | low | enabled | true |
|
|
|
create-agent skill
L0: One-Sentence Summary
Collect requirements through natural-language conversation and call the HTTP API to create a specialized digital Agent.
L1: Overview and Use Cases
Capability Description
create-agent is a Meta-Skill that gives DesireCore the ability to create other Agents. It collects user requirements through multi-turn conversation, generates persona and principles content, and calls POST /api/agents to complete the creation.
Use Cases
- The user wants a digital assistant for a specialty domain (e.g. legal advisor, financial analyst)
- An enterprise needs to quickly deploy a customized business Agent
- A developer needs to quickly produce an Agent prototype from a template
Core Value
- Lower the barrier: No programming knowledge required; create an Agent through conversation
- Specialization: Generate appropriate persona and principles based on a domain template
- Governable: The created repository conforms to the AgentFS v2 spec and supports version management
L2: Detailed Specification
Conversation Flow
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 意图识别 │ ──→ │ 需求收集 │ ──→ │ 内容生成 │
└──────────────┘ └──────────────┘ └──────────────┘
│
↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 回执生成 │ ←── │ API 创建 │ ←── │ 用户确认 │
└──────────────┘ └──────────────┘ └──────────────┘
Stage 1: Intent Recognition
Trigger conditions (any one is sufficient):
- The user explicitly says "create an Agent" or "build me an assistant"
- The user describes needing professional help in some domain that the current Agent doesn't have
- The user asks "can you help me grow a..."
Output: Confirm the user's create intent and proceed to requirement collection.
Stage 2: Requirement Collection
Required information:
| Field | Description | Example Probing Question |
|---|---|---|
name |
Agent name | "What name would you like to give this Agent?" |
role |
Core duty | "What's its main responsibility?" |
target_users |
Target users | "Who will use this Agent?" |
domain |
Specialty area | "What expertise does it need?" |
Optional information:
| Field | Description | Default |
|---|---|---|
style |
Communication style | Determined by domain template |
boundaries |
Off-limits / red lines | Determined by domain template |
language |
Primary language | Chinese |
Collection strategy:
- Prefer to infer information from the user's natural description
- Only probe for required fields the user hasn't mentioned
- Ask at most 2 follow-up questions per turn
Stage 3: Content Generation
Based on the collected requirements, assemble structured persona and principles data. Do not output raw markdown; instead, organize by field and present to the user.
Persona fields (all fields optional; missing ones are auto-filled by the system):
| Layer | Field | Description |
|---|---|---|
| L0 | — | One-sentence core identity |
| L1 | role |
Role positioning |
| L1 | personality |
Personality trait tags |
| L1 | communication_style |
Communication style |
| L2 | — | Specialty domain, core values, decision preferences (free-form) |
Principles fields (all also optional):
| Layer | Field | Description |
|---|---|---|
| L0 | — | One-sentence top-level principle |
| L1 | must_do |
Things the Agent must do |
| L1 | must_not |
Things the Agent must never do (safety red lines) |
| L1 | priority |
Priority ordering |
| L2 | — | Governance principles, escalation rules (free-form) |
Domain matching reference:
| Domain Keywords | Recommended personality | Default must_not |
|---|---|---|
| Legal, contract, legal affairs | Professional, rigorous, prudent | No litigation representation; not a substitute for formal legal advice |
| Finance, accounting, investment | Precise, analytical, conservative | No investment advice; do not handle real transactions |
| Code, development, architecture | Logical, pragmatic, direct | No direct production access; do not store credentials |
| General / other | Friendly, helpful | Standard safety norms |
Stage 4: User Confirmation
When showing the preview to the user, present each field in natural language / table form. Do not show raw markdown source:
About to create Agent:
Name: Legal Advisor Assistant Description: A digital Agent focused on contract review and legal risk assessment
Persona
Field Content Core identity You are Legal Advisor Assistant, focused on contract review and legal risk assessment Role positioning A digital legal advisor focused on contract review and legal risk assessment Personality Professional, rigorous, prudent Communication style Use legal terminology accurately while also providing plain-language explanations Principles
Field Content Top principle User interest is the highest priority; not a substitute for formal legal advice Must do Cite statutes accurately, mark uncertainty, recommend consulting a professional lawyer Must not Provide litigation representation, substitute for formal legal advice, leak user consultations Priority User safety > Accuracy > Efficiency
Confirm creation? (Confirm / Modify / Cancel)
"Modify" branch handling:
When the user chooses "Modify":
- Ask the user which field to modify (e.g. "Which one do you want to modify?")
- The user identifies the field to modify (e.g. "change personality to something more lively")
- The Agent re-collects content for that field
- Update the corresponding field in the preview
- Show the full preview again → re-enter the confirmation flow
Stage 5: Call API to Create
API endpoint: POST /api/agents
Request body (structured format):
{
"name": "法律顾问小助手",
"description": "专注于合同审查和法律风险评估的数字智能体",
"persona": {
"L0": "你是法律顾问小助手,专注于合同审查和法律风险评估的数字智能体。",
"L1": {
"role": "专注于合同审查和法律风险评估的数字法律顾问",
"personality": ["专业", "严谨", "审慎"],
"communication_style": "准确使用法律术语,同时提供通俗解释"
}
},
"principles": {
"L0": "以用户利益为最高优先级,不替代正式法律意见。",
"L1": {
"must_do": ["准确引用法律条文", "标注不确定性", "建议咨询专业律师"],
"must_not": ["提供诉讼代理", "替代正式法律意见", "泄露用户法律咨询内容"],
"priority": "用户安全 > 准确性 > 效率"
}
}
}
Minimal create (only name; the rest is auto-generated):
{ "name": "我的助手" }
Basic create (name + description; description auto-fills persona L0):
{ "name": "法律顾问", "description": "专注合同审查" }
Any unprovided fields are auto-filled with sensible defaults by the system. persona and principles also accept raw markdown strings (backward compatible).
Optional: To specify a slug ID, generate a sensible kebab-case slug from name (e.g. "Legal Advisor" → "legal-advisor") and include "id": "<slug>" in the request body. If not specified, the system auto-generates one from name.
Successful response (201 Created):
{
"success": true,
"agentId": "fa-lv-gu-wen-xiao-zhu-shou",
"agent": {
"id": "fa-lv-gu-wen-xiao-zhu-shou",
"name": "法律顾问小助手",
"description": "专注于合同审查和法律风险评估的数字智能体",
"skillsCount": 0,
"toolsCount": 0,
"status": "offline"
}
}
The agent field in the response contains the full info of the newly created Agent and can be used directly in the receipt.
Stage 6: Receipt Generation
Receipt report:
After successful creation, present the receipt in a user-friendly way (do not expose internal paths or technical details):
Agent "Legal Advisor Assistant" has been created!
Next steps:
- Start a conversation right away
- Add skills to make it more powerful
- Adjust its personality or behavior rules
Background Knowledge
AgentFS repository structure, troubleshooting points, and protected paths are detailed in
_agentfs-background.mdand_protected-paths.yaml.
Error Handling
| Error Code | Scenario | Handling |
|---|---|---|
| 400 | Missing name or invalid ID format |
Ask user to check input |
| 409 | Agent ID already exists | Suggest using another name |
| 500 | Internal server error | Ask user to try again later |
Permission Requirements
- Prefer accessing the Agent Service HTTP API via the
Bashtool with curl - The API base URL is already injected into the "Local API" section of the system prompt; reference it directly
- Creation requires user confirmation
Dependencies
- Agent Service HTTP API (
POST /api/agents) - The local API URL declaration in the system prompt