[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3CAF9RA98KTP52KZMQ29B":3,"skill-same:01M6K3CAF9RA98KTP52KZMQ29B":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":72},"01M6K3CAF9RA98KTP52KZMQ29B","manual-test",null,"Use to validate stories via curl (API) or browser (full-stack) after the test suite and before \u002Ffinish. Browser capability gaps warn; observed bugs loop back through \u002Ftdd.","jstoup111\u002Fai-conductor","jstoup111","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1585332?v=4","01M6K374Y0VEFPVCT2KPBAN4HC","James Stoup","01M6K3751X0GFKNBD0198F50XN",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fmanual-test\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"manual test","test","manual","stories","gaps","gating","via","verify","curl","stack","claims","browser","api","false","loop","use","true","test suite","bugs","back","2026-11-10 10:12:30",false,"---\nname: manual-test\ndisable-model-invocation: true\ndescription: \"Use to validate stories via curl (API) or browser (full-stack) after the test suite and before \u002Ffinish. Browser capability gaps warn; observed bugs loop back through \u002Ftdd.\"\nenforcement: gating\nphase: ship\nstandalone: false\nrequires: [verify-claims]\n---\n\n## Purpose\n\nValidates that implemented stories actually work by exercising the running application.\nAutomated tests verify code correctness; manual testing verifies the system works end-to-end\nas a user would experience it.\n\n**Correctness gate:** a \"story X passes\" result is a claim. Per the `\u002Fverify-claims` protocol, a\npass is `verified` — you actually observed the response\u002Fbehavior — never assumed from the code or\ninferred from a green unit test. If a story was not actually exercised, do not claim it passed;\nreport it as untested rather than presenting an assumption as a result.\n\n## Practices\n\n### 0. Feature Type Check\n\nBefore starting manual testing, check the stories in `.docs\u002Fstories\u002F` for this feature:\n- If **no stories reference HTTP endpoints, API routes, or user-facing UI**, report SKIP:\n  \"Manual test skipped — feature has no endpoint\u002FUI criteria (services, jobs, mailers, CI).\"\n- Suggest console-based verification instead: `rails console` smoke test or script execution.\n- Display the skip reason to the user, then **record it via the CLI** — this is the sole\n  way the step is marked done; there is no hand-written marker path:\n  ```\n  ai-conductor manual-test-record --skip --reason \"\u003Creason>\" --pipeline-dir \u002Fabs\u002Fpath\u002Fto\u002F.pipeline\n  ```\n  Use the absolute worktree `.pipeline` path supplied in the step's system prompt (never a\n  relative path).\n\n### 1. Detect Project Type\n\n| Indicator | Testing Method |\n|---|---|\n| API-only (no views) | `curl` commands against running server |\n| Full-stack (views exist) | Browser automation via Chrome MCP or Capybara |\n\nFor a full-stack project, verify that the already-configured browser driver and browser runtime\nare available and can launch before exercising browser criteria. **Do not install browser packages,\nbinaries, or system dependencies during `manual-test`\u002FSHIP.**\n\n- If the browser driver, browser binary, or required launch capability is missing or cannot start,\n  record each affected browser criterion as `WARN`. Include the exact dependency\u002Flaunch error and a\n  concrete recovery command in Notes, then continue exercising any API criteria with `curl`.\n- A `WARN` is non-blocking capability evidence. It does not enter the bug loop or route back to BUILD.\n- Once a browser session launches, an observed mismatch between expected and actual application\n  behavior is `FAIL`, even if other criteria are `WARN`. Do not relabel an application failure as an\n  environment warning.\n\n### 2. Start the Application\n\nEnsure the application is running and accessible:\n\n**Rails:**\n```bash\n# Start server in background\nbin\u002Frails server -d -p 3000\n# Or if using Docker:\ndocker compose up -d\n```\n\n**Node:**\n```bash\nnpm start &\n# Or: npm run dev &\n```\n\n**Always stop and restart the server before testing.** A stale server from a prior session\nruns old code and gives false results. Kill any existing server process, then start fresh:\n\n```bash\n# Kill existing server (check common ports)\nlsof -ti:3000 | xargs kill -9 2>\u002Fdev\u002Fnull || true  # Rails\nlsof -ti:8000 | xargs kill -9 2>\u002Fdev\u002Fnull || true  # FastAPI\u002FDjango\nlsof -ti:5173 | xargs kill -9 2>\u002Fdev\u002Fnull || true  # Vite\n\n# Start fresh\n```\n\nAfter starting, verify it's up: `curl -s http:\u002F\u002Flocalhost:3000\u002Fup` (or health check endpoint).\n\n### 3. Walk Through Stories (API Projects)\n\nFor each story in `.docs\u002Fstories\u002F`, execute the acceptance criteria manually using `curl`:\n\n```bash\n# Story: Create a short link (happy path)\ncurl -s -X POST http:\u002F\u002Flocalhost:3000\u002Flinks \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"link\": {\"original_url\": \"https:\u002F\u002Fexample.com\"}}' | python3 -m json.tool\n\n# Story: Expired link returns 410 (negative path)\ncurl -s -o \u002Fdev\u002Fnull -w \"%{http_code}\" http:\u002F\u002Flocalhost:3000\u002Fabc123\n# Expected: 410\n```\n\n**For each story, record:**\n\n| Story | Criterion | Expected | Actual | Result |\n|---|---|---|---|---|\n| Create link | 201 with short_code | 201 + 6-char code | 201 + \"xK9mR2\" | PASS |\n| Expired link | 410 Gone | 410 | 410 | PASS |\n| Invalid URL | 422 with error | 422 | 500 Internal Server Error | **FAIL** |\n\n### 4. Walk Through Stories (Full-Stack Projects)\n\nUse browser automation (Chrome MCP if configured, otherwise manual Capybara-style):\n\n1. Navigate to each page referenced in stories\n2. Perform the actions described in Given\u002FWhen\u002FThen\n3. Verify visible output matches expected behavior\n4. Take screenshots of key states as manual-test evidence\n\n### 5. Display Results\n\nDisplay results to the user in the conversation, then **record them via the CLI** —\n`manual-test-record` is the sole intended writer of `.pipeline\u002Fmanual-test-results.md`;\ndo not hand-write or append to that file yourself. The conductor's completion gate reads\nthis file to verify manual-test ran for the current feature — without it, the step has no\nobjective on-disk evidence and cannot pass.\n\nRecord the run by piping (or pointing at) the results content and the absolute worktree\n`.pipeline` path supplied in the step's system prompt:\n\n```\nai-conductor manual-test-record --results - --pipeline-dir \u002Fabs\u002Fpath\u002Fto\u002F.pipeline \u003C\u003C'EOF'\n\u003Cresults table + bugs section, in the format below>\nEOF\n```\n\nor, if the results were written to a file first:\n\n```\nai-conductor manual-test-record --results \u002Fpath\u002Fto\u002Fresults.md --pipeline-dir \u002Fabs\u002Fpath\u002Fto\u002F.pipeline\n```\n\nSupply only the current attempt's table and bug list; the CLI adds the `## Attempt N` header and\ntimestamp, appends, and never truncates earlier attempts.\n\nUse this format for the content you pass to `--results` (both in chat and to the CLI):\n\n```\n# Manual Test Results\n**Server:** localhost:3000\n**Tester:** Claude (automated curl) \u002F User (browser)\n\n## Attempt 1 — 2026-07-06T10:00:00Z\n\n| Story | Criterion | Result | Notes |\n|---|---|---|---|\n| ... | ... | PASS\u002FFAIL\u002FWARN | ... |\n\n### Bugs Found\n1. **BUG-001:** Invalid URL returns 500 instead of 422 (story: create-link, negative path: invalid input)\n2. **BUG-002:** ...\n```\n\nAlways pass the **absolute worktree `.pipeline` path** from the step's system prompt — never a\nrelative `.pipeline\u002F...` path, which can land in the wrong checkout. If you cannot run the CLI (no\npipeline directory supplied, or the command fails), do NOT consider manual_test complete and never\nhand-write the results file — HALT and report the blocker.\n\n**Whitewash guard (#367):** after a recorded `FAIL`, a later attempt with no `FAIL` rows (PASS\nand\u002For WARN) is accepted only if new commits exist since the failure, so the Step C fix MUST land as\ncommits before the re-verify attempt. `WARN` rows do not block the gate.\n\n### 6. Bug Loop\n\n**Any FAIL result becomes a bug that loops back through `\u002Ftdd`. WARN results do not:**\n\n**Step A — Confirm the buggy code path is supposed to exist** (the `\u002Fdebugging` Phase 4\nGATE). Manual-test surfaces defects on *shipped* code — read the governing APPROVED ADR\u002FPRD for\nthe affected component first. If the buggy path violates or is superseded by an approved\ndecision, the fix is a **conformance finding (kickback), not a patch** — a bug on a condemned\npath is a removal signal. This cheap design check precedes the expensive RED→fix→suite cycle.\n\n**Step B — If the cause is not obvious, discover it before fixing.** A manual FAIL gives you the\n*symptom* (e.g. \"500 instead of 422\"), not the *cause*. When you cannot point to the root cause\nwith confidence from the failure alone, do NOT guess a fix or a reproducing test — dispatch the\n`\u002Fdebugging` protocol (root cause before fix; no fixes without evidence) in a fresh sub-session,\nhanding it the failing story, the observed-vs-expected result, and any server output\u002Flogs. Come\nback with an evidence-backed root cause, then proceed. Skip this step only when the cause is\ngenuinely self-evident from the failure.\n\n**Step C — Fix via TDD, now that the cause is known:**\n1. Write a failing test that reproduces the bug at the right layer (RED)\n2. Fix it (GREEN)\n3. Commit\n4. Re-run the manual test for that story to verify\n\n**Do NOT proceed to `\u002Ffinish` with known bugs.** The manual test gate must be clean.\n\n### 7. Shut Down\n\nStop the application server after testing:\n\n```bash\n# Rails\nkill $(cat tmp\u002Fpids\u002Fserver.pid)\n# Docker\ndocker compose down\n```\n\n## Verification\n\n- [ ] Application started and accessible\n- [ ] Every story (happy + negative paths) tested manually\n- [ ] Results displayed to user\n- [ ] Browser automation availability was checked without installing dependencies; unavailable or\n      unlaunchable browser criteria were recorded as WARN with the error and recovery command\n- [ ] Every exit path (Step 0 SKIP or Step 5 real-run PASS\u002FFAIL\u002FWARN) ended by actually invoking\n      `ai-conductor manual-test-record` (`--skip --reason ...` or `--results ...`) against the\n      absolute worktree `.pipeline` path — not a hand-written or fabricated marker\n- [ ] All bugs fixed via TDD loop\n- [ ] Re-verification passed after bug fixes\n- [ ] Application shut down cleanly\n","## Purpose\n\nValidates that implemented stories actually work by exercising the running application.\nAutomated tests verify code correctness; manual testing verifies the system works end-to-end\nas a user would experience it.\n\n**Correctness gate:** a \"story X passes\" result is a claim. Per the `\u002Fverify-claims` protocol, a\npass is `verified` — you actually observed the response\u002Fbehavior — never assumed from the code or\ninferred from a green unit test. If a story was not actually exercised, do not claim it passed;\nreport it as untested rather than presenting an assumption as a result.\n\n## Practices\n\n### 0. Feature Type Check\n\nBefore starting manual testing, check the stories in `.docs\u002Fstories\u002F` for this feature:\n- If **no stories reference HTTP endpoints, API routes, or user-facing UI**, report SKIP:\n  \"Manual test skipped — feature has no endpoint\u002FUI criteria (services, jobs, mailers, CI).\"\n- Suggest console-based verification instead: `rails console` smoke test or script execution.\n- Display the skip reason to the user, then **record it via the CLI** — this is the sole\n  way the step is marked done; there is no hand-written marker path:\n  ```\n  ai-conductor manual-test-record --skip --reason \"\u003Creason>\" --pipeline-dir \u002Fabs\u002Fpath\u002Fto\u002F.pipeline\n  ```\n  Use the absolute worktree `.pipeline` path supplied in the step's system prompt (never a\n  relative path).\n\n### 1. Detect Project Type\n\n| Indicator | Testing Method |\n|---|---|\n| API-only (no views) | `curl` commands against running server |\n| Full-stack (views exist) | Browser automation via Chrome MCP or Capybara |\n\nFor a full-stack project, verify that the already-configured browser driver and browser runtime\nare available and can launch before exercising browser criteria. **Do not install browser packages,\nbinaries, or system dependencies during `manual-test`\u002FSHIP.**\n\n- If the browser driver, browser binary, or required launch capability is missing or cannot start,\n  record each affected browser criterion as `WARN`. Include the exact dependency\u002Flaunch error and a\n  concrete recovery command in Notes, then continue exercising any API criteria with `curl`.\n- A `WARN` is non-blocking capability evidence. It does not enter the bug loop or route back to BUILD.\n- Once a browser session launches, an observed mismatch between expected and actual application\n  behavior is `FAIL`, even if other criteria are `WARN`. Do not relabel an application failure as an\n  environment warning.\n\n### 2. Start the Application\n\nEnsure the application is running and accessible:\n\n**Rails:**\n```bash\n# Start server in background\nbin\u002Frails server -d -p 3000\n# Or if using Docker:\ndocker compose up -d\n```\n\n**Node:**\n```bash\nnpm start &\n# Or: npm run dev &\n```\n\n**Always stop and restart the server before testing.** A stale server from a prior session\nruns old code and gives false results. Kill any existing server process, then start fresh:\n\n```bash\n# Kill existing server (check common ports)\nlsof -ti:3000 | xargs kill -9 2>\u002Fdev\u002Fnull || true  # Rails\nlsof -ti:8000 | xargs kill -9 2>\u002Fdev\u002Fnull || true  # FastAPI\u002FDjango\nlsof -ti:5173 | xargs kill -9 2>\u002Fdev\u002Fnull || true  # Vite\n\n# Start fresh\n```\n\nAfter starting, verify it's up: `curl -s http:\u002F\u002Flocalhost:3000\u002Fup` (or health check endpoint).\n\n### 3. Walk Through Stories (API Projects)\n\nFor each story in `.docs\u002Fstories\u002F`, execute the acceptance criteria manually using `curl`:\n\n```bash\n# Story: Create a short link (happy path)\ncurl -s -X POST http:\u002F\u002Flocalhost:3000\u002Flinks \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"link\": {\"original_url\": \"https:\u002F\u002Fexample.com\"}}' | python3 -m json.tool\n\n# Story: Expired link returns 410 (negative path)\ncurl -s -o \u002Fdev\u002Fnull -w \"%{http_code}\" http:\u002F\u002Flocalhost:3000\u002Fabc123\n# Expected: 410\n```\n\n**For each story, record:**\n\n| Story | Criterion | Expected | Actual | Result |\n|---|---|---|---|---|\n| Create link | 201 with short_code | 201 + 6-char code | 201 + \"xK9mR2\" | PASS |\n| Expired link | 410 Gone | 410 | 410 | PASS |\n| Invalid URL | 422 with error | 422 | 500 Internal Server Error | **FAIL** |\n\n### 4. Walk Through Stories (Full-Stack Projects)\n\nUse browser automation (Chrome MCP if configured, otherwise manual Capybara-style):\n\n1. Navigate to each page referenced in stories\n2. Perform the actions described in Given\u002FWhen\u002FThen\n3. Verify visible output matches expected behavior\n4. Take screenshots of key states as manual-test evidence\n\n### 5. Display Results\n\nDisplay results to the user in the conversation, then **record them via the CLI** —\n`manual-test-record` is the sole intended writer of `.pipeline\u002Fmanual-test-results.md`;\ndo not hand-write or append to that file yourself. The conductor's completion gate reads\nthis file to verify manual-test ran for the current feature — without it, the step has no\nobjective on-disk evidence and cannot pass.\n\nRecord the run by piping (or pointing at) the results content and the absolute worktree\n`.pipeline` path supplied in the step's system prompt:\n\n```\nai-conductor manual-test-record --results - --pipeline-dir \u002Fabs\u002Fpath\u002Fto\u002F.pipeline \u003C\u003C'EOF'\n\u003Cresults table + bugs section, in the format below>\nEOF\n```\n\nor, if the results were written to a file first:\n\n```\nai-conductor manual-test-record --results \u002Fpath\u002Fto\u002Fresults.md --pipeline-dir \u002Fabs\u002Fpath\u002Fto\u002F.pipeline\n```\n\nSupply only the current attempt's table and bug list; the CLI adds the `## Attempt N` header and\ntimestamp, appends, and never truncates earlier attempts.\n\nUse this format for the content you pass to `--results` (both in chat and to the CLI):\n\n```\n# Manual Test Results\n**Server:** localhost:3000\n**Tester:** Claude (automated curl) \u002F User (browser)\n\n## Attempt 1 — 2026-07-06T10:00:00Z\n\n| Story | Criterion | Result | Notes |\n|---|---|---|---|\n| ... | ... | PASS\u002FFAIL\u002FWARN | ... |\n\n### Bugs Found\n1. **BUG-001:** Invalid URL returns 500 instead of 422 (story: create-link, negative path: invalid input)\n2. **BUG-002:** ...\n```\n\nAlways pass the **absolute worktree `.pipeline` path** from the step's system prompt — never a\nrelative `.pipeline\u002F...` path, which can land in the wrong checkout. If you cannot run the CLI (no\npipeline directory supplied, or the command fails), do NOT consider manual_test complete and never\nhand-write the results file — HALT and report the blocker.\n\n**Whitewash guard (#367):** after a recorded `FAIL`, a later attempt with no `FAIL` rows (PASS\nand\u002For WARN) is accepted only if new commits exist since the failure, so the Step C fix MUST land as\ncommits before the re-verify attempt. `WARN` rows do not block the gate.\n\n### 6. Bug Loop\n\n**Any FAIL result becomes a bug that loops back through `\u002Ftdd`. WARN results do not:**\n\n**Step A — Confirm the buggy code path is supposed to exist** (the `\u002Fdebugging` Phase 4\nGATE). Manual-test surfaces defects on *shipped* code — read the governing APPROVED ADR\u002FPRD for\nthe affected component first. If the buggy path violates or is superseded by an approved\ndecision, the fix is a **conformance finding (kickback), not a patch** — a bug on a condemned\npath is a removal signal. This cheap design check precedes the expensive RED→fix→suite cycle.\n\n**Step B — If the cause is not obvious, discover it before fixing.** A manual FAIL gives you the\n*symptom* (e.g. \"500 instead of 422\"), not the *cause*. When you cannot point to the root cause\nwith confidence from the failure alone, do NOT guess a fix or a reproducing test — dispatch the\n`\u002Fdebugging` protocol (root cause before fix; no fixes without evidence) in a fresh sub-session,\nhanding it the failing story, the observed-vs-expected result, and any server output\u002Flogs. Come\nback with an evidence-backed root cause, then proceed. Skip this step only when the cause is\ngenuinely self-evident from the failure.\n\n**Step C — Fix via TDD, now that the cause is known:**\n1. Write a failing test that reproduces the bug at the right layer (RED)\n2. Fix it (GREEN)\n3. Commit\n4. Re-run the manual test for that story to verify\n\n**Do NOT proceed to `\u002Ffinish` with known bugs.** The manual test gate must be clean.\n\n### 7. Shut Down\n\nStop the application server after testing:\n\n```bash\n# Rails\nkill $(cat tmp\u002Fpids\u002Fserver.pid)\n# Docker\ndocker compose down\n```\n\n## Verification\n\n- [ ] Application started and accessible\n- [ ] Every story (happy + negative paths) tested manually\n- [ ] Results displayed to user\n- [ ] Browser automation availability was checked without installing dependencies; unavailable or\n      unlaunchable browser criteria were recorded as WARN with the error and recovery command\n- [ ] Every exit path (Step 0 SKIP or Step 5 real-run PASS\u002FFAIL\u002FWARN) ended by actually invoking\n      `ai-conductor manual-test-record` (`--skip --reason ...` or `--results ...`) against the\n      absolute worktree `.pipeline` path — not a hand-written or fabricated marker\n- [ ] All bugs fixed via TDD loop\n- [ ] Re-verification passed after bug fixes\n- [ ] Application shut down cleanly\n",{"name":5,"phase":49,"requires":50,"standalone":45,"description":7,"enforcement":29,"disable-model-invocation":52},"ship",[51],"verify-claims",true,"main","60310a111655e2d63b87223befba464932465487","skills\u002Fmanual-test",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 22:26:29",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":52},[62,65,68],{"tool":63,"command":64},"npx","npx skills add jstoup111\u002Fai-conductor --skill manual-test",{"tool":66,"command":67},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill manual-test",{"tool":69,"command":70},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill manual-test","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fmanual-test\u002FSKILL.md",[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fmanual-test\u002Fagents\u002Fopenai.yaml",[80,98,133,157,175,191],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":44},"01M70YKSA2H7Q9WSRD1ECEGY20","build-review-dependency-hygiene","Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-review-dependency-hygiene\u002FSKILL.md",[],[87,88,89,90,91,92,93,94,95,96,40,97,29],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","judge",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":115,"publishedAt":44},"01M6K3EQQ6ADH3G2RMYK6XE26E","writing-system-tests","Use BEFORE implementing any feature that has stories in .docs\u002Fstories\u002F — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP\u002Frequest-level acceptance tests for headless\u002FAPI projects, end-to-end UI tests for projects with a frontend, using the project's own test framework and directory conventions.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-system-tests\u002FSKILL.md",[104,107,110],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[116,117,118,119,120,121,122,123,124,125,126,36,34,127,128,129,130,29,131,132],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","directory","ui","framework","failing","phase","request",{"skillNo":134,"name":51,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":44},"01M6K3EHR0QQ1QY1S9RC6D1WTD","Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fverify-claims\u002FSKILL.md",[],[139,34,31,140,141,142,143,144,40,145,146,39,147,148,149,150,151,152,153,154,155,29,156],"verify claims","do","adr","for","decision","claim","mechanics","only","workflow","code","reports","plan","active","questions","about","spec","invoke","when",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":44},"01M6K3ED4NF5DJA2Y35MH2JCRC","tdd","Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[159,164,165,166,124,167,92,168,169,170,171,93,172,40,39,173,25,174,156,131],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test-first",{"skillNo":176,"name":27,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":44},"01M6K3E6PEXBXYY2K8TSRTN1JT","Use only within active engineer\u002Fconduct DECIDE after architecture approval, when a committed `.docs\u002Fstories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstories\u002FSKILL.md",[],[27,181,140,142,182,183,184,40,146,39,126,185,186,187,34,188,31,189,151,190,155,29,156],"conduct","decide","engineer","general","requirements","architecture","examples","artifact","requests","implementation",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":44},"01M6K3E1HE7267YKFJQ3YFCGW5","stack-land","Use when an operator needs to land reviewed manual changes on the correct closed child of a stacked feature. Operator-invoked only: inspect ownership, propose the safe child with evidence, and require confirmation before opening the landing.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstack-land\u002FSKILL.md",[],[33,198,199,173,34,200,201,202,31,93,203,26,204,205,206,40,207,146,39,208,156,209],"land","stack land","evidence","child","changes","inspect","correct","landing","safe","operator","confirmation","advisory"]