flutter-worktrees
Use when starting feature work that needs isolation from current workspace - creates isolated git worktrees with Flutter project setup
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when starting feature work that needs isolation from current workspace - creates isolated git worktrees with Flutter project setup
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
| name | flutter-worktrees |
| description | Use when starting feature work that needs isolation from current workspace - creates isolated git worktrees with Flutter project setup |
Git worktrees let you work on multiple branches simultaneously in separate directories. Each worktree is fully independent - you can run different Flutter versions, have different dependencies, without affecting your main workspace.
Core principle: Isolated workspace = safe experimentation + parallel development
Announce at start: "I'm using the flutter-worktrees skill to create an isolated workspace."
# From main repository
git worktree add ../flutter-app-feature-auth feature/auth
# Or create new branch
git worktree add -b feature/auth ../flutter-app-feature-auth main
Naming convention: ../[project-name]-[feature-name]
cd ../flutter-app-feature-auth
# Install dependencies
flutter pub get
# Verify Flutter is working
flutter doctor
# If needed, run code generation
dart run build_runner build --delete-conflicting-outputs
# Check project state
flutter analyze
flutter test
# Should show no issues if setup is correct
Follow normal development workflow:
All changes stay isolated in this worktree.
# From main repository
cd ../flutter-app # Back to main
# Remove worktree
git worktree remove ../flutter-app-feature-auth
# If branch was merged, it's already in main
# If discarded, the branch still exists and can be deleted:
git branch -D feature/auth
parent-directory/
├── flutter-app/ # Main repository
│ ├── lib/
│ ├── test/
│ ├── pubspec.yaml
│ └── .git/ # Main git directory
├── flutter-app-feature-auth/ # Worktree 1
│ ├── lib/
│ ├── test/
│ ├── pubspec.yaml
│ └── .git # File pointing to main .git
└── flutter-app-feature-profile/ # Worktree 2
├── lib/
├── test/
├── pubspec.yaml
└── .git
Each worktree has its own:
.dart_tool/ directorypubspec.lock (can differ if experimenting with versions)Always run flutter pub get after creating worktree!
If project uses code generation (freezed, json_serializable, etc.):
dart run build_runner build --delete-conflicting-outputs
VS Code: Open worktree folder as new workspace Android Studio: Open worktree folder as new project
Each worktree can have different:
No conflicts between worktrees!
# 1. Create isolated workspace for auth feature
git worktree add -b feature/auth ../flutter-app-auth main
# 2. Navigate and setup
cd ../flutter-app-auth
flutter pub get
dart run build_runner build --delete-conflicting-outputs
# 3. Verify
flutter analyze
flutter test
# 4. Work on feature (using flutter-craft skills)
# ... implement auth feature ...
# 5. When done, back to main
cd ../flutter-app
# 6. Merge if ready
git merge feature/auth
# 7. Cleanup
git worktree remove ../flutter-app-auth
Never:
flutter pub get in new worktreegit worktree remove)If worktree has issues:
# List all worktrees
git worktree list
# Prune stale worktree references
git worktree prune
After creating worktree:
After feature complete:
| Command | Purpose |
|---|---|
git worktree add <path> <branch> | Create worktree |
git worktree add -b <new-branch> <path> <base> | Create with new branch |
git worktree list | List all worktrees |
git worktree remove <path> | Remove worktree |
git worktree prune | Clean stale references |
flutter pub get | Required after creating! |
Creates a new Flutter project with Clean Architecture, domain pattern boilerplate, and production-ready setup
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation using Clean Architecture principles.
Use when you have a written implementation plan to execute with review checkpoints
Use when facing 2+ independent Flutter tasks that can be worked on without shared state or sequential dependencies
Use when you have a design or requirements for a multi-step Flutter feature, before touching code
Use when executing Flutter implementation plans with independent tasks in the current session