agentleFS
MereithhhMereithhh/very-happy/.agents/skills/dev/SKILL.md

dev

Skill7 starsChanged 8 days agoMITView on GitHub

Local development guide for the very-happy monorepo: production Web V2, standalone server, CLI/daemon, wire schemas, isolated homes, builds, tests, and troubleshooting. Use when asked to build, install locally, start dev, run a package, or debug the local stack. The legacy Expo happy-app is not the production Web client.

  • Installs packages

49 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use team, test and 4 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • nicepkgSkill

    team

    根据任务快速组建临时 AI Agent 团队协作。自动从 .claude/agents/ 中选择最合适的成员组队。

    Also in 3 projects that use this

  • Microsoft AzureSkill

    test

    Also in 5 projects that use this

  • ryu111Skill

    browser

    agent-browser CLI 瀏覽器自動化指南。E2E 測試、UI 調試、設計驗證。適用於需要實際操作瀏覽器的場景。

    Also in 3 projects that use this

  • VercelSkill

    deploy

    Deploy applications to Vercel. Use when the user says "deploy", "deploy to Vercel", "push to production", "deploy my app", or "go live".

    Also in 4 projects that use this

  • GitHubSkill

    refactor

    Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.

    Also in 4 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 10 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 0 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 31 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Verify a test actually pins the line it claims to (source-assertion tests can pass after the asserted string is deleted — see …

    line 34
  2. Very specific:

    If a dev daemon is stuck, resolve the exact HAPPY_HOME_DIR first, then stop it and remove only that home's daemon.state.json.lock.

    line 120
  3. Very specific:

    Do not test local changes by mutating vh-sg, the relays or the daemon hosts (mac-office, dev-sg) unless the user asked for a deployment.

    line 139

“Common” is measured: kept by at least 6 in 10 of the 31 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

very-happy local development

The repository uses pnpm workspaces. The production client is packages/happy-web-v2; do not route Web work to the legacy happy-app.

First setup

pnpm install --frozen-lockfile
pnpm -C packages/happy-wire build

happy-wire/dist is gitignored but consumed through the package entrypoint, so a clean checkout must build it before packages that import wire.

UI 工作同时读取 .agents/skills/design/SKILL.md,遵循项目统一设计契约并验证真实功能完整性。

Fast package loops

Web V2 (defaults to port 8082 and proxies API/socket traffic):

pnpm -C packages/happy-web-v2 dev
pnpm -C packages/happy-web-v2 exec vitest run
pnpm -C packages/happy-web-v2 exec tsc --noEmit
pnpm -C packages/happy-web-v2 exec vite build

Verify a test actually pins the line it claims to (source-assertion tests can pass after the asserted string is deleted — see docs/PROCESS.md):

node scripts/dev/mutation-check.mjs --pkg happy-web-v2 \
  --test src/screens/onboarding/connectMachine.test.ts \
  --mutate "packages/happy-web-v2/src/screens/sessions/Sidebar.tsx:key: 'connect-machine'"

视觉/CSS 改动要在真实浏览器里量(AGENTS「验收」是硬要求),别现搭 harness:

# 真实 CSS + 真 Chromium;scenario 里写 measure(),需要时写 pixels() 采像素
node scripts/dev/css-probe.mjs path/to/scenario.mjs --out ~/code/github/skills/tmp/ui-review/shots

手机验证必须读取实际 matchMedia('(pointer: coarse)').matches,不能仅凭 hasTouch/窗口宽度认定触屏生效。当前锁定 Playwright 与缓存 Chromium 的长页截图会重置触屏模拟;css-probe.mjs 已在 page 创建后显式启用原生触屏,手机通过 CDP 只截真实视口,并核验截图后仍为 coarse。长内容另验滚动和可达性,不能把手机视口截图当全页截图。自定义浏览器脚本也要在导航/截图后核验媒体查询,截图与交互必须采用同一指针模式。

「这个功能该不该做」先量语料再决定:

node scripts/dev/corpus-stats.mjs                # 本机 transcript 里 agent 输出的 markdown 形态
node scripts/dev/corpus-stats.mjs --samples math # 看命中样本(数学那一项几乎全是假阳性)

Vitest runs happy-web-v2 in the node environment, so a test that renders a real component must call installBrowserTestGlobals() from @/testing/browserTestGlobals before importing it (dynamically — static imports hoist above the setup). Pure-function modules need nothing.

Standalone server (PGlite, no Postgres/Redis/S3 required):

pnpm -C packages/happy-server standalone:dev
pnpm -C packages/happy-server exec vitest run
pnpm -C packages/happy-server exec tsc --noEmit

CLI/daemon:

pnpm -C packages/happy-cli test
node packages/happy-cli/dist/index.mjs --version

For a disposable CLI home, never reuse the production daemon state:

VH_DEV_HOME=$(mktemp -d)
HAPPY_HOME_DIR="$VH_DEV_HOME" HAPPY_SERVER_URL=http://127.0.0.1:3005 \
  node packages/happy-cli/dist/index.mjs daemon start

packages/happy-cli's cli:install deliberately replaces the global binary and restarts the real daemon using ~/.happy; use it only when that side effect is intended.

Full local Web V2 + server

Terminal 1:

pnpm -C packages/happy-server standalone:dev

Terminal 2:

VH_SERVER_URL=http://127.0.0.1:3005 pnpm -C packages/happy-web-v2 dev

The Vite server uses the configured target for /v1, /v2, /v3, /health and WebSocket proxying, preserving the production same-origin shape.

The root pnpm env:* manager still contains upstream Expo assumptions. Until it is migrated to Web V2, do not use pnpm env:web as proof of the production Web path; prefer the two-terminal loop above.

Logs and daemon recovery

ls -t ~/.happy/logs | head
tail -f ~/.happy/logs/$(ls -t ~/.happy/logs | head -1)
very-happy daemon status

If a dev daemon is stuck, resolve the exact HAPPY_HOME_DIR first, then stop it and remove only that home's daemon.state.json.lock. Never broadly delete ~/.happy.

The daemon resolves claude through PATH. Non-interactive shells and launchd do not source .zshrc, so PATH must explicitly include ~/.local/bin.

Cross-package rules

  • Protocol/schema changes: update happy-wire, build its dist, and document the old/new compatibility matrix in a spec.
  • Synced setting fields never receive Zod .default() values; defaults live in the settings defaults layer.
  • Repository tools run through pnpm exec, never bare npx.
  • The merge gates and known exception are canonical in AGENTS.md and docs/PROCESS.md; do not invent a lighter package-specific gate here.

Production is not a dev environment

Do not test local changes by mutating vh-sg, the relays or the daemon hosts (mac-office, dev-sg) unless the user asked for a deployment. Production topology and recovery commands live in docs/operations.md.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.