Peec Start

Start Peec

Role

The single entry point for any Peec AI growth-loop session. Reads state, decides which skill is responsible for the next move, hands off. No content production, no analysis — pure dispatch.

Input

None. The skill resolves everything from <cwd>/growth_loop/setup_state.json and (if missing) live Peec calls.

Output

A 4–8 line decision block, then exactly one skill invocation as the next step. Nothing more.

When to use

• Opening a Peec growth session and unsure where to start
• Periodic ritual ("what's the move this week?")
• After onboarding a new project that already has data in Peec
• When a hook injects === PEEC PROJECT DETECTED === context

Do not use when:

• The user already named a specific skill (/peec-agent, /peec-content-intel, etc.) — call that directly
• The user is mid-execution of another skill — don't interrupt

Pipeline

1. Read local state

Read <project>/growth_loop/setup_state.json

<project> = $CLAUDE_PROJECT_DIR env var if set, else cwd. Walk up at most 2 parents looking for growth_loop/setup_state.json (mirrors hooks/peec-detect.py behavior).

2. Branch — no state file

If file missing, run a single parallel Peec read:

mcp__peec-ai__list_projects
mcp__peec-ai__list_brands(project_id)         # only after project resolved
mcp__peec-ai__list_prompts(project_id, limit=5)
mcp__peec-ai__list_topics(project_id)

Then:

3. Branch — state file present

Compute age_days = now - completed_at.

User-intent split: if the user opened with an observational phrase ("wo stehe ich?", "wie ist mein status?", "checkup", "was ist der stand?", "show me the picture") → route to /peec-checkup regardless of age. The agent path is for deciding the next move; checkup is for seeing the picture. They are complementary.

Otherwise (action-oriented intent — "was als nächstes?", "what's next", default /peec-start with no qualifier):

If phases_completed is missing one of {competitors, prompts, topics, tags}, override the above and hand off to /peec-setup partial:<missing-phase> first.

4. Output schema

# Start Peec — <YYYY-MM-DD>

State:        <found|missing|brownfield>
Project:      <domain> (peec_project_id=<id>)
Locale:       country=<XX> · language=<xx>
Setup age:    <N days> (<fresh|stale|very stale|n/a>)
Phases:       <list> · missing: <list>

Decision: <one sentence with the chosen skill + scope>

Why: <one sentence — which signal in the state caused this branch>

Next: <invoking the chosen skill now>

Then immediately invoke that skill. Do not wait for confirmation unless the chosen branch is destructive (/peec-setup in full mode on a populated Peec project — that always confirms once).

Why this skill exists

Three frictions kept biting:

1. New users open a Peec project, don't know which of 7 skills to call first.
2. The hook (hooks/peec-detect.py) needs a manual counterpart for users who turned hooks off.
3. The orchestrator (/peec-agent) refuses to run without a setup state — so first-timers hit a dead end.

peec-start fixes all three by being the single safe entry point that always picks a defensible next step.

Relationship to other skills

/peec-start
   │
   ├── no state, Peec empty       → /peec-setup (full)
   ├── no state, Peec populated   → /peec-setup (import)
   ├── state present, < 90 days   → /peec-agent
   ├── state present, > 90 days   → /peec-setup (audit)
   └── state has missing phases   → /peec-setup (partial:<phase>)

Never produces deliverables itself. Never bypasses the _shared/SETUP_STATE.md protocol — uses the same age thresholds and the same import-mode trigger as Phase 0 of peec-setup, so the dispatcher and the orchestrator agree on what "fresh" means.

Guardrails

• Never call mcp__peec-ai__create_* or mcp__peec-ai__delete_*. Dispatch only.
• Never write setup_state.json. Only /peec-setup writes it.
• Never silently default target_country / prompt_language. If state is missing both AND user hasn't said, ASK once before handoff.
• Never invoke more than one downstream skill per /peec-start run.