GigLedger Development Orchestrator

Purpose

This skill serves as the primary development guide for GigLedger. It orchestrates development by:

1. •Enforcing documentation as source of truth - All decisions reference docs/
2. •Managing GitHub project tickets - Implements features from https://github.com//projects/1
3. •Updating launch checklist - Marks items complete in docs/10_launch_checklist.md
4. •Ensuring code standards - Validates implementation against architectural docs

Core Principle

If it's not in the docs, it's not a requirement.

All implementation decisions must reference the appropriate documentation file.

Documentation Structure (Source of Truth)

Critical Architectural Rules

These rules are non-negotiable and enforced on every feature:

1. [Backend Communication Rule]

• •Client communicates through proper channels only
• •No direct external API calls from client

Reference: docs/06_integration_spec.md

2. [Architecture Pattern] Architecture

Every feature must follow this structure:

lib/features/{feature_name}/
├── presentation/    # UI components, pages, state
├── application/     # Use cases, business logic services
├── domain/         # Models, repository interfaces
└── data/           # DTOs, implementations

Reference: docs/07_app_architecture.md

3. Data Flow Direction

UI → State → Use Case → Repository (Domain)
  → Repository Impl (Data) → Backend

Never bypass layers or skip the domain layer.

4. DTO vs Domain Models

• •DTOs (data layer): Match database, nullable, defensive
• •Domain Models (domain/application): Non-null, computed fields allowed

Reference: docs/05_data_model_and_schema.md

Workflow for Implementing GitHub Tickets

When working on a ticket from https://github.com//projects/1:

Step 1: Validate Scope

1. •Read the ticket requirements
2. •Check docs/02_mvp_prd.md to confirm it's in scope
3. •If out of scope, flag it and ask for clarification

Step 2: Reference Documentation

1. •Identify which docs apply to this feature
2. •Read the relevant sections completely
3. •Note any constraints or requirements

Step 3: Plan Implementation

1. •Determine which feature module this belongs to
2. •Plan the four-layer structure
3. •Identify required database collections (reference docs/05_data_model_and_schema.md)
4. •Plan data flow from backend to UI

Step 4: Implement

1. •Create feature directory structure
2. •Implement layers in order: Domain → Data → Application → Presentation
3. •Use [state management] for state management
4. •Follow best practices from docs/07_app_architecture.md

Step 5: Update Checklist

After completing a feature, update docs/10_launch_checklist.md:

• •Mark relevant items as [x] when completed
• •Add notes if needed
• •Commit the checklist update with the feature

Updating the Launch Checklist

The checklist in docs/10_launch_checklist.md tracks production readiness. Update it as you complete items:

Before:

- [ ] All MVP screens implemented

After:

- [x] All MVP screens implemented

Always update the checklist in the same commit as the feature that completes it.

MVP Scope Enforcement

In Scope (Implement These)

Reference: docs/02_mvp_prd.md section 3

Out of Scope (Reject These)

Reference: docs/02_mvp_prd.md section 4

Code Quality Standards

State Management

• •Use [state management solution] providers
• •One state object per screen
• •Immutable state patterns
• •Handle async with [async pattern]

Error Handling

• •Graceful degraded UI for missing data
• •Never block navigation on errors
• •Show data freshness indicators
• •Log errors for monitoring

Performance

• •Enable database persistence
• •Cache expensive computations in memory
• •Avoid rebuilding expensive UI
• •Use server-aggregated data
• •Paginate large datasets

Security

• •No API keys in client code
• •Read-only access to protected data
• •Users only read/write their own profile
• •All sensitive operations through backend

Testing Requirements

Reference: docs/07_app_architecture.md (testing section)

• •Unit tests: Domain models, use cases, aggregation logic
• •Widget/Component tests: Core screens, critical interactions
• •Integration tests: Database read flows, navigation paths

GitHub Project Integration

When pulling tickets from https://github.com//projects/1:

1. •Read ticket description fully
2. •Map to documentation - Which docs apply?
3. •Validate scope - Is it in MVP?
4. •Plan implementation - Four-layer structure
5. •Implement with docs open - Reference constantly
6. •Update checklist - Mark progress in docs/10_launch_checklist.md
7. •Test according to standards
8. •Commit with documentation references in commit message

When to Use Other Skills

This orchestrator skill delegates to specialized skills for deep dives:

• •architecture-expert: Detailed four-layer implementation questions
• •schema-expert: Database design and DTO questions
• •integration-expert: Backend integration specifics
• •mvp-validator: Quick scope validation checks

Questions to Ask Before Coding

1. •Is this feature in docs/02_mvp_prd.md section 3 (In-Scope)?
2. •Which database collections do I need? (Check docs/05_data_model_and_schema.md)
3. •Does this require external data? (If yes, must use backend proxy per docs/06_integration_spec.md)
4. •Which feature module does this belong to?
5. •What are the acceptance criteria? (Check PRD)

Documentation Updates

If you discover something unclear or not documented:

1. •Do not assume - Stop and ask for clarification
2. •Update docs first - Add the decision to appropriate doc
3. •Then implement - Code only after docs are clear

Summary

This skill ensures that GigLedger development:

• •Always follows documented architecture
• •Validates scope against MVP PRD
• •Updates launch checklist as features complete
• •References GitHub tickets with documentation context
• •Maintains code quality and testing standards
• •Never bypasses architectural constraints

Remember: Docs are the source of truth. Code follows docs, not the other way around.