# Vibe Philing

> Phil's structured build workflow: Plan → Review → Execute. Invoke for any multi-phase project or non-trivial implementation task. Subcommands: plan, review, execute. Default: asks which phase.

- Skill: `slfmr1/vibe-philing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add slfmr1/vibe-philing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/slfmr1/vibe-philing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: slfmr1 (https://skillmd.com/u/slfmr1)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/slfmr1/vibe-philing

---


# 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?**
> 1. **Plan** — Neues Projekt planen oder bestehenden Plan erweitern
> 2. **Review** — Bestehenden Plan bewerten und verbessern
> 3. **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:
1. **Overview** — What, why, for whom (3-5 sentences)
2. **Architecture** — Components, data flow, tech choices with rationale
3. **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
4. **Delegation Strategy** — Which parts use subagents, why, what instructions they get
5. **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
1. **Follow the plan.** If something needs to change, flag it — don't silently deviate.
2. **Test as you go.** Run verification after each significant step, not just at the end.
3. **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`:
1. Mark completed phase as `[done]`
2. Add discovery log:
> **Erkenntnisse aus Phase [N]:**
> - [What we learned]
> - [What should change in the plan]
3. 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.