Claude-skill-registry context-synchronization
Synchronize project documentation after track completion. Use when a track reaches completed status and product, tech-stack, or guidelines documents may need updates.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/context-synchronization" ~/.claude/skills/majiayu000-claude-skill-registry-context-synchronization && rm -rf "$T"
skills/data/context-synchronization/SKILL.mdContext Synchronization
This skill provides the protocol for synchronizing project-level documentation after completing a Conductor track.
Execution Trigger
Only execute this protocol when:
- A track has reached
status in the tracks file[x] - The
command has finished all tasks/claude-conductor:implement
Do NOT execute for:
- Status changes other than completion
- Partial task completion
- Track creation
Protocol Overview
- Load the completed track's specification
- Analyze for documentation impacts
- Propose updates with user confirmation
- Apply approved changes
- Commit documentation updates
Step-by-Step Process
1. Announce Synchronization
Inform the user:
"I am now synchronizing the project-level documentation with the completed track's specifications."
2. Load Track Specification
Read the completed track's
conductor/tracks/<track_id>/spec.md into context.
3. Load Project Documents
Read the following files:
conductor/product.mdconductor/product-guidelines.mdconductor/tech-stack.md
4. Analyze and Update
4.1 Update conductor/product.md
conductor/product.mdCondition for Update: Determine if the completed feature or bug fix significantly impacts the description of the product itself.
Examples that warrant updates:
- New major feature that changes product capabilities
- Fundamental change to how users interact with the product
- New integration that expands product scope
Examples that do NOT warrant updates:
- Bug fixes
- Internal refactoring
- Minor UI tweaks
- Performance improvements
Propose and Confirm: If an update is needed:
"Based on the completed track, I propose the following updates to
:"product.md[Proposed changes in diff format]"Do you approve these changes? (yes/no)"
Action: Only after explicit user confirmation, apply the edits. Record whether this file was changed.
4.2 Update conductor/tech-stack.md
conductor/tech-stack.mdCondition for Update: Determine if significant changes in the technology stack occurred.
Examples that warrant updates:
- New library or framework added
- Database technology changed
- New external service integration
- Significant architectural change
Examples that do NOT warrant updates:
- Version bumps of existing dependencies
- Development-only tool changes
- Configuration changes
Propose and Confirm: If an update is needed:
"Based on the completed track, I propose the following updates to
:"tech-stack.md[Proposed changes in diff format]"Do you approve these changes? (yes/no)"
Action: Only after explicit user confirmation, apply the edits. Record whether this file was changed.
4.3 Update conductor/product-guidelines.md
(Strictly Controlled)
conductor/product-guidelines.mdCRITICAL WARNING: This file defines the core identity and communication style of the product. It should be modified with extreme caution and ONLY in cases of significant strategic shifts.
Valid reasons to update:
- Product rebrand
- Fundamental change in user engagement philosophy
- Major shift in target audience
- Complete redesign of product voice/tone
Invalid reasons (do NOT update):
- Routine feature updates
- Bug fixes
- Minor UI changes
- Performance improvements
- New features that don't change brand identity
Condition for Update: You may ONLY propose an update if the track's
spec.md explicitly describes a change that directly impacts branding, voice, tone, or other core product guidelines.
Propose and Confirm (with warning): If the strict conditions are met:
"WARNING: The completed track suggests a change to the core product guidelines. This is an unusual step. Please review carefully:"
[Proposed changes in diff format]"Do you approve these critical changes to
? (yes/no)"product-guidelines.md
Action: Only after explicit user confirmation, apply the edits. Record whether this file was changed.
5. Final Report
Announce completion and provide a summary based on which files were changed.
Example (product.md changed):
"Documentation synchronization is complete.
- Changes made to
: The user-facing description of the product was updated to include the new feature.product.md- No changes needed for
: The technology stack was not affected.tech-stack.md- No changes needed for
: Core product guidelines remain unchanged."product-guidelines.md
Example (no changes):
"Documentation synchronization is complete. No updates were necessary for
,product.md, ortech-stack.mdbased on the completed track."product-guidelines.md
6. Commit Changes
If any files were changed:
- Stage:
,product.md
, and/ortech-stack.mdproduct-guidelines.md - Commit message:
docs(conductor): Synchronize docs for track '<track_description>'
Diff Format Guidelines
When proposing changes, use diff format for clarity:
# Product Overview - Our product helps users manage tasks efficiently. + Our product helps users manage tasks efficiently with real-time collaboration features. ## Key Features - Task management - Due date tracking + - Real-time collaboration + - Team workspaces
User Confirmation Patterns
Always wait for explicit user response:
Approval patterns:
- "yes"
- "y"
- "approve"
- "looks good"
Rejection patterns:
- "no"
- "n"
- "reject"
- Any request for changes
If unclear, ask for clarification before proceeding.