documentation
Documentation standards for ARCHITECTURE.md, PLAN.md, DESIGN.md, SPECS.md, SKILL.md, diagrams, and README indexing. Use when creating or updating project documentation.
适合你,如果需要在项目中建立统一的文档标准
/ 通过 npx 安装 校验哈希
npx oh-my-skill add tinywasm/devflow/documentation/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- tinywasm/devflow/documentation/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify tinywasm/devflow/documentation安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
1GitHub stars
~696上下文体积 · 单文件
索引托管
怎么用
商店整理自技能原文 · 版本 6481063 · 表述以原文为准它做什么
Claude 会在编码或执行前,先更新项目文档,包括架构、计划、设计、规格、技能说明和图表等,并确保 README 索引所有永久文档。
什么时候触发
当创建或更新项目文档时触发,尤其是在开始编码或运行 `gopush` 之前。
装好后可以这样说
Claude 会按标准格式编写架构文档。
Claude 会生成包含约束和测试策略的计划。
Claude 会更新索引,排除临时文件。
技能原文 SKILL.md
Documentation
- Documentation First: You MUST update the documentation before coding or running
gopush. - Context-Aware Rule Compilation: Every
PLAN.mdMUST start with a "Development Rules" section that copies/pastes the relevant constraints from this skill file (e.g., WASM restrictions, DI rules).
- Standard Documents:
docs/ARCHITECTURE.md: Defines WHAT & WHY (abstract design, constraints). NO implementation code.docs/PLAN.md: Defines HOW (steps, reference code, test strategy). It is the master orchestrator for execution. Ephemeral:codejobrenames it toCHECK_PLAN.mdand deletes it when the loop closes (see skill agents-workflow).docs/DESIGN.md: (On demand) Justifies technical decisions and explores alternatives. Must NOT duplicateARCHITECTURE.md. Heavily linked byARCHITECTURE.mdto keep the main document clean and focused on abstract structure rather than debate.docs/SPECS.md: (On demand) Strict functional requirements, exact inputs/outputs, and data logic. Must NOT duplicateARCHITECTURE.md.PLAN.mdconsumes it to derive exact test cases and assertions (link direction: plan → specs, never the reverse).docs/SKILL.md: (On demand) Provides an LLM-friendly, highly condensed summary of the library's context and constraints.- Modular Docs: If
ARCHITECTURE.mdorPLAN.mdbecome too large, they must be divided into domain-specific, uppercase, underscore-separated files (e.g.,docs/BUS_ARCHITECTURE.md,docs/CHART_BAR_PLAN.md).
- Diagram Standards:
- Format & Location: Markdown files (
*.md) containing Mermaid code, stored indocs/diagrams/and linked from the architecture documents. - Simplicity: Use simple, vertical, linear flowcharts (
flowchart TD). NEVER use thesubgraphdirective (ruins TUI rendering). Use<br/>for line breaks inside standard nodes instead of quoting text strings.
- Ephemeral vs Permanent: Permanent docs (
README.md,ARCHITECTURE.md,DESIGN.md,SPECS.md, diagrams) must NEVER link to or citePLAN.md/CHECK_PLAN.md— not even section references like "PLAN §8" — those files are deleted at loop close, so every such reference is a guaranteed dead link. Rationale and rejected alternatives belong inDESIGN.md; contracts inARCHITECTURE.md. A permanent doc written documentation-first (before the implementation lands) may carry a self-deleting marker —STATUS (remove this note when X lands): …— whose removal is an explicit task of the plan.
- Readme Indexing: The
README.mdmust act as an index. Every file indocs/must be linked fromREADME.md— except the ephemeral lifecycle files (PLAN.md,PLAN_*.md,CHECK_PLAN.md), which are never indexed. Cross-link logically related permanent documents (e.g.,ARCHITECTURE.mdlinking toSPECS.mdorDESIGN.md) to avoid duplicating information across files.
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →
评论
登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。
…