Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Kihara777/NixKits --skill write-project-docsgit clone --depth 1 https://github.com/Kihara777/NixKitsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kihara777/nixkits/write-project-docs)<a href="https://agentmods.dev/skills/kihara777/nixkits/write-project-docs"><img src="https://agentmods.dev/badge/skills/kihara777/nixkits/write-project-docs.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00058 | $0.02855 |
| Opus 5 | $0.00029 | $0.01427 |
| Sonnet 5 | $0.00012 | $0.00571 |
| Haiku 4.5 | $0.00006 | $0.00285 |
Grade A, and why
write-project-docs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 222 lines — stays where its author put it; the contents beside it link to each section on GitHub.
项目文档编写（NixKits 风格）
为任意项目生成完整的多语言文档体系。
何时使用
- 用户要求"编写文档"或"生成文档"
- 用户希望采用 NixKits 风格（简洁、多语言、表驱动）
- 用户有含模块/包/服务的现有项目需要文档化
自动发现契约
- 扫描 —
skills/translate-*/下查找所有翻译技能 - 读取 — 解析 frontmatter 中的
language_code、display_name、base_language - 注册 — 将发现的语言扩展纳入目录结构、语言切换器、列名映射等生成逻辑
编写规则
- 零废话 — 没有引导性修辞，没有"欢迎来到"
- 表格优先于段落 — 用
基本信息表格展示元数据 - 代码块完整可运行 — 可直接复制粘贴
- 技术术语保持英文 — 即使在中文/日文文档中
- 语言切换器标签 — 统一用各语言
display_name（语言自称），自身不加链接 - 中文标题 2 或 4 字词 — 优先简洁对称词汇（如
组件、基本信息） - 不生成目录 — 文档足够短，直接扫读
- 目标行数 ~40-60 行 — 补丁/模块文档以
rcc-fix.md（39 行）为标杆 - 标准节结构 —
基本信息→修正内容/功能→安装→注意 - 禁止反模式：
| 反模式 | 正确做法 |
|---|---|
| 硬编码语言列表 | 自动发现 translate-*/ |
硬编码文档路径（如 docs/zh/） |
根据语言代码动态生成 |
| 链接修复只改路径不改显示文本 | 路径和显示文本同步修正 |
| README 只更新主语言 | 同步所有已发现的本地化版本 |
| 源文件修改后不跟新文档 | 每次源变更后立即校对相关文档 |
| 在已有节之前插入内容时未检查是否已存在 | 逐行 grep 确认目标文本不重复后再写入 |
工作流程
第 1 步：评估项目
读取所有可用的模块/包/服务元数据，对每个模块提取名称、描述、类型、依赖、安装命令、使用示例。
第 2 步：模块分类
按功能类别分组。对于 Nix flake 项目：
| 分类 | 发现方式 |
|---|---|
| 软件 | packages/*.nix 中的 callPackage |
| 模块 | modules/*.nix 中的 NixOS 模块定义 |
| 覆盖层 | overlays/*.nix 中的 overlay 函数 |
| 技能 | skills/*/SKILL.md 中的 frontmatter |
| 开发 | devShells 在 flake.nix 中 |
第 3 步：生成 README
主语言 README 放根目录（无后缀），本地化版本放 docs/README.<code>.md。
第 4 步：生成模块文档
docs/<lang>/<module>.md，遵循四段式结构，每组自动包含对应分类标题。
第 5 步：生成技能文档
docs/<lang>/skills/<skill>.md，每技能包含基本信息 + 功能 + 使用。
第 6 步：语言切换器
按 zh → en → ja → 扩展语言（自动发现顺序） 生成。从源文件提取路径，用脚本逐个精确构造（禁止 sed 模式匹配）。
⚠️ 自身语言的标签必须为纯文本，不加链接。 其他语言才加 []() 链接。错误示例：[中文](home.md)（自身可点击）→ 正确：中文（纯文本，不可点击）。
第 7 步：最终检查
- 无死链接
- 各模板满员（无缺失语言版本）
- 中文 2/4 字标题一致
- 引用块格式统一
第 8 步：语言切换器双向同步（⚠️ 易遗漏）
新增语言变体后，必须双向更新所有语言切换器：
| 方向 | 操作 |
|---|---|
| 新文件 → 自身 | 创建时已含完整切换器 |
| 现有文件 → 新语言 | ⚠️ 易遗漏！ 需追加新语言链接到所有现有文件的切换器行 |
实施方法：用 sed 匹配切换器行（以 [中文]/[English]/[日本語] 开头），追加新链接。禁止用行号定位（sed '2s' 可能命中空行而非切换器）。
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 222 lines · 58 tokens per session scan A 0d7e579c8b26
write-project-docs is a skill published in the GitHub repository Kihara777/NixKits (25 stars, last pushed 3d ago), licensed MIT. It adds 58 tokens to every session and 2,855 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
why
Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics…
technical-writing
Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.
teach
Explain a body of work plainly so a person actually understands it. Runs the how and why skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.
unslop
Cut AI tells from any writing. Must always apply.
how
Use for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for…
quality-code
Standards for writing or modifying handwritten source code. Use when implementing code changes or reviewing handwritten code. Do not use for browsing, explanation, diagnosis without implementation, generated code, or vendored code.