blog
Write release blog posts for Chorus — problem-first narrative, bilingual (zh/en), following the project's editorial style.
Chorus documentation router — consult the live Chorus docs site to answer product-usage questions (UI workflow, agent/plugin setup, API/MCP, deployment, operations).
$ npx -y skills add Chorus-AIDLC/Chorus --skill docs-chorus --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/docs-chorusContext preview
The summary Claude sees to decide when to auto-load this skill.
Chorus documentation router — consult the live Chorus docs site to answer product-usage questions (UI workflow, agent/plugin setup, API/MCP, deployment, operations).
name: docs-chorus description: Chorus documentation router — consult the live Chorus docs site to answer product-usage questions (UI workflow, agent/plugin setup, API/MCP, deployment, operations). license: AGPL-3.0 metadata: author: chorus version: "0.18.1" category: project-management mcp_server: chorus
This skill is a **thin router to the live Chorus documentation site** (`https://doc.chorus-ai.dev`). Use it to answer questions about **how to use, configure, deploy, or operate Chorus** — grounding the answer in the current published docs instead of memory.
It is **not** a workflow skill: it does not drive the AI-DLC pipeline. For that, use `idea-chorus`, `proposal-chorus`, `develop-chorus`, `review-chorus`, or `yolo-chorus`.
---
Use this skill whenever the user asks a **product-usage** question about Chorus, such as:
Do **NOT** use it to *drive* the pipeline (claiming ideas, writing proposals, executing tasks) — that is what the stage skills above are for. This skill answers "how does the product work / how do I set it up"; the stage skills *do* the work.
---
The docs site is agent-friendly. Follow this three-step convention every time. **Do NOT** answer from memory, and **do NOT** hardcode a page list — the index is the source of truth and pages change over time.
1. **Fetch the index.** Get `https://doc.chorus-ai.dev/llms.txt` — a machine-readable index that lists every documentation page with a one-line summary and its `.md` URL. **The index is a single, unlocalized file that lives ONLY at the root `/llms.txt`. Never prefix it with a locale — `https://doc.chorus-ai.dev/zh/llms.txt` (and `/ja/`, `/ko/`) does NOT exist and returns 404.** 2. **Fetch the relevant page(s) as raw Markdown.** Pick the page(s) that match the question from the index, then fetch the raw Markdown by **appending `.md`** to the page URL (e.g. `https://doc.chorus-ai.dev/guides/getting-started` → `https://doc.chorus-ai.dev/guides/getting-started.md`). 3. **Ground the answer and link the human page.** Base your answer on the fetched Markdown, and link the human-facing page (the `.md` URL **without** the `.md` suffix) so the user can open it in a browser.
Use whatever web-fetch capability your environment provides (your built-in fetch tool, `curl`, etc.) — this skill states the convention, not a specific tool binding.
---
The `/llms.txt` index itself is **not** localized — there is exactly one, at the root. Localization applies to **pages**, not the index:
---
This skill **complements** the AI-DLC workflow skills — it does not replace them:
| The user wants to… | Use | |--------------------|-----| | Learn how to use / configure / deploy / operate Chorus | **this skill** (`docs-chorus`) | | Drive an idea / write a proposal / execute or verify a task | `idea-chorus`, `proposal-chorus`, `develop-chorus`, `review-chorus`, `yolo-chorus` |
Always use the live host `doc.chorus-ai.dev`. `docs.chorus-ai.dev` (with an "s") is a dead link — never use it.
The Agent Harness for AI-Human Collaboration, inspired by the AI-DLC (AI-Driven Development Lifecycle)
Repo: Chorus-AIDLC/Chorus
Write release blog posts for Chorus — problem-first narrative, bilingual (zh/en), following the project's editorial style.
Use when manually verifying a Chorus frontend change in a real browser — finding local login credentials, driving the running dev server with the Playwright…
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through…
Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal…