project-builder

What this skill does

## Phase 0: SKILL DISCOVERY & REQUIRED READING

**⚠️ CRITICAL — UI Design Quality Gate:** If the project produces ANY visual HTML output (dashboard, web app, landing page, portfolio, any page the user will see), you MUST `read_file` the `ui-design` skill's SKILL.md and follow it BEFORE writing any HTML/CSS. This is not optional. project-builder handles engineering; ui-design handles visual quality (and tells you when to reach for a component library like shadcn/ui, HeroUI, or coss ui instead of hand-writing). Skipping ui-design produces generic AI slop.

**A. Pick the skills.** Gather every data source the project needs. For each one, prefer a skill: check `<available_skills>`, and if nothing fits, try `search_skills(query)` for official + marketplace coverage. Skills are the most reliable layer — they ship tested clients, auth, and rate-limit handling. Web search is a last resort. Only write raw HTTP / SDK code when no skill can cover the source.

**B. Read the platform rules for what the project touches.** These rules live in references (not in your system prompt) so you must `read_file` them before writing code. Skipping this is the #1 cause of 401s, broken paths, and "worked locally, fails in preview" bugs.

| If the project includes... | `read_file` before Phase 2 |
|---|---|
| Any external API call | `config/context/references/sc-proxy.md` |
| Preview / dashboard / web app | `config/context/references/preview-guide.md` |
| Scheduled task | `config/context/references/scheduled-tasks-guide.md` |
| Long-running background job | `config/context/references/background-tasks.md` |
| File writing >300 lines | `config/context/references/tool-writing-guide.md` |
| **Any visual HTML output** (dashboard, web app, landing page, portfolio) | **`ui-design` skill SKILL.md** — load it and follow it for all visual decisions (track choice, color, typography, layout, animation, and when to use a component library). This skill is the UI quality gate; skipping it produces generic AI slop. |

---

## Phase 1: DESIGN
**Translate vague requests into concrete specs.** If intent is ambiguous, ask ONE question.

Architecture decision tree:
```
Periodic alerts/reports?  → Scheduled Task
Live visual interface?    → Preview Server (dashboard)
One-time analysis?        → Inline (no build needed)
Reusable tool?            → Script in workspace
```

For medium+ projects, present to user BEFORE writing code:
1. Data flow — sources → processing → output
2. Architecture choice and why
3. Cost estimate — (cost/run) × frequency × 30 = monthly
4. Known limitations

**UI Design Gate (required, blocking — for visual projects):**
If the architecture choice is Preview Server or any project that outputs HTML the user will see:
1. `read_file` the `ui-design` skill's SKILL.md **now** (if you haven't already in this session) and pick a track (hand-built vs component library).
2. For hand-built UI, run the Design Dials (in ui-design's `references/design-process.md`) to determine Surface, Accent, Typography, and Aesthetic Family.
3. Include the Design Dials output line in your phase plan below.
If you skip this step, the UI will look like generic AI output. This gate is blocking — do not proceed to Phase 2 without completing it.

**Design Gate (required, blocking):**
After Phase 1, STOP and present a short phase plan (milestones for DESIGN/BUILD/DEBUG). Ask explicitly: **"Approve this plan and proceed to Phase 2 BUILD?"** Match the user's language when phrasing the question — never inject a hardcoded non-English string.
- If user confirms: proceed to Phase 2.
- If user requests changes: revise design and re-confirm.
- If no confirmation: do not write/modify code.

---

## Phase 1.5: SCAFFOLD (mandatory for shareable projects)

After design is confirmed, **before writing any code**, scaffold the project under the standard layout. This makes the project shareable via `community-publish` skill from day one — no migration later.

**Standard project location:** `output/projects/{slug}/`

```
output/projects/{slug}/
├── project.yaml          # name, version (start 0.1.0), type, description, license, entry, env_required
├── PROJECT.md            # 4 required sections: What / Required env / How to start / Outputs / Troubleshooting
├── .env.example          # every env var the code reads, with placeholder values
├── .gitignore            # at minimum: .env, *.key, *.pem, __pycache__, node_modules
└── src/                  # all code lives here, NOT scattered
    ├── run.py            # type=task — first line MUST be: # -*- task-system: v3 -*-
    ├── server.py         # type=service
    ├── main.py           # type=script
    └── index.html / app.py + frontend  # type=preview
```

**Project type → entry mapping:**

| Architecture choice | type | entry path |
|---|---|---|
| Scheduled Task | `task` | `src/run.py` |
| Preview Server | `preview` | `src/index.html` (static) or `src/app.py` |
| Background daemon | `service` | `src/server.py` |
| One-shot tool | `script` | `src/main.py` |

**Skip scaffold only when:**
- Pure inline analysis with no persistent code
- Modifying an existing `output/projects/...` project (keep its layout)
- User explicitly says "just throw a script in /tmp" or similar

**During Phase 2 BUILD, maintain the scaffold:**
- Every new env var read by code → add to `.env.example` in same edit
- Every behavioral change → update PROJECT.md
- Never write code outside `src/` (configs, fixtures: project root or `src/data/`)

**Why this matters:** Projects already in standard layout publish in one command. Projects scattered across `tasks/`, `output/scripts/`, `dashboards/`, etc. need `tidy_project()` migration before they can be shared, and the user often doesn't want to rebuild PROJECT.md from memory.

**For existing scattered code:** call `community-publish` skill → `tidy_project(any_dir)` to reorganize before publishing.

---

**API cost & rate limits:**
All external API calls go through sc-proxy, which bills per request and enforces rate limits.
Before designing, **read `config/context/references/sc-proxy.md`** for pricing table and limits.
- Estimate cost: `credits_per_request × requests_per_run × runs_per_day × 30`
- Respect rate limits: e.g. CoinGecko 60 req/min — a task polling 10 coins every minute is fine; 100 coins is not
- Prefer batch endpoints over N single calls (e.g. `coin_price` with multiple ids vs N separate calls)
- Pure script tasks (no API): ~0 credits/run
- **LLM cost warning:** high-end models can exceed **$0.10 per single call**. Pricing varies dramatically by model tier; expensive models can be **100x+** the cost of budget models for the same workflow.
- **Model-aware estimate required:** break LLM cost down by model (`model_price_per_call × expected_calls_per_run × runs_per_day × 30`) instead of using a single generic number.
- Dashboard auto-refresh costs credits — default to manual refresh unless user asks otherwise
- **Spending protection:** if projected monthly LLM cost is high, explicitly ask whether to enforce per-caller limits before implementation.
- **Per-caller tracking (required):** every proxied request must include `SC-CALLER-ID` (e.g. `job:{JOB_ID}`, `preview:{preview_id}`, `chat:{thread_id}`) so usage can be traced and capped. Details in `config/context/references/sc-proxy.md` § Caller Credit Limit

**Data reliability:** Native tools > proxied APIs > direct requests > web scraping > LLM numbers (never).
**Iron rule: Scripts fetch data. LLMs analyze text. Final output = script variables + LLM prose.**

**Task scripts can import skill functions directly:**
```python
from core.skill_tools import coingecko, coinglass  # auto-discovers skills/*/exports.py
prices = coingecko.coin_price(coin_ids=["bitcoin"], timestamps=["now"])
```
Tool names = SKILL.md frontmatter `tools:` list. See `build-patterns.md § Using Skill Functions`.

---

## Phase 2: BUILD
Every piece follows this cycle:
```
Build one small piece → Run it → Verify output → ✅ Next piece / ❌ F