[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CB6SGSVCQJD0AYHHKW6QMZ":3,"skill-same:01M6CB6SGSVCQJD0AYHHKW6QMZ":70},{"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":18,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6CB6SGSVCQJD0AYHHKW6QMZ","plan",null,"Plan mode for Hermes: inspect context and write\u002Fupdate the active plan artifact without executing. Keep the plan local unless the user explicitly asks to register it in Doct.","adnichols\u002Fai-configs","adnichols","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F493746?v=4","01M6C33VRY9WF6XWYPT1AFA7JJ","Aaron Nichols","01M6C33VWTNKGRM92E9G643V4W",5,"MIT","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fplan\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30],"writing","workflow","update","planning","hermes","hermes agent","write","context","user","ops","html","implementation","2026-11-10 10:12:30",false,"---\nname: plan\ndescription: \"Plan mode for Hermes: inspect context and write\u002Fupdate the active plan artifact without executing. Keep the plan local unless the user explicitly asks to register it in Doct.\"\nversion: 2.0.0\nauthor: Hermes Agent\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [planning, plan-mode, implementation, workflow, doct, html-plans]\n    related_skills: [writing-plans, planning-workflow, doct-document-ops, reviewed-html-plan]\n---\n\n# Plan Mode\n\nUse this skill when the user wants a plan instead of execution. You are in plan-materialization mode. This is still non-execution work: synthesize validated research into the actual execution plan file.\n\nKeep the plan as a local file. Do not register it in Doct unless the user explicitly asks to send, publish, register, or review it in Doct, or invokes `reviewed-html-plan` \u002F `send-plan-to-doct`. Determine the exact source path from repo-local guidance (`AGENTS.md`, `thoughts\u002Fplans\u002FAGENTS.md`, local planning skills, or an existing plan path supplied by the user). Follow the local artifact format exactly; do not create Markdown companions for an HTML-plan repo. If repo guidance does not define the active plan artifact format\u002Fpath and the user did not supply an existing plan path, ask one targeted question and stop. Do not assume markdown.\n\nTreat this command as planning-only work even though normal file writes are available. You may inspect the repo and write the plan artifact, but you must not change product code, tests, app config, docs, generated files, or environment files.\n\nYour job ends after writing or updating the single plan file and reporting the result. Do not create execution todos, do not begin implementation, and do not run execution-oriented verification once the plan file is complete.\n\n## Usage\n\n```\n\u002Fplan \u003Cslug | \"short description\" | existing-plan-path>\n```\n\n## Output\n\nOutput: exactly one `plan_path`, resolved from repo-local guidance or an existing plan path supplied by the user.\n\n## Process\n\n### 1) Resolve Plan Path\n\n1. If arguments look like a path to an existing plan file, treat it as `plan_path`.\n2. Otherwise derive `slug` from arguments (lowercase, digits, hyphens only).\n3. Set `plan_path` to the repo's active plan path from local guidance. If local guidance does not define one and the user did not supply an existing plan path, ask one targeted question and stop. Do not infer a markdown path.\n4. Ensure the parent directory for `plan_path` exists (create it if missing).\n\n### 2) Re-establish Planning Context\n\nBefore writing the plan:\n\n1. Read the repo root `AGENTS.md`.\n2. Read `thoughts\u002Fspecs\u002Fproduct_intent.md` if the repo uses it.\n3. Read `thoughts\u002Fplans\u002FAGENTS.md` only if it exists for local planning overrides.\n4. If local guidance names an HTML plan contract, template, validator, or plan service, read those docs before writing and use the checked-in tooling they name.\n5. Load relevant skills:\n   - `doct-document-ops` only when the user explicitly asked to register, publish, update, or monitor a plan in Doct; use its `doct-agent plans` workflow against `https:\u002F\u002Fdoct.nodaste.com` for HTML plans\n   - `product-principles` when the plan affects workflows, defaults, onboarding, recovery behavior, error handling, architecture, or regression strategy; use it to define the golden path, self-healing expectations, fail-closed boundaries, agent-legible errors, and to audit repo guidance\u002Ftests for dissonance\n   - `tdd-test-writer` when phases will depend on tests-first delivery\n   - `dependency-selection` when introducing non-trivial functionality\n   - Domain-specific skills (frontend, React\u002FNext, Rust, etc.)\n\nIf required planning guidance is missing, ask the user instead of guessing.\n\n### 3) Read Existing Plan (If Present)\n\nIf `plan_path` exists, read it fully.\n\nPreserve existing state:\n- Any completed checkboxes (`[x]`) in `## Progress` and their IDs\n- Existing entries in `## Decisions \u002F Deviations Log`\n- Existing entries in `## Plan Changelog` (append when regenerating)\n\nLegacy migration (read-only; do not delete):\n- If `thoughts\u002Fplans\u002F\u003Cslug>\u002Fspec.md` and\u002For `thoughts\u002Fplans\u002F\u003Cslug>\u002Ftasks.md` exist, read them.\n- Prefer the legacy spec as the source of intent.\n\n### 4) Validate Repo Reality\n\nValidate key claims by directly inspecting the codebase:\n- Locate relevant files and existing patterns\n- Confirm APIs, data shapes, configuration, and constraints\n- Identify integration points and risks\n- Verify actual commands, targets, package names, and paths\n- Identify the simplest supported workflow and which inputs should be optional because the system can infer or heal them\n- Identify any routine manual remediation or status-check steps that should instead be absorbed into the normal product flow\n- Audit `AGENTS.md`, product-intent docs, onboarding\u002Finstall docs, config\u002Fstatus surfaces, and tests for dissonance with that golden path\n\nUse `bash` with `find`, `rg`, and `read` for targeted research. Keep discovery in the driving session by default; use a read-only exploration subagent only when a broad search materially benefits from isolated context.\n\nDo not run side-effecting commands while doing this validation.\n\n### 5) Write plan_path\n\nWrite (or update) `plan_path` following shared planning workflow and repo-specific guidance.\n\nNon-negotiable requirements:\n- Write exactly one plan file at `plan_path`\n- Preserve prior progress and append-only logs when regenerating\n- `## Progress` contains the only checkboxes with stable IDs (`P1`, `P2`, ...)\n- Each phase includes `### End State`, `### Tests first`, `### Expected files`, `### Work`, and `### Verify`\n- Ready plans have no unresolved `Open Questions`\n- `### Verify` steps are copy\u002Fpaste ready and match actual repo reality\n- The plan is resumable by another agent without inventing missing semantics\n- Every implementation plan includes a near-top standalone product-owner context section before implementation history and technical detail. It explains the situation in plain language without assuming issue\u002FLinear context, explains why the work is needed now, and makes the key conclusion unmistakable (especially runtime\u002Fcustomer defect versus stale test or operational evidence). It separately covers `Customers`, `Runtime product behavior`, `Security \u002F permissions`, `Testing \u002F release confidence`, and `Deployment \u002F migration`, saying `No change` or `Not applicable` when a dimension is unaffected. Use a scannable impact table or equivalent structured block for non-trivial plans; lightweight plans must use at least concise labeled prose.\n- Follow the `planning-workflow` `What's new` contract after Product-owner context and before Goal; a heading or surrounding-section restatement is insufficient.\n- Follow the `planning-workflow` integration-integrity planning contract. When an exact untyped contract or distributed production behavior is found, include the Contract and distributed-integration inventory with source-search evidence; record `None identified, based on \u003Csource search>` when neither trigger applies.\n- If the plan is rendered or delivered as HTML, use the standard reviewer layout: a dark-mode visual theme with an explicit dark background, light foreground text, readable muted text, accessible link\u002Faccent colors, `color-scheme: dark`, and a full-width single-column page. Put a concise table of contents near the top of the document, immediately after the title\u002Fstatus summary and before the main plan sections. Format the ToC as a horizontal section with responsive columns so the plan body keeps the full content width. Do not use a permanent left sidebar\u002Frail for navigation or let the agent choose light mode or an alternate navigation layout.\n- If the user explicitly asked to register, update, or monitor the plan in Doct, use `doct-document-ops` as the sole source for current Doct commands: auth\u002Fcontext checks, `doct-agent plans register --base-url https:\u002F\u002Fdoct.nodaste.com --source-format html --title '\u003CPlan Title>'`, canonical Doct URLs, `plans update`, plan queue inspection, agent claims, ack\u002Fresolve, and final readiness\u002Fstatus updates.\n- If a plan is registered in Doct, every user-facing URL must be the canonical Doct URL from `https:\u002F\u002Fdoct.nodaste.com`; do not share local `plan-review`, loopback, or Tailscale service URLs unless the user explicitly requested a legacy local review service.\n- For product-facing work, the plan explicitly documents the default workflow, inferred defaults, self-healing expectations, fail-closed boundaries, actionable agent-legible error guidance, and any repo-doc\u002Ftest updates needed to stay aligned\n- When a repo uses a reviewed-plan flow, the plan assumes explicit handoff to the canonical continuation named in repo-local guidance rather than hidden recovery paths.\n- If repo guidance requires a checked-in local plan server instead of Doct, validate\u002Fserve\u002Fopen the plan with that server, reuse an already-running instance for the target plan, and never substitute Vite, file URLs, Python\u002FNode static servers, or a custom plan service.\n- The plan does not normalize routine \"run this other command to inspect\u002Ffix it\" operator loops unless the work is explicitly about a high-risk or ambiguous exception path\n\n### 6) Consistency Pass\n\nBefore finishing:\n- The product-owner context stands alone, appears before implementation history\u002Ftechnical detail, explains why now, states the key conclusion, and covers all five impact dimensions at complexity-appropriate depth\n- `What's new` follows Product-owner context and precedes Goal with a distinct audience-visible product delta\n- Every acceptance criterion has at least one phase `### Verify` item\n- Every progress checkbox corresponds to a phase header\n- Phase ordering and naming is consistent\n- Every phase has a `### Tests first` section describing user-visible outcomes\n- `### Verify` commands are copy\u002Fpaste ready and match current repo\u002Fpackage\u002Ftarget names\n- No non-plan file was modified\n\n## Forbidden Actions\n\n- Do not create a new execution todo list after the plan is complete\n- Do not switch into build, run, or implementation mode\n- Do not edit any file except `plan_path` unless scope is explicitly broadened\n- Do not run lint, tests, build, e2e, migrations, or other execution-oriented verification\n- Do not invoke other skills as part of this command; only suggest them\n\n## Suggested Next Steps\n\nAfter this skill completes, suggest only next steps supported by repo-local guidance. For reviewed-plan repos, name the canonical continuation from `AGENTS.md` or the repo's planning overrides; do not invent a fallback review or execution command.\n","# Plan Mode\n\nUse this skill when the user wants a plan instead of execution. You are in plan-materialization mode. This is still non-execution work: synthesize validated research into the actual execution plan file.\n\nKeep the plan as a local file. Do not register it in Doct unless the user explicitly asks to send, publish, register, or review it in Doct, or invokes `reviewed-html-plan` \u002F `send-plan-to-doct`. Determine the exact source path from repo-local guidance (`AGENTS.md`, `thoughts\u002Fplans\u002FAGENTS.md`, local planning skills, or an existing plan path supplied by the user). Follow the local artifact format exactly; do not create Markdown companions for an HTML-plan repo. If repo guidance does not define the active plan artifact format\u002Fpath and the user did not supply an existing plan path, ask one targeted question and stop. Do not assume markdown.\n\nTreat this command as planning-only work even though normal file writes are available. You may inspect the repo and write the plan artifact, but you must not change product code, tests, app config, docs, generated files, or environment files.\n\nYour job ends after writing or updating the single plan file and reporting the result. Do not create execution todos, do not begin implementation, and do not run execution-oriented verification once the plan file is complete.\n\n## Usage\n\n```\n\u002Fplan \u003Cslug | \"short description\" | existing-plan-path>\n```\n\n## Output\n\nOutput: exactly one `plan_path`, resolved from repo-local guidance or an existing plan path supplied by the user.\n\n## Process\n\n### 1) Resolve Plan Path\n\n1. If arguments look like a path to an existing plan file, treat it as `plan_path`.\n2. Otherwise derive `slug` from arguments (lowercase, digits, hyphens only).\n3. Set `plan_path` to the repo's active plan path from local guidance. If local guidance does not define one and the user did not supply an existing plan path, ask one targeted question and stop. Do not infer a markdown path.\n4. Ensure the parent directory for `plan_path` exists (create it if missing).\n\n### 2) Re-establish Planning Context\n\nBefore writing the plan:\n\n1. Read the repo root `AGENTS.md`.\n2. Read `thoughts\u002Fspecs\u002Fproduct_intent.md` if the repo uses it.\n3. Read `thoughts\u002Fplans\u002FAGENTS.md` only if it exists for local planning overrides.\n4. If local guidance names an HTML plan contract, template, validator, or plan service, read those docs before writing and use the checked-in tooling they name.\n5. Load relevant skills:\n   - `doct-document-ops` only when the user explicitly asked to register, publish, update, or monitor a plan in Doct; use its `doct-agent plans` workflow against `https:\u002F\u002Fdoct.nodaste.com` for HTML plans\n   - `product-principles` when the plan affects workflows, defaults, onboarding, recovery behavior, error handling, architecture, or regression strategy; use it to define the golden path, self-healing expectations, fail-closed boundaries, agent-legible errors, and to audit repo guidance\u002Ftests for dissonance\n   - `tdd-test-writer` when phases will depend on tests-first delivery\n   - `dependency-selection` when introducing non-trivial functionality\n   - Domain-specific skills (frontend, React\u002FNext, Rust, etc.)\n\nIf required planning guidance is missing, ask the user instead of guessing.\n\n### 3) Read Existing Plan (If Present)\n\nIf `plan_path` exists, read it fully.\n\nPreserve existing state:\n- Any completed checkboxes (`[x]`) in `## Progress` and their IDs\n- Existing entries in `## Decisions \u002F Deviations Log`\n- Existing entries in `## Plan Changelog` (append when regenerating)\n\nLegacy migration (read-only; do not delete):\n- If `thoughts\u002Fplans\u002F\u003Cslug>\u002Fspec.md` and\u002For `thoughts\u002Fplans\u002F\u003Cslug>\u002Ftasks.md` exist, read them.\n- Prefer the legacy spec as the source of intent.\n\n### 4) Validate Repo Reality\n\nValidate key claims by directly inspecting the codebase:\n- Locate relevant files and existing patterns\n- Confirm APIs, data shapes, configuration, and constraints\n- Identify integration points and risks\n- Verify actual commands, targets, package names, and paths\n- Identify the simplest supported workflow and which inputs should be optional because the system can infer or heal them\n- Identify any routine manual remediation or status-check steps that should instead be absorbed into the normal product flow\n- Audit `AGENTS.md`, product-intent docs, onboarding\u002Finstall docs, config\u002Fstatus surfaces, and tests for dissonance with that golden path\n\nUse `bash` with `find`, `rg`, and `read` for targeted research. Keep discovery in the driving session by default; use a read-only exploration subagent only when a broad search materially benefits from isolated context.\n\nDo not run side-effecting commands while doing this validation.\n\n### 5) Write plan_path\n\nWrite (or update) `plan_path` following shared planning workflow and repo-specific guidance.\n\nNon-negotiable requirements:\n- Write exactly one plan file at `plan_path`\n- Preserve prior progress and append-only logs when regenerating\n- `## Progress` contains the only checkboxes with stable IDs (`P1`, `P2`, ...)\n- Each phase includes `### End State`, `### Tests first`, `### Expected files`, `### Work`, and `### Verify`\n- Ready plans have no unresolved `Open Questions`\n- `### Verify` steps are copy\u002Fpaste ready and match actual repo reality\n- The plan is resumable by another agent without inventing missing semantics\n- Every implementation plan includes a near-top standalone product-owner context section before implementation history and technical detail. It explains the situation in plain language without assuming issue\u002FLinear context, explains why the work is needed now, and makes the key conclusion unmistakable (especially runtime\u002Fcustomer defect versus stale test or operational evidence). It separately covers `Customers`, `Runtime product behavior`, `Security \u002F permissions`, `Testing \u002F release confidence`, and `Deployment \u002F migration`, saying `No change` or `Not applicable` when a dimension is unaffected. Use a scannable impact table or equivalent structured block for non-trivial plans; lightweight plans must use at least concise labeled prose.\n- Follow the `planning-workflow` `What's new` contract after Product-owner context and before Goal; a heading or surrounding-section restatement is insufficient.\n- Follow the `planning-workflow` integration-integrity planning contract. When an exact untyped contract or distributed production behavior is found, include the Contract and distributed-integration inventory with source-search evidence; record `None identified, based on \u003Csource search>` when neither trigger applies.\n- If the plan is rendered or delivered as HTML, use the standard reviewer layout: a dark-mode visual theme with an explicit dark background, light foreground text, readable muted text, accessible link\u002Faccent colors, `color-scheme: dark`, and a full-width single-column page. Put a concise table of contents near the top of the document, immediately after the title\u002Fstatus summary and before the main plan sections. Format the ToC as a horizontal section with responsive columns so the plan body keeps the full content width. Do not use a permanent left sidebar\u002Frail for navigation or let the agent choose light mode or an alternate navigation layout.\n- If the user explicitly asked to register, update, or monitor the plan in Doct, use `doct-document-ops` as the sole source for current Doct commands: auth\u002Fcontext checks, `doct-agent plans register --base-url https:\u002F\u002Fdoct.nodaste.com --source-format html --title '\u003CPlan Title>'`, canonical Doct URLs, `plans update`, plan queue inspection, agent claims, ack\u002Fresolve, and final readiness\u002Fstatus updates.\n- If a plan is registered in Doct, every user-facing URL must be the canonical Doct URL from `https:\u002F\u002Fdoct.nodaste.com`; do not share local `plan-review`, loopback, or Tailscale service URLs unless the user explicitly requested a legacy local review service.\n- For product-facing work, the plan explicitly documents the default workflow, inferred defaults, self-healing expectations, fail-closed boundaries, actionable agent-legible error guidance, and any repo-doc\u002Ftest updates needed to stay aligned\n- When a repo uses a reviewed-plan flow, the plan assumes explicit handoff to the canonical continuation named in repo-local guidance rather than hidden recovery paths.\n- If repo guidance requires a checked-in local plan server instead of Doct, validate\u002Fserve\u002Fopen the plan with that server, reuse an already-running instance for the target plan, and never substitute Vite, file URLs, Python\u002FNode static servers, or a custom plan service.\n- The plan does not normalize routine \"run this other command to inspect\u002Ffix it\" operator loops unless the work is explicitly about a high-risk or ambiguous exception path\n\n### 6) Consistency Pass\n\nBefore finishing:\n- The product-owner context stands alone, appears before implementation history\u002Ftechnical detail, explains why now, states the key conclusion, and covers all five impact dimensions at complexity-appropriate depth\n- `What's new` follows Product-owner context and precedes Goal with a distinct audience-visible product delta\n- Every acceptance criterion has at least one phase `### Verify` item\n- Every progress checkbox corresponds to a phase header\n- Phase ordering and naming is consistent\n- Every phase has a `### Tests first` section describing user-visible outcomes\n- `### Verify` commands are copy\u002Fpaste ready and match current repo\u002Fpackage\u002Ftarget names\n- No non-plan file was modified\n\n## Forbidden Actions\n\n- Do not create a new execution todo list after the plan is complete\n- Do not switch into build, run, or implementation mode\n- Do not edit any file except `plan_path` unless scope is explicitly broadened\n- Do not run lint, tests, build, e2e, migrations, or other execution-oriented verification\n- Do not invoke other skills as part of this command; only suggest them\n\n## Suggested Next Steps\n\nAfter this skill completes, suggest only next steps supported by repo-local guidance. For reviewed-plan repos, name the canonical continuation from `AGENTS.md` or the repo's planning overrides; do not invent a fallback review or execution command.\n",{"name":5,"author":36,"license":15,"version":37,"metadata":38,"description":7},"Hermes Agent","2.0.0",{"hermes":39},{"tags":40,"related_skills":44},[22,41,30,20,42,43],"plan-mode","doct","html-plans",[45,46,47,48],"writing-plans","planning-workflow","doct-document-ops","reviewed-html-plan","main","64e2fc9afa7bb3da1138eb73399144d0e7e73e9d","_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fplan",4,"https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs","https:\u002F\u002Fgithub.com\u002Fadnichols","2026-11-06 00:28:38",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add adnichols\u002Fai-configs --skill plan",{"tool":62,"command":63},"bunx","bunx skills add adnichols\u002Fai-configs --skill plan",{"tool":65,"command":66},"pnpm","pnpm dlx skills add adnichols\u002Fai-configs --skill plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fplan\u002FSKILL.md",true,[],[71,91,116,141,152,168],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":31},"01M6CB7RN791P5RRRCJWWC7DAR","blocked-page-recovery","Use when a fetch fails: 403\u002F429, paywall, WAF, bot wall.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fweb\u002Fblocked-page-recovery\u002FSKILL.md",[],[78,79,80,81,82,83,84,24,23,85,86,87,88,89,90],"recovery","page","blocked page recovery","bot","fallback","use","fetch","Citations","waf","windows","research","linux","macos",{"skillNo":92,"name":45,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":109,"publishedAt":31},"01M6CB7NQY2VVYCQJ1QBXACQF4","Use when creating or updating executable software plans. Keep plans as local files unless the user explicitly asks to register them in Doct.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[96,101,104],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":102,"categoryName":103,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[19,110,111,112,20,113,27,114,22,115,30,29,83,28,24,23,5],"writing plans","documentation","test","design","development","files",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":131,"publishedAt":31},"01M6CB7JME246KZQHP73Z2STDF","test-driven-development","TDD: enforce RED-GREEN-REFACTOR, tests before code.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Ftest-driven-development\u002FSKILL.md",[122,125,128],{"categoryNo":123,"categoryName":124,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":126,"categoryName":127,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":129,"categoryName":130,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000037","律师与法务",[112,114,132,133,134,24,23,135,5,136,137,138,90,139,89,140,87],"test driven development","red-green-refactor","superpowers","quality","refactor","code","debugging","tdd","testing",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":31},"01M6CB7FQ407KQTD4Z9VAWKY54","systematic-debugging","4-phase root cause debugging: understand bugs before fixing.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[147],{"categoryNo":126,"categoryName":127,"taxonomyType":99,"taxonomyTypeDesc":100},[138,149,114,134,24,23,150,5,151,87,112,89,90],"systematic debugging","troubleshooting","investigation",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":161,"publishedAt":31},"01M6CB7D57MK88HE5YPZHKH68Q","spike","Throwaway experiments to validate an idea before build.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fspike\u002FSKILL.md",[158],{"categoryNo":159,"categoryName":160,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000021","资料检索与研究",[154,87,162,163,88,164,89,90,165,166,167,24,23,5,22],"validate","experiments","prototype","feasibility","sketch","experiment",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":178,"publishedAt":31},"01M6CB7APAQ37YE5YE1MAAFT42","simplify-code","Parallel 3-agent cleanup of recent code changes.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fsimplify-code\u002FSKILL.md",[174,175],{"categoryNo":102,"categoryName":103,"taxonomyType":99,"taxonomyTypeDesc":100},{"categoryNo":176,"categoryName":177,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000030","开发工程师",[179,180,137,181,24,23,182,5,136,183,184,185,114,87,112,89,186,90],"simplify code","simplify","subagent","parallel","code-review","delegation","cleanup","review"]