project-builder

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 sources and tools. For research and API documentation, use web search. For live market numbers or external actions, reuse the relevant installed skill. Read its SKILL.md before use; search missing skills with auto_install=false and install only with user approval. Write custom API code only after checking that no suitable skill covers the operation; verify endpoints and response shapes against current official documentation.

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.

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: Present a short phase plan for multi-stage work. If the user has already authorized a clear, reversible implementation, proceed without asking for the same approval again. Ask only when scope is genuinely ambiguous, a material cost needs approval, or the next action is irreversible/external (publish, send, trade, delete). An active Plan Mode remains read-only until the user approves execution.

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

Project type → entry mapping:

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:

Tool names = SKILL.md frontmatter tools: list. See build-patterns.md § Using Skill Functions.

Phase 2: BUILD

Every piece follows this cycle:

Verification layering:

• Critical (must pass before preview/activate): data correctness, core logic, no crashes
• Informational (can fix after delivery): styling, edge case messages, minor UX polish

Anti-patterns:

• ❌ "Done!" without running anything
• ❌ Writing 200+ lines then testing for the first time
• ❌ "It should work"

→ Detailed patterns: read references/build-patterns.md

Code Practices

• read_file before edit_file — understand what's there
• edit_file > write_file for modifications
• Check ls before write_file — avoid duplicating existing files
• Large files (>300 lines): split into multiple files, or skeleton-first + bash inject
• Env vars: os.environ["KEY"], persist installs to setup.sh

Dashboard UX Defaults (type=preview)

Decide sensible defaults yourself and render real data on first load. Treat filters as optional refinements users can adjust later — never as prerequisites that gate the initial view. Auto-refresh on a sensible interval. No "Click to load" / "Enter address" / "Select symbol" before anything appears.

Visual design quality (MANDATORY for all HTML output): If the ui-design skill is installed, you MUST read_file its SKILL.md and follow it before writing any HTML/CSS. project-builder owns the engineering workflow; ui-design owns the visual quality. Using project-builder alone produces functional but visually generic output.

Platform Rules

• Agent tools are tool calls only — not importable in scripts
• Preview paths must be relative (./path not /path)
• Hardcode the preview port in code, do not read from env. Each preview runs in its own pod and the env-port contract is not reliable across pods. Pick any free port (e.g. 8765), write it directly into the app, and pass the same number to preview(action="serve", port=...). The two must match exactly.
• Concurrent previews need different IDs. If two previews share the same dir, the newer one auto-kills the older one (same-dir replacement rule). The preview id is now anchored to the directory: re-serving the same dir keeps the same id even if the title changes, so previously shared /preview/{id}/ links stay valid. After re-serving, always re-send the /preview/{id}/ link to the user. Do NOT invent new titles hoping for a fresh id, and do NOT guess id variants.
• Fullstack = one port (backend serves API + static files)
• Cron times are UTC — convert from user timezone
• Preview serving & publishing → read platform reference config/context/references/preview-guide.md
• localhost APIs → read config/context/references/localhost-api.md
  • Task scripts decide WHEN to invoke the agent, WHAT data/context to pass, WHICH model to use
  • Pattern: script fetches data → evaluates if noteworthy → calls LLM only when needed → prints result
• LLM in scripts — two options (details in references/build-patterns.md):
  • OpenRouter (via sc-proxy): lightweight, for summarize/translate/format text. Direct API call, no agent overhead.
  • localhost /chat/stream: full agent with tools. Use only when LLM needs tool access.
• Data template rule: Script owns the numbers, LLM owns the words. Final output assembles data from script variables + analysis from LLM. Never let LLM output be the sole source of numbers the user sees.
• API costs & rate limits → read platform reference config/context/references/sc-proxy.md
• Monetization (optional): any HTTP service you build can be turned into a PAID service with the x402 skill — a reverse-proxy gateway in front of the untouched app charges USDC on Base per call / subscription (weekly–yearly) / lifetime / prepaid balance, with multi-plan support. If the user mentions charging for the project, selling API access, or agent-to-agent payments, read skills/x402/SKILL.md after the build phase and wrap the service with scripts/monetize.py (expose the GATEWAY port, not the upstream). Full paid-service chain after wrapping: preview(serve) the gateway → community-publish → publish_preview() (public URL) → create_paid_service(..., pricing_options=[...]) → submit_for_review() (multi-plan services: review probes each plan's 402 amount via the X-Pricing-Model header) → publish_service() → live on the Service Marketplace. Details: community-publish SKILL.md § Paid service listing.
• Always-on services (long-running / published / paid): agent machines auto-suspend when idle and auto-update restarts kill service processes. Any service that must stay reachable 24/7 needs: ① a keepalive watchdog (scheduled task restarting the service — see skills/x402/SKILL.md "Always-on availability"), ② the machine switched to MANUAL update mode (web dashboard toggle; the agent can only READ the mode in-machine — if it reads "auto", remind the user to flip the switch, or the next platform update will take the service down).

Phase 3: DEBUG

• CHECK LOGS first — task logs, preview diagnostics, stderr. If logs reveal a clear cause, skip to FIX.
• REPRODUCE only when logs are insufficient — see the failure yourself
• ISOLATE which layer is broken (data? logic? LLM? output? frontend? backend?)
• FIX the root cause, then VERIFY with the same repro steps. Don't just fix — fix and confirm.

Three-Strike Rule: Same approach fails twice → STOP → rethink → explain to user → different approach.

→ Full debug procedures: read references/debug-handbook.md

Quick Checklists

Kickoff: ☐ Clarified intent ☐ Proposed architecture ☐ Estimated cost ☐ User confirmed (required before Phase 2)

Build: ☐ Each component tested ☐ Numbers match source ☐ Errors handled ☐ Preview healthy (web)

Debug: ☐ Logs checked ☐ Reproduced (or skipped — logs sufficient) ☐ Isolated layer ☐ Root cause found ☐ Fix verified ☐ Regressions checked