菜单
Update README.md and SPEC.md based on docs/concepts/ and docs/ directories. Use when documentation sources change and README or the reimplementation specification (SPEC.md) need to reflect the latest state.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Clean up the repository's docs, comments, rules, and tests as a CAFleet team of disjoint-slice scanner members gated by a reviewer — exactly one workflow per run. Use the residue workflow when the user asks to clean up historical narration or historical residue, remove deprecation notes / "this replaces X" / "renamed from Y" / "previously … now …" prose, drop design-number provenance citations, or delete removal-sentinel tests. Use the affirmative workflow when the user asks to run an affirmative-writing sweep, fix prohibition-only rule sections, pair prohibitions with affirmatives, remove meaningless fallbacks, or make code fail fast. Use the simplification workflow when the user asks to simplify the docs or comments, tighten verbose prose, de-duplicate documentation, or remove redundant comments. Nothing is applied before the reviewer approves the merged run artifact. Members load this skill by its name clean-docs via their backend's skill-loader.
Teach an author how to integrate the CAFleet-orchestrated team pattern into a new skill they are writing. Auto-load when the author intends to create a new CAFleet-orchestrated skill, write a skill that spawns cafleet members, add a Director/Member team skill, design a multi-agent broker-coordinated skill, build a CAFleet-team-driven skill, or write a skill that uses `cafleet member create`. This skill is project-local to the cafleet repo and is fully self-contained — no `cafleet` `reference/base-dir.md` cross-reference is required to follow the guide.
Use when the user asks to create a design doc, design document, specification, or technical spec (create workflow → Director/Drafter/Reviewer team); to validate, review, or interview an existing design doc through multi-round Q&A (interview workflow); or to implement or execute a design doc (execute workflow → TDD team). Also the standardized format spec — consult the template and guidelines when editing a design doc. Always invoke this skill and route into the matching workflow, orchestrated as a CAFleet team. Teammates in member teams load this skill by its name cafleet-design-doc via their backend's skill-loader.
Use when the user asks to research a topic or create a multi-source research report (report workflow → Director/Manager/Researcher team writing to researches/<topic>/); to build a presentation, slide deck, or reading transcript from a report (presentation workflow); to create a chart, plot, graph, figure, or data visualization (visualization reference); or to author slides with the custom Slidev theme (slidev reference). Always invoke this skill and route into the matching workflow, orchestrated as a CAFleet team. Members in member teams load this skill by its name cafleet-research via their backend's skill-loader.
Interact with the CAFleet message broker and supervise CAFleet member teams. Use when an agent needs to register as a member, send/receive messages, poll inbox, acknowledge messages, or discover other members; or when a Director is about to spawn, monitor, health-check, or recover a stalled team of CAFleet members (any `cafleet member create`), which requires the dedicated monitoring member, the heartbeat, and the supervision governance.
| name | update-readme |
| description | Update README.md and SPEC.md based on docs/concepts/ and docs/ directories. Use when documentation sources change and README or the reimplementation specification (SPEC.md) need to reflect the latest state. |
| allowed-tools | Agent |
Launch an agent to update README.md and SPEC.md based on current project documentation.
Use the Agent tool to spawn an agent with the following parameters:
general-purposesonnetdefault"Update README and SPEC from docs"Use the following as the agent prompt:
You are a documentation writer for the CAFleet project. Your job is to keep two maintained targets in sync with the current content of docs/concepts/ and docs/: README.md and SPEC.md (the reimplementation specification).
## Workflow
1. Read all docs/concepts/*.md files (use Glob to enumerate) for the canonical architecture
2. Discover and read all files under docs/ (use Glob to find them)
3. Read the zensical.toml nav (repo root) for the docs-site section layout, then read the current README.md
4. Sync README.md's thin surface: align the pitch paragraph with docs/index.md, the Install block with the Install section of docs/quickstart.md, and the Documentation links with the nav
5. Read the current SPEC.md (the reimplementation specification, at the repo root)
6. Reconcile SPEC.md against the source materials per the "SPEC.md Maintenance" rules below, updating only where the contract surfaces have drifted
## README Structure
README.md is a thin entry point with exactly four surfaces, in order:
1. **Title, demo video, and pitch** -- Project name, the demo video asset, and a one-paragraph pitch aligned with docs/index.md (no bullet list)
2. **Install** -- The two-command install block (`uv tool install cafleet` / `cafleet setup`) plus a link to the full install guide
3. **Documentation** -- Links to the docs-site sections (Quickstart, How-to guides, Concepts, Specification, Contributing, API Reference)
4. **License** -- MIT
All other descriptive content (features, architecture, quick start, CLI usage, API overview, tech stack, project structure, development) lives in docs/ only -- never add it back to README.md.
## SPEC.md Maintenance
SPEC.md is the single authoritative reimplementation specification (message broker + coding-agent registry). It is a **contract document**: exact CLI option names/types/defaults, `CAFLEET_*` config, the SQLite schema, the HTTP API, exact error strings, JSON key order, and text layouts ARE the contract. Treat it as a maintained target, not a source to rewrite:
- **Update only on drift.** Change SPEC.md only where the canonical sources show the contract surface has actually changed -- the CLI command/option set (§6.3, §10), configuration (§7.1), persistence schema/migrations (§6.1, §8), the HTTP API (§6.8), or observable semantics. If nothing relevant changed, leave SPEC.md untouched.
- **Preserve its structure and detail.** Do not restructure, renumber, summarize, or simplify SPEC.md. Keep its section numbering, exact strings, tables, argv specs, and verbatim blocks intact. Make the smallest edit that removes the drift.
- **Keep it descriptive, not opinionated.** SPEC.md states the specification only -- no recommendations, "preferred"/"cleaner"/"acceptable alternative" language, or implementation advice. Match the existing neutral, affirmative voice.
- **Reflect removals fully.** When a feature/flag/endpoint is removed from the sources, remove every corresponding mention from SPEC.md in the same pass (no deprecation notes left behind).
## Rules
- Write in English
- Do not use emojis
- Keep it concise and developer-friendly
- CLI command is `cafleet` (unified CLI for both server admin and agent operations)
- SPEC.md is a maintained target alongside README.md -- reconcile it per "SPEC.md Maintenance" above, preserving its contract-level structure and detail