slfmr1 Vibe-Philing
Structured workflow for building software Phil's way: thorough planning, critical review, disciplined execution.
Activation
Check for subcommand argument:
/vibe-philing plan→ PLAN phase/vibe-philing review→ REVIEW phase/vibe-philing execute→ EXECUTE phase/vibe-philing(no arg) → ask:
Hey Phil! Welche Phase starten wir?
- Plan — Neues Projekt planen oder bestehenden Plan erweitern
- Review — Bestehenden Plan bewerten und verbessern
- Execute — Eine Phase aus dem Plan umsetzen
PLAN Phase
Entry
Ask Phil:
Was bauen wir? Beschreib mir das Projekt so detailliert wie möglich.
Enter a dialogue loop. Do NOT start planning until you have enough clarity. Ask targeted questions about:
- Scope and boundaries (was gehört dazu, was nicht?)
- Users/audience
- Tech constraints or preferences
- Integration points with existing systems
- Success criteria
For each answer, explain your understanding back and ask follow-ups. Keep going until both sides are confident.
Learning Mode
Phil learns by building. When he asks "why?" or "how?":
- Explain in plain terms, no jargon walls
- Offer 2-3 alternatives with trade-offs (table format works well)
- Recommend one, state why
- Keep it to 3-5 sentences — link to docs for deep dives
Research
Use subagents (Agent tool) for any research that would consume >20% of context:
- Exploring existing codebase patterns
- Investigating libraries, APIs, or approaches
- Comparing architectural options
Do NOT burn main context on extensive exploration. Delegate, get the summary, proceed.
Building the Plan
Once requirements are clear, create plan files in the project directory:
docs/plan.md with these sections:
- Overview — What, why, for whom (3-5 sentences)
- Architecture — Components, data flow, tech choices with rationale
- Phases — Numbered, each with:
- Clear scope and deliverables
- HOW to build it (approach, not just what)
- Files to create/modify
- Testing strategy for this phase
- Verification criteria
- Delegation Strategy — Which parts use subagents, why, what instructions they get
- Risks & Open Questions — Things that might change or need input later
docs/development_architecture.md — Living doc describing the system being built (components, data models, key interfaces, decisions).
Exit
Plan steht. Nächster Schritt: Review.
Lies docs/plan.md und starte /vibe-philing review
REVIEW Phase
Entry
Read the plan files. Then immediately rate:
Plan-Bewertung: [X]/10
Was fehlt bis 10/10:
- [Issue 1 — concrete, actionable]
- [Issue 2] ...
Review Criteria
Rate against these dimensions (mention which ones lose points):
| Dimension | Question |
|---|---|
| Completeness | Does every phase have scope, approach, testing, and verification? |
| Feasibility | Can each phase be executed in one session? |
| Architecture | Are component boundaries clean? Single source of truth? |
| Testing | Is testing planned INTO phases, not bolted on after? |
| Delegation | Are subagent tasks clearly defined with instructions? |
| Risk | Are unknowns identified? Fallback plans where needed? |
| Documentation | Are architecture docs part of deliverables, not afterthoughts? |
Iteration
Welche Punkte sollen wir angehen? Oder hast du Fragen zu meiner Bewertung?
Challenge assumptions. If the plan has a weak spot, say so directly. Iterate until 10/10. Do not inflate scores.
Exit
When plan = 10/10:
Plan ist 10/10. Bereit für die Umsetzung.
Lies docs/plan.md und starte /vibe-philing execute
EXECUTE Phase
Entry
Read the plan file. Find the first phase NOT marked [done]. Confirm scope:
Phase [N]: [Name] — Scope-Check:
- [Deliverable 1]
- [Deliverable 2]
- Testing: [what we'll verify] Passt das so, oder hat sich was geändert?
Execution Rules
- Follow the plan. If something needs to change, flag it — don't silently deviate.
- Test as you go. Run verification after each significant step, not just at the end.
- Update docs. Architecture doc must reflect what was actually built.
Code Review (mandatory)
After implementation is complete, launch a subagent for code review:
- Reads the diff/new files
- Checks: correctness, edge cases, consistency with architecture doc, test coverage
- Reports findings back
Share results with Phil. Fix issues before marking complete.
Plan Update (mandatory)
Before ending the session, update docs/plan.md:
- Mark completed phase as
[done] - Add discovery log:
Erkenntnisse aus Phase [N]:
- [What we learned]
- [What should change in the plan]
- Adjust later phases if discoveries affect them
Exit & Context Check
Estimate current context window usage:
Under ~40%:
Phase [N] abgeschlossen. Sollen wir direkt Phase [N+1] starten, oder neue Session?
Approaching ~40%:
Phase [N] abgeschlossen. Wir sind bei ~40% Context — neue Session empfohlen.
Lies docs/plan.md und starte /vibe-philing execute
Cross-Phase Rules
- Subagents are not optional. Research, code review, and doc generation go to subagents. Main context is for decisions and interaction.
- Plan-File = Single Source of Truth. All status, discoveries, and adjustments live there. New sessions read the plan to know where we stand.
- Be honest about scores and quality. Phil values directness over comfort.
- Moderate explanation depth. Phil is learning — not a beginner, not an expert. Show the reasoning, skip the basics.
- Architecture docs are deliverables. They ship with the code, not after.
- Never enter the dumb zone. Monitor context usage. Recommend session switch before compression kicks in.