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.
When & Why to Use This Skill
The Context Synchronization skill automates the maintenance of project-level documentation by analyzing completed development milestones. It ensures that critical files—such as product descriptions, technical stacks, and project guidelines—remain perfectly aligned with the latest implementation, effectively eliminating documentation debt and ensuring a single source of truth.
Use Cases
- Updating the technical stack documentation automatically whenever new libraries, frameworks, or external services are integrated into the codebase.
- Refining product overviews and feature lists in 'product.md' immediately after a development track is completed to reflect new capabilities.
- Ensuring project guidelines and brand voice documents stay current during major strategic shifts or product rebrands.
- Streamlining the developer handoff process by generating and committing documentation diffs based on actual task specifications.
| name | context-synchronization |
|---|---|
| description | Synchronize project documentation after track completion. Use when a track reaches completed status and product, tech-stack, or guidelines documents may need updates. |
Context 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
[x]status in the tracks file - The
/claude-conductor:implementcommand has finished all tasks
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
Condition 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
Condition 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)
CRITICAL 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
product-guidelines.md? (yes/no)"
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
product.md: The user-facing description of the product was updated to include the new feature.- No changes needed for
tech-stack.md: The technology stack was not affected.- No changes needed for
product-guidelines.md: Core product guidelines remain unchanged."
Example (no changes):
"Documentation synchronization is complete. No updates were necessary for
product.md,tech-stack.md, orproduct-guidelines.mdbased on the completed track."
6. Commit Changes
If any files were changed:
- Stage:
product.md,tech-stack.md, and/orproduct-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.