{"id":"e14f8799-f636-4dc4-bbfd-c92f41247439","entityType":"agent","slug":"clawhub-hanningwang-mano-afk","name":"mano-afk","canonicalUrl":"https://www.xpersona.co/agent/clawhub-hanningwang-mano-afk","canonicalPath":"/agent/clawhub-hanningwang-mano-afk","generatedAt":"2026-10-11T20:58:03.863Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T18:21:05.209Z","emptyReason":null},"description":"Autonomous full-cycle app builder — PRD, architecture, code, deployment, testing, and bug fixing from a natural language description. Remembers user preferen...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s175nb9hv26h88dzxry3zcx61n83hzp4:mano-afk","sourceUrl":"https://clawhub.ai/hanningwang/mano-afk","homepage":"https://clawhub.ai/hanningwang/skills/mano-afk","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/hanningwang/mano-afk","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/hanningwang/skills/mano-afk","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"mano-afk technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T18:21:05.209Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T18:21:05.209Z","emptyReason":null},"stars":null,"forks":null,"downloads":1010,"packageName":null,"latestVersion":"1.0.8","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T18:21:05.149Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T18:21:05.209Z","lastCrawledAt":"2026-10-11T18:21:05.149Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T18:21:05.149Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.8","createdAt":"2026-06-01T10:50:39.570Z","changelog":"mano-afk 1.0.8 - Simplified and clarified the E2E setup process in Step 0; users are now prompted to opt in to E2E testing, with clear guidance and an option to skip. - Adjusted the E2E test section (Step 4.3) to explicitly check for prerequisites, and clarified that installation actions are not taken autonomously during testing. - Made minor streamlining and clarity improvements throughout user-facing instructions, especially around E2E workflow and configuration. - No code or file changes in this release; documentation update only.","fileCount":10,"zipByteSize":20134},{"version":"1.0.7","createdAt":"2026-06-01T09:26:21.447Z","changelog":"**mano-afk 1.0.7 – Changelog** - Removed the skill-card.md file (now deleted from the repository). - Minor updates to project/skill documentation—including a more concise skill description and reorganization of sections. - Clarified instructions for environment variable setup and E2E test configuration. - Updated installation metadata for better integration with Homebrew and Openclaw. - No functional or behavior changes to the app builder pipeline or usage.","fileCount":10,"zipByteSize":20140},{"version":"1.0.6","createdAt":"2026-04-29T08:17:56.908Z","changelog":"mano-afk 1.0.6 - Clarified that the skill only requires curl by default; other binaries (e.g., npm, pip) are used as needed based on the user's project and are not fixed dependencies. - Updated documentation under \"Data, Privacy & Safety\" to explain when development toolchains are used. - No functional or code changes; documentation update only.","fileCount":10,"zipByteSize":20828},{"version":"1.0.5","createdAt":"2026-04-29T08:11:50.706Z","changelog":"**Summary:** This version adds a clear section on data, privacy, and safety, and clarifies the use of environment variables. - Added a \"Data, Privacy & Safety\" section outlining scope, data handling, credential use, and supply chain security. - Clarified that the skill does not require or transmit local data outside the project directory. - Specified how and when optional environment variables like ANTHROPIC_API_KEY may be used or requested. - Reiterated user control: only Step 0 is interactive; rest of the process is fully autonomous. - No changes to core logic, orchestration, or workflow.","fileCount":9,"zipByteSize":19194},{"version":"1.0.4","createdAt":"2026-04-29T08:02:14.183Z","changelog":"No changes detected in this version. - Change the url for claude code skill - Adjust the position of statements - The SKILL.md and other files are unchanged. - No new features, fixes, or updates were introduced in 1.0.4.","fileCount":9,"zipByteSize":19226},{"version":"1.0.3","createdAt":"2026-04-29T07:48:40.487Z","changelog":"mano-afk 1.0.3 - No changes in code or files detected for this version. - Documentation in SKILL.md updated for clarity and accuracy. - Architecture section clarified: build sub-agent now explicitly described as never running tests; only main agent executes tests. - Minor rewording for precision in agent roles and orchestration flow. - No impact on features, commands, or user interaction.","fileCount":9,"zipByteSize":19197},{"version":"1.0.2","createdAt":"2026-04-29T07:41:01.235Z","changelog":"**Summary:** This update clarifies data handling and privacy, ensuring all persistent data stays within the skill folder or project directory. - Strictly confines learning artifacts (rules, preferences) to the skill's `references/` directory; no writes outside the skill or project folder. - Expands documentation on privacy and data boundaries—clarifies no transmission or modification occurs outside project/code. - Ensures credentials, if used, are only stored in the project’s local `.env` file and never globally. - Reiterates that supply chain uses open source and direct build sources. - No changes to installation, workflow, or user interaction logic.","fileCount":9,"zipByteSize":19071},{"version":"1.0.1","createdAt":"2026-04-29T07:30:04.023Z","changelog":"- Clarified handling of optional environment variables, especially `ANTHROPIC_API_KEY`, now configured during interactive setup and stored in `deploy/.env`, not the user's shell. - Updated metadata to explicitly require the `curl` binary for testing. - Adjusted installation guidance: the `mano-afk` binary is required only for E2E visual tests, not for all test phases. - Improved documentation regarding when dependencies are needed and what happens if installation or configuration is declined (those phases are skipped, with reasons logged). - Minor editorial clarifications and reorganization for better readability.","fileCount":9,"zipByteSize":18476}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s175nb9hv26h88dzxry3zcx61n83hzp4:mano-afk","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s175nb9hv26h88dzxry3zcx61n83hzp4:mano-afk` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/hanningwang/mano-afk before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T20:58:03.859Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hanningwang-mano-afk/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T18:21:05.209Z","emptyReason":null},"readme":"Skill: mano-afk\n\nOwner: hanningwang\n\nSummary: Autonomous full-cycle app builder — PRD, architecture, code, deployment, testing, and bug fixing from a natural language description. Remembers user preferen...\n\nTags: latest:1.0.8\n\nVersion history:\n\nv1.0.8 | 2026-06-01T10:50:39.570Z | user\n\nmano-afk 1.0.8\n\n- Simplified and clarified the E2E setup process in Step 0; users are now prompted to opt in to E2E testing, with clear guidance and an option to skip.\n- Adjusted the E2E test section (Step 4.3) to explicitly check for prerequisites, and clarified that installation actions are not taken autonomously during testing.\n- Made minor streamlining and clarity improvements throughout user-facing instructions, especially around E2E workflow and configuration.\n- No code or file changes in this release; documentation update only.\n\nv1.0.7 | 2026-06-01T09:26:21.447Z | user\n\n**mano-afk 1.0.7 – Changelog**\n\n- Removed the skill-card.md file (now deleted from the repository).\n- Minor updates to project/skill documentation—including a more concise skill description and reorganization of sections.\n- Clarified instructions for environment variable setup and E2E test configuration.\n- Updated installation metadata for better integration with Homebrew and Openclaw.\n- No functional or behavior changes to the app builder pipeline or usage.\n\nv1.0.6 | 2026-04-29T08:17:56.908Z | user\n\nmano-afk 1.0.6\n\n- Clarified that the skill only requires curl by default; other binaries (e.g., npm, pip) are used as needed based on the user's project and are not fixed dependencies.\n- Updated documentation under \"Data, Privacy & Safety\" to explain when development toolchains are used.\n- No functional or code changes; documentation update only.\n\nv1.0.5 | 2026-04-29T08:11:50.706Z | user\n\n**Summary:**  \nThis version adds a clear section on data, privacy, and safety, and clarifies the use of environment variables.\n\n- Added a \"Data, Privacy & Safety\" section outlining scope, data handling, credential use, and supply chain security.\n- Clarified that the skill does not require or transmit local data outside the project directory.\n- Specified how and when optional environment variables like ANTHROPIC_API_KEY may be used or requested.\n- Reiterated user control: only Step 0 is interactive; rest of the process is fully autonomous.\n- No changes to core logic, orchestration, or workflow.\n\nv1.0.4 | 2026-04-29T08:02:14.183Z | user\n\nNo changes detected in this version.  \n- Change the url for claude code skill\n- Adjust the position of statements\n- The SKILL.md and other files are unchanged.\n- No new features, fixes, or updates were introduced in 1.0.4.\n\nv1.0.3 | 2026-04-29T07:48:40.487Z | user\n\nmano-afk 1.0.3\n\n- No changes in code or files detected for this version.\n- Documentation in SKILL.md updated for clarity and accuracy.\n- Architecture section clarified: build sub-agent now explicitly described as never running tests; only main agent executes tests.\n- Minor rewording for precision in agent roles and orchestration flow.\n- No impact on features, commands, or user interaction.\n\nv1.0.2 | 2026-04-29T07:41:01.235Z | user\n\n**Summary:**  \nThis update clarifies data handling and privacy, ensuring all persistent data stays within the skill folder or project directory.\n\n- Strictly confines learning artifacts (rules, preferences) to the skill's `references/` directory; no writes outside the skill or project folder.\n- Expands documentation on privacy and data boundaries—clarifies no transmission or modification occurs outside project/code.\n- Ensures credentials, if used, are only stored in the project’s local `.env` file and never globally.\n- Reiterates that supply chain uses open source and direct build sources.\n- No changes to installation, workflow, or user interaction logic.\n\nv1.0.1 | 2026-04-29T07:30:04.023Z | user\n\n- Clarified handling of optional environment variables, especially `ANTHROPIC_API_KEY`, now configured during interactive setup and stored in `deploy/.env`, not the user's shell.\n- Updated metadata to explicitly require the `curl` binary for testing.\n- Adjusted installation guidance: the `mano-afk` binary is required only for E2E visual tests, not for all test phases.\n- Improved documentation regarding when dependencies are needed and what happens if installation or configuration is declined (those phases are skipped, with reasons logged).\n- Minor editorial clarifications and reorganization for better readability.\n\nv1.0.0 | 2026-04-29T06:55:24.355Z | user\n\nmano-afk 1.0.0 – Initial Release\n\n- Launches a fully automated, AFK-friendly pipeline that builds, deploys, and tests applications from natural language descriptions with no manual intervention.\n- Supports step-by-step orchestration: minimal initial user input, then full autonomy including ambiguous decision handling and default settings documentation.\n- Implements persistent learning: build rules and user preferences carry across projects for continuous improvement.\n- Includes end-to-end (E2E) test support (local or cloud), automatic deployment verification, linting, and exhaustive test execution/recording.\n- Fails only when strictly necessary (irrecoverable errors); comprehensive error handling and reporting included.\n- Integrates sub-agents for building and adversarial testing, ensuring robust, production-ready output.\n\nArchive index:\n\nArchive v1.0.8: 10 files, 20134 bytes\n\nFiles: references/build-pipeline.md (8897b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1242b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4028b), skill-card.md (2925b), SKILL.md (13775b), _meta.json (127b)\n\nFile v1.0.8:SKILL.md\n\n---\nname: mano-afk\ndescription: Autonomous full-cycle app builder — PRD, architecture, code, deployment, testing, and bug fixing from a natural language description. Remembers user preferences and development pitfalls to self-evolve across projects. Use when the user explicitly requests a fully autonomous end-to-end app build.\nhomepage: https://github.com/Mininglamp-AI/mano-afk\nmetadata: {\"openclaw\": {\"emoji\": \"⚙️\", \"install\": [{\"id\": \"brew\", \"kind\": \"brew\", \"formula\":\"Mininglamp-AI/tap/mano-afk\", \"bins\":[\"mano-afk\"],\"label\": \"Install mano-afk (brew)\"}]}}\n---\n\n# mano-afk\n\nFully automated pipeline that builds, deploys, and tests applications from a natural language description. The user is AFK for the entire duration. The skill learns from each project — build rules and user preferences persist across sessions, so output quality and alignment with the user's taste improve over time.\n\n**Claude Code users:** Use the Claude Code-specific SKILL.md at [`claude/SKILL.md`](https://github.com/Mininglamp-AI/mano-afk/tree/master/claude).\n\n## Architecture\n\nThree roles collaborate to deliver the application:\n\n- **Main Agent** (you): orchestration, test execution, fix coordination, user communication\n- **Build Sub-agent**: requirements → architecture → code → deploy → bug fixes (when given specific errors)\n- **Adversary Sub-agent**: independent test case design (does not execute tests)\n\nThe main agent delegates code generation to a sub-agent (the longest phase) and stays free during that time. The main agent runs all tests directly for full visibility into results.\n\n## Orchestration\n\n**AFK rule:** Step 0 is the only user interaction window. From Step 1 onward, make all decisions autonomously — never ask the user. Ambiguous decisions (8bit vs float, React vs Vue, port selection) use the most reasonable default and document in PRD.md. Only stop if completely infeasible (missing hardware, no permissions, 10 fix iterations exhausted).\n\n### Step 0: User Setup (interactive)\n\nThis is the only step where the agent may ask the user questions.\n\n**Requirements triage:** If the request is too vague to determine core functionality (e.g., \"build me an app\"), or contains ambiguous requirements that could lead to fundamentally different products, ask the user to clarify — keep it to 1-2 focused questions, not a long interview. Non-critical gaps (visual design, validation rules, tech stack, layout) are filled autonomously by the build sub-agent.\n\n**E2E test setup:** Check `mano-afk config --get e2e-mode`.\n\n- **`local` or `cloud`** — already configured, proceed.\n- **Not set** — recommend E2E testing to the user: \"E2E testing lets mano-afk verify your app through the actual UI — clicking buttons, filling forms, checking visual results. Want to set it up?\" Then run `mano-afk check` and follow its printed guidance to complete configuration. If the user declines, skip E2E — the skill works without it.\n\nWhen Step 0 completes, tell the user: **\"Hold the beer. AFK from now on.\"**\n\n### Step 1: Prepare (autonomous — no user interaction)\n\nDerive a short, kebab-case project name from the request (e.g., \"make me a todo app\" → `todo-app`).\n\n**Project directory:** Read the configured project root via `mano-afk config --get projects-dir` (default: `~/Projects/`). Project directory: `{projects-dir}/{project-name}/`.\n\nRead `references/report-template.md` — you will use it in Step 4 to write `report.md`. Note the absolute path to the `references/` directory — it will be passed to sub-agents for the remaining reference files.\n\n### Step 2: Build (sub-agent)\n\nSpawn a build sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n\n1. The absolute path to `build-pipeline.md` — instruct the sub-agent to read and follow it\n2. The absolute path to this skill's `references/` directory — the sub-agent reads rules.md, preferences.md, and templates as needed\n3. The user's original request, verbatim\n4. The project directory path\n\nRespond to the user immediately with what is being built and the project directory. The build sub-agent follows 4 phases internally: **Phase 1** generates `PRD.md` (product requirements with acceptance criteria), **Phase 2** designs architecture and generates `README.md` (with test cases derived from PRD), **Phase 3** writes code, **Phase 4** deploys. Wait for `progress.md` to show `status: ready_for_testing`.\n\n**Timeout:** Build tasks (dependency installation, compilation, deployment) can take a long time. Set a generous timeout when spawning the sub-agent — at least 30 minutes, or no timeout if the platform supports it.\n\n### Step 3: Verify Deployment\n\nBefore testing, confirm the app is accessible:\n1. Check that `deploy/start.sh` exists in the project\n2. Run it if servers are not already running\n3. Verify with `curl` or port check\n4. If deployment fails (start.sh missing, server crashes, port unreachable), read `deploy/backend.log` and `deploy/frontend.log`, then go to Step 5 (Fix Loop) with the deployment error as the failure description\n\n### Step 4: Test\n\nExecute every test case defined in the README across all categories. No test case may be skipped or deferred.\n\nBefore starting each category, count the total test cases from the README. Print a progress counter for each test: `[3/18] api_3 PASS` or `[5/18] api_5 FAIL`. This makes skipped tests visible — if the counter jumps from 3 to 7, tests 4-6 were skipped.\n\nRecord results in `report.md` (use the report template). On failure, include full error output (response body, stderr, logs).\n\n#### 4.1 Lint\n\nRun the linter configured by the build sub-agent. Auto-fix what's possible (`--fix`), then report remaining errors.\n\n#### 4.2 API Tests\n\nRun every API test case defined in the README. Use `curl -s -w \"\\nHTTP_STATUS:%{http_code}\\n\"` to capture response body and status code. Print full response body on failure.\n\n#### 4.3 E2E Tests (optional)\n\nE2E tests use `mano-afk run` to open the app in a browser, interact with the UI via a vision-language model, and verify visual outcomes.\n\n**Prerequisites — skip this section entirely if any check fails:**\n1. `mano-afk` is on PATH (installed via the skill's brew metadata during skill installation — do NOT install packages autonomously)\n2. `mano-afk config --get e2e-mode` returns `local` or `cloud` (if not set, skip and record reason in `report.md`)\n\n**Database reset:** Before running the first E2E test, clear all application tables (e.g., `DELETE FROM` each app table, or delete and re-initialize the SQLite file). This removes residual data from API tests. Do NOT reset between individual E2E tests — they run sequentially and may depend on state created by prior tests.\n\nRun every E2E test case defined in the README:\n\n```bash\nmano-afk run \"{steps}\" --url \"{url}\" --expect \"{expected}\"\n```\n\n`--url` opens the target page in the default browser before the agent starts. The agent sees the page already loaded — do NOT include \"Open localhost:...\" in the task steps.\n\nAll execution parameters (`--local`/`--cloud`, `--max-steps`, `--minimize`) are read from `mano-afk config`. CLI flags override config when specified. Use `mano-afk config --list` to see current values.\n\nExecution rules:\n- Run each test sequentially\n- Each `mano-afk` task can take up to 30 minutes. Set `exec` timeout to at least 1800s, or use `background: true` with `yieldMs: 1800000`. Never use a short timeout\n- Do not use mouse/keyboard while a test is running\n- Use `mano-afk stop` to: resolve 409 session conflicts, clean up after a killed process, or abort a running task\n\n#### 4.4 Adversary Review\n\nAfter all previous tests pass, spawn an adversary sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n1. Role: \"You are an independent QA reviewer. Your job is to identify potential problems the builder likely missed.\"\n2. The full content of the project's `PRD.md` (requirements and acceptance criteria) and `README.md` (architecture and test cases)\n3. The project directory path (the adversary reads source code for code-level findings)\n\nThe adversary does NOT interact with the running app — it reviews requirements and code only.\n\nThe adversary sub-agent **identifies potential problems only** — it does NOT execute anything. It returns findings in two layers, each as a table with columns: ID, Finding, Severity, Suggested Verification.\n\n- **Layer 1 — User perspective**: usability gaps, cross-feature consistency, confusing flows, poor UX\n- **Layer 2 — Code perspective**: data integrity, missing validation, error handling, state consistency\n\nConstraints: cover both layers, do NOT repeat issues already in README test cases, do NOT flag security vulnerabilities (XSS, SQL injection, CSRF).\n\n**Triage each finding yourself** using the appropriate method: code inspection (schema/config issues), API test (backend behavior via curl), or E2E test (UI rendering, user flows, visual state). At least 2-3 findings must be verified via E2E test. **Reset the database before running adversary E2E verifications** to avoid pollution from prior tests. Record each verdict in report.md: confirmed (→ fix loop) or dismissed (with reason).\n\n### Completion Checklist (before proceeding to Step 5 or 6)\n\nBefore moving forward, verify each item. If any is \"no\", go back and complete it.\n\n- [ ] Every API test case in README executed and recorded\n- [ ] Every E2E test case in README executed and recorded (or all skipped with reason if prerequisites not met)\n- [ ] Adversary review completed with findings from both layers\n- [ ] At least 2-3 adversary findings verified via E2E test (if E2E is available)\n- [ ] All confirmed adversary findings entered into fix loop\n\n### Step 5: Fix Loop\n\nIf any test fails:\n\n1. Collect all failures with full error output (response body, stderr, logs, mano-afk output)\n2. Spawn a **new** build sub-agent in fix mode via `sessions_spawn` with `runtime=\"subagent\"` — provide:\n   - The absolute path to `build-pipeline.md` (fix mode does not need other reference files)\n   - Project directory path\n   - Detailed failure descriptions: test ID, command run, expected result, actual result, full error output\n3. Wait for the sub-agent to fix and re-deploy (`progress.md` shows `status: ready_for_testing`)\n4. Re-run failed tests with the same tool and method used in the original test. A test verified via E2E test must be re-verified via E2E test.\n5. Repeat until all pass (max 10 iterations)\n\n**E2E false positives:** If an E2E test fails but you inspect the code and confirm the implementation is correct (the failure is a vision model misinterpretation), dismiss it as a false positive in `report.md` with your reasoning. Do not enter the fix loop for false positives — fixing correct code wastes iterations.\n\n**Step back on repeated failures:** If the same test fails 2+ times, include a note in the fix prompt: \"This test has failed N times. Previous fix attempts: [descriptions]. Consider a structural fix rather than a patch.\"\n\n**Exhausted iterations:** If 10 iterations are reached and failures remain, proceed to Step 6 with current results. Finalize `report.md` with all remaining failures, iteration history, and a summary of what was attempted.\n\n### Step 6: Completion\n\n- Summarize to the user: total tests, pass/fail, project directory\n- **Update rules:** Review the fix loop history. If any error pattern would prevent the same class of bug in a future project, add a general rule to `references/rules.md` (max 100, remove least valuable if full). Also merge any `new-rules.md` the build sub-agent wrote in the project root.\n- **Update preferences:** If the user gives follow-up feedback (styling, features), update `references/preferences.md`\n\n## Reference Directory\n\nThe `references/` directory is **local to this skill** and contains files that evolve across projects. It does not modify any global CLI configuration, system settings, or files outside this skill's directory.\n\n**Scope:** These files are only read by mano-afk's build and adversary sub-agents. They have no effect on other skills, other CLI tools, or the host system.\n\n**What is stored:**\n\n| File | Purpose | Updated When | Max entries |\n|---|---|---|---|\n| `build-pipeline.md` | Build sub-agent instructions (phases 1-4 + fix mode) | Manual only | — |\n| `rules.md` | General build rules, lessons learned from past fix loops | After fix loop completes (Step 6) | 100 |\n| `preferences.md` | User styling/UX preferences | After user gives feedback (Step 6) | 50 |\n| `prd-template.md` | PRD generation template (5 chapters) | Manual only | — |\n| `project-structure.md` | Standard directory layout template | Manual only | — |\n| `readme-template.md` | README.md generation template | Manual only | — |\n| `report-template.md` | report.md generation template | Manual only | — |\n\nOnly `rules.md` and `preferences.md` are modified during execution. All other files are read-only templates. Rules and preferences persist across projects so the skill can improve over time.\n\n## Data & Privacy\n\n- **Local by default:** Code generation, linting, API tests, and deployment run entirely on your machine.\n- **Cloud data transmission:** E2E tests (4.3) in cloud mode use `mano-afk run`, which sends screenshots and task descriptions to cloud VLA model providers. This only happens when `e2e-mode` is explicitly set to `cloud` via `mano-afk config`. Local mode and skipping E2E tests involve no cloud calls.\n- **Opt-in only:** E2E tests require explicit configuration (`mano-afk config --set e2e-mode local|cloud`). Without this, they are skipped.\n- **No other external calls:** The skill does not phone home, collect telemetry, or send project data to any service beyond the above opt-in test execution.\n\nFile v1.0.8:_meta.json\n\n{\n  \"ownerId\": \"kn7ccfetx2c3t68s44jkw2wq5d82n0pp\",\n  \"slug\": \"mano-afk\",\n  \"version\": \"1.0.8\",\n  \"publishedAt\": 1780311039570\n}\n\nFile v1.0.8:references/build-pipeline.md\n\n# Build Pipeline\n\nYou are a code builder. You receive a user request, make design decisions, write code, and deliver a running deployment. You do **not** run tests — the caller handles all testing and will send you specific errors to fix if needed.\n\n## Mode\n\nYou operate in one of two modes based on your prompt:\n\n**Build mode** (default): No test failures in prompt → create a new application, phases 1–4.\n\n**Fix mode**: Test failures included in prompt → read the existing code at the project directory, fix the issues, re-deploy, update `progress.md` with `status: ready_for_testing`.\n\n## Execution Rules\n\n- Do **NOT** invoke any other skill. Use your own tools to write code, run commands, read and edit files directly.\n- Do **NOT** ask the user for clarification on design decisions. Make autonomous decisions and document them. (Note: the main agent handles user-facing checkpoints — the build sub-agent operates autonomously within its delegated scope.)\n- Do **NOT** run tests. The caller handles all testing.\n- Do **NOT** set tight timeouts on long-running commands (dependency installs, builds, deployments). Use generous timeouts or none.\n\n## Progress Reporting\n\nWrite `progress.md` in the project root at every phase transition. Format:\n\n```\nphase: {N}\nstatus: {in_progress | ready_for_testing | failed}\ntitle: {Phase title}\ndetail: {Current action or result summary}\n```\n\n## Project Setup\n\n- Create the project in its own independent directory (never inside an existing project)\n- Python projects: always use a virtual environment\n- The references directory path is provided in your prompt. Read `rules.md`, `preferences.md`, and templates from it as needed.\n\n## Safety Boundary\n\n- Do not delete files/directories outside the project folder\n- Do not overwrite pre-existing files\n- Do not expose credentials in code — use environment variables\n- Do not run destructive commands on existing data\n- Do not source the user's shell profile (`~/.zshrc`, `~/.bashrc`) — pass only required env vars explicitly\n- Do not install system-level packages — if a required tool is missing, report it via `progress.md` and stop\n\n**Disclosure:** This sub-agent autonomously creates files (PRD.md, README.md, source code, deploy scripts), installs project-scoped dependencies (npm install, pip install inside venv), initializes databases, and starts local servers within the project directory. These actions are expected and disclosed — the user consented when invoking the skill.\n\n---\n\n## Phase 1: Product Requirements\n\n> **Update progress.md** — `phase: 1, status: in_progress, title: Product Requirements`\n\n1. **Read references** — read `rules.md`, `preferences.md`, and `prd-template.md` from the references directory.\n2. **Understand the request** — identify core functionality, target user, data model, and scope boundary.\n3. **Fill in gaps autonomously** — for any detail not specified by the user (visual design, validation rules, error messages, layout, interaction details), make reasonable decisions based on rules and preferences. Document each decision.\n4. **Expand scope** — add standard features the user didn't mention but would expect: error handling, responsive layout, input validation, empty states.\n5. **Apply styling** — read `preferences.md` for global taste, then derive a project-specific color palette and component styles from the product's domain.\n6. **Generate `PRD.md`** — write a complete PRD using the `prd-template.md` structure. Every feature must have acceptance criteria (Given-When-Then) with L1/L2/L3 levels. Every error scenario must have an explicit message and behavior. The PRD is the single source of truth for what to build.\n\nThe PRD replaces the old decision checklist. All design decisions are embedded in the PRD's functional requirements and visual design sections.\n\n---\n\n## Phase 2: Design Architecture\n\n> **Update progress.md** — `phase: 2, status: in_progress, title: Design Architecture`\n\nDesign full technical architecture to satisfy every requirement in the PRD you just generated.\n\n### Tech Stack Selection\n\n| Complexity | Frontend | Backend | Database | Deployment |\n|---|---|---|---|---|\n| Simple (static/SPA) | HTML/CSS/JS or React | None or Express | None or SQLite | Static serve or `npx serve` |\n| Medium (CRUD app) | React or Vue | Node/Express or FastAPI | SQLite or PostgreSQL | `npm start` / `uvicorn` |\n| Complex (multi-service) | React + state management | FastAPI or Node | PostgreSQL | Docker Compose |\n\n**Pre-flight check:** After selecting the tech stack, verify that the required tools are installed (e.g., `node --version`, `python3 --version`). If missing, update `progress.md` with `status: failed` and the missing dependency — do NOT install system packages autonomously.\n\n### Architecture Deliverables\n\n1. **Component diagram** — every major component and how they connect\n2. **API design** — every endpoint with method, path, request/response schema\n3. **Data model** — every entity, fields, types, relationships\n4. **File structure** — exact directory tree (see project structure template in the references directory)\n\nValidate: every AC in the PRD maps to at least one API endpoint and/or UI component.\n\n### Generate README.md\n\nGenerate README.md using the readme template in the references directory. The test cases section must derive from the PRD's acceptance criteria:\n- **API Tests**: for each AC that involves backend behavior, generate a concrete test case (curl command, expected status, expected response). Include the AC number in the test ID.\n- **E2E Tests**: for each AC that involves UI interaction or visual state, generate an E2E test case. Follow the writing rules in the readme template strictly:\n  - **task** = operation path only (clicks, inputs, navigation). No verification verbs. No conditionals. Specific targets (\"the first card\", not \"any card\").\n  - **expect** = observable page state only. No conditionals (no \"if\"). No instructions.\n  - Order tests so state dependencies flow downward. Mark dependencies in the Depends column.\n  - Tests start from a **clean database**. Each test inherits state from previous tests. Design accordingly.\n  - Merge ACs that share the same screen with no unique operations into one test with a richer expect.\n  - For the first E2E test on each page/route, include visual quality expectations in `--expect` (layout, colors, no broken images).\n- Every L1 and L2 AC must have at least one test case. L3 ACs should have test cases where feasible.\n\n---\n\n## Phase 3: Build Code\n\n> **Update progress.md** — `phase: 3, status: in_progress, title: Build Code`\n\n### Lint Configuration\n\nAuto-select linter based on tech stack:\n\n| Stack | Linter | Config File |\n|---|---|---|\n| JavaScript/TypeScript | ESLint | `.eslintrc.json` |\n| Python | Ruff | `ruff.toml` |\n| CSS | Stylelint | `.stylelintrc.json` |\n\n### Project Structure\n\nFollow the project structure template in the references directory. Flatten for simple apps without backend.\n\n### Code Standards\n\nComplete, functional code — no placeholders or TODOs. Follow `rules.md` for technical standards and `preferences.md` for styling. Apply the visual design from `PRD.md` Chapter 5.\n\n---\n\n## Phase 4: Deploy\n\n> **Update progress.md** — `phase: 4, status: in_progress, title: Deploy`\n\n1. Install dependencies\n2. Initialize database if needed\n3. Start backend — redirect stdout/stderr to `deploy/backend.log`\n4. Start frontend — redirect stdout/stderr to `deploy/frontend.log`\n5. Verify accessible (curl health endpoint or check port). On failure, read log files immediately.\n6. If the app uses LLM/API features, verify the API key is accessible from the running backend (e.g., `curl` the AI endpoint).\n\nCreate `deploy/start.sh` — idempotent, one-command startup. If the app requires environment variables (e.g., API keys), the script must explicitly pass only the required variables — do NOT source the user's shell profile (`~/.zshrc`, `~/.bashrc`, etc.) as it exposes unrelated secrets. Use `export VAR_NAME=\"${VAR_NAME}\"` at the top of the script for each required variable.\n\n> **Update progress.md** — `phase: 4, status: ready_for_testing, title: Deploy`\n\n---\n\n## Fix Mode\n\nWhen your prompt includes test failure descriptions:\n\n1. Read the failure details: test ID, command, expected vs actual, full error output\n2. Read the relevant source code at the project directory\n3. Diagnose root cause — if the same error has been reported before (noted in prompt), consider a structural fix\n4. Apply minimal code changes to resolve the issues\n5. Re-deploy: run `deploy/start.sh` or equivalent, verify accessible\n6. If new rules were learned (general patterns that would prevent this class of bug in future projects), write them to `new-rules.md` in the project root\n\n> **Update progress.md** — `status: ready_for_testing, detail: Fixed: {brief summary of changes}`\n\nFile v1.0.8:references/prd-template.md\n\n# {Project Name} — PRD\n\n## 1. Product Overview\n\n**Core value:** {one sentence — why this product exists}\n**Target user:** {who uses it and how}\n**Scope boundary:** {what is explicitly NOT included}\n\n## 2. Functional Requirements\n\nEach feature includes acceptance criteria (AC) in Given-When-Then format. AC numbering: `AC-{feature}.{seq}`, tagged L1 (core path), L2 (business rules), or L3 (edge cases).\n\n### 2.1 {Feature Name}\n\n**Description:** {what it does, one paragraph}\n\n**AC-2.1.1 (L1):** {title}\nGiven {precondition}\nWhen {action}\nThen {expected result}\n\n**AC-2.1.2 (L2):** {title}\nGiven ... When ... Then ...\n\n**AC-2.1.3 (L3):** {title}\nGiven ... When ... Then ...\n\n## 3. Business Rules\n\n### Data Constraints\n\n| Field | Type | Constraint |\n|---|---|---|\n| {field} | {type} | {required/optional, range, format, max length} |\n\n### State Machine (if applicable)\n\n`{state_1} → {state_2} → ... → {terminal_state}`\n- {transition rules, terminal state behavior}\n\n## 4. Error & Exception Design\n\n| Scenario | User-facing Message | Behavior |\n|---|---|---|\n| {scenario} | \"{message}\" | {recovery path} |\n\nEvery user-reachable error must have an explicit message and recovery path. No \"TBD\".\n\n## 5. Visual Design\n\n### Color Palette\n\nDerive from the product's domain. Reference `preferences.md` for the user's global taste. Define at minimum: Primary (+ light/dark variants), Success, Warning, Error, Background, Surface, Text Primary/Secondary, Border — all with hex values.\n\n### Layout\n\n```\n{ASCII wireframe of the main page}\n```\n\n{Brief layout description: navigation, content area, responsive behavior}\n\n### Key Component Styles\n\nButtons, Cards, Forms, Tables — define border-radius, shadow, padding, hover/active transitions for each.\n\nFile v1.0.8:references/preferences.md\n\n# User Preferences\n\nAccumulated styling and UX preferences. This file starts broad and evolves as the user's taste becomes clearer. Max 50 entries — replace outdated preferences when adding beyond the limit.\n\n## Design Philosophy\n\n1. **Every visual choice should have intent.** Do not accept framework defaults without evaluating whether they serve the app's purpose. Color, spacing, and layout should be deliberate.\n2. **Each app should have its own visual identity.** Avoid generic patterns (uniform gray backgrounds, single blue accent, identical rounded corners). Derive the visual language from the app's domain and purpose.\n\n## Icons & Visual Elements\n\n3. **Use an icon library, never emoji for functional UI.** Default: Lucide React (`lucide-react`). Emoji are for content, not for buttons, nav, or labels.\n4. **Prefer meaningful whitespace over decoration.** Use generous spacing to separate content. Avoid dense layouts.\n\n## Color\n\n5. **Derive the color palette from the app's domain.** A finance app might use deep greens and golds; a timer app might use warm reds and ambers. Don't pick colors arbitrarily — let the subject matter guide the palette.\n6. **Build a full color scale, not a single accent.** At minimum: a primary color with light/dark variants, a neutral scale for text and backgrounds, and a semantic set (success, warning, error). Use CSS custom properties so the palette is easy to adjust.\n\n## Typography & Spacing\n\n7. **System font stack by default.** `-apple-system, BlinkMacSystemFont, \"Segoe UI\", Roboto, sans-serif`. Only add custom fonts when they serve a clear design purpose.\n8. **Establish a clear type hierarchy.** At least 3 distinct levels: heading, body, caption. Size differences should be noticeable, not subtle.\n9. **Consistent spacing scale.** Use multiples of 4px or 8px. Pick a base unit and stick to it throughout the app.\n\n## Layout\n\n10. **Card-based layout with subtle shadows.** Cards for grouping related content. Keep shadows light — the card should feel elevated, not floating.\n11. **Responsive by default.** CSS Grid or Flexbox. Design for mobile first when the app is consumer-facing.\n12. **Centered content with max-width.** Main content area should not exceed 1200px. Avoid full-width layouts that stretch content thin.\n\n## Components & Interaction\n\n13. **Transitions on interactive elements.** Buttons, links, cards — anything clickable should have a subtle hover/active transition. No jarring state changes.\n14. **Meaningful empty states.** Include a description of what will appear and a call-to-action to get started. Avoid bare \"no data\" messages.\n15. **Form validation: inline, on blur or submit.** Don't validate on every keystroke. Show errors below the field, clear them when the user starts fixing.\n16. **Loading: skeleton screens for content, spinners for actions.** Skeleton for page loads, small spinner for button submissions.\n\n## Theme\n\n17. **Dark mode if the framework supports it easily.** Use CSS variables for theming. Default to light mode.\n\n## Quality Checklist (applied during build)\n\n18. **Numbers should be formatted.** Currency with symbols, large numbers with separators, dates in locale-appropriate format.\n19. **Hover states, focus rings, and transitions must be present.** If you can click it, it needs visual feedback.\n20. **No orphaned styles.** Every CSS rule should serve a visible purpose. Remove unused styles before shipping.\n\nFile v1.0.8:references/project-structure.md\n\n# Project Structure Template\n\nStandard layout for full-stack apps. For simple apps without a backend, flatten to just the frontend structure.\n\n```\n{project-name}/\n+-- README.md                    # Generated documentation\n+-- report.md                    # Build/fix history\n+-- frontend/\n|   +-- package.json\n|   +-- public/\n|   |   +-- index.html\n|   +-- src/\n|       +-- App.jsx              # Root component\n|       +-- index.js             # Entry point\n|       +-- components/          # Reusable UI components\n|       +-- pages/               # Route-level components\n|       +-- services/            # API client functions\n|       +-- styles/              # CSS/styling\n+-- backend/\n|   +-- requirements.txt         # or package.json\n|   +-- app.py                   # Entry point\n|   +-- routes/                  # API route handlers\n|   +-- models/                  # Data models\n|   +-- services/                # Business logic\n|   +-- database/                # DB setup, migrations\n+-- tests/\n|   +-- api/                     # API test scripts\n|   +-- e2e/                     # VLA test definitions\n+-- deploy/\n    +-- start.sh                 # One-command startup script\n    +-- docker-compose.yml       # If applicable\n```\n\nFile v1.0.8:references/readme-template.md\n\n# {Project Name}\n\n{One-sentence description}\n\n## Tech Stack\n\n| Layer | Technology | Reason |\n|---|---|---|\n| Frontend | {framework} | {why} |\n| Backend | {framework} | {why} |\n| Database | {db} | {why} |\n\n## Architecture\n\n### API Endpoints\n| Method | Path | Description | Request | Response |\n|---|---|---|---|---|\n| GET | /api/items | List all items | — | `[{id, name, ...}]` |\n| POST | /api/items | Create item | `{name, ...}` | `{id, name, ...}` |\n\n### Data Model\n| Entity | Fields |\n|---|---|\n| {Entity} | {field1} ({type}), {field2} ({type}), ... |\n\n### File Structure\n{directory tree}\n\n## Setup & Deployment\n\n```bash\n./deploy/start.sh\n```\n\n## Test Cases\n\nTest cases are derived from the acceptance criteria in `PRD.md`. Each test ID references the corresponding AC number for traceability.\n\n### Lint\n- {Linter} with {config}: zero errors required\n\n### API Tests\n| ID | AC | Method | Path | Input | Expected Status | Expected Response |\n|---|---|---|---|---|---|---|\n| api_1 | AC-2.1.1 | GET | /api/items | — | 200 | `[{id, name, ...}]` |\n| api_2 | AC-2.2.1 | POST | /api/items | `{name: \"test\"}` | 201 | `{id: 1, name: \"test\"}` |\n| api_3 | AC-2.2.2 | POST | /api/items | `{}` | 400 | `{error: \"name is required\"}` |\n| api_4 | AC-2.1.3 | GET | /api/items/999 | — | 404 | `{error: \"not found\"}` |\n\n### E2E Tests (VLA via mano-afk)\n\n**Writing rules:**\n- **task**: Operation path only — clicks, inputs, navigation. No verification verbs (verify, check, ensure). No conditionals (if, any). Targets must be specific (\"the first item\", not \"any item\").\n- **expect**: Observable page state only — what is visible after operations. No conditionals. No instructions.\n- Tests run sequentially top-to-bottom. Use Depends to declare state dependencies.\n- `--url` opens the page before the agent starts — do not include URL navigation in task.\n- Merge tests that verify the same screen with no additional operations.\n\n| ID | AC | Depends | Task | Expect |\n|---|---|---|---|---|\n| e2e_1 | AC-2.1.1 | — | `mano-afk run \"Open the Items tab\" --url \"http://localhost:3000\" --expect \"...\"` | List of items with names and dates. No broken layout or missing images. |\n| e2e_2 | AC-2.2.1 | — | `mano-afk run \"Click Add Item, type 'Test' in the name field, click Submit\" --url \"http://localhost:3000\" --expect \"...\"` | \"Test\" appears as a new row in the items list |\n| e2e_3 | AC-2.2.3 | e2e_2 | `mano-afk run \"Click the delete icon on the first item row, confirm the deletion\" --url \"http://localhost:3000\" --expect \"...\"` | The item is removed. \"No items yet\" message displayed. |\n\n### Adversary Tests\nDesigned and executed by independent sub-agent based on PRD.md and this README. Up to 10 test cases covering edge cases, error handling, and spec compliance.\n\nFile v1.0.8:references/report-template.md\n\n# Build Report: {Project Name}\n\n## Summary\n- Total iterations: {N}\n- Final status: {ALL PASS / X failures remaining}\n- Total time: {elapsed}\n\n## Test Results\n\n### Lint\n| Linter | Errors | Warnings | Status |\n|---|---|---|---|\n| ESLint | 0 | 0 | PASS |\n\n### API Tests\n| ID | AC | Test | Result | Notes |\n|---|---|---|---|---|\n| api_1 | AC-2.1.1 | GET /api/items | PASS | — |\n| api_2 | AC-2.2.1 | POST /api/items | PASS | — |\n| api_3 | AC-2.2.2 | POST /api/items (invalid) | FAIL -> PASS (iter 2) | Fixed validation |\n\n### E2E Tests\n| ID | AC | Journey | Result | Notes |\n|---|---|---|---|---|\n| e2e_1 | AC-2.1.1 | Page load visual check | PASS | — |\n| e2e_2 | AC-2.2.1 | Create item | FAIL | Confirm dialog not dismissed |\n\n### Adversary Tests\n| ID | Finding | Severity | Result | Notes |\n|---|---|---|---|---|\n| adv_1 | Empty form submission | Medium | PASS | — |\n| adv_2 | Rapid double-click submit | High | FAIL | Created duplicate entry |\n\n## Iteration Log\n\n### Iteration 1 (Initial Build)\n- **Status**: FAIL (3/10 tests failed)\n- **Failures**:\n  - api_3 (AC-2.2.2): Missing input validation, returned 500 instead of 400\n  - e2e_1 (AC-2.1.1): VISUAL_DEFECT — Card component has no padding, text overlaps border\n  - e2e_2 (AC-2.2.1): Delete confirm dialog not handled\n\n### Iteration 2\n- **Fixed**:\n  - api_3: Added request body validation in POST /api/items route\n  - e2e_1: Added padding: 16px to .card-body CSS class\n- **Files modified**: backend/routes/items.py, frontend/src/styles/card.css\n- **Status**: FAIL (1/10 tests failed)\n- **Remaining failures**:\n  - e2e_2 (AC-2.2.1): Confirm dialog not dismissed\n\n### Iteration N (Final)\n- **Fixed**:\n  - e2e_2: Added window.confirm() handler in delete button onClick\n- **Files modified**: frontend/src/components/ItemDetail.jsx\n- **Status**: ALL PASS\n\n## Lessons Learned\n- {Any new rules written to new-rules.md during this build}\n\nFile v1.0.8:references/rules.md\n\n# Build Rules\n\nGeneral rules learned from past projects. Max 100 rules — remove the least valuable when adding beyond the limit.\n\n## Technical Defaults\n\n1. **Python projects: always use a virtual environment.** Create venv in the project directory and install all deps inside it. Never `pip install` globally.\n2. **Prefer SQLite over PostgreSQL for simple projects.** Use PostgreSQL only when the app needs concurrent multi-user writes, complex queries, or multiple related tables with joins.\n3. **Pin dependency versions.** Use exact versions in `requirements.txt` and `package.json` to prevent build breakage from upstream changes.\n4. **Use environment variables for all configuration.** Never hardcode API keys, database paths, ports, or secrets. Provide sensible defaults in code.\n5. **Create `.gitignore` appropriate for the stack.** Include node_modules, __pycache__, .env, venv, build artifacts, and IDE files.\n\n## Code Quality\n\n6. **One component per file.** Keep components, routes, and models in separate files. Avoid god files with multiple unrelated exports.\n7. **Every API route must return proper HTTP status codes.** 200 for success, 201 for created, 400 for validation errors, 404 for not found, 500 for server errors. Never return 200 with an error in the body.\n8. **Add input validation at the API boundary.** Validate request bodies before processing. Return 400 with a clear error message for invalid input.\n9. **Frontend must handle three states for every async operation:** loading, success, and error. Never leave the user staring at a blank screen.\n\n## Lint\n\n10. **JavaScript/TypeScript: use ESLint with recommended rules.** Generate `.eslintrc.json` with `\"extends\": [\"eslint:recommended\"]`. For React, add `plugin:react/recommended`.\n11. **Python: use Ruff.** Generate `ruff.toml` with default rules. Enable `select = [\"E\", \"F\", \"I\"]` at minimum (errors, pyflakes, isort).\n12. **Zero lint errors before proceeding to other tests.** Auto-fix what can be auto-fixed, manually fix the rest.\n\n## Adversary Testing\n\n13. **Adversary sub-agent receives README and source code access.** It reviews findings in two layers: Layer 1 (user perspective) from README and running app, Layer 2 (code perspective) from reading source code. No build history or prior test results.\n14. **Adversary scope: functional correctness, edge cases, error handling, data integrity.** Do NOT test for security attacks (XSS, SQL injection, CSRF) unless explicitly requested.\n15. **Maximum 10 adversary test cases per session.** Focus on high-value tests the builder likely missed.\n16. **Always add delete confirmation dialogs for destructive actions.** Any button that permanently removes user data (holdings, entries, records) must show a `window.confirm()` or custom confirmation dialog before executing.\n17. **Persist triggered/computed state changes to the backend.** If the frontend computes a state change (e.g., alert triggered), it must call the corresponding backend endpoint to persist it. Client-side-only state is lost on refresh.\n18. **Add upper bound validation for numeric inputs.** Beyond `> 0`, validate that quantities and prices don't exceed a reasonable maximum (e.g., `999,999,999,999`) to prevent Infinity/NaN in calculations.\n19. **Modals must close on Escape key press.** Add a `keydown` event listener for the Escape key on all modal components. This is a standard UX expectation.\n20. **Wrap all async handlers in try/catch with user-facing error feedback.** Every `async` handler that calls an API must have a try/catch that shows a toast or inline error. Unhandled promise rejections leave users without feedback.\n21. **Cache third-party API responses with rate limits.** When proxying external APIs (CoinGecko, OpenWeather, etc.), add server-side in-memory caching with a TTL matching the refresh interval. On rate-limit (429) or network errors, return cached data instead of forwarding the error. Without caching, normal usage (auto-refresh, multiple users, testing) will quickly trigger rate limits.\n\nFile v1.0.8:skill-card.md\n\n## Description:\n\nAutonomous full-cycle app builder that turns a natural-language request into a PRD, architecture, code, deployment, tests, and fix iterations while remembering user preferences and development pitfalls.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[hanningwang](https://clawhub.ai/user/hanningwang)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use mano-afk to autonomously build and verify an application from a natural-language description, including product requirements, architecture, generated source code, deployment scripts, test execution, fix loops, and a final build report.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill grants broad autonomous build, dependency, deployment, and test authority in generated app workspaces.\n\nMitigation: Use the skill only in disposable or clearly separated app-build workspaces and avoid connecting it to production databases or production services.\n\nRisk: The Homebrew install path is third-party maintained.\n\nMitigation: Review the Homebrew tap and source before installing or executing the associated command-line tool.\n\nRisk: Cloud E2E mode can transmit screenshots and task descriptions to external model providers.\n\nMitigation: Use local E2E mode or leave E2E disabled unless the project screenshots and task descriptions are acceptable to share with the configured cloud provider.\n\nRisk: Learned rules and preferences can persist and influence future generated projects.\n\nMitigation: Inspect references/rules.md and references/preferences.md after runs and remove any unreviewed or unwanted guidance.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/hanningwang/skills/mano-afk)\n- [Homepage](https://github.com/Mininglamp-AI/mano-afk)\n- [Build Pipeline](references/build-pipeline.md)\n- [PRD Template](references/prd-template.md)\n- [README Template](references/readme-template.md)\n- [Report Template](references/report-template.md)\n- [Project Structure Template](references/project-structure.md)\n- [Build Rules](references/rules.md)\n- [User Preferences](references/preferences.md)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown guidance with inline shell commands and generated project files]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May create PRD.md, README.md, report.md, source files, deploy scripts, local logs, and persistent rules or preferences within the skill and generated project workspace.]\n\n## Skill Version(s):\n\n1.0.8 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.7: 10 files, 20140 bytes\n\nFiles: references/build-pipeline.md (8245b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1242b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4028b), skill-card.md (2823b), SKILL.md (14765b), _meta.json (127b)\n\nFile v1.0.7:SKILL.md\n\n---\nname: mano-afk\ndescription: Autonomous full-cycle app builder — PRD, architecture, code, deployment, testing, and bug fixing from a natural language description. Remembers user preferences and development pitfalls to self-evolve across projects. Use when the user explicitly requests a fully autonomous end-to-end app build.\nhomepage: https://github.com/Mininglamp-AI/mano-afk\nmetadata: {\"openclaw\": {\"emoji\": \"⚙️\", \"install\": [{\"id\": \"brew\", \"kind\": \"brew\", \"formula\":\"Mininglamp-AI/tap/mano-afk\", \"bins\":[\"mano-afk\"],\"label\": \"Install mano-afk (brew)\"}]}}\n---\n\n# mano-afk\n\nFully automated pipeline that builds, deploys, and tests applications from a natural language description. The user is AFK for the entire duration. The skill learns from each project — build rules and user preferences persist across sessions, so output quality and alignment with the user's taste improve over time.\n\n**Claude Code users:** Use the Claude Code-specific SKILL.md at [`claude/SKILL.md`](https://github.com/Mininglamp-AI/mano-afk/tree/master/claude).\n\n## Architecture\n\nThree roles collaborate to deliver the application:\n\n- **Main Agent** (you): orchestration, test execution, fix coordination, user communication\n- **Build Sub-agent**: requirements → architecture → code → deploy → bug fixes (when given specific errors)\n- **Adversary Sub-agent**: independent test case design (does not execute tests)\n\nThe main agent delegates code generation to a sub-agent (the longest phase) and stays free during that time. The main agent runs all tests directly for full visibility into results.\n\n## Orchestration\n\n**AFK rule:** Step 0 is the only user interaction window. From Step 1 onward, make all decisions autonomously — never ask the user. Ambiguous decisions (8bit vs float, React vs Vue, port selection) use the most reasonable default and document in PRD.md. Only stop if completely infeasible (missing hardware, no permissions, 10 fix iterations exhausted).\n\n### Step 0: User Setup (interactive)\n\nThis is the only step where the agent may ask the user questions.\n\n**Requirements triage:** If the request is too vague to determine core functionality (e.g., \"build me an app\"), or contains ambiguous requirements that could lead to fundamentally different products, ask the user to clarify — keep it to 1-2 focused questions, not a long interview. Non-critical gaps (visual design, validation rules, tech stack, layout) are filled autonomously by the build sub-agent.\n\n**App LLM check:** If the request involves LLM/AI features, ask the user for the environment variable name that holds the API key (e.g., `OPENAI_API_KEY`). The build sub-agent will reference this env var in the generated code.\n\n**E2E test mode:** Check `mano-afk config --get e2e-mode` (`local` or `cloud`).\n\n- **`local`** — requires `default-model-path` to be configured via `mano-afk config --set default-model-path <path>`.\n- **`cloud`** — requires `ANTHROPIC_API_KEY` environment variable to be set.\n- **Not set** — first-time setup. Check the platform:\n  - **macOS**: ask the user: Local (Mano-P) or Cloud (Anthropic API key) or Skip?\n  - **Other platforms**: Local is not available. Ask the user to configure Cloud or Skip.\n  - If **Local**: run `mano-afk check` to verify SDK and model. Follow the printed guidance to resolve any missing components (install SDK, set model path, etc.).\n  - If **Cloud**: ask the user to set `export ANTHROPIC_API_KEY=<key>` in their shell. Run `mano-afk check` to confirm.\n  - If `mano-afk run` or `mano-afk check` prints setup guidance (missing model path, missing API key), follow the instructions in the output to help the user complete configuration.\n  - If the user declines both → **Skip** E2E tests (logged in `report.md`).\n\nWhen Step 0 completes, tell the user: **\"Hold the beer. AFK from now on.\"**\n\n### Step 1: Prepare (autonomous — no user interaction)\n\nDerive a short, kebab-case project name from the request (e.g., \"make me a todo app\" → `todo-app`).\n\n**Project directory:** Read the configured project root via `mano-afk config --get projects-dir` (default: `~/Projects/`). Project directory: `{projects-dir}/{project-name}/`.\n\nRead `references/report-template.md` — you will use it in Step 4 to write `report.md`. Note the absolute path to the `references/` directory — it will be passed to sub-agents for the remaining reference files.\n\n### Step 2: Build (sub-agent)\n\nSpawn a build sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n\n1. The absolute path to `build-pipeline.md` — instruct the sub-agent to read and follow it\n2. The absolute path to this skill's `references/` directory — the sub-agent reads rules.md, preferences.md, and templates as needed\n3. The user's original request, verbatim\n4. The project directory path\n\nRespond to the user immediately with what is being built and the project directory. The build sub-agent follows 4 phases internally: **Phase 1** generates `PRD.md` (product requirements with acceptance criteria), **Phase 2** designs architecture and generates `README.md` (with test cases derived from PRD), **Phase 3** writes code, **Phase 4** deploys. Wait for `progress.md` to show `status: ready_for_testing`.\n\n**Timeout:** Build tasks (dependency installation, compilation, deployment) can take a long time. Set a generous timeout when spawning the sub-agent — at least 30 minutes, or no timeout if the platform supports it.\n\n### Step 3: Verify Deployment\n\nBefore testing, confirm the app is accessible:\n1. Check that `deploy/start.sh` exists in the project\n2. Run it if servers are not already running\n3. Verify with `curl` or port check\n4. If deployment fails (start.sh missing, server crashes, port unreachable), read `deploy/backend.log` and `deploy/frontend.log`, then go to Step 5 (Fix Loop) with the deployment error as the failure description\n\n### Step 4: Test\n\nExecute every test case defined in the README across all categories. No test case may be skipped or deferred.\n\nBefore starting each category, count the total test cases from the README. Print a progress counter for each test: `[3/18] api_3 PASS` or `[5/18] api_5 FAIL`. This makes skipped tests visible — if the counter jumps from 3 to 7, tests 4-6 were skipped.\n\nRecord results in `report.md` (use the report template). On failure, include full error output (response body, stderr, logs).\n\n**Headless environments:** If no graphical desktop is available, skip VLA tests (4.3). Adversary review (4.4) still runs — triage uses code inspection and curl, not mano-afk.\n\n#### 4.1 Lint\n\nRun the linter configured by the build sub-agent. Auto-fix what's possible (`--fix`), then report remaining errors.\n\n#### 4.2 API Tests\n\nRun every API test case defined in the README. Use `curl -s -w \"\\nHTTP_STATUS:%{http_code}\\n\"` to capture response body and status code. Print full response body on failure.\n\n**mano-afk requirement (4.3):** `mano-afk` must be installed before running VLA tests. Installation is handled by the skill's install metadata (the user is prompted during skill installation). If `mano-afk` is not on PATH at test time, skip 4.3 and log the reason — do NOT install packages autonomously.\n\n#### 4.3 VLA Tests (E2E)\n\nRead `mano-afk config --get e2e-mode`. If `local` → use Local mode. If `cloud` → use Cloud mode. If not set → Skip (record reason in `report.md`).\n\n**Database reset:** Before running the first E2E test, clear all application tables (e.g., `DELETE FROM` each app table, or delete and re-initialize the SQLite file). This removes residual data from API tests. Do NOT reset between individual E2E tests — they run sequentially and may depend on state created by prior tests.\n\nRun every E2E test case defined in the README using the chosen mode:\n\n```bash\nmano-afk run \"{steps}\" --url \"{url}\" --expect \"{expected}\"\n```\n\n`--url` opens the target page in the default browser before the agent starts. The agent sees the page already loaded — do NOT include \"Open localhost:...\" in the task steps.\n\nAll execution parameters (`--local`/`--cloud`, `--max-steps`, `--minimize`) are read from `mano-afk config`. CLI flags override config when specified. Use `mano-afk config --list` to see current values.\n\nExecution rules:\n- Run each test sequentially\n- Each `mano-afk` task can take up to 30 minutes. Set `exec` timeout to at least 1800s, or use `background: true` with `yieldMs: 1800000`. Never use a short timeout\n- Do not use mouse/keyboard while a test is running\n- Use `mano-afk stop` to: resolve 409 session conflicts, clean up after a killed process, or abort a running task\n\n#### 4.4 Adversary Review\n\nAfter all previous tests pass, spawn an adversary sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n1. Role: \"You are an independent QA reviewer. Your job is to identify potential problems the builder likely missed.\"\n2. The full content of the project's `PRD.md` (requirements and acceptance criteria) and `README.md` (architecture and test cases)\n3. The project directory path (the adversary reads source code for code-level findings)\n\nThe adversary does NOT interact with the running app — it reviews requirements and code only.\n\nThe adversary sub-agent **identifies potential problems only** — it does NOT execute anything. It returns findings in two layers, each as a table with columns: ID, Finding, Severity, Suggested Verification.\n\n- **Layer 1 — User perspective**: usability gaps, cross-feature consistency, confusing flows, poor UX\n- **Layer 2 — Code perspective**: data integrity, missing validation, error handling, state consistency\n\nConstraints: cover both layers, do NOT repeat issues already in README test cases, do NOT flag security vulnerabilities (XSS, SQL injection, CSRF).\n\n**Triage each finding yourself** using the appropriate method: code inspection (schema/config issues), API test (backend behavior via curl), or E2E test (UI rendering, user flows, visual state). At least 2-3 findings must be verified via E2E test. **Reset the database before running adversary E2E verifications** to avoid pollution from prior tests. Record each verdict in report.md: confirmed (→ fix loop) or dismissed (with reason).\n\n### Completion Checklist (before proceeding to Step 5 or 6)\n\nBefore moving forward, verify each item. If any is \"no\", go back and complete it.\n\n- [ ] Every API test case in README executed and recorded\n- [ ] Every E2E test case in README executed and recorded\n- [ ] Adversary review completed with findings from both layers\n- [ ] At least 2-3 adversary findings verified via E2E test\n- [ ] All confirmed adversary findings entered into fix loop\n\n### Step 5: Fix Loop\n\nIf any test fails:\n\n1. Collect all failures with full error output (response body, stderr, logs, mano-afk output)\n2. Spawn a **new** build sub-agent in fix mode via `sessions_spawn` with `runtime=\"subagent\"` — provide:\n   - The absolute path to `build-pipeline.md` (fix mode does not need other reference files)\n   - Project directory path\n   - Detailed failure descriptions: test ID, command run, expected result, actual result, full error output\n3. Wait for the sub-agent to fix and re-deploy (`progress.md` shows `status: ready_for_testing`)\n4. Re-run failed tests with the same tool and method used in the original test. A test verified via E2E test must be re-verified via E2E test.\n5. Repeat until all pass (max 10 iterations)\n\n**E2E false positives:** If an E2E test fails but you inspect the code and confirm the implementation is correct (the failure is a vision model misinterpretation), dismiss it as a false positive in `report.md` with your reasoning. Do not enter the fix loop for false positives — fixing correct code wastes iterations.\n\n**Step back on repeated failures:** If the same test fails 2+ times, include a note in the fix prompt: \"This test has failed N times. Previous fix attempts: [descriptions]. Consider a structural fix rather than a patch.\"\n\n**Exhausted iterations:** If 10 iterations are reached and failures remain, proceed to Step 6 with current results. Finalize `report.md` with all remaining failures, iteration history, and a summary of what was attempted.\n\n### Step 6: Completion\n\n- Summarize to the user: total tests, pass/fail, project directory\n- **Update rules:** Review the fix loop history. If any error pattern would prevent the same class of bug in a future project, add a general rule to `references/rules.md` (max 100, remove least valuable if full). Also merge any `new-rules.md` the build sub-agent wrote in the project root.\n- **Update preferences:** If the user gives follow-up feedback (styling, features), update `references/preferences.md`\n\n## Reference Directory\n\nThe `references/` directory is **local to this skill** and contains files that evolve across projects. It does not modify any global CLI configuration, system settings, or files outside this skill's directory.\n\n**Scope:** These files are only read by mano-afk's build and adversary sub-agents. They have no effect on other skills, other CLI tools, or the host system.\n\n**What is stored:**\n\n| File | Purpose | Updated When | Max entries |\n|---|---|---|---|\n| `build-pipeline.md` | Build sub-agent instructions (phases 1-4 + fix mode) | Manual only | — |\n| `rules.md` | General build rules, lessons learned from past fix loops | After fix loop completes (Step 6) | 100 |\n| `preferences.md` | User styling/UX preferences | After user gives feedback (Step 6) | 50 |\n| `prd-template.md` | PRD generation template (5 chapters) | Manual only | — |\n| `project-structure.md` | Standard directory layout template | Manual only | — |\n| `readme-template.md` | README.md generation template | Manual only | — |\n| `report-template.md` | report.md generation template | Manual only | — |\n\nOnly `rules.md` and `preferences.md` are modified during execution. All other files are read-only templates. Rules and preferences persist across projects so the skill can improve over time.\n\n## Data & Privacy\n\n- **Local by default:** Code generation, linting, API tests, and deployment run entirely on your machine.\n- **Cloud data transmission:** VLA tests (4.3) use `mano-afk run`, which sends screenshots and task descriptions to VLA model providers for visual understanding. This data leaves your machine. VLA tests only run when `e2e-mode` is explicitly configured via `mano-afk config`; if not set, they are skipped entirely.\n- **Opt-in only:** VLA tests require explicit configuration (`mano-afk config --set e2e-mode local|cloud`). Without this, they are skipped. They are also skipped in headless environments.\n- **No other external calls:** The skill does not phone home, collect telemetry, or send project data to any service beyond the above test execution.\n\nFile v1.0.7:_meta.json\n\n{\n  \"ownerId\": \"kn7ccfetx2c3t68s44jkw2wq5d82n0pp\",\n  \"slug\": \"mano-afk\",\n  \"version\": \"1.0.7\",\n  \"publishedAt\": 1780305981447\n}\n\nFile v1.0.7:references/build-pipeline.md\n\n# Build Pipeline\n\nYou are a code builder. You receive a user request, make design decisions, write code, and deliver a running deployment. You do **not** run tests — the caller handles all testing and will send you specific errors to fix if needed.\n\n## Mode\n\nYou operate in one of two modes based on your prompt:\n\n**Build mode** (default): No test failures in prompt → create a new application, phases 1–4.\n\n**Fix mode**: Test failures included in prompt → read the existing code at the project directory, fix the issues, re-deploy, update `progress.md` with `status: ready_for_testing`.\n\n## Execution Rules\n\n- Do **NOT** invoke any other skill. Use your own tools to write code, run commands, read and edit files directly.\n- Do **NOT** ask the user for clarification on design decisions. Make autonomous decisions and document them. (Note: the main agent handles user-facing checkpoints — the build sub-agent operates autonomously within its delegated scope.)\n- Do **NOT** run tests. The caller handles all testing.\n- Do **NOT** set tight timeouts on long-running commands (dependency installs, builds, deployments). Use generous timeouts or none.\n\n## Progress Reporting\n\nWrite `progress.md` in the project root at every phase transition. Format:\n\n```\nphase: {N}\nstatus: {in_progress | ready_for_testing | failed}\ntitle: {Phase title}\ndetail: {Current action or result summary}\n```\n\n## Project Setup\n\n- Create the project in its own independent directory (never inside an existing project)\n- Python projects: always use a virtual environment\n- The references directory path is provided in your prompt. Read `rules.md`, `preferences.md`, and templates from it as needed.\n\n## Safety Boundary\n\n- Do not delete files/directories outside the project folder\n- Do not overwrite pre-existing files\n- Do not expose credentials in code — use environment variables\n- Do not run destructive commands on existing data\n\n---\n\n## Phase 1: Product Requirements\n\n> **Update progress.md** — `phase: 1, status: in_progress, title: Product Requirements`\n\n1. **Read references** — read `rules.md`, `preferences.md`, and `prd-template.md` from the references directory.\n2. **Understand the request** — identify core functionality, target user, data model, and scope boundary.\n3. **Fill in gaps autonomously** — for any detail not specified by the user (visual design, validation rules, error messages, layout, interaction details), make reasonable decisions based on rules and preferences. Document each decision.\n4. **Expand scope** — add standard features the user didn't mention but would expect: error handling, responsive layout, input validation, empty states.\n5. **Apply styling** — read `preferences.md` for global taste, then derive a project-specific color palette and component styles from the product's domain.\n6. **Generate `PRD.md`** — write a complete PRD using the `prd-template.md` structure. Every feature must have acceptance criteria (Given-When-Then) with L1/L2/L3 levels. Every error scenario must have an explicit message and behavior. The PRD is the single source of truth for what to build.\n\nThe PRD replaces the old decision checklist. All design decisions are embedded in the PRD's functional requirements and visual design sections.\n\n---\n\n## Phase 2: Design Architecture\n\n> **Update progress.md** — `phase: 2, status: in_progress, title: Design Architecture`\n\nDesign full technical architecture to satisfy every requirement in the PRD you just generated.\n\n### Tech Stack Selection\n\n| Complexity | Frontend | Backend | Database | Deployment |\n|---|---|---|---|---|\n| Simple (static/SPA) | HTML/CSS/JS or React | None or Express | None or SQLite | Static serve or `npx serve` |\n| Medium (CRUD app) | React or Vue | Node/Express or FastAPI | SQLite or PostgreSQL | `npm start` / `uvicorn` |\n| Complex (multi-service) | React + state management | FastAPI or Node | PostgreSQL | Docker Compose |\n\n**Pre-flight check:** After selecting the tech stack, verify that the required tools are installed (e.g., `node --version`, `python3 --version`). If missing, update `progress.md` with `status: failed` and the missing dependency — do NOT install system packages autonomously.\n\n### Architecture Deliverables\n\n1. **Component diagram** — every major component and how they connect\n2. **API design** — every endpoint with method, path, request/response schema\n3. **Data model** — every entity, fields, types, relationships\n4. **File structure** — exact directory tree (see project structure template in the references directory)\n\nValidate: every AC in the PRD maps to at least one API endpoint and/or UI component.\n\n### Generate README.md\n\nGenerate README.md using the readme template in the references directory. The test cases section must derive from the PRD's acceptance criteria:\n- **API Tests**: for each AC that involves backend behavior, generate a concrete test case (curl command, expected status, expected response). Include the AC number in the test ID.\n- **E2E Tests**: for each AC that involves UI interaction or visual state, generate an E2E test case. Follow the writing rules in the readme template strictly:\n  - **task** = operation path only (clicks, inputs, navigation). No verification verbs. No conditionals. Specific targets (\"the first card\", not \"any card\").\n  - **expect** = observable page state only. No conditionals (no \"if\"). No instructions.\n  - Order tests so state dependencies flow downward. Mark dependencies in the Depends column.\n  - Tests start from a **clean database**. Each test inherits state from previous tests. Design accordingly.\n  - Merge ACs that share the same screen with no unique operations into one test with a richer expect.\n  - For the first E2E test on each page/route, include visual quality expectations in `--expect` (layout, colors, no broken images).\n- Every L1 and L2 AC must have at least one test case. L3 ACs should have test cases where feasible.\n\n---\n\n## Phase 3: Build Code\n\n> **Update progress.md** — `phase: 3, status: in_progress, title: Build Code`\n\n### Lint Configuration\n\nAuto-select linter based on tech stack:\n\n| Stack | Linter | Config File |\n|---|---|---|\n| JavaScript/TypeScript | ESLint | `.eslintrc.json` |\n| Python | Ruff | `ruff.toml` |\n| CSS | Stylelint | `.stylelintrc.json` |\n\n### Project Structure\n\nFollow the project structure template in the references directory. Flatten for simple apps without backend.\n\n### Code Standards\n\nComplete, functional code — no placeholders or TODOs. Follow `rules.md` for technical standards and `preferences.md` for styling. Apply the visual design from `PRD.md` Chapter 5.\n\n---\n\n## Phase 4: Deploy\n\n> **Update progress.md** — `phase: 4, status: in_progress, title: Deploy`\n\n1. Install dependencies\n2. Initialize database if needed\n3. Start backend — redirect stdout/stderr to `deploy/backend.log`\n4. Start frontend — redirect stdout/stderr to `deploy/frontend.log`\n5. Verify accessible (curl health endpoint or check port). On failure, read log files immediately.\n6. If the app uses LLM/API features, verify the API key is accessible from the running backend (e.g., `curl` the AI endpoint). If env vars are not inherited, the `deploy/start.sh` script must source the shell profile (e.g., `source ~/.zshrc`) before starting servers.\n\nCreate `deploy/start.sh` — idempotent, one-command startup. The script must `source ~/.zshrc` (or equivalent) to inherit environment variables like API keys.\n\n> **Update progress.md** — `phase: 4, status: ready_for_testing, title: Deploy`\n\n---\n\n## Fix Mode\n\nWhen your prompt includes test failure descriptions:\n\n1. Read the failure details: test ID, command, expected vs actual, full error output\n2. Read the relevant source code at the project directory\n3. Diagnose root cause — if the same error has been reported before (noted in prompt), consider a structural fix\n4. Apply minimal code changes to resolve the issues\n5. Re-deploy: run `deploy/start.sh` or equivalent, verify accessible\n6. If new rules were learned (general patterns that would prevent this class of bug in future projects), write them to `new-rules.md` in the project root\n\n> **Update progress.md** — `status: ready_for_testing, detail: Fixed: {brief summary of changes}`\n\nFile v1.0.7:references/prd-template.md\n\n# {Project Name} — PRD\n\n## 1. Product Overview\n\n**Core value:** {one sentence — why this product exists}\n**Target user:** {who uses it and how}\n**Scope boundary:** {what is explicitly NOT included}\n\n## 2. Functional Requirements\n\nEach feature includes acceptance criteria (AC) in Given-When-Then format. AC numbering: `AC-{feature}.{seq}`, tagged L1 (core path), L2 (business rules), or L3 (edge cases).\n\n### 2.1 {Feature Name}\n\n**Description:** {what it does, one paragraph}\n\n**AC-2.1.1 (L1):** {title}\nGiven {precondition}\nWhen {action}\nThen {expected result}\n\n**AC-2.1.2 (L2):** {title}\nGiven ... When ... Then ...\n\n**AC-2.1.3 (L3):** {title}\nGiven ... When ... Then ...\n\n## 3. Business Rules\n\n### Data Constraints\n\n| Field | Type | Constraint |\n|---|---|---|\n| {field} | {type} | {required/optional, range, format, max length} |\n\n### State Machine (if applicable)\n\n`{state_1} → {state_2} → ... → {terminal_state}`\n- {transition rules, terminal state behavior}\n\n## 4. Error & Exception Design\n\n| Scenario | User-facing Message | Behavior |\n|---|---|---|\n| {scenario} | \"{message}\" | {recovery path} |\n\nEvery user-reachable error must have an explicit message and recovery path. No \"TBD\".\n\n## 5. Visual Design\n\n### Color Palette\n\nDerive from the product's domain. Reference `preferences.md` for the user's global taste. Define at minimum: Primary (+ light/dark variants), Success, Warning, Error, Background, Surface, Text Primary/Secondary, Border — all with hex values.\n\n### Layout\n\n```\n{ASCII wireframe of the main page}\n```\n\n{Brief layout description: navigation, content area, responsive behavior}\n\n### Key Component Styles\n\nButtons, Cards, Forms, Tables — define border-radius, shadow, padding, hover/active transitions for each.\n\nFile v1.0.7:references/preferences.md\n\n# User Preferences\n\nAccumulated styling and UX preferences. This file starts broad and evolves as the user's taste becomes clearer. Max 50 entries — replace outdated preferences when adding beyond the limit.\n\n## Design Philosophy\n\n1. **Every visual choice should have intent.** Do not accept framework defaults without evaluating whether they serve the app's purpose. Color, spacing, and layout should be deliberate.\n2. **Each app should have its own visual identity.** Avoid generic patterns (uniform gray backgrounds, single blue accent, identical rounded corners). Derive the visual language from the app's domain and purpose.\n\n## Icons & Visual Elements\n\n3. **Use an icon library, never emoji for functional UI.** Default: Lucide React (`lucide-react`). Emoji are for content, not for buttons, nav, or labels.\n4. **Prefer meaningful whitespace over decoration.** Use generous spacing to separate content. Avoid dense layouts.\n\n## Color\n\n5. **Derive the color palette from the app's domain.** A finance app might use deep greens and golds; a timer app might use warm reds and ambers. Don't pick colors arbitrarily — let the subject matter guide the palette.\n6. **Build a full color scale, not a single accent.** At minimum: a primary color with light/dark variants, a neutral scale for text and backgrounds, and a semantic set (success, warning, error). Use CSS custom properties so the palette is easy to adjust.\n\n## Typography & Spacing\n\n7. **System font stack by default.** `-apple-system, BlinkMacSystemFont, \"Segoe UI\", Roboto, sans-serif`. Only add custom fonts when they serve a clear design purpose.\n8. **Establish a clear type hierarchy.** At least 3 distinct levels: heading, body, caption. Size differences should be noticeable, not subtle.\n9. **Consistent spacing scale.** Use multiples of 4px or 8px. Pick a base unit and stick to it throughout the app.\n\n## Layout\n\n10. **Card-based layout with subtle shadows.** Cards for grouping related content. Keep shadows light — the card should feel elevated, not floating.\n11. **Responsive by default.** CSS Grid or Flexbox. Design for mobile first when the app is consumer-facing.\n12. **Centered content with max-width.** Main content area should not exceed 1200px. Avoid full-width layouts that stretch content thin.\n\n## Components & Interaction\n\n13. **Transitions on interactive elements.** Buttons, links, cards — anything clickable should have a subtle hover/active transition. No jarring state changes.\n14. **Meaningful empty states.** Include a description of what will appear and a call-to-action to get started. Avoid bare \"no data\" messages.\n15. **Form validation: inline, on blur or submit.** Don't validate on every keystroke. Show errors below the field, clear them when the user starts fixing.\n16. **Loading: skeleton screens for content, spinners for actions.** Skeleton for page loads, small spinner for button submissions.\n\n## Theme\n\n17. **Dark mode if the framework supports it easily.** Use CSS variables for theming. Default to light mode.\n\n## Quality Checklist (applied during build)\n\n18. **Numbers should be formatted.** Currency with symbols, large numbers with separators, dates in locale-appropriate format.\n19. **Hover states, focus rings, and transitions must be present.** If you can click it, it needs visual feedback.\n20. **No orphaned styles.** Every CSS rule should serve a visible purpose. Remove unused styles before shipping.\n\nFile v1.0.7:references/project-structure.md\n\n# Project Structure Template\n\nStandard layout for full-stack apps. For simple apps without a backend, flatten to just the frontend structure.\n\n```\n{project-name}/\n+-- README.md                    # Generated documentation\n+-- report.md                    # Build/fix history\n+-- frontend/\n|   +-- package.json\n|   +-- public/\n|   |   +-- index.html\n|   +-- src/\n|       +-- App.jsx              # Root component\n|       +-- index.js             # Entry point\n|       +-- components/          # Reusable UI components\n|       +-- pages/               # Route-level components\n|       +-- services/            # API client functions\n|       +-- styles/              # CSS/styling\n+-- backend/\n|   +-- requirements.txt         # or package.json\n|   +-- app.py                   # Entry point\n|   +-- routes/                  # API route handlers\n|   +-- models/                  # Data models\n|   +-- services/                # Business logic\n|   +-- database/                # DB setup, migrations\n+-- tests/\n|   +-- api/                     # API test scripts\n|   +-- e2e/                     # VLA test definitions\n+-- deploy/\n    +-- start.sh                 # One-command startup script\n    +-- docker-compose.yml       # If applicable\n```\n\nFile v1.0.7:references/readme-template.md\n\n# {Project Name}\n\n{One-sentence description}\n\n## Tech Stack\n\n| Layer | Technology | Reason |\n|---|---|---|\n| Frontend | {framework} | {why} |\n| Backend | {framework} | {why} |\n| Database | {db} | {why} |\n\n## Architecture\n\n### API Endpoints\n| Method | Path | Description | Request | Response |\n|---|---|---|---|---|\n| GET | /api/items | List all items | — | `[{id, name, ...}]` |\n| POST | /api/items | Create item | `{name, ...}` | `{id, name, ...}` |\n\n### Data Model\n| Entity | Fields |\n|---|---|\n| {Entity} | {field1} ({type}), {field2} ({type}), ... |\n\n### File Structure\n{directory tree}\n\n## Setup & Deployment\n\n```bash\n./deploy/start.sh\n```\n\n## Test Cases\n\nTest cases are derived from the acceptance criteria in `PRD.md`. Each test ID references the corresponding AC number for traceability.\n\n### Lint\n- {Linter} with {config}: zero errors required\n\n### API Tests\n| ID | AC | Method | Path | Input | Expected Status | Expected Response |\n|---|---|---|---|---|---|---|\n| api_1 | AC-2.1.1 | GET | /api/items | — | 200 | `[{id, name, ...}]` |\n| api_2 | AC-2.2.1 | POST | /api/items | `{name: \"test\"}` | 201 | `{id: 1, name: \"test\"}` |\n| api_3 | AC-2.2.2 | POST | /api/items | `{}` | 400 | `{error: \"name is required\"}` |\n| api_4 | AC-2.1.3 | GET | /api/items/999 | — | 404 | `{error: \"not found\"}` |\n\n### E2E Tests (VLA via mano-afk)\n\n**Writing rules:**\n- **task**: Operation path only — clicks, inputs, navigation. No verification verbs (verify, check, ensure). No conditionals (if, any). Targets must be specific (\"the first item\", not \"any item\").\n- **expect**: Observable page state only — what is visible after operations. No conditionals. No instructions.\n- Tests run sequentially top-to-bottom. Use Depends to declare state dependencies.\n- `--url` opens the page before the agent starts — do not include URL navigation in task.\n- Merge tests that verify the same screen with no additional operations.\n\n| ID | AC | Depends | Task | Expect |\n|---|---|---|---|---|\n| e2e_1 | AC-2.1.1 | — | `mano-afk run \"Open the Items tab\" --url \"http://localhost:3000\" --expect \"...\"` | List of items with names and dates. No broken layout or missing images. |\n| e2e_2 | AC-2.2.1 | — | `mano-afk run \"Click Add Item, type 'Test' in the name field, click Submit\" --url \"http://localhost:3000\" --expect \"...\"` | \"Test\" appears as a new row in the items list |\n| e2e_3 | AC-2.2.3 | e2e_2 | `mano-afk run \"Click the delete icon on the first item row, confirm the deletion\" --url \"http://localhost:3000\" --expect \"...\"` | The item is removed. \"No items yet\" message displayed. |\n\n### Adversary Tests\nDesigned and executed by independent sub-agent based on PRD.md and this README. Up to 10 test cases covering edge cases, error handling, and spec compliance.\n\nFile v1.0.7:references/report-template.md\n\n# Build Report: {Project Name}\n\n## Summary\n- Total iterations: {N}\n- Final status: {ALL PASS / X failures remaining}\n- Total time: {elapsed}\n\n## Test Results\n\n### Lint\n| Linter | Errors | Warnings | Status |\n|---|---|---|---|\n| ESLint | 0 | 0 | PASS |\n\n### API Tests\n| ID | AC | Test | Result | Notes |\n|---|---|---|---|---|\n| api_1 | AC-2.1.1 | GET /api/items | PASS | — |\n| api_2 | AC-2.2.1 | POST /api/items | PASS | — |\n| api_3 | AC-2.2.2 | POST /api/items (invalid) | FAIL -> PASS (iter 2) | Fixed validation |\n\n### E2E Tests\n| ID | AC | Journey | Result | Notes |\n|---|---|---|---|---|\n| e2e_1 | AC-2.1.1 | Page load visual check | PASS | — |\n| e2e_2 | AC-2.2.1 | Create item | FAIL | Confirm dialog not dismissed |\n\n### Adversary Tests\n| ID | Finding | Severity | Result | Notes |\n|---|---|---|---|---|\n| adv_1 | Empty form submission | Medium | PASS | — |\n| adv_2 | Rapid double-click submit | High | FAIL | Created duplicate entry |\n\n## Iteration Log\n\n### Iteration 1 (Initial Build)\n- **Status**: FAIL (3/10 tests failed)\n- **Failures**:\n  - api_3 (AC-2.2.2): Missing input validation, returned 500 instead of 400\n  - e2e_1 (AC-2.1.1): VISUAL_DEFECT — Card component has no padding, text overlaps border\n  - e2e_2 (AC-2.2.1): Delete confirm dialog not handled\n\n### Iteration 2\n- **Fixed**:\n  - api_3: Added request body validation in POST /api/items route\n  - e2e_1: Added padding: 16px to .card-body CSS class\n- **Files modified**: backend/routes/items.py, frontend/src/styles/card.css\n- **Status**: FAIL (1/10 tests failed)\n- **Remaining failures**:\n  - e2e_2 (AC-2.2.1): Confirm dialog not dismissed\n\n### Iteration N (Final)\n- **Fixed**:\n  - e2e_2: Added window.confirm() handler in delete button onClick\n- **Files modified**: frontend/src/components/ItemDetail.jsx\n- **Status**: ALL PASS\n\n## Lessons Learned\n- {Any new rules written to new-rules.md during this build}\n\nFile v1.0.7:references/rules.md\n\n# Build Rules\n\nGeneral rules learned from past projects. Max 100 rules — remove the least valuable when adding beyond the limit.\n\n## Technical Defaults\n\n1. **Python projects: always use a virtual environment.** Create venv in the project directory and install all deps inside it. Never `pip install` globally.\n2. **Prefer SQLite over PostgreSQL for simple projects.** Use PostgreSQL only when the app needs concurrent multi-user writes, complex queries, or multiple related tables with joins.\n3. **Pin dependency versions.** Use exact versions in `requirements.txt` and `package.json` to prevent build breakage from upstream changes.\n4. **Use environment variables for all configuration.** Never hardcode API keys, database paths, ports, or secrets. Provide sensible defaults in code.\n5. **Create `.gitignore` appropriate for the stack.** Include node_modules, __pycache__, .env, venv, build artifacts, and IDE files.\n\n## Code Quality\n\n6. **One component per file.** Keep components, routes, and models in separate files. Avoid god files with multiple unrelated exports.\n7. **Every API route must return proper HTTP status codes.** 200 for success, 201 for created, 400 for validation errors, 404 for not found, 500 for server errors. Never return 200 with an error in the body.\n8. **Add input validation at the API boundary.** Validate request bodies before processing. Return 400 with a clear error message for invalid input.\n9. **Frontend must handle three states for every async operation:** loading, success, and error. Never leave the user staring at a blank screen.\n\n## Lint\n\n10. **JavaScript/TypeScript: use ESLint with recommended rules.** Generate `.eslintrc.json` with `\"extends\": [\"eslint:recommended\"]`. For React, add `plugin:react/recommended`.\n11. **Python: use Ruff.** Generate `ruff.toml` with default rules. Enable `select = [\"E\", \"F\", \"I\"]` at minimum (errors, pyflakes, isort).\n12. **Zero lint errors before proceeding to other tests.** Auto-fix what can be auto-fixed, manually fix the rest.\n\n## Adversary Testing\n\n13. **Adversary sub-agent receives README and source code access.** It reviews findings in two layers: Layer 1 (user perspective) from README and running app, Layer 2 (code perspective) from reading source code. No build history or prior test results.\n14. **Adversary scope: functional correctness, edge cases, error handling, data integrity.** Do NOT test for security attacks (XSS, SQL injection, CSRF) unless explicitly requested.\n15. **Maximum 10 adversary test cases per session.** Focus on high-value tests the builder likely missed.\n16. **Always add delete confirmation dialogs for destructive actions.** Any button that permanently removes user data (holdings, entries, records) must show a `window.confirm()` or custom confirmation dialog before executing.\n17. **Persist triggered/computed state changes to the backend.** If the frontend computes a state change (e.g., alert triggered), it must call the corresponding backend endpoint to persist it. Client-side-only state is lost on refresh.\n18. **Add upper bound validation for numeric inputs.** Beyond `> 0`, validate that quantities and prices don't exceed a reasonable maximum (e.g., `999,999,999,999`) to prevent Infinity/NaN in calculations.\n19. **Modals must close on Escape key press.** Add a `keydown` event listener for the Escape key on all modal components. This is a standard UX expectation.\n20. **Wrap all async handlers in try/catch with user-facing error feedback.** Every `async` handler that calls an API must have a try/catch that shows a toast or inline error. Unhandled promise rejections leave users without feedback.\n21. **Cache third-party API responses with rate limits.** When proxying external APIs (CoinGecko, OpenWeather, etc.), add server-side in-memory caching with a TTL matching the refresh interval. On rate-limit (429) or network errors, return cached data instead of forwarding the error. Without caching, normal usage (auto-refresh, multiple users, testing) will quickly trigger rate limits.\n\nFile v1.0.7:skill-card.md\n\n## Description: <br>\nAutonomous full-cycle app builder for PRD creation, architecture, code, deployment, testing, and bug fixing from a natural language description. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[hanningwang](https://clawhub.ai/user/hanningwang) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill when they want an agent to autonomously turn a natural language app request into a working project, including requirements, implementation, deployment, testing, and fix loops. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated startup scripts may source a full shell profile, exposing unrelated secrets or triggering shell-profile side effects. <br>\nMitigation: Before running generated API-key-backed apps, review or override deploy/start.sh and provide only the specific required environment variables. <br>\nRisk: The skill is highly autonomous and can create projects, install dependencies, start services, run tests, and update local rules or preferences. <br>\nMitigation: Run it in an isolated project directory and review generated files, commands, reports, and any rule or preference updates before trusting the output. <br>\nRisk: Cloud VLA test mode can send screenshots and task descriptions to configured model providers. <br>\nMitigation: Use cloud VLA testing only when that data sharing is acceptable; otherwise choose local mode where supported or skip E2E tests. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/hanningwang/mano-afk) <br>\n- [Build pipeline reference](references/build-pipeline.md) <br>\n- [Project structure reference](references/project-structure.md) <br>\n- [PRD template](references/prd-template.md) <br>\n- [README template](references/readme-template.md) <br>\n- [Report template](references/report-template.md) <br>\n- [Build rules](references/rules.md) <br>\n- [User preferences](references/preferences.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance] <br>\n**Output Format:** [Markdown, project files, code, configuration, and shell command sequences] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Autonomous multi-step workflow that can create projects, install dependencies, start services, run tests, and update local rules or preferences.] <br>\n\n## Skill Version(s): <br>\n1.0.7 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.6: 10 files, 20828 bytes\n\nFiles: references/build-pipeline.md (8492b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1323b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4041b), skill-card.md (3141b), SKILL.md (16214b), _meta.json (127b)\n\nFile v1.0.6:SKILL.md\n\n---\nname: mano-afk\ndescription: Autonomous full-cycle app builder. Turns a natural language description into a production-ready application — PRD, architecture, code, deployment, testing, and bug fixing — fully automated, no human in the loop. Learns from each project by updating rules and preferences files inside the skill's own references/ directory (never writes outside the skill folder or project directory). Use when the user wants to build an application end-to-end without manual intervention.\nhomepage: https://github.com/Mininglamp-AI/mano-afk\nmetadata: {\"openclaw\": {\"emoji\": \"⚙️\", \"requires\": {\"bins\": [\"curl\"]}, \"install\": [{\"kind\": \"brew\", \"formula\":\"Mininglamp-AI/tap/mano-afk\", \"bins\":[\"mano-afk\"]}]}}\n---\n\n# mano-afk\n\nFully automated pipeline that builds, deploys, and tests applications from a natural language description. The user is AFK for the entire duration. The skill learns from each project — build rules (`references/rules.md`) and user preferences (`references/preferences.md`) are updated inside the skill's own `references/` directory after each build. No files are written outside the skill folder or the target project directory.\n\n### Data, Privacy & Safety\n\n- **What it does:** Creates a new project directory, installs dependencies, starts local dev servers, and runs tests via `curl` and `mano-afk run`. All actions are confined to the project directory. The tech stack (and therefore which toolchain binaries are used — e.g., `node`/`npm` for JS projects, `python3`/`pip` for Python projects) is determined at build time based on the user's request. These are standard development tools, not fixed dependencies of the skill itself — only `curl` is always required.\n- **What it does NOT do:** Does not read or transmit local files outside the project, does not access clipboard or browser history, does not modify system configuration, and does not send data to any external service (except standard package registries like npm/PyPI during dependency install).\n- **Persistence:** Build rules (`references/rules.md`) and user preferences (`references/preferences.md`) are stored inside the skill's own `references/` directory — never in global paths, home directory dotfiles, or other skills' directories.\n- **Credentials:** No API key is required to use the skill. `ANTHROPIC_API_KEY` is optional (only for cloud E2E testing) and stored in the project's `deploy/.env` (gitignored), never in the user's shell profile.\n- **Supply chain:** The `mano-afk` CLI is open source ([GitHub](https://github.com/Mininglamp-AI/mano-afk)). The Homebrew formula ([formula source](https://github.com/Mininglamp-AI/homebrew-tap/blob/main/Formula/mano-afk.rb)) builds directly from the public source. Prebuilt binaries are available on [GitHub Releases](https://github.com/Mininglamp-AI/mano-afk/releases).\n- **User control:** Step 0 is the only interactive step — the user confirms scope before autonomous execution begins. The build stops automatically if 10 fix iterations are exhausted or if it encounters missing permissions.\n\n### Optional environment variables\n\nThese are **not required** to use the skill. The skill asks the user during Step 0 whether to configure them. If declined, the corresponding features are skipped.\n\n| Variable | When needed | Purpose |\n|---|---|---|\n| `ANTHROPIC_API_KEY` | Only if E2E test mode is set to `cloud` | Powers cloud-based visual E2E testing via `mano-afk run` |\n\nThis variable is not read by the skill itself at install time. It is configured interactively during Step 0 and stored in the project's `deploy/.env` (gitignored, never in the user's shell profile).\n\n**Claude Code users:** Use the Claude Code-specific skill at [`skill/`](https://github.com/Mininglamp-AI/mano-afk/tree/master/skill).\n\n## Architecture\n\nThree roles collaborate to deliver the application:\n\n- **Main Agent** (you): orchestration, test execution, fix coordination, user communication\n- **Build Sub-agent**: requirements → architecture → code → deploy → bug fixes (when given specific errors)\n- **Adversary Sub-agent**: independent test case design (does not execute tests)\n\nThe main agent delegates code generation to the build sub-agent (the longest phase) and stays free during that time. The main agent runs all tests directly for full visibility into results. The build sub-agent (defined in `references/build-pipeline.md`) never runs tests — it only writes code and deploys.\n\n## Orchestration\n\n**AFK rule:** Step 0 is the only user interaction window. From Step 1 onward, make all decisions autonomously — never ask the user. Ambiguous decisions (8bit vs float, React vs Vue, port selection) use the most reasonable default and document in PRD.md. Only stop if completely infeasible (missing hardware, no permissions, 10 fix iterations exhausted).\n\n### Step 0: User Setup (interactive)\n\nThis is the only step where the agent may ask the user questions.\n\n**Requirements triage:** If the request is too vague to determine core functionality (e.g., \"build me an app\"), or contains ambiguous requirements that could lead to fundamentally different products, ask the user to clarify — keep it to 1-2 focused questions, not a long interview. Non-critical gaps (visual design, validation rules, tech stack, layout) are filled autonomously by the build sub-agent.\n\n**E2E test mode:** Check `mano-afk config --get e2e-mode` (`local` or `cloud`).\n\n- **`local`** — requires `default-model-path` to be configured via `mano-afk config --set default-model-path <path>`.\n- **`cloud`** — requires `ANTHROPIC_API_KEY` environment variable to be set.\n- **Not set** — first-time setup. Check the platform:\n  - **macOS**: ask the user: Local (Mano-P) or Cloud (Anthropic API key) or Skip?\n  - **Other platforms**: Local is not available. Ask the user to configure Cloud or Skip.\n  - If **Local**: run `mano-afk check` to verify SDK and model. Follow the printed guidance to resolve any missing components (install SDK, set model path, etc.).\n  - If **Cloud**: ask the user to provide their Anthropic API key. Write it to the project's `deploy/.env` as `ANTHROPIC_API_KEY=<key>`. Run `mano-afk check` to confirm.\n  - If `mano-afk run` or `mano-afk check` prints setup guidance (missing model path, missing API key), follow the instructions in the output to help the user complete configuration.\n  - If the user declines both → **Skip** E2E tests (logged in `report.md`).\n\nWhen Step 0 completes, tell the user: **\"Hold the beer. AFK from now on.\"**\n\n### Step 1: Prepare (autonomous — no user interaction)\n\nDerive a short, kebab-case project name from the request (e.g., \"make me a todo app\" → `todo-app`).\n\n**Project directory:** Read the configured project root via `mano-afk config --get projects-dir` (default: `~/Projects/`). Project directory: `{projects-dir}/{project-name}/`.\n\nRead `references/report-template.md` — you will use it in Step 4 to write `report.md`. Note the absolute path to the `references/` directory — it will be passed to sub-agents for the remaining reference files.\n\n### Step 2: Build (sub-agent)\n\nSpawn a build sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n\n1. The absolute path to `build-pipeline.md` — instruct the sub-agent to read and follow it\n2. The absolute path to this skill's `references/` directory — the sub-agent reads rules.md, preferences.md, and templates as needed\n3. The user's original request, verbatim\n4. The project directory path\n\nRespond to the user immediately with what is being built and the project directory. The build sub-agent follows 4 phases internally: **Phase 1** generates `PRD.md` (product requirements with acceptance criteria), **Phase 2** designs architecture and generates `README.md` (with test cases derived from PRD), **Phase 3** writes code, **Phase 4** deploys. Wait for `progress.md` to show `status: ready_for_testing`.\n\n**Timeout:** Build tasks (dependency installation, compilation, deployment) can take a long time. Set a generous timeout when spawning the sub-agent — at least 30 minutes, or no timeout if the platform supports it.\n\n### Step 3: Verify Deployment\n\nBefore testing, confirm the app is accessible:\n1. Check that `deploy/start.sh` exists in the project\n2. Run it if servers are not already running\n3. Verify with `curl` or port check\n4. If deployment fails (start.sh missing, server crashes, port unreachable), read `deploy/backend.log` and `deploy/frontend.log`, then go to Step 5 (Fix Loop) with the deployment error as the failure description\n\n### Step 4: Test\n\nExecute every test case defined in the README across all categories. No test case may be skipped or deferred.\n\nBefore starting each category, count the total test cases from the README. Print a progress counter for each test: `[3/18] api_3 PASS` or `[5/18] api_5 FAIL`. This makes skipped tests visible — if the counter jumps from 3 to 7, tests 4-6 were skipped.\n\nRecord results in `report.md` (use the report template). On failure, include full error output (response body, stderr, logs).\n\n**Headless environments:** If no graphical desktop is available, skip VLA tests (4.3). Adversary review (4.4) still runs — triage uses code inspection and curl, not mano-afk.\n\n#### 4.1 Lint\n\nRun the linter configured by the build sub-agent. Auto-fix what's possible (`--fix`), then report remaining errors.\n\n#### 4.2 API Tests\n\nRun every API test case defined in the README. Use `curl -s -w \"\\nHTTP_STATUS:%{http_code}\\n\"` to capture response body and status code. Print full response body on failure.\n\n**mano-afk requirement (4.3):** `mano-afk` is required only for E2E visual tests. Install if missing: macOS: `brew install Mininglamp-AI/tap/mano-afk`. If the user declines installation or it fails, skip 4.3 and log the reason — all other test categories still run.\n\n#### 4.3 VLA Tests (E2E)\n\nRead `mano-afk config --get e2e-mode`. If `local` → use Local mode. If `cloud` → use Cloud mode. If not set → Skip (record reason in `report.md`).\n\n**Database reset:** Before running the first E2E test, clear all application tables (e.g., `DELETE FROM` each app table, or delete and re-initialize the SQLite file). This removes residual data from API tests. Do NOT reset between individual E2E tests — they run sequentially and may depend on state created by prior tests.\n\nRun every E2E test case defined in the README using the chosen mode:\n\n```bash\nmano-afk run \"{steps}\" --url \"{url}\" --expect \"{expected}\"\n```\n\n`--url` opens the target page in the default browser before the agent starts. The agent sees the page already loaded — do NOT include \"Open localhost:...\" in the task steps.\n\nAll execution parameters (`--local`/`--cloud`, `--max-steps`, `--minimize`) are read from `mano-afk config`. CLI flags override config when specified. Use `mano-afk config --list` to see current values.\n\nExecution rules:\n- Run each test sequentially\n- Each `mano-afk` task can take up to 30 minutes. Set `exec` timeout to at least 1800s, or use `background: true` with `yieldMs: 1800000`. Never use a short timeout\n- Do not use mouse/keyboard while a test is running\n- Use `mano-afk stop` to: resolve 409 session conflicts, clean up after a killed process, or abort a running task\n\n#### 4.4 Adversary Review\n\nAfter all previous tests pass, spawn an adversary sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n1. Role: \"You are an independent QA reviewer. Your job is to identify potential problems the builder likely missed.\"\n2. The full content of the project's `PRD.md` (requirements and acceptance criteria) and `README.md` (architecture and test cases)\n3. The project directory path (the adversary reads source code for code-level findings)\n\nThe adversary does NOT interact with the running app — it reviews requirements and code only.\n\nThe adversary sub-agent **identifies potential problems only** — it does NOT execute anything. It returns findings in two layers, each as a table with columns: ID, Finding, Severity, Suggested Verification.\n\n- **Layer 1 — User perspective**: usability gaps, cross-feature consistency, confusing flows, poor UX\n- **Layer 2 — Code perspective**: data integrity, missing validation, error handling, state consistency\n\nConstraints: cover both layers, do NOT repeat issues already in README test cases, do NOT flag security vulnerabilities (XSS, SQL injection, CSRF).\n\n**Triage each finding yourself** using the appropriate method: code inspection (schema/config issues), API test (backend behavior via curl), or E2E test (UI rendering, user flows, visual state). At least 2-3 findings must be verified via E2E test. **Reset the database before running adversary E2E verifications** to avoid pollution from prior tests. Record each verdict in report.md: confirmed (→ fix loop) or dismissed (with reason).\n\n### Completion Checklist (before proceeding to Step 5 or 6)\n\nBefore moving forward, verify each item. If any is \"no\", go back and complete it.\n\n- [ ] Every API test case in README executed and recorded\n- [ ] Every E2E test case in README executed and recorded\n- [ ] Adversary review completed with findings from both layers\n- [ ] At least 2-3 adversary findings verified via E2E test\n- [ ] All confirmed adversary findings entered into fix loop\n\n### Step 5: Fix Loop\n\nIf any test fails:\n\n1. Collect all failures with full error output (response body, stderr, logs, mano-afk output)\n2. Spawn a **new** build sub-agent in fix mode via `sessions_spawn` with `runtime=\"subagent\"` — provide:\n   - The absolute path to `build-pipeline.md` (fix mode does not need other reference files)\n   - Project directory path\n   - Detailed failure descriptions: test ID, command run, expected result, actual result, full error output\n3. Wait for the sub-agent to fix and re-deploy (`progress.md` shows `status: ready_for_testing`)\n4. Re-run failed tests with the same tool and method used in the original test. A test verified via E2E test must be re-verified via E2E test.\n5. Repeat until all pass (max 10 iterations)\n\n**E2E false positives:** If an E2E test fails but you inspect the code and confirm the implementation is correct (the failure is a vision model misinterpretation), dismiss it as a false positive in `report.md` with your reasoning. Do not enter the fix loop for false positives — fixing correct code wastes iterations.\n\n**Step back on repeated failures:** If the same test fails 2+ times, include a note in the fix prompt: \"This test has failed N times. Previous fix attempts: [descriptions]. Consider a structural fix rather than a patch.\"\n\n**Exhausted iterations:** If 10 iterations are reached and failures remain, proceed to Step 6 with current results. Finalize `report.md` with all remaining failures, iteration history, and a summary of what was attempted.\n\n### Step 6: Completion\n\n- Summarize to the user: total tests, pass/fail, project directory\n- **Update rules:** Review the fix loop history. If any error pattern would prevent the same class of bug in a future project, add a general rule to `references/rules.md` (max 100, remove least valuable if full). Also merge any `new-rules.md` the build sub-agent wrote in the project root.\n- **Update preferences:** If the user gives follow-up feedback (styling, features), update `references/preferences.md`\n\n## Reference Directory\n\nThe `references/` directory contains files that evolve across projects:\n\n| File | Purpose | Max entries |\n|---|---|---|\n| `build-pipeline.md` | Build sub-agent instructions (phases 1-4 + fix mode) | — |\n| `rules.md` | General build rules, lessons learned | 100 |\n| `preferences.md` | User styling/UX preferences | 50 |\n| `prd-template.md` | PRD generation template (5 chapters) | — |\n| `project-structure.md` | Standard directory layout template | — |\n| `readme-template.md` | README.md generation template | — |\n| `report-template.md` | report.md generation template | — |\n\nRules and preferences are updated during execution (fix loop lessons, post-completion feedback) and persist across projects. All persistent state lives inside this `references/` directory — the skill never writes to global paths, home directory, or other skills' directories.\n\nFile v1.0.6:_meta.json\n\n{\n  \"ownerId\": \"kn7ccfetx2c3t68s44jkw2wq5d82n0pp\",\n  \"slug\": \"mano-afk\",\n  \"version\": \"1.0.6\",\n  \"publishedAt\": 1777450676908\n}\n\nFile v1.0.6:references/build-pipeline.md\n\n# Build Pipeline (Sub-agent Instructions)\n\nThis file is read by the **build sub-agent only** — not the main agent. The main agent handles orchestration and test execution (see SKILL.md). The build sub-agent's sole responsibility is code generation and deployment.\n\nYou are a code builder. You receive a user request, make design decisions, write code, and deliver a running deployment. You do **not** run tests — the main agent handles all testing and will send you specific errors to fix if needed.\n\n## Mode\n\nYou operate in one of two modes based on your prompt:\n\n**Build mode** (default): No test failures in prompt → create a new application, phases 1–4.\n\n**Fix mode**: Test failures included in prompt → read the existing code at the project directory, fix the issues, re-deploy, update `progress.md` with `status: ready_for_testing`.\n\n## Execution Rules\n\n- Do **NOT** invoke any other skill. Use your own tools to write code, run commands, read and edit files directly.\n- Do **NOT** ask the user for clarification. Make autonomous decisions and document them.\n- Do **NOT** run tests. The main agent handles all testing.\n- Do **NOT** set tight timeouts on long-running commands (dependency installs, builds, deployments). Use generous timeouts or none.\n\n## Progress Reporting\n\nWrite `progress.md` in the project root at every phase transition. Format:\n\n```\nphase: {N}\nstatus: {in_progress | ready_for_testing | failed}\ntitle: {Phase title}\ndetail: {Current action or result summary}\n```\n\n## Project Setup\n\n- Create the project in its own independent directory (never inside an existing project)\n- Python projects: always use a virtual environment\n- The references directory path is provided in your prompt. Read `rules.md`, `preferences.md`, and templates from it as needed.\n\n## Safety Boundary\n\n- Only write files inside the project directory or the skill's own `references/` directory\n- Do not delete files/directories outside the project folder\n- Do not overwrite pre-existing files\n- Do not expose credentials in code — use environment variables\n- Do not run destructive commands on existing data\n- Do not read or source the user's shell profile (`~/.zshrc`, `~/.bashrc`, `~/.profile`, etc.)\n- Store runtime secrets only in `deploy/.env` (never committed to git)\n\n---\n\n## Phase 1: Product Requirements\n\n> **Update progress.md** — `phase: 1, status: in_progress, title: Product Requirements`\n\n1. **Read references** — read `rules.md`, `preferences.md`, and `prd-template.md` from the references directory.\n2. **Understand the request** — identify core functionality, target user, data model, and scope boundary.\n3. **Fill in gaps autonomously** — for any detail not specified by the user (visual design, validation rules, error messages, layout, interaction details), make reasonable decisions based on rules and preferences. Document each decision.\n4. **Expand scope** — add standard features the user didn't mention but would expect: error handling, responsive layout, input validation, empty states.\n5. **Apply styling** — read `preferences.md` for global taste, then derive a project-specific color palette and component styles from the product's domain.\n6. **Generate `PRD.md`** — write a complete PRD using the `prd-template.md` structure. Every feature must have acceptance criteria (Given-When-Then) with L1/L2/L3 levels. Every error scenario must have an explicit message and behavior. The PRD is the single source of truth for what to build.\n\nThe PRD replaces the old decision checklist. All design decisions are embedded in the PRD's functional requirements and visual design sections.\n\n---\n\n## Phase 2: Design Architecture\n\n> **Update progress.md** — `phase: 2, status: in_progress, title: Design Architecture`\n\nDesign full technical architecture to satisfy every requirement in the PRD you just generated.\n\n### Tech Stack Selection\n\n| Complexity | Frontend | Backend | Database | Deployment |\n|---|---|---|---|---|\n| Simple (static/SPA) | HTML/CSS/JS or React | None or Express | None or SQLite | Static serve or `npx serve` |\n| Medium (CRUD app) | React or Vue | Node/Express or FastAPI | SQLite or PostgreSQL | `npm start` / `uvicorn` |\n| Complex (multi-service) | React + state management | FastAPI or Node | PostgreSQL | Docker Compose |\n\n**Pre-flight check:** After selecting the tech stack, verify that the required tools are installed (e.g., `node --version`, `python3 --version`). If missing, attempt to install via `brew`. If installation fails, update `progress.md` with `status: failed` and the missing dependency.\n\n### Architecture Deliverables\n\n1. **Component diagram** — every major component and how they connect\n2. **API design** — every endpoint with method, path, request/response schema\n3. **Data model** — every entity, fields, types, relationships\n4. **File structure** — exact directory tree (see project structure template in the references directory)\n\nValidate: every AC in the PRD maps to at least one API endpoint and/or UI component.\n\n### Generate README.md\n\nGenerate README.md using the readme template in the references directory. The test cases section must derive from the PRD's acceptance criteria:\n- **API Tests**: for each AC that involves backend behavior, generate a concrete test case (curl command, expected status, expected response). Include the AC number in the test ID.\n- **E2E Tests**: for each AC that involves UI interaction or visual state, generate an E2E test case. Follow the writing rules in the readme template strictly:\n  - **task** = operation path only (clicks, inputs, navigation). No verification verbs. No conditionals. Specific targets (\"the first card\", not \"any card\").\n  - **expect** = observable page state only. No conditionals (no \"if\"). No instructions.\n  - Order tests so state dependencies flow downward. Mark dependencies in the Depends column.\n  - Tests start from a **clean database**. Each test inherits state from previous tests. Design accordingly.\n  - Merge ACs that share the same screen with no unique operations into one test with a richer expect.\n  - For the first E2E test on each page/route, include visual quality expectations in `--expect` (layout, colors, no broken images).\n- Every L1 and L2 AC must have at least one test case. L3 ACs should have test cases where feasible.\n\n---\n\n## Phase 3: Build Code\n\n> **Update progress.md** — `phase: 3, status: in_progress, title: Build Code`\n\n### Lint Configuration\n\nAuto-select linter based on tech stack:\n\n| Stack | Linter | Config File |\n|---|---|---|\n| JavaScript/TypeScript | ESLint | `.eslintrc.json` |\n| Python | Ruff | `ruff.toml` |\n| CSS | Stylelint | `.stylelintrc.json` |\n\n### Project Structure\n\nFollow the project structure template in the references directory. Flatten for simple apps without backend.\n\n### Code Standards\n\nComplete, functional code — no placeholders or TODOs. Follow `rules.md` for technical standards and `preferences.md` for styling. Apply the visual design from `PRD.md` Chapter 5.\n\n---\n\n## Phase 4: Deploy\n\n> **Update progress.md** — `phase: 4, status: in_progress, title: Deploy`\n\n1. Install dependencies\n2. Initialize database if needed\n3. Start backend — redirect stdout/stderr to `deploy/backend.log`\n4. Start frontend — redirect stdout/stderr to `deploy/frontend.log`\n5. Verify accessible (curl health endpoint or check port). On failure, read log files immediately.\n\nCreate `deploy/start.sh` — idempotent, one-command startup. If the project uses a `deploy/.env` file, the script must load it (e.g., `set -a; source deploy/.env; set +a`) before starting servers. Never source the user's shell profile (`~/.zshrc`, `~/.bashrc`, etc.). Add `deploy/.env` to `.gitignore`.\n\n> **Update progress.md** — `phase: 4, status: ready_for_testing, title: Deploy`\n\n---\n\n## Fix Mode\n\nWhen your prompt includes test failure descriptions:\n\n1. Read the failure details: test ID, command, expected vs actual, full error output\n2. Read the relevant source code at the project directory\n3. Diagnose root cause — if the same error has been reported before (noted in prompt), consider a structural fix\n4. Apply minimal code changes to resolve the issues\n5. Re-deploy: run `deploy/start.sh` or equivalent, verify accessible\n6. If new rules were learned (general patterns that would prevent this class of bug in future projects), write them to `new-rules.md` in the project root\n\n> **Update progress.md** — `status: ready_for_testing, detail: Fixed: {brief summary of changes}`\n\nFile v1.0.6:references/prd-template.md\n\n# {Project Name} — PRD\n\n## 1. Product Overview\n\n**Core value:** {one sentence — why this product exists}\n**Target user:** {who uses it and how}\n**Scope boundary:** {what is explicitly NOT included}\n\n## 2. Functional Requirements\n\nEach feature includes acceptance criteria (AC) in Given-When-Then format. AC numbering: `AC-{feature}.{seq}`, tagged L1 (core path), L2 (business rules), or L3 (edge cases).\n\n### 2.1 {Feature Name}\n\n**Description:** {what it does, one paragraph}\n\n**AC-2.1.1 (L1):** {title}\nGiven {precondition}\nWhen {action}\nThen {expected result}\n\n**AC-2.1.2 (L2):** {title}\nGiven ... When ... Then ...\n\n**AC-2.1.3 (L3):** {title}\nGiven ... When ... Then ...\n\n## 3. Business Rules\n\n### Data Constraints\n\n| Field | Type | Constraint |\n|---|---|---|\n| {field} | {type} | {required/optional, range, format, max length} |\n\n### State Machine (if applicable)\n\n`{state_1} → {state_2} → ... → {terminal_state}`\n- {transition rules, terminal state behavior}\n\n## 4. Error & Exception Design\n\n| Scenario | User-facing Message | Behavior |\n|---|---|---|\n| {scenario} | \"{message}\" | {recovery path} |\n\nEvery user-reachable error must have an explicit message and recovery path. No \"TBD\".\n\n## 5. Visual Design\n\n### Color Palette\n\nDerive from the product's domain. Reference `preferences.md` for the user's global taste. Define at minimum: Primary (+ light/dark variants), Success, Warning, Error, Background, Surface, Text Primary/Secondary, Border — all with hex values.\n\n### Layout\n\n```\n{ASCII wireframe of the main page}\n```\n\n{Brief layout description: navigation, content area, responsive behavior}\n\n### Key Component Styles\n\nButtons, Cards, Forms, Tables — define border-radius, shadow, padding, hover/active transitions for each.\n\nFile v1.0.6:references/preferences.md\n\n# User Preferences\n\nAccumulated styling and UX preferences. This file starts broad and evolves as the user's taste becomes clearer. Max 50 entries — replace outdated preferences when adding beyond the limit.\n\n## Design Philosophy\n\n1. **Every visual choice should have intent.** Do not accept framework defaults without evaluating whether they serve the app's purpose. Color, spacing, and layout should be deliberate.\n2. **Each app should have its own visual identity.** Avoid generic patterns (uniform gray backgrounds, single blue accent, identical rounded corners). Derive the visual language from the app's domain and purpose.\n\n## Icons & Visual Elements\n\n3. **Use an icon library, never emoji for functional UI.** Default: Lucide React (`lucide-react`). Emoji are for content, not for buttons, nav, or labels.\n4. **Prefer meaningful whitespace over decoration.** Use generous spacing to separate content. Avoid dense layouts.\n\n## Color\n\n5. **Derive the color palette from the app's domain.** A finance app might use deep greens and golds; a timer app might use warm reds and ambers. Don't pick colors arbitrarily — let the subject matter guide the palette.\n6. **Build a full color scale, not a single accent.** At minimum: a primary color with light/dark variants, a neutral scale for text and backgrounds, and a semantic set (success, warning, error). Use CSS custom properties so the palette is easy to adjust.\n\n## Typography & Spacing\n\n7. **System font stack by default.** `-apple-system, BlinkMacSystemFont, \"Segoe UI\", Roboto, sans-serif`. Only add custom fonts when they serve a clear design purpose.\n8. **Establish a clear type hierarchy.** At least 3 distinct levels: heading, body, caption. Size differences should be noticeable, not subtle.\n9. **Consistent spacing scale.** Use multiples of 4px or 8px. Pick a base unit and stick to it throughout the app.\n\n## Layout\n\n10. **Card-based layout with subtle shadows.** Cards for grouping related content. Keep shadows light — the card should feel elevated, not floating.\n11. **Responsive by default.** CSS Grid or Flexbox. Design for mobile first when the app is consumer-facing.\n12. **Centered content with max-width.** Main content area should not exceed 1200px. Avoid full-width layouts that stretch content thin.\n\n## Components & Interaction\n\n13. **Transitions on interactive elements.** Buttons, links, cards — anything clickable should have a subtle hover/active transition. No jarring state changes.\n14. **Meaningful empty states.** Include a description of what will appear and a call-to-action to get started. Avoid bare \"no data\" messages.\n15. **Form validation: inline, on blur or submit.** Don't validate on every keystroke. Show errors below the field, clear them when the user starts fixing.\n16. **Loading: skeleton screens for content, spinners for actions.** Skeleton for page loads, small spinner for button submissions.\n\n## Theme\n\n17. **Dark mode if the framework supports it easily.** Use CSS variables for theming. Default to light mode.\n\n## Quality Checklist (applied during build)\n\n18. **Numbers should be formatted.** Currency with symbols, large numbers with separators, dates in locale-appropriate format.\n19. **Hover states, focus rings, and transitions must be present.** If you can click it, it needs visual feedback.\n20. **No orphaned styles.** Every CSS rule should serve a visible purpose. Remove unused styles before shipping.\n\nFile v1.0.6:references/project-structure.md\n\n# Project Structure Template\n\nStandard layout for full-stack apps. For simple apps without a backend, flatten to just the frontend structure.\n\n```\n{project-name}/\n+-- README.md                    # Generated documentation\n+-- report.md                    # Build/fix history\n+-- frontend/\n|   +-- package.json\n|   +-- public/\n|   |   +-- index.html\n|   +-- src/\n|       +-- App.jsx              # Root component\n|       +-- index.js             # Entry point\n|       +-- components/          # Reusable UI components\n|       +-- pages/               # Route-level components\n|       +-- services/            # API client functions\n|       +-- styles/              # CSS/styling\n+-- backend/\n|   +-- requirements.txt         # or package.json\n|   +-- app.py                   # Entry point\n|   +-- routes/                  # API route handlers\n|   +-- models/                  # Data models\n|   +-- services/                # Business logic\n|   +-- database/                # DB setup, migrations\n+-- tests/\n|   +-- api/                     # API test scripts\n|   +-- e2e/                     # VLA test definitions\n+-- deploy/\n    +-- .env                     # Runtime secrets (gitignored, never committed)\n    +-- start.sh                 # One-command startup script\n    +-- docker-compose.yml       # If applicable\n```\n\nFile v1.0.6:references/readme-template.md\n\n# {Project Name}\n\n{One-sentence description}\n\n## Tech Stack\n\n| Layer | Technology | Reason |\n|---|---|---|\n| Frontend | {framework} | {why} |\n| Backend | {framework} | {why} |\n| Database | {db} | {why} |\n\n## Architecture\n\n### API Endpoints\n| Method | Path | Description | Request | Response |\n|---|---|---|---|---|\n| GET | /api/items | List all items | — | `[{id, name, ...}]` |\n| POST | /api/items | Create item | `{name, ...}` | `{id, name, ...}` |\n\n### Data Model\n| Entity | Fields |\n|---|---|\n| {Entity} | {field1} ({type}), {field2} ({type}), ... |\n\n### File Structure\n{directory tree}\n\n## Setup & Deployment\n\n```bash\n./deploy/start.sh\n```\n\n## Test Cases\n\nTest cases are derived from the acceptance criteria in `PRD.md`. Each test ID references the corresponding AC number for traceability.\n\n### Lint\n- {Linter} with {config}: zero errors required\n\n### API Tests\n| ID | AC | Method | Path | Input | Expected Status | Expected Response |\n|---|---|---|---|---|---|---|\n| api_1 | AC-2.1.1 | GET | /api/items | — | 200 | `[{id, name, ...}]` |\n| api_2 | AC-2.2.1 | POST | /api/items | `{name: \"test\"}` | 201 | `{id: 1, name: \"test\"}` |\n| api_3 | AC-2.2.2 | POST | /api/items | `{}` | 400 | `{error: \"name is required\"}` |\n| api_4 | AC-2.1.3 | GET | /api/items/999 | — | 404 | `{error: \"not found\"}` |\n\n### E2E Tests (VLA via mano-afk)\n\n**Writing rules:**\n- **task**: Operation path only — clicks, inputs, navigation. No verification verbs (verify, check, ensure). No conditionals (if, any). Targets must be specific (\"the first item\", not \"any item\").\n- **expect**: Observable page state only — what is visible after operations. No conditionals. No instructions.\n- Tests run sequentially top-to-bottom. Use Depends to declare state dependencies.\n- `--url` opens the page before the agent starts — do not include URL navigation in task.\n- Merge tests that verify the same screen with no additional operations.\n\n| ID | AC | Depends | Task | Expect |\n|---|---|---|---|---|\n| e2e_1 | AC-2.1.1 | — | `mano-afk run \"Open the Items tab\" --url \"http://localhost:3000\" --expect \"...\"` | List of items with names and dates. No broken layout or missing images. |\n| e2e_2 | AC-2.2.1 | — | `mano-afk run \"Click Add Item, type 'Test' in the name field, click Submit\" --url \"http://localhost:3000\" --expect \"...\"` | \"Test\" appears as a new row in the items list |\n| e2e_3 | AC-2.2.3 | e2e_2 | `mano-afk run \"Click the delete icon on the first item row, confirm the deletion\" --url \"http://localhost:3000\" --expect \"...\"` | The item is removed. \"No items yet\" message displayed. |\n\n### Adversary Tests\nDesigned and executed by independent sub-agent based on PRD.md and this README. Up to 10 test cases covering edge cases, error handling, and spec compliance.\n\nFile v1.0.6:references/report-template.md\n\n# Build Report: {Project Name}\n\n## Summary\n- Total iterations: {N}\n- Final status: {ALL PASS / X failures remaining}\n- Total time: {elapsed}\n\n## Test Results\n\n### Lint\n| Linter | Errors | Warnings | Status |\n|---|---|---|---|\n| ESLint | 0 | 0 | PASS |\n\n### API Tests\n| ID | AC | Test | Result | Notes |\n|---|---|---|---|---|\n| api_1 | AC-2.1.1 | GET /api/items | PASS | — |\n| api_2 | AC-2.2.1 | POST /api/items | PASS | — |\n| api_3 | AC-2.2.2 | POST /api/items (invalid) | FAIL -> PASS (iter 2) | Fixed validation |\n\n### E2E Tests\n| ID | AC | Journey | Result | Notes |\n|---|---|---|---|---|\n| e2e_1 | AC-2.1.1 | Page load visual check | PASS | — |\n| e2e_2 | AC-2.2.1 | Create item | FAIL | Confirm dialog not dismissed |\n\n### Adversary Tests\n| ID | Finding | Severity | Result | Notes |\n|---|---|---|---|---|\n| adv_1 | Empty form submission | Medium | PASS | — |\n| adv_2 | Rapid double-click submit | High | FAIL | Created duplicate entry |\n\n## Iteration Log\n\n### Iteration 1 (Initial Build)\n- **Status**: FAIL (3/10 tests failed)\n- **Failures**:\n  - api_3 (AC-2.2.2): Missing input validation, returned 500 instead of 400\n  - e2e_1 (AC-2.1.1): VISUAL_DEFECT — Card component has no padding, text overlaps border\n  - e2e_2 (AC-2.2.1): Delete confirm dialog not handled\n\n### Iteration 2\n- **Fixed**:\n  - api_3: Added request body validation in POST /api/items route\n  - e2e_1: Added padding: 16px to .card-body CSS class\n- **Files modified**: backend/routes/items.py, frontend/src/styles/card.css\n- **Status**: FAIL (1/10 tests failed)\n- **Remaining failures**:\n  - e2e_2 (AC-2.2.1): Confirm dialog not dismissed\n\n### Iteration N (Final)\n- **Fixed**:\n  - e2e_2: Added window.confirm() handler in delete button onClick\n- **Files modified**: frontend/src/components/ItemDetail.jsx\n- **Status**: ALL PASS\n\n## Lessons Learned\n- {Any new rules written to new-rules.md during this build}\n\nFile v1.0.6:references/rules.md\n\n# Build Rules\n\nGeneral rules learned from past projects. Max 100 rules — remove the least valuable when adding beyond the limit.\n\n## Technical Defaults\n\n1. **Python projects: always use a virtual environment.** Create venv in the project directory and install all deps inside it. Never `pip install` globally.\n2. **Prefer SQLite over PostgreSQL for simple projects.** Use PostgreSQL only when the app needs concurrent multi-user writes, complex queries, or multiple related tables with joins.\n3. **Pin dependency versions.** Use exact versions in `requirements.txt` and `package.json` to prevent build breakage from upstream changes.\n4. **Use environment variables for all configuration.** Never hardcode API keys, database paths, ports, or secrets. Provide sensible defaults in code.\n5. **Create `.gitignore` appropriate for the stack.** Include node_modules, __pycache__, .env, deploy/.env, venv, build artifacts, and IDE files.\n\n## Code Quality\n\n6. **One component per file.** Keep components, routes, and models in separate files. Avoid god files with multiple unrelated exports.\n7. **Every API route must return proper HTTP status codes.** 200 for success, 201 for created, 400 for validation errors, 404 for not found, 500 for server errors. Never return 200 with an error in the body.\n8. **Add input validation at the API boundary.** Validate request bodies before processing. Return 400 with a clear error message for invalid input.\n9. **Frontend must handle three states for every async operation:** loading, success, and error. Never leave the user staring at a blank screen.\n\n## Lint\n\n10. **JavaScript/TypeScript: use ESLint with recommended rules.** Generate `.eslintrc.json` with `\"extends\": [\"eslint:recommended\"]`. For React, add `plugin:react/recommended`.\n11. **Python: use Ruff.** Generate `ruff.toml` with default rules. Enable `select = [\"E\", \"F\", \"I\"]` at minimum (errors, pyflakes, isort).\n12. **Zero lint errors before proceeding to other tests.** Auto-fix what can be auto-fixed, manually fix the rest.\n\n## Adversary Testing\n\n13. **Adversary sub-agent receives README and source code access.** It reviews findings in two layers: Layer 1 (user perspective) from README and running app, Layer 2 (code perspective) from reading source code. No build history or prior test results.\n14. **Adversary scope: functional correctness, edge cases, error handling, data integrity.** Do NOT test for security attacks (XSS, SQL injection, CSRF) unless explicitly requested.\n15. **Maximum 10 adversary test cases per session.** Focus on high-value tests the builder likely missed.\n16. **Always add delete confirmation dialogs for destructive actions.** Any button that permanently removes user data (holdings, entries, records) must show a `window.confirm()` or custom confirmation dialog before executing.\n17. **Persist triggered/computed state changes to the backend.** If the frontend computes a state change (e.g., alert triggered), it must call the corresponding backend endpoint to persist it. Client-side-only state is lost on refresh.\n18. **Add upper bound validation for numeric inputs.** Beyond `> 0`, validate that quantities and prices don't exceed a reasonable maximum (e.g., `999,999,999,999`) to prevent Infinity/NaN in calculations.\n19. **Modals must close on Escape key press.** Add a `keydown` event listener for the Escape key on all modal components. This is a standard UX expectation.\n20. **Wrap all async handlers in try/catch with user-facing error feedback.** Every `async` handler that calls an API must have a try/catch that shows a toast or inline error. Unhandled promise rejections leave users without feedback.\n21. **Cache third-party API responses with rate limits.** When proxying external APIs (CoinGecko, OpenWeather, etc.), add server-side in-memory caching with a TTL matching the refresh interval. On rate-limit (429) or network errors, return cached data instead of forwarding the error. Without caching, normal usage (auto-refresh, multiple users, testing) will quickly trigger rate limits.\n\nFile v1.0.6:skill-card.md\n\n## Description: <br>\nAutonomous full-cycle app builder that turns a natural-language request into a production-ready application with PRD, architecture, code, deployment, testing, and bug fixing. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[hanningwang](https://clawhub.ai/user/hanningwang) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineering agents use this skill to build, deploy, test, and iterate on an application from a natural-language request after an initial setup confirmation. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill can create projects, install dependencies or Homebrew packages, start local services, and run long test loops after a single setup step. <br>\nMitigation: Run it in an isolated development environment, review the Step 0 scope carefully, and inspect generated files and test results before relying on the output. <br>\nRisk: Cloud E2E testing can send test context to Anthropic when cloud mode and ANTHROPIC_API_KEY are configured. <br>\nMitigation: Use local or skipped E2E mode when sensitive data is involved, and provide real secrets only when cloud testing is intended. <br>\nRisk: Dependency installation and service startup can pull packages from public registries and execute development toolchains selected at build time. <br>\nMitigation: Prefer disposable workspaces, review dependency manifests, and restrict network or package installation permissions where appropriate. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/hanningwang/mano-afk) <br>\n- [Publisher Profile](https://clawhub.ai/user/hanningwang) <br>\n- [Project Homepage](https://github.com/Mininglamp-AI/mano-afk) <br>\n- [Homebrew Formula Source](https://github.com/Mininglamp-AI/homebrew-tap/blob/main/Formula/mano-afk.rb) <br>\n- [GitHub Releases](https://github.com/Mininglamp-AI/mano-afk/releases) <br>\n- [Build Pipeline](references/build-pipeline.md) <br>\n- [PRD Template](references/prd-template.md) <br>\n- [README Template](references/readme-template.md) <br>\n- [Report Template](references/report-template.md) <br>\n- [Project Structure Template](references/project-structure.md) <br>\n- [Build Rules](references/rules.md) <br>\n- [User Preferences](references/preferences.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance] <br>\n**Output Format:** [Markdown guidance, generated project files, shell commands, and build/test reports] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May create a project directory, install dependencies, start local servers, run tests, and update skill-local rules or preferences.] <br>\n\n## Skill Version(s): <br>\n1.0.6 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.5: 9 files, 19194 bytes\n\nFiles: references/build-pipeline.md (8492b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1323b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4041b), SKILL.md (15909b), _meta.json (127b)\n\nFile v1.0.5:SKILL.md\n\n---\nname: mano-afk\ndescription: Autonomous full-cycle app builder. Turns a natural language description into a production-ready application — PRD, architecture, code, deployment, testing, and bug fixing — fully automated, no human in the loop. Learns from each project by updating rules and preferences files inside the skill's own references/ directory (never writes outside the skill folder or project directory). Use when the user wants to build an application end-to-end without manual intervention.\nhomepage: https://github.com/Mininglamp-AI/mano-afk\nmetadata: {\"openclaw\": {\"emoji\": \"⚙️\", \"requires\": {\"bins\": [\"curl\"]}, \"install\": [{\"kind\": \"brew\", \"formula\":\"Mininglamp-AI/tap/mano-afk\", \"bins\":[\"mano-afk\"]}]}}\n---\n\n# mano-afk\n\nFully automated pipeline that builds, deploys, and tests applications from a natural language description. The user is AFK for the entire duration. The skill learns from each project — build rules (`references/rules.md`) and user preferences (`references/preferences.md`) are updated inside the skill's own `references/` directory after each build. No files are written outside the skill folder or the target project directory.\n\n### Data, Privacy & Safety\n\n- **What it does:** Creates a new project directory, installs dependencies (npm/pip), starts local dev servers, and runs tests via `curl` and `mano-afk run`. All actions are confined to the project directory.\n- **What it does NOT do:** Does not read or transmit local files outside the project, does not access clipboard or browser history, does not modify system configuration, and does not send data to any external service (except standard package registries like npm/PyPI during dependency install).\n- **Persistence:** Build rules (`references/rules.md`) and user preferences (`references/preferences.md`) are stored inside the skill's own `references/` directory — never in global paths, home directory dotfiles, or other skills' directories.\n- **Credentials:** No API key is required to use the skill. `ANTHROPIC_API_KEY` is optional (only for cloud E2E testing) and stored in the project's `deploy/.env` (gitignored), never in the user's shell profile.\n- **Supply chain:** The `mano-afk` CLI is open source ([GitHub](https://github.com/Mininglamp-AI/mano-afk)). The Homebrew formula ([formula source](https://github.com/Mininglamp-AI/homebrew-tap/blob/main/Formula/mano-afk.rb)) builds directly from the public source. Prebuilt binaries are available on [GitHub Releases](https://github.com/Mininglamp-AI/mano-afk/releases).\n- **User control:** Step 0 is the only interactive step — the user confirms scope before autonomous execution begins. The build stops automatically if 10 fix iterations are exhausted or if it encounters missing permissions.\n\n### Optional environment variables\n\nThese are **not required** to use the skill. The skill asks the user during Step 0 whether to configure them. If declined, the corresponding features are skipped.\n\n| Variable | When needed | Purpose |\n|---|---|---|\n| `ANTHROPIC_API_KEY` | Only if E2E test mode is set to `cloud` | Powers cloud-based visual E2E testing via `mano-afk run` |\n\nThis variable is not read by the skill itself at install time. It is configured interactively during Step 0 and stored in the project's `deploy/.env` (gitignored, never in the user's shell profile).\n\n**Claude Code users:** Use the Claude Code-specific skill at [`skill/`](https://github.com/Mininglamp-AI/mano-afk/tree/master/skill).\n\n## Architecture\n\nThree roles collaborate to deliver the application:\n\n- **Main Agent** (you): orchestration, test execution, fix coordination, user communication\n- **Build Sub-agent**: requirements → architecture → code → deploy → bug fixes (when given specific errors)\n- **Adversary Sub-agent**: independent test case design (does not execute tests)\n\nThe main agent delegates code generation to the build sub-agent (the longest phase) and stays free during that time. The main agent runs all tests directly for full visibility into results. The build sub-agent (defined in `references/build-pipeline.md`) never runs tests — it only writes code and deploys.\n\n## Orchestration\n\n**AFK rule:** Step 0 is the only user interaction window. From Step 1 onward, make all decisions autonomously — never ask the user. Ambiguous decisions (8bit vs float, React vs Vue, port selection) use the most reasonable default and document in PRD.md. Only stop if completely infeasible (missing hardware, no permissions, 10 fix iterations exhausted).\n\n### Step 0: User Setup (interactive)\n\nThis is the only step where the agent may ask the user questions.\n\n**Requirements triage:** If the request is too vague to determine core functionality (e.g., \"build me an app\"), or contains ambiguous requirements that could lead to fundamentally different products, ask the user to clarify — keep it to 1-2 focused questions, not a long interview. Non-critical gaps (visual design, validation rules, tech stack, layout) are filled autonomously by the build sub-agent.\n\n**E2E test mode:** Check `mano-afk config --get e2e-mode` (`local` or `cloud`).\n\n- **`local`** — requires `default-model-path` to be configured via `mano-afk config --set default-model-path <path>`.\n- **`cloud`** — requires `ANTHROPIC_API_KEY` environment variable to be set.\n- **Not set** — first-time setup. Check the platform:\n  - **macOS**: ask the user: Local (Mano-P) or Cloud (Anthropic API key) or Skip?\n  - **Other platforms**: Local is not available. Ask the user to configure Cloud or Skip.\n  - If **Local**: run `mano-afk check` to verify SDK and model. Follow the printed guidance to resolve any missing components (install SDK, set model path, etc.).\n  - If **Cloud**: ask the user to provide their Anthropic API key. Write it to the project's `deploy/.env` as `ANTHROPIC_API_KEY=<key>`. Run `mano-afk check` to confirm.\n  - If `mano-afk run` or `mano-afk check` prints setup guidance (missing model path, missing API key), follow the instructions in the output to help the user complete configuration.\n  - If the user declines both → **Skip** E2E tests (logged in `report.md`).\n\nWhen Step 0 completes, tell the user: **\"Hold the beer. AFK from now on.\"**\n\n### Step 1: Prepare (autonomous — no user interaction)\n\nDerive a short, kebab-case project name from the request (e.g., \"make me a todo app\" → `todo-app`).\n\n**Project directory:** Read the configured project root via `mano-afk config --get projects-dir` (default: `~/Projects/`). Project directory: `{projects-dir}/{project-name}/`.\n\nRead `references/report-template.md` — you will use it in Step 4 to write `report.md`. Note the absolute path to the `references/` directory — it will be passed to sub-agents for the remaining reference files.\n\n### Step 2: Build (sub-agent)\n\nSpawn a build sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n\n1. The absolute path to `build-pipeline.md` — instruct the sub-agent to read and follow it\n2. The absolute path to this skill's `references/` directory — the sub-agent reads rules.md, preferences.md, and templates as needed\n3. The user's original request, verbatim\n4. The project directory path\n\nRespond to the user immediately with what is being built and the project directory. The build sub-agent follows 4 phases internally: **Phase 1** generates `PRD.md` (product requirements with acceptance criteria), **Phase 2** designs architecture and generates `README.md` (with test cases derived from PRD), **Phase 3** writes code, **Phase 4** deploys. Wait for `progress.md` to show `status: ready_for_testing`.\n\n**Timeout:** Build tasks (dependency installation, compilation, deployment) can take a long time. Set a generous timeout when spawning the sub-agent — at least 30 minutes, or no timeout if the platform supports it.\n\n### Step 3: Verify Deployment\n\nBefore testing, confirm the app is accessible:\n1. Check that `deploy/start.sh` exists in the project\n2. Run it if servers are not already running\n3. Verify with `curl` or port check\n4. If deployment fails (start.sh missing, server crashes, port unreachable), read `deploy/backend.log` and `deploy/frontend.log`, then go to Step 5 (Fix Loop) with the deployment error as the failure description\n\n### Step 4: Test\n\nExecute every test case defined in the README across all categories. No test case may be skipped or deferred.\n\nBefore starting each category, count the total test cases from the README. Print a progress counter for each test: `[3/18] api_3 PASS` or `[5/18] api_5 FAIL`. This makes skipped tests visible — if the counter jumps from 3 to 7, tests 4-6 were skipped.\n\nRecord results in `report.md` (use the report template). On failure, include full error output (response body, stderr, logs).\n\n**Headless environments:** If no graphical desktop is available, skip VLA tests (4.3). Adversary review (4.4) still runs — triage uses code inspection and curl, not mano-afk.\n\n#### 4.1 Lint\n\nRun the linter configured by the build sub-agent. Auto-fix what's possible (`--fix`), then report remaining errors.\n\n#### 4.2 API Tests\n\nRun every API test case defined in the README. Use `curl -s -w \"\\nHTTP_STATUS:%{http_code}\\n\"` to capture response body and status code. Print full response body on failure.\n\n**mano-afk requirement (4.3):** `mano-afk` is required only for E2E visual tests. Install if missing: macOS: `brew install Mininglamp-AI/tap/mano-afk`. If the user declines installation or it fails, skip 4.3 and log the reason — all other test categories still run.\n\n#### 4.3 VLA Tests (E2E)\n\nRead `mano-afk config --get e2e-mode`. If `local` → use Local mode. If `cloud` → use Cloud mode. If not set → Skip (record reason in `report.md`).\n\n**Database reset:** Before running the first E2E test, clear all application tables (e.g., `DELETE FROM` each app table, or delete and re-initialize the SQLite file). This removes residual data from API tests. Do NOT reset between individual E2E tests — they run sequentially and may depend on state created by prior tests.\n\nRun every E2E test case defined in the README using the chosen mode:\n\n```bash\nmano-afk run \"{steps}\" --url \"{url}\" --expect \"{expected}\"\n```\n\n`--url` opens the target page in the default browser before the agent starts. The agent sees the page already loaded — do NOT include \"Open localhost:...\" in the task steps.\n\nAll execution parameters (`--local`/`--cloud`, `--max-steps`, `--minimize`) are read from `mano-afk config`. CLI flags override config when specified. Use `mano-afk config --list` to see current values.\n\nExecution rules:\n- Run each test sequentially\n- Each `mano-afk` task can take up to 30 minutes. Set `exec` timeout to at least 1800s, or use `background: true` with `yieldMs: 1800000`. Never use a short timeout\n- Do not use mouse/keyboard while a test is running\n- Use `mano-afk stop` to: resolve 409 session conflicts, clean up after a killed process, or abort a running task\n\n#### 4.4 Adversary Review\n\nAfter all previous tests pass, spawn an adversary sub-agent via `sessions_spawn` with `runtime=\"subagent\"`. Construct the prompt with:\n1. Role: \"You are an independent QA reviewer. Your job is to identify potential problems the builder likely missed.\"\n2. The full content of the project's `PRD.md` (requirements and acceptance criteria) and `README.md` (architecture and test cases)\n3. The project directory path (the adversary reads source code for code-level findings)\n\nThe adversary does NOT interact with the running app — it reviews requirements and code only.\n\nThe adversary sub-agent **identifies potential problems only** — it does NOT execute anything. It returns findings in two layers, each as a table with columns: ID, Finding, Severity, Suggested Verification.\n\n- **Layer 1 — User perspective**: usability gaps, cross-feature consistency, confusing flows, poor UX\n- **Layer 2 — Code perspective**: data integrity, missing validation, error handling, state consistency\n\nConstraints: cover both layers, do NOT repeat issues already in README test cases, do NOT flag security vulnerabilities (XSS, SQL injection, CSRF).\n\n**Triage each finding yourself** using the appropriate method: code inspection (schema/config issues), API test (backend behavior via curl), or E2E test (UI rendering, user flows, visual state). At least 2-3 findings must be verified via E2E test. **Reset the database before running adversary E2E verifications** to avoid pollution from prior tests. Record each verdict in report.md: confirmed (→ fix loop) or dismissed (with reason).\n\n### Completion Checklist (before proceeding to Step 5 or 6)\n\nBefore moving forward, verify each item. If any is \"no\", go back and complete it.\n\n- [ ] Every API test case in README executed and recorded\n- [ ] Every E2E test case in README executed and recorded\n- [ ] Adversary review completed with findings from both layers\n- [ ] At least 2-3 adversary findings verified via E2E test\n- [ ] All confirmed adversary findings entered into fix loop\n\n### Step 5: Fix Loop\n\nIf any test fails:\n\n1. Collect all failures with full error output (response body, stderr, logs, mano-afk output)\n2. Spawn a **new** build sub-agent in fix mode via `sessions_spawn` with `runtime=\"subagent\"` — provide:\n   - The absolute path to `build-pipeline.md` (fix mode does not need other reference files)\n   - Project directory path\n   - Detailed failure descriptions: test ID, command run, expected result, actual result, full error output\n3. Wait for the sub-agent to fix and re-deploy (`progress.md` shows `status: ready_for_testing`)\n4. Re-run failed tests with the same tool and method used in the original test. A test verified via E2E test must be re-verified via E2E test.\n5. Repeat until all pass (max 10 iterations)\n\n**E2E false positives:** If an E2E test fails but you inspect the code and confirm the implementation is correct (the failure is a vision model misinterpretation), dismiss it as a false positive in `report.md` with your reasoning. Do not enter the fix loop for false positives — fixing correct code wastes iterations.\n\n**Step back on repeated failures:** If the same test fails 2+ times, include a note in the fix prompt: \"This test has failed N times. Previous fix attempts: [descriptions]. Consider a structural fix rather than a patch.\"\n\n**Exhausted iterations:** If 10 iterations are reached and failures remain, proceed to Step 6 with current results. Finalize `report.md` with all remaining failures, iteration history, and a summary of what was attempted.\n\n### Step 6: Completion\n\n- Summarize to the user: total tests, pass/fail, project directory\n- **Update rules:** Review the fix loop history. If any error pattern would prevent the same class of bug in a future project, add a general rule to `references/rules.md` (max 100, remove least valuable if full). Also merge any `new-rules.md` the build sub-agent wrote in the project root.\n- **Update preferences:** If the user gives follow-up feedback (styling, features), update `references/preferences.md`\n\n## Reference Directory\n\nThe `references/` directory contains files that evolve across projects:\n\n| File | Purpose | Max entries |\n|---|---|---|\n| `build-pipeline.md` | Build sub-agent instructions (phases 1-4 + fix mode) | — |\n| `rules.md` | General build rules, lessons learned | 100 |\n| `preferences.md` | User styling/UX preferences | 50 |\n| `prd-template.md` | PRD generation template (5 chapters) | — |\n| `project-structure.md` | Standard directory layout template | — |\n| `readme-template.md` | README.md generation template | — |\n| `report-template.md` | report.md generation template | — |\n\nRules and\n\nArchive v1.0.4: 9 files, 19226 bytes\n\nFiles: references/build-pipeline.md (8492b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1323b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4041b), SKILL.md (15882b), _meta.json (127b)\n\nArchive v1.0.3: 9 files, 19197 bytes\n\nFiles: references/build-pipeline.md (8492b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1323b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4041b), SKILL.md (15897b), _meta.json (127b)\n\nArchive v1.0.2: 9 files, 19071 bytes\n\nFiles: references/build-pipeline.md (8235b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1323b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4041b), SKILL.md (15771b), _meta.json (127b)\n\nArchive v1.0.1: 9 files, 18476 bytes\n\nFiles: references/build-pipeline.md (8144b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1323b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4041b), SKILL.md (13838b), _meta.json (127b)\n\nArchive v1.0.0: 9 files, 18233 bytes\n\nFiles: references/build-pipeline.md (8102b), references/prd-template.md (1753b), references/preferences.md (3427b), references/project-structure.md (1242b), references/readme-template.md (2760b), references/report-template.md (1892b), references/rules.md (4028b), SKILL.md (13365b), _meta.json (127b)","readmeExcerpt":"Skill: mano-afk Owner: hanningwang Summary: Autonomous full-cycle app builder — PRD, architecture, code, deployment, testing, and bug fixing from a natural language description. Remembers user preferen... Tags: latest:1.0.8 Version history: v1.0.8 | 2026-06-01T10:50:39.570Z | user mano-afk 1.0.8 - Simplified and clarified the E2E setup process in Step 0; users are now prompted to opt in to E2E testing, with clear gui","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"mano-afk run \"{steps}\" --url \"{url}\" --expect \"{expected}\""},{"language":"text","snippet":"phase: {N}\nstatus: {in_progress | ready_for_testing | failed}\ntitle: {Phase title}\ndetail: {Current action or result summary}"},{"language":"text","snippet":"{ASCII wireframe of the main page}"},{"language":"text","snippet":"{project-name}/\n+-- README.md                    # Generated documentation\n+-- report.md                    # Build/fix history\n+-- frontend/\n|   +-- package.json\n|   +-- public/\n|   |   +-- index.html\n|   +-- src/\n|       +-- App.jsx              # Root component\n|       +-- index.js             # Entry point\n|       +-- components/          # Reusable UI components\n|       +-- pages/               # Route-level components\n|       +-- services/            # API client functions\n|       +-- styles/              # CSS/styling\n+-- backend/\n|   +-- requirements.txt         # or package.json\n|   +-- app.py                   # Entry point\n|   +-- routes/                  # API route handlers\n|   +-- models/                  # Data models\n|   +-- services/                # Business logic\n|   +-- database/                # DB setup, migrations\n+-- tests/\n|   +-- api/                     # API test scripts\n|   +-- e2e/                     # VLA test definitions\n+-- deploy/\n    +-- start.sh                 # One-command startup script\n    +-- docker-compose.yml       # If applicable"},{"language":"bash","snippet":"./deploy/start.sh"},{"language":"bash","snippet":"mano-afk run \"{steps}\" --url \"{url}\" --expect \"{expected}\""}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: mano-afk\ndescription: Autonomous full-cycle app builder — PRD, architecture, code, deployment, testing, and bug fixing from a natural language description. Remembers user preferences and development pitfalls to self-evolve across projects. Use when the user explicitly requests a fully autonomous end-to-end app build.\nhomepage: https://github.com/Mininglamp-AI/mano-afk\nmetadata: {\"openclaw\": {\"emoji\": \"⚙️\", \"install\": [{\"id\": \"brew\", \"kind\": \"brew\", \"formula\":\"Mininglamp-AI/tap/mano-afk\", \"bins\":[\"mano-afk\"],\"label\": \"Install mano-afk (brew)\"}]}}\n---\n\n# mano-afk\n\nFully automated pipeline that builds, deploys, and tests applications from a natural language description. The user is AFK for the entire duration. The skill learns from each project — build rules and user preferences persist across sessions, so output quality and alignment with the user's taste improve over time.\n\n**Claude Code users:** Use the Claude Code-specific SKILL.md at [`claude/SKILL.md`](https://github.com/Mininglamp-AI/mano-afk/tree/master/claude).\n\n## Architecture\n\nThree roles collaborate to deliver the application:\n\n- **Main Agent** (you): orchestration, test execution, fix coordination, user communication\n- **Build Sub-agent**: requirements → architecture → code → deploy → bug fixes (when given specific errors)\n- **Adversary Sub-agent**: independent test case design (does not execute tests)\n\nThe main agent delegates code generation to a sub-agent (the longest phase) and stays free during that time. The main agent runs all tests directly for full visibility into results.\n\n## Orchestration\n\n**AFK rule:** Step 0 is the only user interaction window. From Step 1 onward, make all decisions autonomously — never ask the user. Ambiguous decisions (8bit vs float, React vs Vue, port selection) use the most reasonable default and document in PRD.md. Only stop if completely infeasible (missing hardware, no permissions, 10 fix iterations exhausted).\n\n### Step 0: User Setup (interactive)\n\nThis is the only step where the agent may ask the user questions.\n\n**Requirements triage:** If the request is too vague to determine core functionality (e.g., \"build me an app\"), or contains ambiguous requirements that could lead to fundamentally different products, ask the user to clarify — keep it to 1-2 focused questions, not a long interview. Non-critical gaps (visual design, validation rules, tech stack, layout) are filled autonomously by the build sub-agent.\n\n**E2E test setup:** Check `mano-afk config --get e2e-mode`.\n\n- **`local` or `cloud`** — already configured, proceed.\n- **Not set** — recommend E2E testing to the user: \"E2E testing lets mano-afk verify your app through the actual UI — clicking buttons, filling forms, checking visual results. Want to set it up?\" Then run `mano-afk check` and follow its printed guidance to complete configuration. If the user declines, skip E2E — the skill works without it.\n\nWhen Step 0 completes, tell the user: **\"Hold the beer. AFK from now on.\"**\n\n###"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7ccfetx2c3t68s44jkw2wq5d82n0pp\",\n  \"slug\": \"mano-afk\",\n  \"version\": \"1.0.8\",\n  \"publishedAt\": 1780311039570\n}"},{"path":"references/build-pipeline.md","content":"# Build Pipeline\n\nYou are a code builder. You receive a user request, make design decisions, write code, and deliver a running deployment. You do **not** run tests — the caller handles all testing and will send you specific errors to fix if needed.\n\n## Mode\n\nYou operate in one of two modes based on your prompt:\n\n**Build mode** (default): No test failures in prompt → create a new application, phases 1–4.\n\n**Fix mode**: Test failures included in prompt → read the existing code at the project directory, fix the issues, re-deploy, update `progress.md` with `status: ready_for_testing`.\n\n## Execution Rules\n\n- Do **NOT** invoke any other skill. Use your own tools to write code, run commands, read and edit files directly.\n- Do **NOT** ask the user for clarification on design decisions. Make autonomous decisions and document them. (Note: the main agent handles user-facing checkpoints — the build sub-agent operates autonomously within its delegated scope.)\n- Do **NOT** run tests. The caller handles all testing.\n- Do **NOT** set tight timeouts on long-running commands (dependency installs, builds, deployments). Use generous timeouts or none.\n\n## Progress Reporting\n\nWrite `progress.md` in the project root at every phase transition. Format:\n\n```\nphase: {N}\nstatus: {in_progress | ready_for_testing | failed}\ntitle: {Phase title}\ndetail: {Current action or result summary}\n```\n\n## Project Setup\n\n- Create the project in its own independent directory (never inside an existing project)\n- Python projects: always use a virtual environment\n- The references directory path is provided in your prompt. Read `rules.md`, `preferences.md`, and templates from it as needed.\n\n## Safety Boundary\n\n- Do not delete files/directories outside the project folder\n- Do not overwrite pre-existing files\n- Do not expose credentials in code — use environment variables\n- Do not run destructive commands on existing data\n- Do not source the user's shell profile (`~/.zshrc`, `~/.bashrc`) — pass only required env vars explicitly\n- Do not install system-level packages — if a required tool is missing, report it via `progress.md` and stop\n\n**Disclosure:** This sub-agent autonomously creates files (PRD.md, README.md, source code, deploy scripts), installs project-scoped dependencies (npm install, pip install inside venv), initializes databases, and starts local servers within the project directory. These actions are expected and disclosed — the user consented when invoking the skill.\n\n---\n\n## Phase 1: Product Requirements\n\n> **Update progress.md** — `phase: 1, status: in_progress, title: Product Requirements`\n\n1. **Read references** — read `rules.md`, `preferences.md`, and `prd-template.md` from the references directory.\n2. **Understand the request** — identify core functionality, target user, data model, and scope boundary.\n3. **Fill in gaps autonomously** — for any detail not specified by the user (visual design, validation rules, error messages, layout, interaction details), make reasonable decisi"},{"path":"references/prd-template.md","content":"# {Project Name} — PRD\n\n## 1. Product Overview\n\n**Core value:** {one sentence — why this product exists}\n**Target user:** {who uses it and how}\n**Scope boundary:** {what is explicitly NOT included}\n\n## 2. Functional Requirements\n\nEach feature includes acceptance criteria (AC) in Given-When-Then format. AC numbering: `AC-{feature}.{seq}`, tagged L1 (core path), L2 (business rules), or L3 (edge cases).\n\n### 2.1 {Feature Name}\n\n**Description:** {what it does, one paragraph}\n\n**AC-2.1.1 (L1):** {title}\nGiven {precondition}\nWhen {action}\nThen {expected result}\n\n**AC-2.1.2 (L2):** {title}\nGiven ... When ... Then ...\n\n**AC-2.1.3 (L3):** {title}\nGiven ... When ... Then ...\n\n## 3. Business Rules\n\n### Data Constraints\n\n| Field | Type | Constraint |\n|---|---|---|\n| {field} | {type} | {required/optional, range, format, max length} |\n\n### State Machine (if applicable)\n\n`{state_1} → {state_2} → ... → {terminal_state}`\n- {transition rules, terminal state behavior}\n\n## 4. Error & Exception Design\n\n| Scenario | User-facing Message | Behavior |\n|---|---|---|\n| {scenario} | \"{message}\" | {recovery path} |\n\nEvery user-reachable error must have an explicit message and recovery path. No \"TBD\".\n\n## 5. Visual Design\n\n### Color Palette\n\nDerive from the product's domain. Reference `preferences.md` for the user's global taste. Define at minimum: Primary (+ light/dark variants), Success, Warning, Error, Background, Surface, Text Primary/Secondary, Border — all with hex values.\n\n### Layout\n\n```\n{ASCII wireframe of the main page}\n```\n\n{Brief layout description: navigation, content area, responsive behavior}\n\n### Key Component Styles\n\nButtons, Cards, Forms, Tables — define border-radius, shadow, padding, hover/active transitions for each."},{"path":"references/preferences.md","content":"# User Preferences\n\nAccumulated styling and UX preferences. This file starts broad and evolves as the user's taste becomes clearer. Max 50 entries — replace outdated preferences when adding beyond the limit.\n\n## Design Philosophy\n\n1. **Every visual choice should have intent.** Do not accept framework defaults without evaluating whether they serve the app's purpose. Color, spacing, and layout should be deliberate.\n2. **Each app should have its own visual identity.** Avoid generic patterns (uniform gray backgrounds, single blue accent, identical rounded corners). Derive the visual language from the app's domain and purpose.\n\n## Icons & Visual Elements\n\n3. **Use an icon library, never emoji for functional UI.** Default: Lucide React (`lucide-react`). Emoji are for content, not for buttons, nav, or labels.\n4. **Prefer meaningful whitespace over decoration.** Use generous spacing to separate content. Avoid dense layouts.\n\n## Color\n\n5. **Derive the color palette from the app's domain.** A finance app might use deep greens and golds; a timer app might use warm reds and ambers. Don't pick colors arbitrarily — let the subject matter guide the palette.\n6. **Build a full color scale, not a single accent.** At minimum: a primary color with light/dark variants, a neutral scale for text and backgrounds, and a semantic set (success, warning, error). Use CSS custom properties so the palette is easy to adjust.\n\n## Typography & Spacing\n\n7. **System font stack by default.** `-apple-system, BlinkMacSystemFont, \"Segoe UI\", Roboto, sans-serif`. Only add custom fonts when they serve a clear design purpose.\n8. **Establish a clear type hierarchy.** At least 3 distinct levels: heading, body, caption. Size differences should be noticeable, not subtle.\n9. **Consistent spacing scale.** Use multiples of 4px or 8px. Pick a base unit and stick to it throughout the app.\n\n## Layout\n\n10. **Card-based layout with subtle shadows.** Cards for grouping related content. Keep shadows light — the card should feel elevated, not floating.\n11. **Responsive by default.** CSS Grid or Flexbox. Design for mobile first when the app is consumer-facing.\n12. **Centered content with max-width.** Main content area should not exceed 1200px. Avoid full-width layouts that stretch content thin.\n\n## Components & Interaction\n\n13. **Transitions on interactive elements.** Buttons, links, cards — anything clickable should have a subtle hover/active transition. No jarring state changes.\n14. **Meaningful empty states.** Include a description of what will appear and a call-to-action to get started. Avoid bare \"no data\" messages.\n15. **Form validation: inline, on blur or submit.** Don't validate on every keystroke. Show errors below the field, clear them when the user starts fixing.\n16. **Loading: skeleton screens for content, spinners for actions.** Skeleton for page loads, small spinner for button submissions.\n\n## Theme\n\n17. **Dark mode if the framework supports it easily.** Use CSS variables for theming. Defau"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2410,"uniquenessScore":43,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T18:21:05.209Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T18:21:05.209Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:58:03.863Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}