Agent skill
update-project-docs
Keep CLAUDE.md and AGENTS.md current after significant project changes. Use proactively when: (1) adding new modules, packages, or top-level directories, (2) changing build/test commands or tooling, (3) renaming/moving/deleting files referenced in CLAUDE.md, (4) introducing new conventions or patterns, (5) reorganizing document structure, (6) adding dependencies requiring setup steps. Invoke when user mentions CLAUDE.md, AGENTS.md, project docs update, or after completing architectural changes.
Install this agent skill to your Project
npx add-skill https://github.com/dbosk/claude-skills/tree/main/update-project-docs
SKILL.md
Update Project Docs
Keep CLAUDE.md and AGENTS.md current so future AI sessions start with accurate project context.
When to Trigger
Activate after completing changes that affect how someone navigates or works in the project. Both conditions must hold:
- The project contains a CLAUDE.md or AGENTS.md (if not, skip)
- The changes meet the significance threshold below
Significance Threshold
Trigger (update needed):
- New modules, packages, or top-level directories
- Renamed/moved/deleted files that CLAUDE.md references
- Changed build commands, test commands, or tooling
- New conventions or patterns introduced
- API/interface changes affecting documented entry points
- Document structure reorganization (text projects)
- New dependencies that require setup steps
Skip (too small to trigger):
- Bug fixes within existing architecture
- Adding content within existing structure
- Minor refactors (rename variable, extract small helper)
- Test additions following existing patterns
- Typo fixes, formatting changes
Workflow
-
Check for docs — Locate CLAUDE.md or AGENTS.md in the project root. If neither exists, stop.
-
Review what changed — Use
git diffor recall the changes just made. Identify which aspects affect project navigation or workflow. -
Read current docs — Load the existing CLAUDE.md/AGENTS.md to understand its structure and voice.
-
Identify stale/missing sections — Compare the current project state against what the docs describe. Look for:
- Sections referencing renamed/deleted files
- Missing entries for new modules or directories
- Outdated build/test/lint commands
- Conventions that no longer apply
-
Update — Edit the docs following the Update Principles below. Preserve the existing document style.
-
Show the user — Summarize what was updated and why, so the user can verify the changes make sense.
Update Principles
What to Add
- New module/directory descriptions (one line each)
- Changed build, test, or lint commands
- New conventions or patterns that future sessions should follow
- Setup steps for new dependencies
- Updated file paths for moved/renamed files
What NOT to Add
- Implementation details (that's what code is for)
- Temporary workarounds or TODOs
- Information already obvious from file names
- Content that duplicates README.md
Style Guidelines
- Match existing voice — If the file is terse, stay terse. If it uses full sentences, use full sentences.
- Keep it scannable — Prefer bullet lists over prose paragraphs
- Remove stale info — Deleting outdated content is as important as adding new content. A shorter, accurate file beats a longer, stale one.
- Preserve structure — Add new items to existing sections rather than creating new sections, unless the change introduces an entirely new category.
- Be specific — "Run
make test-integration" not "run the integration tests"
Scope
- Update only project-level CLAUDE.md/AGENTS.md, not workspace or global files
- If both CLAUDE.md and AGENTS.md exist, update whichever contains the relevant section (or both if the information belongs in both)
- Never create a CLAUDE.md/AGENTS.md if one doesn't already exist — that's the user's decision
Reference Files
| File | Content |
|---|---|
references/update-examples.md |
Before/after examples for common scenarios |
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
latex-writing
Guide LaTeX document authoring following best practices and proper semantic markup. Use proactively when: (1) writing or editing .tex files, (2) writing or editing .nw literate programming files, (3) literate-programming skill is active and working with .nw files, (4) user mentions LaTeX, BibTeX, or document formatting, (5) reviewing LaTeX code quality. Ensures proper use of semantic environments (description vs itemize), csquotes (\enquote{} not ``...''), and cleveref (\cref{} not \S\ref{}).
canvas-quiz
Write and review Canvas LMS quiz JSON files (INL1Quiz-*.json) for the tilkry cryptography course. Use proactively when: (1) creating, editing, or reviewing INL1Quiz JSON files, (2) user asks to write quiz questions for a lecture topic, (3) user asks to review quiz quality, redundancy, or distractor balance, (4) user mentions Canvas quiz, INL1Quiz, quiz JSON, or quiz questions. Covers JSON structure, question design, scoring, redundancy analysis, and validation.
didactic-notes
Document pedagogical design decisions in educational materials using the didactic LaTeX package and \ltnote command. Use proactively when (1) writing or editing educational LaTeX materials with pedagogical content, (2) adding variation theory labels or patterns to student-facing content, (3) explaining design trade-offs or choices in educational materials, (4) documenting why specific examples or exercises are sequenced in a particular way. Invoke when user mentions didactic notes, \ltnote, pedagogical reasoning, learning theory notes, educational design documentation, variation theory labels in student content, or asks to move pedagogical reasoning to instructor notes. CRITICAL: Pedagogical reasoning (variation/invariance labels, pattern names, design rationale) should be in \ltnote{}, NOT in student-facing text.
literate-programming
CRITICAL: ALWAYS activate this skill BEFORE making ANY changes to .nw files. Use proactively when: (1) creating, editing, reviewing, or improving any .nw file, (2) planning to add/modify functionality in files with .nw extension, (3) user asks about literate quality, (4) user mentions noweb, literate programming, tangling, or weaving, (5) working in directories containing .nw files, (6) creating new modules/files that will be .nw format. Trigger phrases: 'create module', 'add feature', 'update', 'modify', 'fix' + any .nw file. Never edit .nw files directly without first activating this skill to ensure literate programming principles are applied. (project, gitignored)
try-first-tell-later
Structure educational content using try-first-tell-later pedagogy where students predict, attempt, or reflect before receiving explanations. Creates active learning through cognitive engagement and variation theory's contrast patterns. Use when writing educational materials, designing exercises, creating lecture notes, structuring tutorials, writing teaching examples with LaTeX/Beamer, developing problem sets, or when user mentions try-first, predict-first, productive failure, Socratic method, question-before-answer, exercise-driven learning, or inquiry-based teaching.
writing-crypto
Write cryptography prose and notation using the project's bibsp.sty + preamble.tex conventions (acro + biblatex footnote citations and standardized math macros). Use proactively when: (1) writing/editing cryptography sections in .tex files, (2) introducing or using crypto acronyms such as IND-CPA, IND-CCA, AE, MAC, PRF, ZK, and DH, (3) defining schemes/algorithms/variables in math notation, (4) adding citations for security notions or standard primitives, (5) writing security proofs or reductions, (6) user mentions biblatex, crypto notation, or security proof in cryptographic context.
Didn't find tool you were looking for?