菜单
Use this when you have finished making code changes and you are ready to update the documentation based on those changes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Check papers/ structure for completeness and accuracy — every PDF has text extraction, every paper is indexed in PAPER_INDEX.md and summarized in PAPER_SUMMARIES.md, summaries are factually accurate. Prompts the user for discrepancies.
Use when you want to clean up accumulated git worktrees in a repo. Lists all worktrees with status, verifies data symlinks, ensures code and docs are committed, copies non-symlinked data files to main worktree, asks which to merge or keep, runs post-merge audits on new docs/papers, and removes merged worktrees.
Use after creating or modifying decision documents in docs/ to keep DOCS_INDEX.md and DOCS_SUMMARY.md consistent. Also use as a standalone audit to find coverage gaps, broken links, and ADR format issues. Works across any repo with a docs/ directory. Run alongside updating-noridocs when finishing a branch that includes decision docs.
IMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
End a research session — runs update-docs to checkpoint all progress, then commits and pushes. Use update-docs for mid-session checkpoints without ending the session.
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
| name | Updating Noridocs |
| description | Use this when you have finished making code changes and you are ready to update the documentation based on those changes. |
Noridocs are docs.md files throughout the codebase that document each folder's purpose, architecture, and implementation. Update them after code changes using the nori-change-documenter subagent.
Core principle: Provide context → Dispatch subagent → Verify updates.
Announce at start: "I'm using the Updating Noridocs skill to update documentation."
Prepare information for the subagent:
Use Task tool with nori-change-documenter type:
Task(subagent_type: nori-change-documenter)
In the prompt, provide:
Check that documentation was updated:
git status to see which docs.md files changedskills/nori-sync-docs/SKILL.md.
skills/nori-sync-docs/SKILL.md to sync all noridocs to the remote server.Each docs.md follows this structure:
# Noridoc: [Folder Name]
Path: [Path to the folder from the repository root. Always start with @. For
example, @/src/endpoints or @/docs ]
### Overview
[2-3 bullet summary of the folder]
### How it fits into the larger codebase
[2-10 bullet description of how the folder interacts with and fits into other
parts of the codebase. Focus on system invariants, architecture, internal
depenencies, places that call into this folder, and places that this folder
calls out to]
### Core Implementation
[2-10 bullet description of entry points, data paths, key architectural
details, state management]
### Things to Know
[2-10 bullet description of tricky implementation details, system invariants,
or likely error surfaces]
Created and maintained by Nori.
Noridocs should NOT list files, maintain counts, or track line numbers. These are brittle documentation patterns that will break very quickly.
Providing vague context
Skipping verification
Documenting trivial changes
Never:
Always: