원클릭으로
updating-noridocs
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 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
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 직업 분류 기준
| 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 changedEach 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:
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions
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
Read this skill whenever you need to build a cli where the primary consumer is the agent.
Use when implementing user interfaces or user experiences - guides through exploration of design variations, frontend setup, iteration, and proper integration
Use when asked to create a new skillset.
Use this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.