spec-kitty-cli 0.12.1__py3-none-any.whl

specify_cli/missions/documentation/templates/release-template.md

@@ -0,0 +1,222 @@
+# Release: {documentation_title}
+
+**Documentation Mission**: {mission_name}
+**Release Date**: {release_date}
+**Version**: {version}
+
+> **Purpose**: This document captures the publish and handoff details for this documentation effort. Use it to record hosting configuration, deployment steps, and ownership information.
+
+---
+
+## Hosting Target
+
+**Platform**: {platform}
+<!-- Examples: Read the Docs, GitHub Pages, Netlify, Vercel, GitBook, custom server -->
+
+**Production URL**: {production_url}
+<!-- The live documentation site URL -->
+
+**Staging URL** (if applicable): {staging_url}
+<!-- Preview/staging environment URL -->
+
+**Domain Configuration**:
+- Custom domain: {custom_domain} (or N/A)
+- DNS provider: {dns_provider}
+- SSL/TLS: {ssl_configuration}
+
+---
+
+## Build Output
+
+**Build Command**:
+```bash
+{build_command}
+```
+<!-- Example: sphinx-build -b html docs/ docs/_build/html/ -->
+
+**Output Directory**: `{output_directory}`
+<!-- Example: docs/_build/html/ -->
+
+**Build Requirements**:
+- {requirement_1}
+- {requirement_2}
+<!-- Examples: Node.js 18+, Python 3.11+, Sphinx 7.x -->
+
+**Build Time**: ~{build_time} seconds
+<!-- Approximate time for full build -->
+
+---
+
+## Deployment Steps
+
+### Automated Deployment (if configured)
+
+**CI/CD Platform**: {ci_cd_platform}
+<!-- Examples: GitHub Actions, GitLab CI, CircleCI, Jenkins -->
+
+**Trigger**: {deployment_trigger}
+<!-- Examples: Push to main branch, Tag creation, Manual workflow dispatch -->
+
+**Workflow File**: `{workflow_file_path}`
+<!-- Example: .github/workflows/docs.yml -->
+
+### Manual Deployment Steps
+
+If automated deployment is not available, follow these steps:
+
+1. **Build documentation locally**:
+   ```bash
+   {manual_build_step_1}
+   ```
+
+2. **Verify build output**:
+   ```bash
+   {manual_verify_step}
+   ```
+
+3. **Deploy to hosting**:
+   ```bash
+   {manual_deploy_step}
+   ```
+
+4. **Verify live site**:
+   - Navigate to {production_url}
+   - Check all pages load correctly
+   - Verify navigation works
+   - Test search functionality (if applicable)
+
+---
+
+## Configuration Files
+
+**Key Configuration Locations**:
+
+| File | Purpose | Location |
+|------|---------|----------|
+| {config_file_1} | {purpose_1} | `{location_1}` |
+| {config_file_2} | {purpose_2} | `{location_2}` |
+
+<!-- Examples:
+- docs/conf.py | Sphinx configuration | docs/conf.py
+- mkdocs.yml | MkDocs configuration | mkdocs.yml
+- .readthedocs.yaml | RTD build config | .readthedocs.yaml
+-->
+
+---
+
+## Access & Credentials
+
+**Hosting Platform Access**:
+- Login URL: {platform_login_url}
+- Access method: {access_method}
+  <!-- Examples: SSO via GitHub, Email/password, API key -->
+- Credentials stored: {credential_location}
+  <!-- Examples: Team password manager, Environment secrets, 1Password vault -->
+
+**Required Permissions**:
+- {permission_1}
+- {permission_2}
+<!-- Examples: Admin access to Read the Docs project, GitHub Pages write permissions -->
+
+**Team Members with Access**:
+- {name_1} - {role_1} - {email_1}
+- {name_2} - {role_2} - {email_2}
+
+---
+
+## Ownership & Maintenance
+
+**Primary Maintainer**: {primary_maintainer_name}
+**Contact**: {primary_maintainer_contact}
+**Backup Maintainer**: {backup_maintainer_name}
+
+**Maintenance Schedule**:
+- Documentation reviews: {review_frequency}
+  <!-- Example: Quarterly, After each release, Monthly -->
+- Dependency updates: {dependency_update_frequency}
+  <!-- Example: When major versions release, Annually -->
+- Content refresh: {content_refresh_frequency}
+  <!-- Example: With each product release, As needed -->
+
+**Known Issues**:
+- {known_issue_1}
+- {known_issue_2}
+<!-- Document any current limitations, broken features, or planned improvements -->
+
+---
+
+## Monitoring & Analytics
+
+**Analytics Platform**: {analytics_platform}
+<!-- Examples: Google Analytics, Plausible, PostHog, None -->
+
+**Dashboard URL**: {analytics_dashboard_url}
+
+**Key Metrics**:
+- Page views tracked: {yes_no}
+- Search queries tracked: {yes_no}
+- User feedback collected: {yes_no}
+
+**Monitoring**:
+- Uptime monitoring: {uptime_service}
+  <!-- Examples: UptimeRobot, Pingdom, None -->
+- Build status: {build_status_url}
+  <!-- Link to CI/CD build dashboard -->
+
+---
+
+## Handoff Checklist
+
+Use this checklist when transferring documentation ownership:
+
+- [ ] New maintainer has access to hosting platform
+- [ ] New maintainer can build documentation locally
+- [ ] New maintainer has credentials to all required services
+- [ ] New maintainer understands deployment process
+- [ ] Build and deploy have been demonstrated
+- [ ] Known issues and workarounds explained
+- [ ] Contact information updated in this document
+- [ ] Team notification sent about ownership change
+
+---
+
+## Troubleshooting
+
+### Build Fails
+
+**Symptom**: {build_error_symptom}
+**Cause**: {likely_cause}
+**Solution**: {fix_steps}
+
+### Deployment Fails
+
+**Symptom**: {deploy_error_symptom}
+**Cause**: {likely_cause}
+**Solution**: {fix_steps}
+
+### Site Not Updating
+
+**Symptom**: Changes committed but not visible on live site
+**Causes**:
+- Cache not cleared
+- Deployment pipeline failed silently
+- Wrong branch deployed
+
+**Solutions**:
+- Check CI/CD logs for errors
+- Clear browser cache and CDN cache
+- Verify correct branch is configured for deployment
+
+---
+
+## Additional Resources
+
+- **Documentation Source**: {repo_url}
+- **Issue Tracker**: {issue_tracker_url}
+- **Team Chat**: {chat_channel}
+- **Internal Docs**: {internal_docs_url}
+
+---
+
+**Notes**:
+<!-- Add any additional context, special instructions, or historical information -->

specify_cli/missions/documentation/templates/spec-template.md

@@ -0,0 +1,172 @@
+# Feature Specification: Documentation Project - [PROJECT NAME]
+<!-- Replace [PROJECT NAME] with the confirmed friendly title generated during /spec-kitty.specify. -->
+
+**Feature Branch**: `[###-feature-name]`
+**Created**: [DATE]
+**Status**: Draft
+**Mission**: documentation
+**Input**: User description: "$ARGUMENTS"
+
+## Documentation Scope
+
+**Iteration Mode**: [NEEDS CLARIFICATION: initial | gap-filling | feature-specific]
+**Target Audience**: [NEEDS CLARIFICATION: developers integrating library | end users | contributors | operators]
+**Selected Divio Types**: [NEEDS CLARIFICATION: Which of tutorial, how-to, reference, explanation?]
+**Languages Detected**: [Auto-detected during planning - JavaScript, Python, Rust, etc.]
+**Generators to Use**: [Based on languages - JSDoc, Sphinx, rustdoc]
+
+### Gap Analysis Results *(for gap-filling mode only)*
+
+**Existing Documentation**:
+- [List current docs and their Divio types]
+- Example: `README.md` - explanation (partial)
+- Example: `API.md` - reference (outdated)
+
+**Identified Gaps**:
+- [Missing Divio types or outdated content]
+- Example: No tutorial for getting started
+- Example: Reference docs don't cover new v2 API
+
+**Coverage Percentage**: [X%] *(calculated from gap analysis)*
+
+## User Scenarios & Testing *(mandatory)*
+
+<!--
+  IMPORTANT: Documentation user stories focus on DOCUMENTATION CONSUMERS.
+  Each story should be INDEPENDENTLY TESTABLE - meaning if you implement just ONE type of documentation,
+  it should still deliver value to a specific audience.
+
+  Prioritize by user impact: Which documentation will help the most users accomplish their goals?
+-->
+
+### User Story 1 - [Documentation Consumer Need] (Priority: P1)
+
+[Describe who needs the documentation and what they want to accomplish]
+
+**Why this priority**: [Explain value - e.g., "New users can't adopt the library without a tutorial"]
+
+**Independent Test**: [How to verify documentation achieves the goal]
+- Example: "New developer with no prior knowledge can complete getting-started tutorial in under 15 minutes"
+
+**Acceptance Scenarios**:
+
+1. **Given** [user's starting state], **When** [they read/follow this documentation], **Then** [they accomplish their goal]
+2. **Given** [documentation exists], **When** [user searches for information], **Then** [they find it within X clicks]
+
+---
+
+### User Story 2 - [Documentation Consumer Need] (Priority: P2)
+
+[Describe the second most important documentation need]
+
+**Why this priority**: [Explain value]
+
+**Independent Test**: [Describe how this can be tested independently]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+### User Story 3 - [Documentation Consumer Need] (Priority: P3)
+
+[Describe the third most important documentation need]
+
+**Why this priority**: [Explain value]
+
+**Independent Test**: [Describe how this can be tested independently]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+[Add more user stories as needed, each with an assigned priority]
+
+### Edge Cases
+
+- What happens when documentation becomes outdated after code changes?
+- How do users find information that doesn't fit standard Divio types?
+- What if generated documentation conflicts with manually-written documentation?
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+
+#### Documentation Content
+
+- **FR-001**: Documentation MUST include [tutorial | how-to | reference | explanation] for [feature/area]
+- **FR-002**: Documentation MUST be accessible (proper heading hierarchy, alt text for images, clear language)
+- **FR-003**: Documentation MUST use bias-free language and inclusive examples
+- **FR-004**: Documentation MUST provide working code examples for all key use cases
+
+*Example of marking unclear requirements:*
+
+- **FR-005**: Documentation MUST cover [NEEDS CLARIFICATION: which features? all public APIs? core features only?]
+
+#### Generation Requirements *(if using generators)*
+
+- **FR-006**: System MUST generate API reference from [JSDoc comments | Python docstrings | Rust doc comments]
+- **FR-007**: Generated documentation MUST integrate seamlessly with manually-written documentation
+- **FR-008**: Generator configuration MUST be version-controlled and reproducible
+
+#### Gap-Filling Requirements *(if gap-filling mode)*
+
+- **FR-009**: Gap analysis MUST identify missing Divio types across all documentation areas
+- **FR-010**: Gap analysis MUST detect API reference docs that are outdated compared to current code
+- **FR-011**: System MUST prioritize gaps by user impact (critical, high, medium, low)
+
+### Key Entities
+
+- **Divio Documentation Type**: One of tutorial, how-to, reference, explanation - each with distinct purpose and characteristics
+- **Documentation Generator**: Tool that creates reference documentation from code comments (JSDoc for JavaScript, Sphinx for Python, rustdoc for Rust)
+- **Gap Analysis**: Assessment identifying missing or outdated documentation, with coverage metrics
+- **Documentation Template**: Structured template following Divio principles for a specific documentation type
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: Users can find information they need within [X] clicks/searches
+- **SC-002**: Documentation passes accessibility checks (proper heading hierarchy, alt text for images, clear language)
+- **SC-003**: API reference is [X]% complete (all public APIs documented)
+- **SC-004**: [X]% of users successfully complete tasks using documentation alone (measure via user testing)
+- **SC-005**: Documentation build completes with zero warnings or errors
+
+### Quality Gates
+
+- All images have descriptive alt text
+- Heading hierarchy is proper (H1 → H2 → H3, no skipping levels)
+- No broken links (internal or external)
+- All code examples have been tested and work
+- Spelling and grammar are correct
+
+## Assumptions
+
+- **ASM-001**: Project has code comments/docstrings for reference generation to be valuable
+- **ASM-002**: Users are willing to maintain documentation alongside code changes
+- **ASM-003**: Documentation will be hosted on [platform] using [static site generator]
+- **ASM-004**: Target audience has [technical background level] and familiarity with [technologies]
+
+## Out of Scope
+
+The following are explicitly NOT included in this documentation project:
+
+- Documentation hosting/deployment infrastructure (generates source files only)
+- Documentation analytics and metrics collection (page views, search queries, time on page)
+- AI-powered content generation (templates have placeholders, but content is human-written)
+- Interactive documentation features (try-it-now API consoles, code playgrounds, live demos)
+- Automatic documentation updates when code changes (manual maintenance required)
+- Translation/localization to other languages
+- Video tutorials or screencasts
+- PDF or print-optimized formats (unless explicitly requested)
+
+## Constraints
+
+- Documentation must be maintained as code changes
+- Generated documentation is only as good as code comments
+- Static site generators have limitations on interactivity
+- Some documentation types (tutorials especially) require significant manual effort
+- Documentation must remain accurate - outdated docs are worse than no docs

specify_cli/missions/documentation/templates/task-prompt-template.md

@@ -0,0 +1,140 @@
+---
+work_package_id: "WPxx"
+subtasks:
+  - "Txxx"
+title: "Replace with work package title"
+phase: "Phase N - Replace with phase name"
+lane: "planned"  # DO NOT EDIT - use: spec-kitty agent tasks move-task <WPID> --to <lane>
+assignee: ""      # Optional friendly name when in doing/for_review
+agent: ""         # CLI agent identifier (claude, codex, etc.)
+shell_pid: ""     # PID captured when the task moved to the current lane
+review_status: "" # empty | has_feedback | acknowledged (populated by reviewers/implementers)
+reviewed_by: ""   # Agent ID of the reviewer (if reviewed)
+history:
+  - timestamp: "{{TIMESTAMP}}"
+    lane: "planned"
+    agent: "system"
+    shell_pid: ""
+    action: "Prompt generated via /spec-kitty.tasks"
+---
+
+# Work Package Prompt: {{work_package_id}} – {{title}}
+
+## ⚠️ IMPORTANT: Review Feedback Status
+
+**Read this first if you are implementing this task!**
+
+- **Has review feedback?**: Check the `review_status` field above. If it says `has_feedback`, scroll to the **Review Feedback** section immediately (right below this notice).
+- **You must address all feedback** before your work is complete. Feedback items are your implementation TODO list.
+- **Mark as acknowledged**: When you understand the feedback and begin addressing it, update `review_status: acknowledged` in the frontmatter.
+- **Report progress**: As you address each feedback item, update the Activity Log explaining what you changed.
+
+---
+
+## Review Feedback
+
+> **Populated by `/spec-kitty.review`** – Reviewers add detailed feedback here when work needs changes. Implementation must address every item listed below before returning for re-review.
+
+*[This section is empty initially. Reviewers will populate it if the work is returned from review. If you see feedback here, treat each item as a must-do before completion.]*
+
+---
+
+## Markdown Formatting
+Wrap HTML/XML tags in backticks: `` `<div>` ``, `` `<script>` ``
+Use language identifiers in code blocks: ````python`, ````bash`
+
+---
+
+## Objectives & Success Criteria
+
+- Summarize the exact outcomes that mark this work package complete.
+- Call out key acceptance criteria or success metrics for the bundle.
+
+## Context & Constraints
+
+- Reference prerequisite work and related documents.
+- Link to supporting specs: `.kittify/memory/constitution.md`, `kitty-specs/.../plan.md`, `kitty-specs/.../tasks.md`, data model, contracts, research, quickstart.
+- Highlight architectural decisions, constraints, or trade-offs to honor.
+
+## Subtasks & Detailed Guidance
+
+### Subtask TXXX – Replace with summary
+- **Purpose**: Explain why this subtask exists.
+- **Steps**: Detailed, actionable instructions.
+- **Files**: Canonical paths to update or create.
+- **Parallel?**: Note if this can run alongside others.
+- **Notes**: Edge cases, dependencies, or data requirements.
+
+### Subtask TYYY – Replace with summary
+- Repeat the structure above for every included `Txxx` entry.
+
+## Test Strategy (include only when tests are required)
+
+- Specify mandatory tests and where they live.
+- Provide commands or scripts to run.
+- Describe fixtures or data seeding expectations.
+
+## Risks & Mitigations
+
+- List known pitfalls, performance considerations, or failure modes.
+- Provide mitigation strategies or monitoring notes.
+
+## Review Guidance
+
+- Key acceptance checkpoints for `/spec-kitty.review`.
+- Any context reviewers should revisit before approving.
+
+## Activity Log
+
+> **CRITICAL**: Activity log entries MUST be in chronological order (oldest first, newest last).
+
+### How to Add Activity Log Entries
+
+**When adding an entry**:
+1. Scroll to the bottom of this file (Activity Log section below "Valid lanes")
+2. **APPEND the new entry at the END** (do NOT prepend or insert in middle)
+3. Use exact format: `- YYYY-MM-DDTHH:MM:SSZ – agent_id – lane=<lane> – <action>`
+4. Timestamp MUST be current time in UTC (check with `date -u "+%Y-%m-%dT%H:%M:%SZ"`)
+5. Lane MUST match the frontmatter `lane:` field exactly
+6. Agent ID should identify who made the change (claude-sonnet-4-5, codex, etc.)
+
+**Format**:
+```
+- YYYY-MM-DDTHH:MM:SSZ – <agent_id> – lane=<lane> – <brief action description>
+```
+
+**Example (correct chronological order)**:
+```
+- 2026-01-12T10:00:00Z – system – lane=planned – Prompt created
+- 2026-01-12T10:30:00Z – claude – lane=doing – Started implementation
+- 2026-01-12T11:00:00Z – codex – lane=for_review – Implementation complete, ready for review
+- 2026-01-12T11:30:00Z – claude – lane=done – Review passed, all tests passing  ← LATEST (at bottom)
+```
+
+**Common mistakes (DO NOT DO THIS)**:
+- ❌ Adding new entry at the top (breaks chronological order)
+- ❌ Using future timestamps (causes acceptance validation to fail)
+- ❌ Lane mismatch: frontmatter says `lane: "done"` but log entry says `lane=doing`
+- ❌ Inserting in middle instead of appending to end
+
+**Why this matters**: The acceptance system reads the LAST activity log entry as the current state. If entries are out of order, acceptance will fail even when the work is complete.
+
+**Initial entry**:
+- {{TIMESTAMP}} – system – lane=planned – Prompt created.
+
+---
+
+### Updating Lane Status
+
+To change a work package's lane, either:
+
+1. **Edit directly**: Change the `lane:` field in frontmatter AND append activity log entry (at the end)
+2. **Use CLI**: `spec-kitty agent tasks move-task <WPID> --to <lane> --note "message"` (recommended)
+
+The CLI command updates both frontmatter and activity log automatically.
+
+**Valid lanes**: `planned`, `doing`, `for_review`, `done`
+
+### Optional Phase Subdirectories
+
+For large features, organize prompts under `tasks/` to keep bundles grouped while maintaining lexical ordering.

specify_cli/missions/documentation/templates/tasks-template.md

@@ -0,0 +1,159 @@
+---
+description: "Work package task list template for feature implementation"
+---
+
+# Work Packages: [FEATURE NAME]
+
+**Inputs**: Design documents from `/kitty-specs/[###-feature-name]/`
+**Prerequisites**: plan.md (required), spec.md (user stories), research.md, data-model.md, contracts/, quickstart.md
+
+**Tests**: Only include explicit testing work when stakeholders request it.
+
+**Organization**: Fine-grained subtasks (`Txxx`) roll up into work packages (`WPxx`). Each work package must be independently deliverable and testable.
+
+**Prompt Files**: Each work package references a matching prompt file in `/tasks/` generated by `/spec-kitty.tasks`. Treat this file as the high-level checklist; keep deep implementation detail inside the prompt files.
+
+## Subtask Format: `[Txxx] [P?] Description`
+- **[P]** indicates the subtask can proceed in parallel (different files/components).
+- Include precise file paths or modules.
+
+## Path Conventions
+- **Single project**: `src/`, `tests/`
+- **Web app**: `backend/src/`, `frontend/src/`
+- **Mobile**: `api/src/`, `ios/src/`, `android/src/`
+- Adjust paths to match the implementation plan.
+
+<!-- SAMPLE CONTENT BELOW. MUST BE REPLACED. -->
+
+---
+
+## Work Package WP01: Setup & Environment (Priority: P0)
+
+**Goal**: Establish project skeleton and shared tooling.
+**Independent Test**: Project bootstraps locally with linting and formatter hooks in place.
+**Prompt**: `/tasks/WP01-setup-and-environment.md`
+
+### Included Subtasks
+- [ ] T001 Create project structure per implementation plan
+- [ ] T002 Initialize [language] project with [framework] dependencies
+- [ ] T003 [P] Configure linting and formatting tools
+
+### Implementation Notes
+- Major steps, commands, or configuration files required.
+
+### Parallel Opportunities
+- Highlight subtasks that can proceed concurrently.
+
+### Dependencies
+- None (starting package).
+
+### Risks & Mitigations
+- Example: Tooling compatibility across contributors; pin versions in `.tool-versions`.
+
+---
+
+## Work Package WP02: Foundational Platform (Priority: P0)
+
+**Goal**: Deliver shared services all user stories depend on.
+**Independent Test**: Foundational services pass smoke tests; downstream work packages can start.
+**Prompt**: `/tasks/WP02-foundational-platform.md`
+
+### Included Subtasks
+- [ ] T004 Setup database schema and migrations framework
+- [ ] T005 [P] Implement authentication/authorization framework
+- [ ] T006 [P] Setup API routing and middleware structure
+- [ ] T007 Create base models/entities shared across stories
+- [ ] T008 Configure error handling and logging infrastructure
+- [ ] T009 Setup environment configuration management
+
+### Implementation Notes
+- Provide sequencing, infrastructure CLI commands, secrets requirements.
+
+### Parallel Opportunities
+- Authentication and routing can proceed in parallel once schema scaffolding exists.
+
+### Dependencies
+- Depends on WP01.
+
+### Risks & Mitigations
+- Migration drift → enforce migration linting in CI.
+
+---
+
+## Work Package WP03: User Story 1 – [Title] (Priority: P1) 🎯 MVP
+
+**Goal**: [Brief description of story outcome]
+**Independent Test**: [Describe how to validate the story independently]
+**Prompt**: `/tasks/WP03-user-story-1.md`
+
+### Included Subtasks
+- [ ] T010 [P] Contract test for [endpoint] in `tests/contract/test_[name].py`
+- [ ] T011 [P] Integration test for [journey] in `tests/integration/test_[name].py`
+- [ ] T012 [P] Create [Entity1] model in `src/models/[entity1].py`
+- [ ] T013 [P] Create [Entity2] model in `src/models/[entity2].py`
+- [ ] T014 Implement [Service] in `src/services/[service].py` (depends on T012, T013)
+- [ ] T015 Implement [endpoint/feature] in `src/[location]/[file].py`
+- [ ] T016 Add validation and error handling
+- [ ] T017 Add story-specific logging and metrics
+
+### Implementation Notes
+- Enumerate the workflow (tests first if required, then models → services → endpoints).
+
+### Parallel Opportunities
+- Mention any subtasks that can be split among engineers safely.
+
+### Dependencies
+- Depends on WP02.
+
+### Risks & Mitigations
+- Data integrity risk → include migration rollback plan.
+
+---
+
+## Work Package WP0N: Polish & Cross-Cutting (Priority: Px)
+
+**Goal**: Cross-story improvements and hardening work.
+**Independent Test**: Regression suite passes; observability and documentation updated.
+**Prompt**: `/tasks/WP0N-polish-and-cross-cutting.md`
+
+### Included Subtasks
+- [ ] T0XX Documentation updates in `docs/`
+- [ ] T0XX Code cleanup and refactoring
+- [ ] T0XX Performance optimization across stories
+- [ ] T0XX Security hardening
+- [ ] T0XX Validate quickstart.md scenario
+
+### Implementation Notes
+- Capture finishing touches and validation guidance.
+
+### Parallel Opportunities
+- Identify items safe to run alongside final story testing.
+
+### Dependencies
+- Depends on completion of relevant story packages.
+
+### Risks & Mitigations
+- Regression risk → enforce smoke test before release.
+
+---
+
+## Dependency & Execution Summary
+
+- **Sequence**: WP01 → WP02 → Story-driven packages (priority order) → WP0N polish.
+- **Parallelization**: Highlight safe parallel combinations once prerequisites complete.
+- **MVP Scope**: Call out which work packages constitute the minimal release.
+
+---
+
+## Subtask Index (Reference)
+
+| Subtask ID | Summary | Work Package | Priority | Parallel? |
+|------------|---------|--------------|----------|-----------|
+| T001       | Example | WP01         | P0       | No        |
+| T002       | Example | WP01         | P0       | Yes       |
+| T010       | Example | WP03         | P1       | Yes       |
+| T014       | Example | WP03         | P1       | No        |
+
+---
+
+> Replace all placeholder text above with feature-specific content. Keep this template structure intact so downstream automation can parse work packages reliably.