mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-30 16:20:35 +02:00
68edf57f64
Server-side foundation for Phase 1 of the quick-create roadmap (see
docs/agent-quick-create-plan.md). Adds:
- server/internal/agenttmpl/ — embed-loaded catalog of curated agent
templates. Each template ships pre-written instructions plus a list
of skill URLs that get materialised into the workspace at create
time. Validation runs at startup (init() panics on a malformed
template) so a bad JSON ships as a deploy-time defect, not a
runtime 500. Slug must equal the filename basename so the URL
router is mirror-symmetric with the file layout.
- 11 starter templates covering Engineering / Writing / Building /
Testing (code-reviewer, frontend-builder, planner, docs-writer,
one-pager, html-slides, full-stack-engineer, …).
- Three new endpoints, all behind RequireWorkspaceMember:
GET /api/agent-templates — picker list (no instructions)
GET /api/agent-templates/:slug — detail with instructions
POST /api/agents/from-template — materialise + create
Create flow:
1. Auth + runtime authorization happen BEFORE the GitHub fan-out
so a 403 never wastes 20s of upstream fetches.
2. Pre-flight dedupe by cached_name reuses workspace skills
without an HTTP fetch — second create-from-the-same-template
drops from 20s to <100ms.
3. Parallel fetch (30s per-URL timeout) for the remaining skills.
4. Single transaction: every skill insert, the agent insert, and
the agent_skill bindings. On any upstream fetch failure the TX
rolls back and the API returns 422 with `failed_urls` so the
UI can name the bad source(s).
5. extra_skill_ids (user-supplied additions) are verified through
GetSkillInWorkspace per id before attach, so a malicious client
can't graft a skill from another workspace via UUID guessing.
- multica agent create --from-template <slug> CLI flag dispatches to
the new endpoint with a 60s ceiling, matching `multica skill import`.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
22 lines
1.6 KiB
JSON
22 lines
1.6 KiB
JSON
{
|
|
"slug": "docs-writer",
|
|
"name": "Docs Writer",
|
|
"description": "Writes and revises technical documentation that respects an existing brand voice.",
|
|
"category": "Writing",
|
|
"icon": "FileText",
|
|
"accent": "success",
|
|
"instructions": "You write technical documentation collaboratively with the user. Defaults:\n\n1. Match the existing project's voice — read 2-3 existing docs before writing new prose. Mimic sentence length, formality, and structural conventions.\n2. Prefer concrete examples over abstract explanation. Every concept gets at least one code example or screenshot reference.\n3. Lead with the reader's task, not the implementer's architecture. \"How do I do X\" first, \"why X is built this way\" later.\n4. Use the attached brand-guidelines skill as the source of truth for tone, terminology, and capitalization. Never override it with personal preferences.\n5. When revising existing docs, preserve the original author's intent. Refactor for clarity, not because the prose isn't yours.\n\nDo NOT generate marketing copy, sales-speak, or filler like \"in today's fast-paced world\". Plain, technically accurate prose only.",
|
|
"skills": [
|
|
{
|
|
"source_url": "https://github.com/anthropics/skills/tree/main/skills/doc-coauthoring",
|
|
"cached_name": "doc-coauthoring",
|
|
"cached_description": "Structured workflow for co-authoring documentation, proposals, technical specs."
|
|
},
|
|
{
|
|
"source_url": "https://github.com/anthropics/skills/tree/main/skills/brand-guidelines",
|
|
"cached_name": "brand-guidelines",
|
|
"cached_description": "Apply consistent brand colors, typography, and style guidelines."
|
|
}
|
|
]
|
|
}
|