Use when starting any conversation - establishes how to find and use Flutter development skills, requiring Skill tool invocation before ANY response including clarifying questions
/plugin marketplace add vp-k/flutter-craft/plugin install vp-k-flutter-craft-plugins-flutter-craft@vp-k/flutter-craftThis skill inherits all available tools. When active, it can use any tool Claude has access to.
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>
You have access to Flutter-specific development skills that follow Feature-Driven Development with Clean Architecture principles.
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 TodoWrite per item
│ → Follow skill exactly
└─ NO → Respond (including clarifications)
| Skill | When to Use |
|---|---|
| flutter-project-init | Creating a NEW Flutter project from scratch |
| Skill | When to Use |
|---|---|
| flutter-brainstorming | Before ANY new feature, component, or creative work |
| flutter-planning | After brainstorming, to create detailed implementation plan |
| flutter-executing | When you have a plan file to execute (batch of 3 tasks) |
| flutter-verification | Before claiming ANY work is complete |
| flutter-debugging | Before fixing ANY bug or error |
| Skill | When to Use |
|---|---|
| flutter-testing | When writing tests (priority: Repository → State → Widget) |
| flutter-review-request | After completing implementation, before merge |
| flutter-review-receive | When processing code review feedback |
| Skill | When to Use |
|---|---|
| flutter-subagent-dev | For parallel task implementation with 2-stage review |
| flutter-parallel-agents | When 2+ independent tasks can run in parallel |
| flutter-worktrees | When isolated workspace needed for feature development |
| flutter-finishing | When all tasks complete, to decide merge/PR/keep/discard |
| flutter-writing-skills | When creating new skills for flutter-craft |
These thoughts mean STOP—you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple widget" | Widgets need architecture. Check for skills. |
| "I'll just add a quick feature" | Features need brainstorming. Check first. |
| "Let me fix this bug quickly" | Bugs need systematic debugging. Check first. |
| "The code is done, it should work" | Verify before claiming done. Check for skills. |
| "This doesn't need Clean Architecture" | All Flutter code benefits from structure. |
| "I'll write tests later" | Testing priority exists for a reason. Check first. |
| "This is obvious, no planning needed" | Simple things become complex. Use planning. |
| "Let me just check the code first" | Skills tell you HOW to explore. Check first. |
| Context | Required Skill |
|---|---|
| User says "new project", "create project", "start project" | flutter-project-init |
| User says "add feature", "create", "build" | flutter-brainstorming → flutter-planning |
| User says "fix bug", "error", "not working" | flutter-debugging |
| Plan file exists in docs/plans/ | flutter-executing |
| About to say "done", "complete", "fixed" | flutter-verification FIRST |
| User says "review", "check my code" | flutter-review-request |
| Multiple independent tasks identified | flutter-parallel-agents |
When multiple skills could apply, use this order:
Example flows:
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)
Some skills REQUIRE invoking another skill after completion:
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.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.