本文へ移動
cccskills
無料GitHub で公開

sync-docs

Analyze code changes and update relevant documentation to stay in sync. Runs automatically before /commit. Assumes docs are outdated — only updates what this change touches, never over-reaches.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md8.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Sync Docs Skill

Ensures documentation reflects the current code changes. Conservative for existing docs, proactive for new features — updates what changed, creates what's missing.

Core Philosophy

  1. Assume docs are outdated — don't trust them, verify against source code
  2. Only update what this change touches — if you changed a composable, update its entry in CLAUDE.md. Don't rewrite the whole file.
  3. Create CLAUDE.md for new packages/apps — if a package or app directory lacks a CLAUDE.md and this change adds significant functionality, create one following the standard template.
  4. New features need documentation — when a feature is added (new MCP tools, new API endpoints, new composables, new integrations), it MUST be documented somewhere. This is the exception to "never add sections" — new capabilities require new entries.
  5. Additions over rewrites — prefer adding a line to a table or list over restructuring
  6. Skip if nothing to update — config tweaks, bug fixes to internal logic, formatting changes rarely need doc changes.

When NOT to Update Docs

  • Pure bug fixes with no API/behavior change
  • Internal refactors that don't change any public interface
  • Dependency bumps
  • Test-only changes
  • Formatting/linting changes
  • Changes to files that have no documentation coverage (and shouldn't)

What to Check

0. Missing CLAUDE.md (CREATE if needed)

When to create a new CLAUDE.md:

  • A new package was added to packages/*/ and has no CLAUDE.md
  • An app in apps/*/ gained significant new functionality (MCP tools, integrations, custom server APIs) and has no CLAUDE.md
  • A new layer was added with its own composables, components, or API endpoints

Template for new CLAUDE.md:

# CLAUDE.md - {package-or-app-name}

## Purpose
{One paragraph describing what this does}

## Key Files
| File | Purpose |
|------|---------|
| ... | ... |

## API Endpoints (if applicable)
| Path | Method | Purpose |
|------|--------|---------|

## Common Tasks
{How to use, test, develop}

Don't over-document — start minimal, cover what an AI agent needs to use this package effectively.

1. Package & App CLAUDE.md Files

Each package in packages/*/CLAUDE.md and app in apps/*/CLAUDE.md documents its components, composables, server utils, types, and patterns.

When to update:

  • Added/removed/renamed a component → update "Key Components" or similar section
  • Added/removed/renamed a composable → update "Key Composables" section
  • Changed a composable's return value or parameters → update its documentation
  • Added/removed/renamed an API endpoint → update "API Endpoints" section
  • Changed a component's props/emits significantly → update component docs
  • Added a new export → add it to the relevant section
  • Added new MCP tools → update or create MCP section with tool names, inputs, descriptions
  • Added new integrations (CLI, external services) → add integration section
  • Added new server API routes → add to API endpoints table

How to update:

  • Read the existing CLAUDE.md for the package/app
  • Find the relevant section (components, composables, API, etc.)
  • Add/update/remove the specific entry
  • Match the existing format exactly — don't restructure
  • If the section doesn't exist and the new feature warrants it, add a new section at the appropriate location

2. Root CLAUDE.md

Only update if:

  • A new package was added (add to scopes list)
  • A critical gotcha was discovered (add to gotchas section)
  • A dev command changed (update commands section)
  • Architecture changed fundamentally
  • A new skill/agent was added (add to artifacts table)

3. Docs App Content (docs/content/)

When to update existing pages:

  • The change directly contradicts what a docs page says
  • A documented API endpoint changed its contract
  • A documented component changed its usage pattern
  • A field type was added/removed from the generator

When to create new pages:

  • A major feature was added that users need to know about (e.g., MCP integration, new dispatch service, new CLI command)
  • A new package was released that needs user-facing documentation
  • Use existing pages as templates — match the structure and tone

How to find relevant docs pages:

  • Search docs/content/ for the name of the changed component/composable/endpoint
  • If a docs page references it, check if the reference is still accurate
  • Only fix inaccuracies in existing pages — don't expand or improve unrelated sections

4. Skills and Commands (.claude/skills/, .claude/commands/)

Only update if:

  • The change affects a workflow that a skill describes
  • A CLI command changed that a skill references
  • A file path changed that a skill uses
  • A new feature was added that an existing skill should know about

Added / changed / removed a skill (anything under .claude/skills/) → regenerate the skills overview HTML: node scripts/gen-skills-doc.mjs. For a brand-new skill, also add it to that script's META map (group + trigger) or it lands under "Uncategorised". CI (skills-doc.yml) fails if the HTML is stale.

Workflow

Step 1: Identify What Changed

Run in parallel:

  • git diff --name-only — list changed files
  • git diff --cached --name-only — list staged files
  • git diff --stat — summary of changes

Step 2: Categorize Changes

For each changed file, determine:

  • Package: which packages/*/ does it belong to?
  • Type: component, composable, server util, type, config, other?
  • Impact: public API change, internal change, or cosmetic?

Only proceed with files that have public API impact.

Step 3: Check Relevant Docs

For each package with public API changes:

  1. Read the package's CLAUDE.md (if it exists)
  2. Search for references in docs/content/ using the changed item's name
  3. Compare the docs against what the code now says

Step 4: Make Targeted Updates

For each doc that needs updating:

  1. Show what's changing: Updating packages/crouton-foo/CLAUDE.md — adding useNewComposable to Key Composables
  2. Use the Edit tool to make the minimum change
  3. Match existing formatting

Step 5: Report

Summarize what was updated:

Docs synced:
- packages/crouton-core/CLAUDE.md: added useTeamRoles to composables list
- docs/content/8.api-reference/composables.md: updated useTeamRoles signature

No updates needed:
- 3 internal files changed (no public API impact)

Or if nothing needs updating:

No doc updates needed — changes are internal/cosmetic only.

Mapping: File Change → Doc Location

Changed File PatternCheck This Doc
packages/*/app/components/*.vuepackages/*/CLAUDE.md (components section)
packages/*/app/composables/use*.tspackages/*/CLAUDE.md (composables section)
packages/*/server/api/**packages/*/CLAUDE.md (API section)
packages/*/server/utils/**packages/*/CLAUDE.md (server utils section)
packages/*/types*.tspackages/*/CLAUDE.md (types section)
packages/crouton-cli/**.claude/skills/crouton.md, packages/crouton-cli/CLAUDE.md
packages/crouton-mcp*/**packages/crouton-mcp*/CLAUDE.md
docs/content/**N/A (it IS the docs)
*.nuxt.config.tsPackage CLAUDE.md (config section, if exists)

Examples

Example 1: Added a composable

Changed: packages/crouton-core/app/composables/useTeamRoles.ts

Action:

  1. Read packages/crouton-core/CLAUDE.md
  2. Find composables section
  3. Add useTeamRoles entry matching existing format
  4. Search docs/content/ for "team roles" — if found, verify accuracy

Example 2: Renamed a component

Changed: packages/crouton-editor/app/components/EditorToolbar.vue → EditorActions.vue

Action:

  1. Read packages/crouton-editor/CLAUDE.md
  2. Replace EditorToolbar with EditorActions
  3. Search docs for EditorToolbar references and update

Example 3: Internal bug fix

Changed: packages/crouton-auth/server/utils/session.ts (fixed a null check)

Action: No doc update needed — internal fix, no API change.

Rules

  1. NEVER restructure docs — add/edit/remove specific entries only
  2. NEVER add new sections unless the change introduces an entirely new category
  3. NEVER update docs for internal changes — only public API
  4. ALWAYS match existing format — if the list uses - , keep using -
  5. ALWAYS show what you're updating before doing it
  6. ALWAYS read the doc first before editing it
  7. Prefer skipping over guessing — if you're unsure whether a doc needs updating, skip it

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

a11y

無料

Accessibility review for Vue surfaces — the code-cleaning analog of /code-review and /simplify, pointed at WCAG/ARIA. Reviews just your diff (or a package/file), rates findings by severity, and either comments inline on the PR (--comment) or applies the safe fixes for you (--fix). Steers the depth-aware `a11y` subagent. Use when asked to "check accessibility", "a11y this", "audit ARIA/keyboard", or run /a11y.

日本語の概要は準備中です。原文の説明を表示しています。

FriendlyInternet/nuxt-crouton102026年10月6日 更新

ask-human

無料

Emit a blocking question the owner can read in ~10 seconds and answer in one reply — the scannable, recommendation-first handoff every agent posts when it hits a fork it can't own. Leads with the one decision + a recommendation, carries the 🤖 provenance header, doubles as the

日本語の概要は準備中です。原文の説明を表示しています。

FriendlyInternet/nuxt-crouton102026年10月6日 更新

audit

無料

Audit packages for documentation completeness, detect drift between code and docs, and maintain documentation quality across the monorepo. Use when checking package docs, running audits, or reviewing documentation health.

日本語の概要は準備中です。原文の説明を表示しています。

FriendlyInternet/nuxt-crouton102026年10月6日 更新

Author a placeable layout block that looks right at ANY pane size. The one hard rule — size to the PANE with container queries (@container), never the viewport — plus list/form playbooks and the sizing contract (minWidth etc.) the viability metric reads. Use when adding/converting a croutonLayoutBlocks block, or when a block overflows/breaks in a narrow pane.

日本語の概要は準備中です。原文の説明を表示しています。

FriendlyInternet/nuxt-crouton102026年10月6日 更新

When a bug or regression is reported, the FIRST step — before fixing — is to research how and when it was introduced (git archaeology), then record that finding on the tracking issue/PR. Use the moment a bug, error, broken build, or "this used to work" is reported, before writing a fix. Produces a first-bad-commit (or "not a code regression") note you paste onto the issue.

日本語の概要は準備中です。原文の説明を表示しています。

FriendlyInternet/nuxt-crouton102026年10月6日 更新

commit

無料

Smart, granular git commits following monorepo conventions. Analyzes changes, filters to session-relevant files, groups by intent, and uses conventional commit format. Use when committing code changes.

日本語の概要は準備中です。原文の説明を表示しています。

FriendlyInternet/nuxt-crouton102026年10月6日 更新

FriendlyInternet のスキルをすべて見る

このスキルの問題を報告する