Context Synchronization

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:implement command has finished all tasks

Do NOT execute for:

• Status changes other than completion
• Partial task completion
• Track creation

Protocol Overview

1. Load the completed track's specification
2. Analyze for documentation impacts
3. Propose updates with user confirmation
4. Apply approved changes
5. 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.md
• conductor/product-guidelines.md
• conductor/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, or product-guidelines.md based on the completed track."

6. Commit Changes

If any files were changed:

• Stage: product.md, tech-stack.md, and/or product-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.