2.8 KiB
2.8 KiB
| allowed-tools | description |
|---|---|
| Bash(git *), Read, Write, Edit, Glob, Grep, Bash(dotnet build:*), Bash(dotnet test:*), Bash(dotnet ef:*), AskUserQuestion | Identify the next step in the plan, and start implementing this phase (project) |
Context
- Implementation Plan: !
cat docs/IMPLEMENTATION_PLAN.md | head -400 - Current branch: !
git branch --show-current - Git status: !
git status --porcelain
Your Task - Implement Next Phase
Follow these steps in order:
Step 1: Identify Next Phase
- Read
docs/IMPLEMENTATION_PLAN.md - Find the first row in the table with
☐(open status) - Extract: Phase ID (e.g., C1), Bereich, Beschreibung
- Read the detailed phase section (e.g., "### Phase C1: ...")
- Summarize what needs to be implemented
Step 2: Create Git Branch
- Check git status is clean (no uncommitted changes)
- If dirty, warn user and STOP
- Create branch:
git checkout -b feature/<phase-id>-<short-description>- Example:
feature/c1-club-state-fluxor
- Example:
- Confirm branch created
Step 3: Implement Phase
- Follow the detailed phase description from the plan
- Create/modify files as specified
- Follow project conventions from CLAUDE.md:
- Clean Architecture layers
- XML documentation in English
- Fluxor pattern for state (Actions/Reducers/Effects)
- MudBlazor for UI components
- Build after each major change:
dotnet build - Commit logical chunks with descriptive messages
Step 4: Review Implementation
Perform code review checklist:
Code Conventions:
- Follows Clean Architecture layer separation
- XML documentation on public members (English)
- Proper namespacing and file organization
Error Handling:
- Loading states in Blazor components
- Null checks where appropriate
- Validation on user inputs
Accessibility:
- MudBlazor components use proper labels
- Form fields have Label properties
Tests:
- Run:
dotnet test test/Koogle.Tests - New functionality has tests (if applicable)
Security:
- Authorization attributes on protected resources
- Input validation on boundaries
Build:
dotnet buildsucceeds without errors/warnings
Step 5: Mark Phase Complete
- Edit
docs/IMPLEMENTATION_PLAN.md - In the overview table, change the phase row from
☐to✓ - Example:
| ☐ | **C1** |becomes| ✓ | C1 | - Remove bold formatting when marking complete
- Commit: "Complete phase : "
Step 6: Summary
Report:
- Phase completed
- Files created/modified
- Any issues encountered
- Next phase preview (what comes after)
Important Notes
- If build fails, fix before proceeding
- If tests fail, fix before marking complete
- Ask user for clarification if phase description is ambiguous
- Do NOT skip steps - follow the workflow strictly