| name | Project Planning for Photo Map MVP |
| description | Break down, design, and structure features into implementable tasks for Photo Map MVP. Use when planning new features, creating user stories, defining API endpoints, structuring implementation phases, organizing project tasks, or designing feature breakdowns. |
| allowed-tools | Read, Write, Edit, Grep, Glob |
Project Planning - Photo Map MVP
Project Context
Photo Map MVP to full-stack aplikacja do zarządzania zdjęciami z geolokalizacją.
Stack: Angular 18 (standalone), Spring Boot 3, Java 17, PostgreSQL 15
Deployment: Mikrus VPS (limited resources, no background jobs)
Timeline: 10 dni (6 faz implementacji)
Core Features:
- Authentication (JWT-based login/registration)
- Photo Management (Upload z EXIF, thumbnails, CRUD)
- Gallery View (Responsive grid, rating, filtering)
- Map View (Leaflet.js, GPS markers, clustering)
- Admin Panel (User management)
Key Constraints (Mikrus VPS):
- ❌ No background jobs (Celery, Sidekiq) → synchronous processing
- ❌ No resource-intensive operations (ML, heavy processing)
- ✅ In-memory cache (60s TTL) - no Redis
- ✅ Synchronous thumbnail generation
Więcej szczegółów: references/mvp-scope-boundaries.md
When to Use This Skill
Użyj tego skilla gdy:
- Planujesz dodanie nowej funkcji do Photo Map MVP
- Weryfikujesz pomysł pod kątem MVP scope
- Oceniasz złożoność implementacji
- Rozbijasz funkcję na małe zadania (chunks)
- Identyfikujesz ryzyka nowej funkcji
NIE używaj gdy:
- Szukasz szczegółów technicznych (API specs →
.ai/api-plan.md)
- Szukasz database schema (→
.ai/db-plan.md)
- Szukasz frontend architecture (→
.ai/ui-plan.md)
Feature Verification Process
Proces weryfikacji nowego pomysłu (5 kroków):
Krok 1: MVP Scope Check
Pytanie: Czy funkcja pasuje do MVP?
Sprawdzenie:
- Czy funkcja wymieniona w
.ai/prd.md Core Features? → ✅ GO
- Czy funkcja w "Out of Scope" liście? → ❌ STOP
- Czy funkcja rozwiązuje core problem? → ✅ GO / ❌ STOP
Decision:
- ✅ In Scope → Kontynuuj do Kroku 2
- ⚠️ Maybe → Szukaj simplified version, consulta z użytkownikiem
- ❌ Out of Scope → Odrzuć lub consulta (jeśli strong business case)
Szczegóły: references/mvp-scope-boundaries.md
Krok 2: Tech Stack Compatibility
Pytanie: Czy funkcja zgodna z tech stack i constraints?
Sprawdzenie:
- Sprawdź
.ai/tech-stack.md - czy używamy odpowiednich technologii?
- Mikrus VPS constraints:
- Czy wymaga background jobs? → ❌ (use Spring Integration workaround)
- Czy resource-intensive? → ⚠️ (carefully)
- Czy wymaga nowych bibliotek? → Lista i oceń
Decision:
- ✅ Compatible → Kontynuuj do Kroku 3
- ⚠️ Needs Workaround → Zaplanuj alternatywne podejście
- ❌ Incompatible → Odrzuć lub zmień approach
Krok 3: Complexity Assessment
Pytanie: Jaka jest złożoność funkcji?
Ocena złożoności (sprawdź tabelę w sekcji "Complexity Levels" poniżej):
- Database changes? (ADD COLUMN / CREATE TABLE / None)
- API endpoints? (0 / 1-2 / 3+)
- Frontend + Backend? (Yes / No)
- Async processing? (Yes / No)
Decision:
- Simple: 1-2 chunks (1-2h) → Szybkie wykonanie
- Medium: 3-5 chunks (3-6h) → Checkpoints co 3 chunks
- Complex: 6+ chunks (6-12h) → Multiple checkpoints
Szczegóły: references/complexity-assessment.md
Krok 4: Implementation Planning
Pytanie: Jak rozbić funkcję na małe chunks?
Pattern: 3 małe zadania (30-60 min każde) → Checkpoint
Dla każdego chunk:
- Implement - napisać kod (1 endpoint/component/method)
- Test - zweryfikować (curl/browser)
- Commit - zapisać (Conventional Commits)
Po 3 chunks → CHECKPOINT:
- Pokazać użytkownikowi działającą funkcję
- Zebrać feedback
- Kontynuować lub adjust
Przykłady:
- Simple feature:
examples/simple-feature-example.md
- Medium feature:
examples/good-feature-breakdown.md
- Complex feature:
examples/complex-feature-example.md
Krok 5: Risk Identification
Pytanie: Co może pójść nie tak?
Common Risks:
- Performance: Slow queries, large files, timeouts
- Security: User scoping violations, validation gaps, SQL injection
- Race conditions: Concurrent updates, database locks
- Error handling: Edge cases, corrupt files, network failures
- Migration: Rollback strategy, data loss
Dla każdego risk:
- Zidentyfikuj impact (High / Medium / Low)
- Zaplanuj mitigation strategy
- Dokumentuj w feature proposal
Template: templates/feature-proposal-template.md
Complexity Levels
| Level | Timeline | DB Changes | Endpoints | Example |
|---|
| Simple | 1-2 chunks
(1-2h) | ADD COLUMN (nullable)
or None | 0 (modify existing)
or None | Add photo description field |
| Medium | 3-5 chunks
(3-6h) | ADD COLUMN + INDEX
or simple changes | 1-2 new endpoints | Rating system (1-5 stars) |
| Complex | 6+ chunks
(6-12h) | CREATE TABLE
+ relations | 3+ new endpoints | Batch upload async (Spring Integration) |
Complexity Decision Tree
Q1: Database changes?
- None/ADD COLUMN (nullable) → likely Simple
- ADD COLUMN + INDEX → likely Medium
- CREATE TABLE + relations → likely Complex
Q2: New endpoints?
- 0 (modify existing) → likely Simple
- 1-2 → likely Medium
- 3+ → likely Complex
Q3: Async processing needed?
- No → Simple/Medium
- Yes → Complex (Spring Integration required)
Q4: External dependencies?
- None → Simple/Medium
- New libraries → likely Complex
Szczegóły i przykłady: references/complexity-assessment.md
Quick Reference Tables
Tabela 1: Kiedy Czytać References?
| Pytanie | Reference File |
|---|
| Czy pomysł pasuje do MVP? | mvp-scope-boundaries.md |
| Jak ocenić złożoność? | complexity-assessment.md |
| Jak przeprowadzić weryfikację? | verification-checklist.md |
| Jak wygląda proces planowania PRD? | prd-planning-process.md |
| Jakie są fazy implementacji? | implementation-phases.md |
Tabela 2: Kiedy Używać Examples?
| Scenario | Example File |
|---|
| Pomysł odrzucony (out of scope) | feature-verification-example.md |
| Dobry breakdown funkcji (Medium) | good-feature-breakdown.md |
| Over-engineered funkcja (BAD) | bad-feature-example.md |
| Prosta funkcja (Simple) | simple-feature-example.md |
| Złożona funkcja (Complex) | complex-feature-example.md |
Tabela 3: Kiedy Używać Templates?
| Zadanie | Template File |
|---|
| Weryfikacja nowego pomysłu | feature-proposal-template.md |
| Plan implementacji | implementation-plan-template.md |
| Napisanie user story | user-story-template.md |
| Specyfikacja API endpoint | api-endpoint-spec-template.md |
| Sesja planistyczna PRD | prd-planning-session-template.md |
| Podsumowanie sesji PRD | prd-summary-template.md |
| Analiza tech stacku | tech-stack-analysis-template.md |
Related Documentation
Core Context (.ai/)
Główne dokumenty implementacyjne:
.ai/prd.md - MVP requirements (user stories, acceptance criteria).ai/tech-stack.md - Technology specs (stack, constraints, versions).ai/db-plan.md - Database schema (tables, relations, indexes).ai/api-plan.md - REST API specification (endpoints, DTOs, errors).ai/ui-plan.md - Frontend architecture (components, services, routing)
Decision Context (.decisions/)
Rationale dla decyzji (optional read):
.decisions/prd-context.md - Business context + future vision.decisions/tech-decisions.md - Technology decisions rationale
Project Status
PROGRESS_TRACKER.md - Current implementation status (6 phases, current task)
Skill Resources
references/ - Szczegółowa dokumentacja (7 plików)examples/ - Konkretne przykłady z Photo Map MVP (5 plików)templates/ - Gotowe szablony do użycia (7 plików)
