refactor: change GitHub workflow from task-level to phase-level issues

Update the feature workflow commands to create GitHub issues per phase
instead of per individual task. This reduces issue clutter while still
maintaining granular task tracking via checklists within phase issues.

Key changes:

**publish-to-github.md:**
- Create phase issues instead of individual task issues
- Each phase issue contains the full task checklist from implementation plan
- Add support for `[complex]` marker to break out complex tasks as separate issues
- Update Epic to link to phase issues instead of tasks
- Update github.md template to show phases and optional complex task issues

**create-feature.md:**
- Add documentation for `[complex]` task marker
- Update implementation plan format example with nested sub-tasks
- Add "When to Use [complex]" guidance section

**continue-feature.md:**
- Rewrite workflow to work with phase issues instead of task issues
- Add logic to identify current phase and find unchecked tasks
- Support both phase issue tasks and complex task issues
- Add step to update phase issue checklist after completing tasks
- Update completion reporting for phase-based progress
- Renumber steps (8.x → 7.x) for consistency

**Hybrid approach:**
- Default: one issue per phase with task checklists
- Optional: break out tasks marked `[complex]` or with nested sub-tasks
- Complex task issues link back to parent phase issue

This change results in ~5 issues (1 epic + 4 phases) instead of ~47 issues
for a typical feature, significantly reducing GitHub issue noise.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

.claude/commands/create-feature.md

@@ -25,6 +25,7 @@ This command creates a new feature specification folder with requirements and im
    - Each task should have a checkbox: `[ ] Task description`
    - Tasks should be specific enough for an agent to implement independently
    - Include dependencies between tasks where relevant
+   - Mark complex tasks with `[complex]` suffix (these will get their own GitHub issue when published)
 
 4. **Create action-required.md**
    - Extract all manual steps that require human action
@@ -64,7 +65,9 @@ Brief summary of what will be built.
 
 - [ ] Task 1 description
 - [ ] Task 2 description (depends on Task 1)
-- [ ] Task 3 description
+- [ ] Task 3 description [complex]
+  - [ ] Sub-task 3a
+  - [ ] Sub-task 3b
 
 ## Phase 2: {Phase Name}
 
@@ -77,6 +80,8 @@ Brief summary of what will be built.
       ...
 ```
 
+**Note:** Tasks marked with `[complex]` or containing nested sub-tasks will be created as separate GitHub issues when published (linked to their parent phase issue).
+
 ## action-required.md Format
 
 Use this structure for `action-required.md`:
@@ -135,3 +140,13 @@ After creating the feature, inform the user:
 - Use clear, descriptive task names that explain what will be done
 - Note dependencies explicitly when tasks must be done in order
 - Common manual tasks: account creation, API key generation, environment variables, OAuth app configuration, DNS/domain setup, billing setup, third-party service registration
+
+### When to Use `[complex]`
+
+Mark a task with `[complex]` when it:
+- Has multiple sub-tasks that need individual tracking
+- Requires significant architectural decisions or discussion
+- Spans multiple files or systems
+- Would benefit from its own GitHub issue for comments/review
+
+Most tasks should NOT be marked complex - reserve this for genuinely substantial work items.