After implementation is complete and tests pass, sync confirmed details back to Intent. Captures finalized interfaces, data structures, naming conventions, and architecture decisions...
Synchronize implementation details back to Intent after development is complete. This makes Intent the true single source of truth.
Use /intent-sync when:
During implementation, many details get finalized that weren't specified in the original Intent:
| Category | Examples |
|---|---|
| Interfaces | API endpoints, function signatures, protocol definitions |
| Data Structures | Schema definitions, type definitions, model structures |
| Naming | Final class names, function names, variable conventions |
| Architecture | Module boundaries, dependency directions, layer structure |
| Configuration | Environment variables, config file formats, defaults |
| Error Handling | Error codes, error message formats, recovery strategies |
User confirms implementation is done
ā
Read original Intent file
ā
Scan implemented code for:
- Public interfaces
- Data structures
- Key naming conventions
- Architecture patterns
ā
Compare with Intent
ā
Identify gaps/differences
ā
Present changes for approval
ā
Update Intent with confirmed details
ā
Mark synced sections with timestamp
Scan the codebase for finalized details:
Code Analysis:
āāā Public APIs
ā āāā Endpoints (REST/GraphQL/RPC)
ā āāā Function signatures
ā āāā Event definitions
āāā Data Models
ā āāā Database schemas
ā āāā Type definitions
ā āāā Config structures
āāā Architecture
ā āāā Module structure
ā āāā Dependency graph
ā āāā Layer boundaries
āāā Conventions
āāā Naming patterns
āāā Error formats
āāā Logging standards
Identify what's new or different:
| Status | Meaning | Action |
|---|---|---|
| New | Not in original Intent | Add to Intent |
| Changed | Different from Intent | Update Intent |
| Confirmed | Matches Intent | Mark as implemented |
| Removed | In Intent but not implemented | Remove or mark deferred |
Use AskUserQuestion to confirm changes:
"The following details were finalized during implementation.
Should I sync them back to Intent?"
Interfaces:
- [x] POST /api/users - Create user (new)
- [x] UserSchema: added 'createdAt' field (changed)
Data Structures:
- [x] Config now uses YAML instead of JSON (changed)
Naming:
- [x] Service class renamed to UserService (changed)
Add a new section or update existing sections:
## Finalized Implementation Details
> Synced on: YYYY-MM-DD
> From: [commit hash or version]
### API Interfaces
| Endpoint | Method | Request | Response |
|----------|--------|---------|----------|
| /api/users | POST | `{name, email}` | `{id, name, email, createdAt}` |
| /api/users/:id | GET | - | `{id, name, email, createdAt}` |
### Data Structures
\`\`\`typescript
interface User {
id: string;
name: string;
email: string;
createdAt: Date;
}
\`\`\`
### Module Structure
\`\`\`
src/
āāā api/
ā āāā users.ts # User endpoints
āāā services/
ā āāā UserService.ts # Business logic
āāā models/
ā āāā User.ts # Data model
āāā config/
āāā config.yaml # Configuration
\`\`\`
### Key Decisions Confirmed
| Decision | Final Choice | Rationale |
|----------|--------------|-----------|
| Config format | YAML | Better readability for nested config |
| ID generation | UUID v4 | Standard, no coordination needed |
The sync adds or updates these Intent sections:
## Finalized Implementation DetailsContains:
Use markers to indicate sync status:
## API Design
> [!SYNCED] Last synced: 2024-01-15 from commit abc123
### Endpoints
...
Or in tables:
| Component | Status | Last Synced |
|---|---|---|
| User API | SYNCED | 2024-01-15 |
| Auth API | DRAFT | - |
/intent-interview # Create Intent (initial)
ā
/intent-review # Approve Intent
ā
/intent-plan # Generate execution plan
ā
[Execute: TDD cycles]
ā
/intent-sync # Write back confirmed details (THIS SKILL)
ā
/intent-check # Verify consistency
User: Implementation is done, tests pass. Please sync back to Intent.