跳到正文
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(原文)

安装前可以查看交给 AI 代理的指令内容。

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

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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月20日 更新

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月20日 更新

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月20日 更新

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月20日 更新

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月20日 更新

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月20日 更新

查看 FriendlyInternet 的全部技能

报告此技能的问题