vp-k/flutter-craft/start-flutter-craft

<EXTREMELY-IMPORTANT> If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST read the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this. </EXTREMELY-IMPORTANT>

Using Flutter-Craft Skills

You have access to Flutter-specific development skills that follow Feature-Driven Development with Clean Architecture principles.

The Rule

Check for skills BEFORE ANY RESPONSE. This includes clarifying questions. Even 1% chance means invoke the Skill tool first.

User message received
    ↓
Might any skill apply? (even 1%?)
    ├─ YES → Invoke Skill tool: flutter-craft:<skill-name>
    │        → Announce: "Using [skill] to [purpose]"
    │        → Has checklist? → Create a todo entry per item (task tracking tool)
    │        → Follow skill exactly
    └─ NO  → Respond (including clarifications)

Available Skills

Project Setup Skills

Core Workflow Skills

Testing & Review Skills

Utility Skills

Red Flags

These thoughts mean STOP—you're rationalizing:

Flutter-Specific Triggers

Lightweight Path (small changes)

The full brainstorm → plan → execute chain is for new features and behavior changes. It is NOT required for trivial work. If ALL of these hold:

• Single file (or a comment/typo/rename across files)
• No new behavior, no state management change, no new dependency
• No architecture decision to make

then make the change directly and invoke flutter-verification only. When in doubt whether a change is trivial, it isn't — use the full chain.

Skill Priority

When multiple skills could apply, use this order:

1. Process skills first (brainstorming, debugging) - these determine HOW to approach
2. Implementation skills second (executing, testing) - these guide execution
3. Completion skills last (verification, finishing) - these ensure quality

Example flows:

• "Add login feature" → flutter-brainstorming → flutter-planning → flutter-executing
• "Fix auth bug" → flutter-debugging → flutter-verification
• "Fix typo in a label" → direct edit → flutter-verification (lightweight path)
• "Review my code" → flutter-review-request

Clean Architecture Reminder

All Flutter code should follow Clean Architecture layers:

lib/
└── features/
    └── <feature_name>/
        ├── domain/          # Entities, UseCases, Repository interfaces
        ├── data/            # Models, DataSources, Repository implementations
        └── presentation/    # Widgets, State Management (BLoC/Provider/Riverpod)

REQUIRED SUB-SKILL Chaining

Some skills REQUIRE invoking another skill after completion:

• flutter-brainstorming → MUST invoke → flutter-planning
• flutter-executing → MUST invoke → flutter-verification (each batch)
• flutter-executing (all done) → MUST invoke → flutter-finishing
• flutter-debugging → MUST invoke → flutter-verification

User Instructions

Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.

REMEMBER: If in doubt, invoke the skill. It's better to check and not need it than to skip and miss important steps.