---
id: daily-project-builder
name: "project-builder"
url: https://skills.yangsir.net/skill/daily-project-builder
author: starchild-ai-agent
domain: ai-project-management-collaboration
tags: ["project", "build", "debug", "workflow", "development"]
install_count: 3000
rating: 4.40 (17 reviews)
github: https://github.com/starchild-ai-agent/official-skills
---

# project-builder

> 三阶段项目构建流程：设计 → 构建 → 调试，确保项目质量和可维护性

**Stats**: 3,000 installs · 4.4/5 (17 reviews)

## Before / After 对比

### 智能项目规划与成本控制

**Before**:

在没有 `project-builder` 技能辅助时，项目启动往往缺乏系统性规划。开发者可能直接根据模糊的需求开始编码，导致频繁返工。架构选择凭经验或直觉，而非基于项目特性进行决策，容易引入不必要的复杂性或性能瓶颈。API 调用和 LLM 成本通常在项目后期才被发现，导致预算超支。此外，缺乏对 API 速率限制的预先考量，运行时常出现调用失败，需要额外时间调试和优化。项目初期也缺少向用户清晰展示数据流、架构和潜在限制的环节，增加了沟通成本和后期需求变更的风险。

**After**:

借助 `project-builder` 技能，项目构建流程变得高度结构化和可预测。它强制执行“设计 → 构建 → 调试”三阶段，确保从一开始就将模糊需求转化为具体规范。通过架构决策树，能快速选择最适合项目类型的解决方案（如定时任务、仪表盘或脚本）。在编码前，技能会引导进行详尽的 API 和 LLM 成本估算，并强制考虑速率限制，优先使用批量接口，从而有效避免预算超支和运行时错误。对于中大型项目，它还要求在编码前向用户展示数据流、架构、成本估算和已知限制，显著提升项目透明度和用户满意度。

| Metric | Before | After | Change |
|---|---|---|---|
| 项目返工率 | 25% | 5% | -80% |
| API/LLM 成本超支 | 15% | 2% | -86.67% |
| 因设计缺陷导致的后期修改时间 | 8小时 | 1小时 | -87.5% |
| API 速率限制错误 | 3次/周 | 0.1次/周 | -96.67% |

## Readme

# project-builder

# Project Build

Three phases, always in order: **DESIGN → BUILD → DEBUG**.

**Skill references** (read on demand, not upfront):

- `references/build-patterns.md` — Step-by-step patterns for tasks, dashboards, scripts

- `references/debug-handbook.md` — Layer-by-layer diagnosis, common issues

**Platform references** (shared, in `config/context/references/`):

- `preview-guide.md` — Preview serving, health checks, publishing, community deploy

- `localhost-api.md` — Scripts can call the agent via /chat/stream (decide when to think, what context to pass, which model) and push messages via /push

- `sc-proxy.md` — Transparent proxy, API pricing & rate limits

**Skill references** (in `references/`):

- `build-patterns.md` — Detailed build recipes per project type

- `debug-handbook.md` — Systematic diagnosis protocol

- `dashboard-examples.md` — Code templates for Chart.js, ApexCharts, D3.js, SSE, responsive layouts, dark mode, accessibility (read when building dashboards)

## 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:

- Data flow — sources → processing → output

- Architecture choice and why

- Cost estimate — (cost/run) × frequency × 30 = monthly

- Known limitations

**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:**

```
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 / ❌ Fix first

```

Built
Verify how
Pass

Data fetcher
Run, print raw response
Non-empty, recent, plausible

API endpoint
`curl localhost:{port}/api/...`
Correct JSON

HTML page
`preview_serve` + `preview_check`
`ok = true`

Task script
`python3 tasks/{id}/run.py`
Numbers match source

LLM analysis
Numbers from script vars, not LLM text
Template pattern used

**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`

### Platform Rules

- Agent tools are tool calls only — not importable in scripts

- Preview paths must be relative (`./path` not `/path`)

- 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`

## Phase 3: DEBUG

```
CHECK LOGS → REPRODUCE → ISOLATE → DIAGNOSE → FIX → VERIFY → REGRESS

```

- **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

**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
Weekly Installs498Repository[starchild-ai-ag…l-skills](https://github.com/starchild-ai-agent/official-skills)GitHub Stars3First Seen6 days agoSecurity Audits[Gen Agent Trust HubPass](/starchild-ai-agent/official-skills/project-builder/security/agent-trust-hub)[SocketWarn](/starchild-ai-agent/official-skills/project-builder/security/socket)[SnykPass](/starchild-ai-agent/official-skills/project-builder/security/snyk)Installed onopenclaw496opencode7gemini-cli7deepagents7antigravity7claude-code7

---
*Source: https://skills.yangsir.net/skill/daily-project-builder*
*Markdown mirror: https://skills.yangsir.net/api/skill/daily-project-builder/markdown*