Blog posts: The Deep Trilogy - How the three plugins work together What I Learned - Technical lessons from plugin development /deep-project transforms vague, high-level project requirements into well-scoped planning units through AI-assisted interview and
Blog posts: The Deep Trilogy - How the three plugins work together What I Learned - Technical lessons from plugin development /deep-implement is the final step in the deep planning pipeline.
@piercelambFAQ
deep-project is a Claude Code plugin with 1 hand-picked skill for productivity work, indexed on Flowy. Install it with the command on its page. It includes deep-project. Its skills do not fire on their own yet. Request auto-invocation to have Flowy route them as you prompt. Free and open source.
> /plugin marketplace add piercelamb/deep-project> /plugin install deep-project@piercelamb-plugins
Blog posts:
- The Deep Trilogy - How the three plugins work together
- What I Learned - Technical lessons from plugin development
/deep-project transforms vague, high-level project requirements into well-scoped planning units through AI-assisted interview and decomposition. It ensures you've thought through every major component of the software you want to build and properly scoped them for thorough planning through /deep-plan.
This plugin is the first step in the deep planning pipeline. After decomposition, each unit can be fed to /deep-plan for comprehensive planning with research, external LLM review, and a TDD approach.
I built this after the first time I wanted to put a vague, broadly scoped software project through /deep-plan. I realized that at a certain level of broadness, for e.g., "Build me an app that does x y and z", that the optimal use of /deep-plan would be to split that vague idea into its distinct, major components and /deep-plan each of them. /deep-project is the plugin that allows you to give it very broad, vague ideas and have it tease out context and form the components that should each be /deep-planned.
/plugin marketplace add piercelamb/deep-project
/plugin install deep-project
/plugin enable deep-project
/deep-project @planning/requirements.md
deep-project orchestrates a decomposition workflow that breaks large projects into manageable pieces before detailed planning:
Interview → Split Analysis → Dependency Mapping → Directory Creation → Spec Generation
The plugin guides you through:
By the end, you have a planning directory with a project manifest and numbered split directories, each containing a spec file ready for /deep-plan.
This plugin is part of a three-plugin pipeline for turning ideas into production code:
/deep-project (decompose) → /deep-plan (plan) → /deep-implement (build)
┌───────────────────────────────────────────────────────────────────┐
│ THE DEEP TRILOGY │
│ From Vague Idea to Production Code │
├───────────────────────────────────────────────────────────────────┤
│ │
│ "I want to build a SaaS platform" │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ /deep-project │ ◀── YOU ARE HERE │
│ └─────────────────────────────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 01-auth │ │ 02-bill │ │ ... │ │
│ │ spec.md │ │ spec.md │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ /deep- │ │ /deep- │ │ ... │ │
│ │ plan │ │ plan │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ ┌────┐┌────┐┌────┐┌────┐┌────┐┌─────────┐ │
│ │ 01 ││ 02 ││ 01 ││ 02 ││ 03 ││ ... │ │
│ └────┘└────┘└────┘└────┘└────┘└─────────┘ │
│ │ │ │ │ │ │ │
│ └─┬──┘ └──┬──┴────┘ │ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐┌─────────┐ ┌─────────┐ │
│ │ /deep- ││ /deep- │ │ ... │ │
│ │implement││implement│ │ │ │
│ └─────────┘└─────────┘ └─────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐┌─────────┐ ┌─────────┐ │
│ │ auth ││ billing │ │ ... │ │
│ │ code ││ code │ │ │ │
│ └─────────┘└─────────┘ └─────────┘ │
│ │ │ │ │
│ └──────────┴──────────────────┘ │
│ │ │
│ ▼ │
│ Production Codebase │
│ │
└───────────────────────────────────────────────────────────────────┘
| Plugin | Purpose | Input | Output |
|---|---|---|---|
/deep-project | Decompose | Vague requirements | Focused spec files |
/deep-plan | Plan | Spec file | Section files with TDD |
/deep-implement | Build | Section files | Production code |
Where to start?
/deep-project/deep-plan/deep-implementYou: "Claude, I need to build a complete SaaS platform"
Claude: *overwhelmed by scope, makes assumptions, misses critical relationships*
Result: Inconsistent implementation, integration issues, rework
You: "/deep-project @planning/saas-requirements.md"
deep-project: Interview → Split Analysis → Manifest → Spec Files
Result:
- 01-auth-system/spec.md
- 02-billing-integration/spec.md
- 03-user-dashboard/spec.md
Each ready for focused /deep-plan sessions
Time Investment: ~15 minutes of interview Time Saved: Hours of coordination and rework from poorly scoped planning
Use deep-project when:
Skip deep-project when:
TL;DR: Create a requirements file, run the command, answer questions.
1. Create a requirements file:
Option A: Use your editor — Create planning/requirements.md with your project description.
Option B: Command line:
mkdir -p planning
cat > planning/requirements.md << 'EOF'
# My SaaS Platform
Build a complete SaaS platform with:
- User authentication (OAuth, email/password)
- Subscription billing
- Admin dashboard
- User-facing dashboard
- API for third-party integrations
EOF
Requirements files can be as detailed or vague as you like. The interview phase will extract specifics.
2. Run deep-project:
/deep-project @planning/requirements.md
3. Follow the prompts through Interview → Split Analysis → Confirmation → Generation
That's it. Your planning directory will contain numbered split directories with focused spec files.
┌─────────────────────────────────────────────────────────────────┐
│ deep-project workflow │
├─────────────────────────────────────────────────────────────────┤
│ │
│ /deep-project @requirements.md │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Interview │ ──▶ │ Split │ ──▶ │ Dependency │ │
│ │ (adaptive) │ │ Analysis │ │ Mapping │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Spec │ ◀── │ Directory │ ◀── │ User │ │
│ │ Generation │ │ Creation │ │ Confirmation │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 01-auth/spec.md 02-billing/spec.md 03-dashboard/... │ │
│ │ (Focused planning units ready for /deep-plan) │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Option A: CLI commands
/plugin marketplace add piercelamb/deep-project
/plugin install deep-project
/plugin enable deep-project
Option B: Via UI
/plugin marketplace add piercelamb/deep-project
/plugin install deep-project
/plugins
Then scroll to "Installed", find deep-project, and click "Enable".
Already installed
/deep-planor/deep-implement? All three plugins share a marketplace. If you've already added any one of the deep trilogy repos, just run/plugin install deep-projectdirectly — no need to add another marketplace.
Option A: Via settings.json
Clone the repo, then add to your project's .claude/settings.json:
git clone https://github.com/piercelamb/deep-project.git /path/to/deep-project
{
"plugins": {
"paths": ["/path/to/deep-project"]
}
}
Option B: Via --plugin-dir flag (development/testing)
git clone https://github.com/piercelamb/deep-project.git /path/to/deep-project
claude --plugin-dir /path/to/deep-project
/deep-project @path/to/requirements.md
The requirements file can be as detailed or vague as you like. The planning directory is inferred from the requirements file's parent directory.
If the workflow is interrupted (context limit, user pause), re-run with the same requirements file:
/deep-project @planning/requirements.md
The plugin detects existing artifacts and resumes from the appropriate step.
| Phase | What Happens |
|---|---|
| Setup | Validate input, check for existing session, initialize |
| Interview | Adaptive Q&A to understand project scope and relationships |
| Split Analysis | Determine if project benefits from multiple units |
| Dependency Mapping | Identify relationships and execution order |
| User Confirmation | Present proposed structure for approval |
| Directory Creation | Create numbered split directories |
| Spec Generation | Write focused spec.md for each split |
After running deep-project, your planning directory contains:
planning/
├── requirements.md # Your original input
├── deep_project_interview.md # Interview transcript
├── project-manifest.md # ★ Split structure & dependencies
└── splits/
├── 01-auth-system/
│ └── spec.md # Focused spec for auth
├── 02-billing/
│ └── spec.md # Focused spec for billing
└── 03-dashboard/
└── spec.md # Focused spec for dashboard
The manifest contains:
Managed via pyproject.toml - no external API keys required (unlike /deep-plan).
Start with high-level requirements - Don't over-specify. The interview surfaces details.
Answer interview questions thoroughly - Your mental model shapes the decomposition.
Review the manifest carefully - This is where you catch scope issues before they cascade.
Prefer more splits over fewer - Smaller, focused units are easier to plan and implement.
Map dependencies explicitly - Integration issues come from implicit assumptions.
Issue: The @file path doesn't exist
Solution:
Issue: Context limit or manual interruption
Solution:
/deep-project @requirements.mdIssue: Existing files conflict with current requirements
Solution:
Run the test suite:
cd /path/to/deep-project
uv run pytest tests/
deep_project/
├── .claude-plugin/
│ ├── plugin.json # Plugin metadata
│ └── marketplace.json # Marketplace listing
├── LICENSE # MIT License
├── README.md # This file
├── pyproject.toml # Python dependencies
├── hooks/
│ └── hooks.json # Session hooks
├── scripts/
│ ├── checks/ # Setup & validation scripts
│ ├── hooks/ # Hook implementations
│ └── lib/ # Shared utilities
├── skills/
│ └── deep-project/
│ ├── SKILL.md # Main skill definition
│ └── references/ # Protocol documents
└── tests/ # Test suite
Contributions welcome! Please:
uv run pytest tests/Pierce Lamb
0.2.1
.claude-plugin/
marketplace.json
plugin.json
.github/
CODEOWNERS
.gitignore
assets/
hero.jpeg
CHANGELOG.md
hooks/
hooks.json
LICENSE
pyproject.toml
README.md
scripts/
checks/
.gitkeep
create-split-dirs.py
setup-session.py
hooks/
capture-session-id.py
lib/
__init__.py
.gitkeep
config.py
manifest.py
state.py
task_reconciliation.py
task_storage.py
tasks.py
skills/
deep-project/
references/
.gitkeep
interview-protocol.md
project-manifest.md
spec-generation.md
split-heuristics.md
SKILL.md
tests/
conftest.py
fixtures/
expected_outputs/
.gitkeep
multi_split/
.gitkeep
single_unit/
.gitkeep
sample_requirements.md
test_capture_session_id.py
test_config.py
test_create_split_dirs.py
test_integration.py
test_manifest.py
test_setup_session.py
test_state.py
test_task_integration.py
test_task_reconciliation.py
test_task_storage.py
test_tasks.py
uv.lock© 2026 Flowy · Free and open source
Built for Claude Code · Not affiliated with Anthropic