Creates concise feature briefs for handoff to Claude Code. Use when users want to document a feature for implementation, need a spec for coding, want to capture architecture decisions for handoff, or are planning features to be built by an AI coding agent. Generates token-efficient implementation directives that communicate intent while delegating schema discovery to the coding agent.
Create concise, token-efficient feature briefs that communicate implementation intent to Claude Code while delegating technical discovery to the coding agent.
Feature briefs are implementation directives, not detailed design specs. They:
When a task list exists for the feature, include a link to it immediately after the title.
This creates bidirectional linking between the brief and task list for easy navigation in Obsidian.
# Feature Brief: [Feature Name]
**Task List:** [feature-name-tasks.md](feature-name-tasks.md)
Guidelines:
[filename.md] or [filename.md](filename.md)Generate briefs using this structure:
State what we're building and the core user value. Be specific about the outcome.
Good: "Add workout sync functionality that pulls completed workouts from HealthKit and stores them in the app's database. This enables users to see their training history without manual entry."
Weak: "Implement HealthKit integration for workouts."
Key workflows in "As a user, I can..." format. Focus on observable behaviors, not implementation.
- As a user, I can see my completed workouts from Apple Watch in the app
- As a user, I can view workout details including duration, distance, and heart rate
- As a user, I can manually refresh to pull latest workouts
Limit to 3-6 stories. If more are needed, the feature may need splitting.
How the feature should work. Include:
Write as prose or short bullets. Avoid implementation details—focus on what happens, not how it's coded.
Workouts sync on app launch and manual refresh. Only workouts completed after
the user's account creation date should sync. Duplicate detection uses the
HealthKit workout UUID. If a workout already exists, skip it silently.
For workouts without GPS data, distance may be nil—display "—" in the UI.
Explicit scope limits. What this feature does NOT do.
Out of scope:
- Real-time streaming of in-progress workouts
- Editing or deleting synced workouts
- Syncing to other platforms (Strava, Garmin)
- Background sync (manual/app-launch only for v1)
This prevents scope creep during implementation.
Instructions for Claude Code. This is the prompt engineering section.
Standard template:
## Implementation Guidance
Before implementing:
1. Query the database schema to understand current table structures
2. Examine existing patterns in [relevant area/module]
3. Review how similar features handle [relevant concern]
Propose a plan before writing code. Include:
- Which tables/models will be created or modified
- Key functions or services needed
- How this integrates with existing code
[Any feature-specific technical hints, e.g.:]
- Use the existing HealthKitService for Apple Health integration
- Follow the medallion architecture pattern (Bronze → Silver → Gold)
- Coordinate with the existing sync queue for background operations
Adjust based on what's relevant to the feature.
Present the brief in a clean, copy-paste-ready format with Obsidian-compatible YAML frontmatter:
---