[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CB7NQY2VVYCQJ1QBXACQF4":3,"skill-same:01M6CB7NQY2VVYCQJ1QBXACQF4":87},{"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":31,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":69,"repositoryHtmlUrl":70,"repositoryHomepageUrl":6,"ownerHtmlUrl":71,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":72,"install":73,"resources":86},"01M6CB7NQY2VVYCQJ1QBXACQF4","writing-plans",null,"Use when creating or updating executable software plans. Keep plans as local files unless the user explicitly asks to register them 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\u002Fwriting-plans\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"writing","writing plans","files","design","implementation","html","use","ops","user","hermes agent","hermes","plan","planning","development","documentation","test","workflow","2026-11-10 10:12:30",false,"---\nname: writing-plans\ndescription: Use when creating or updating executable software plans. Keep plans as local files unless the user explicitly asks to register them in Doct.\nversion: 2.0.0\nauthor: Hermes Agent\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [planning, design, implementation, workflow, documentation, doct, html-plans]\n    related_skills: [planning-workflow, doct-document-ops, reviewed-html-plan, test-driven-development]\n---\n\n# Writing Implementation Plans\n\nUse this skill as the canonical source of truth for writing executable implementation plans across repos.\n\n## Default: plans stay local\n\nWhen the user asks to create, write, or update a plan, write a local plan file. Do not register it in Doct.\n\nRegister in Doct only when they explicitly ask to send, publish, register, or review the plan in Doct, or invoke `reviewed-html-plan` \u002F `send-plan-to-doct`. Then write HTML, register through `doct-document-ops`, start the comment listener, and share the canonical Doct URL.\n\nResolve the source path from repo-local guidance or an existing plan path supplied by the user. If local guidance does not define the active artifact and the user did not supply an existing plan path, ask one targeted question and stop. Do not assume HTML or Markdown.\n\n## Boundaries\n\n- `plan mode` is for discovery only: inspect the codebase, validate assumptions, gather evidence, and identify ambiguities.\n- `dev:plan` (or equivalent plan-materialization step) writes the actual plan file once discovery has produced enough evidence to choose the correct readiness state: `execution-ready` when foundational decisions are resolved, or a single non-ready `research-ready` artifact when further research is the next handoff. Before that handoff point, the work remains `discovery`.\n- There is no default shared artifact path or extension. Resolve the single-file active plan artifact from repo-local guidance or an existing plan path supplied by the user. If local guidance does not define the active artifact and the user did not supply an existing plan path, ask one targeted question and stop. Do not assume markdown.\n- `dev:plan` ends when the plan artifact is written or updated; execution starts only after a separate explicit execution command or a new user instruction.\n- In Pi-style reviewed-plan workflows, keep the handoff explicit and prefer the repo's canonical workflow skill from repo-local guidance. Keep the plan as a local file. Register it in Doct only when the user explicitly asks to send, publish, register, or review it in Doct, or when they invoke `reviewed-html-plan` \u002F `send-plan-to-doct`. Do not assume a hidden fallback to Claude Code, a local `plan-review` service, or any other alternate review surface.\n- During plan writing, edit only the target plan artifact unless the repo's `AGENTS.md` explicitly allows another planning-side file.\n- Do not change product code, tests, app config, docs, generated files, or environment files while planning.\n- Avoid unrelated side effects: no installs, codegen, migrations, formatting runs, rebases, resets, or destructive commands. Commit the plan artifact when the repository workflow requires it.\n\n## Planning inputs\n\nBefore writing a plan, read in this order:\n\n1. Root `AGENTS.md` for repo-specific commands, quality gates, docs, and skill-routing hints.\n2. `thoughts\u002Fspecs\u002Fproduct_intent.md` when the repo requires product-intent alignment.\n3. Optional `thoughts\u002Fplans\u002FAGENTS.md` only when the repo uses local planning overrides beyond this shared skill.\n4. Existing plan file, legacy plan bundle, task list, issue, or source specification that the plan must preserve.\n\nWhen local guidance defines an active HTML plan workflow, also read its referenced contract\u002Ftemplate docs before writing the plan. Do not create markdown companions for a repo whose active plan authority is HTML.\n\nIf required repo guidance or product intent is missing, stop and ask the user or tell them the repo bootstrap needs to be completed first.\n\n## Skill routing\n\nAlways consider which additional skills are needed before writing the plan.\n\n- Load `doct-document-ops` only when the user explicitly asked to register, publish, update, or monitor a plan in Doct. Use `https:\u002F\u002Fdoct.nodaste.com` as the registration endpoint.\n- Load `product-principles` for planning work that affects user\u002Foperator\u002Fagent workflows, defaults, onboarding, recovery behavior, error handling, architecture, or regression strategy. Use it to define the golden path, safe defaults, self-healing expectations, actionable error guidance, and a quick dissonance audit against repo guidance (`AGENTS.md`, product-intent docs, onboarding docs, config\u002Fstatus surfaces, and tests).\n- Load `tdd-test-writer` when phases will rely on tests-first delivery or when the RED-phase contract needs strengthening.\n- Load repo-recommended skills from `AGENTS.md` for the relevant surface or stack.\n- Load domain-specific skills when the planned work clearly spans those domains (frontend, React\u002FNext, Rust, MCP, browser automation, UI review, etc.).\n\nThe plan should reflect the behavior those skills require, not merely mention them.\n\nWhen product work touches interactions, commands, processes, or operator\u002Fagent workflows, the plan should encode these default beliefs unless repo evidence explicitly requires a different constraint:\n\n- the product should do the obvious right thing by default,\n- routine faults should be detected and healed inside the normal requested flow,\n- normal workflows should not depend on users discovering and running separate status or remediation commands,\n- errors should assume a capable agent is reading them and should explain what happened, what the system already tried, why automation stopped, and what to do next,\n- fail-closed behavior is reserved for ambiguous or high-risk situations such as data loss, security\u002Fprivacy risk, or identity\u002Fauthority uncertainty.\n\n## Research standard\n\nValidate important claims directly against repo reality before writing the plan:\n\n- locate existing files, routes, registries, commands, and patterns,\n- confirm data shapes, schemas, contracts, and constraints,\n- identify integration points, parity surfaces, and likely risks,\n- verify command names, package names, and file paths used in `### Verify` sections,\n- identify the simplest supported workflow and which inputs should be optional because the system can infer or heal them,\n- identify which manual status-check or repair steps currently exist and whether they should instead become built-in behavior on the normal path,\n- check whether repo guidance, onboarding docs, config defaults, status surfaces, and tests are aligned with that default-path contract.\n\nUse targeted `Glob`, `Grep`, and `Read` first. Delegate broad codebase discovery only when targeted search is not enough.\n\n## Integration-integrity planning contract\n\nWhen discovery identifies an exact contract that types cannot fully verify or behavior distributed across production sites, add a **Contract and distributed-integration inventory**. Record the source of truth, producer\u002Fconsumer or source-search-backed operation rows, dependent docs\u002Fexamples, cross-boundary or production-path proof, reconciliation status, and coverage as `exhaustive-by-site`, `exhaustive-by-family`, or `justified representative`.\n\nBefore planning dependent edits, reread the current source definition. Prefer one shared executable definition or contract artifact over duplicated fixtures. A helper, middleware, wrapper, or event-existence test is not completion evidence for a distributed outcome; contractual documented CLI forms must execute through the actual parser. If neither trigger applies, record `None identified, based on \u003Csource search>` rather than inventing an inventory.\n\n## Canonical plan contract\n\nWrite plans as execution artifacts, not brainstorming notes. A ready plan must be executable by another agent without inventing missing semantics.\n\n- Preserve the validated source scope. A ready plan should include only work that is critical to achieving the stated goal and verifying it.\n- When the requested scope is vague, tighten it by sharpening the Goal \u002F Non-goals or other scoped language instead of widening the phase list to absorb adjacent surfaces.\n- Do not promote adjacent cleanup, optional follow-ups, broader parity not required by the source intent, or extra explicitness that does not materially change go\u002Fno-go confidence into required plan work unless source requirements or validated repo evidence show they are necessary for success.\n- Plan complete promised slices, not skeletons. Every claimed functional outcome must be connected, usable, and verifiable within its stated scope, without required stubs, TODO behavior, dead-end surfaces, missing producer\u002Fconsumer wiring, fake success, or verification that bypasses the real implementation.\n- If the requested outcome cannot be completed safely in one change, resize it before implementation to a smaller independently useful complete slice. Independent future enhancements, scale work, optional hardening, and polish may remain out of scope; work required for the current slice to function as claimed may not.\n- When a plan is rendered or delivered as HTML, use the standard reviewer layout by default: a dark-mode visual theme with explicit dark background, light foreground text, readable muted text, accessible link\u002Faccent colors, `color-scheme: dark`, plus 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 reviewers can scan links without sacrificing plan body width. Do not use a permanent left sidebar\u002Frail for navigation. Do not leave color mode or navigation layout to browser, OS, or agent-selected defaults.\n- When the user explicitly asked to register or review a plan in Doct, write HTML and delegate service details to `doct-document-ops`: register through `doct-agent plans register --base-url https:\u002F\u002Fdoct.nodaste.com --source-format html --title '\u003CPlan Title>'`, update through `doct-agent plans update`, share the canonical Doct URL, and process comments\u002Factions through `doct-agent plans queue\u002Fagent\u002Fack\u002Fresolve`.\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\n### Product-owner context contract\n\nNear the top of every implementation plan, before implementation history, current-code detail, progress, phases, or verification mechanics, include a standalone product-owner context section. Write it for a product owner who has no prior issue, Linear, incident, or repository context. It must:\n\n- explain the situation in plain language, defining unavoidable domain terms instead of leading with file paths, symbols, request traces, or issue chronology,\n- explain why the change is needed now and what new evidence, failure, decision, or timing makes the work timely,\n- state the key conclusion unmistakably, especially whether the plan addresses a customer\u002Fruntime product defect, a stale test or evidence problem, an operational\u002Fdocumentation gap, or a combination,\n- separate the impact on `Customers`, `Runtime product behavior`, `Security \u002F permissions`, `Testing \u002F release confidence`, and `Deployment \u002F migration`; explicitly say `No change` or `Not applicable` rather than silently omitting an unaffected dimension,\n- distinguish observed facts from proposed work so a reviewer does not confuse a failing test with a shipped-product failure.\n\nKeep this complexity-aware. A lightweight plan must satisfy the contract with concise labeled prose. A non-trivial plan must use a clearly scannable impact table or an equivalent structured block with those five impact dimensions. This is an authoring and review contract, not a Doct renderer requirement; preserve the standard dark full-width layout and fit the section into that layout.\n\n### What's new contract\n\nFor every full implementation plan, put a standalone `What's new` section after Product-owner context and before Goal. Give it a behavior-focused headline and a one-sentence product promise, then state the concrete audience-visible changes, before\u002Fafter workflow, observable result, and preserved guarantees. It must not restate Goal, rationale, phases, or acceptance criteria; a heading without a distinct product delta does not satisfy the contract. Work already exempt from a full plan remains exempt.\n\nRequired sections for new plans unless repo-local overrides say otherwise:\n\n1. Title\n2. Status\n3. Product-owner context (situation, why now, key conclusion, and impact breakdown)\n4. What's new (standalone product change and preserved guarantees)\n5. Goal\n6. Decision Attention \u002F Low-confidence Areas\n7. Why this plan exists\n8. Authority and inputs\n9. Current implementation reality\n10. Progress\n11. Resume instructions (agent)\n12. Product intent alignment\n13. Locked decisions\n14. Acceptance criteria\n15. BDD scenarios\n16. Phase-by-phase execution plan\n17. Verification strategy\n18. Delivery order\n19. Non-goals\n20. Decisions \u002F Deviations log\n\nDecision Attention must appear near the top of every non-trivial plan, immediately after Product-owner context, `What's new`, and goal\u002Fstatus framing. It indexes blockers, required user input, unresolved or low-confidence decisions, and areas where repo evidence is weak. If none remain, say `None` or `No product decision required` explicitly; do not omit the section or bury the answer in later phases.\n\nLegacy heading aliases may be preserved in historical plans, but new plans should use canonical headings unless the repo explicitly says otherwise.\n\n\n## TDD + BDD rules\n\nFor every acceptance area:\n\n- define acceptance in observable user or system outcomes,\n- define what the system should do automatically before asking the user or agent to intervene,\n- add `Given\u002FWhen\u002FThen` scenarios for happy path, failure path, and relevant edge cases,\n- add counterexample or ambiguity scenarios when matching, routing, identity, parsing, refs, or policies could yield misleading passes,\n- add boundary or scale scenarios when volume, fan-out, or aggregation could change correctness,\n- add cross-surface parity scenarios when behavior must match across HTTP\u002FCLI\u002FMCP\u002FUI or similar interfaces.\n\nFor workflow and product-surface planning, include scenarios that distinguish:\n\n- routine recoverable faults that should self-heal,\n- ambiguous or high-risk faults that should fail closed,\n- and the exact agent-legible error or inline guidance expected when automation must stop.\n\nFor every phase:\n\n- start with failing tests first when practical,\n- map tests to acceptance criteria and BDD scenario IDs,\n- make the RED-phase contract strong enough to catch partial or misleading implementations,\n- if strict TDD is not practical, state why and define compensating verification.\n\n## Phase template\n\nEvery phase must include:\n\n- `### End State`\n- `### Tests first`\n- `### Work`\n- `### Expected files`\n- `### Open questions \u002F decision dependencies`\n- `### Verify`\n\nUse `None` for phase-specific questions only when there are no unresolved decisions. If a dependency changes scope, behavior, data handling, security\u002Fprivacy posture, or compatibility, resolve it before marking the plan execution-ready instead of deferring it to implementation.\n\nPhase guidance:\n\n- keep phases coarse and outcome-oriented,\n- do not hide task lists inside phases,\n- make multi-surface parity inventory explicit in `### Expected files` or `### Work`,\n- lock canonical contracts, schemas, fixtures, payloads, or evidence sources before downstream phases depend on them.\n\n## Resumability rules\n\n- `## Progress` contains the only checkboxes in the plan.\n- Use stable IDs like `P1`, `P2`, ... and keep them aligned to phase headers.\n- Enforce a one-to-one phase\u002Fprogress mapping: every progress checkbox maps to exactly one detailed phase, and every detailed phase maps back to exactly one progress checkbox.\n- Preserve completed items and append-only deviation\u002Fhistory sections when regenerating a plan.\n- `Resume instructions` must tell the next agent to read the document fully, identify the first unchecked progress item, continue phase-by-phase, and ask the user only for truly unresolvable decisions.\n\n## Ready bar\n\nAn `execution-ready` plan is ready only when all of the following are true:\n\n- important questions are resolved,\n- the near-top product-owner context is standalone, plain-language, explicit about why now and the key conclusion, and separates all five impact dimensions,\n- `What's new` appears after Product-owner context and before Goal and states a distinct audience-visible change rather than a heading or restatement,\n- Decision Attention is near the top and truthfully reports blockers, user-input needs, and low-confidence areas,\n- required plan work stays faithful to the validated source scope, with optional adjacent improvements excluded or called out as non-goals rather than required phases,\n- acceptance criteria and BDD scenarios are concrete,\n- every progress checkbox has exactly one matching phase and every phase has exactly one matching progress checkbox,\n- every phase includes explicit `Open questions \u002F decision dependencies`, with `None` only when true,\n- phase `### Verify` steps are executable and current for the real repo,\n- product-intent alignment is explicit when required,\n- parity expectations are explicit for multi-surface work,\n- self-healing expectations and fail-closed boundaries are explicit for workflow-affecting work,\n- plans do not normalize routine manual remediation when the product should absorb that burden instead,\n- UI impact is explicitly triaged and is not `unknown`,\n- UI-impacting work includes repo-appropriate existing\u002Ftarget design evidence and verification gates,\n- no unresolved `Open Questions` remain in a ready plan,\n- no unresolved low-confidence decisions remain,\n- foundational decisions are not deferred into later execution phases,\n- progress and resume instructions are present,\n- review-gated plans have fresh independent, non-self sign-off after the latest material edit and no later non-pass review.\n\nIf any item above is still missing, the plan is `not ready`: stay in `discovery` while evidence is still being gathered, or emit a `research-ready` artifact when research is the explicit next handoff.\n\n## Readiness states\n\n- `discovery` means planning evidence is still being gathered and the work is not yet plan-finalization-ready; it is a pre-handoff state, not a substitute for a written research handoff.\n- `research-ready` means exactly one non-ready plan artifact may be written once discovery has established that research is the next handoff; that artifact must capture unresolved decisions, the next research step, and the condition for later promotion.\n- `execution-ready` means the plan can hand off to execution without inventing missing contracts, rollout semantics, compatibility rules, or other foundational behavior.\n- A plan is `not ready` when foundational decisions are deferred into later execution phases, even if the phase list itself looks complete.\n\n## Low-confidence decision workflow\n\n- Treat any materially outcome-shaping unknown as a `low-confidence` decision: contracts, migrations, rollout semantics, compatibility behavior, safety constraints, or cross-surface behavior.\n- Resolve low-confidence decisions from repo evidence first.\n- If repo evidence is insufficient and the choice changes intended behavior, ask the user before finalizing the plan.\n- If the answer is researchable without user intent input, delegate research immediately or emit a non-ready `research-ready` research plan artifact.\n- A non-ready plan artifact must list the unresolved low-confidence decisions, make the exact next research action explicit, and stay clearly separate from an `execution-ready` handoff.\n- Never bury low-confidence decisions inside future execution phases or assume implementation will resolve them later.\n\n## UI-impact triage\n\nEvery non-trivial plan must state whether it changes UI, reviewer-facing artifacts, operator-facing command output, generated docs, visual design, or interaction behavior.\n\nUse these defaults:\n\n- `UI impact: no` only when no visible\u002Foperator-facing surface changes.\n- `UI impact: text-only` when the visible change is prose, guidance, command output, or plan-artifact structure without runtime UI or styling changes.\n- `UI impact: yes` when the work changes screens, flows, browser artifacts, navigation, forms, visual hierarchy, or interaction behavior.\n- `UI impact: unknown` blocks execution-ready status until resolved.\n\nFor `UI impact: yes`, include high-fidelity existing and target mocks or screenshots when the repo surface supports them, plus repo-appropriate design evidence and verification gates. For `text-only`, include a concise current\u002Ftarget textual rendition and the inspection commands or review checks that prove the guidance changed.\n\n## Complexity-aware completeness\n\n- Keep the doctrine `complexity-aware` and domain-agnostic: scale planning depth to the real task shape, not the stack.\n- Simple local wiring or narrow refactor tasks should stay `lightweight`; they may use concise labeled prose for product-owner context and should not be forced into heavyweight schema, protocol, rollout, or tabular sections when those do not improve confidence.\n- Non-trivial, migration-heavy, compatibility-sensitive, or multi-surface work requires complete contracts before it can be `execution-ready`, including a scannable product-owner impact table or equivalent structured block.\n- Every non-trivial ready plan must include a `test coverage matrix` that maps acceptance criteria and BDD scenarios to planned test layers, intended suites or files, and `### Verify` commands strong enough to catch partial implementations.\n- If task complexity is uncertain, bias toward more explicit contracts and acceptance-to-test mapping until evidence justifies a lighter plan.\n\n## Verification ownership\n\n- Phase `### Verify` checks are agent-run execution gates: they must be runnable during implementation, grounded in repo reality, and expanded with compensating checks when strict TDD is not practical.\n- Final completion still requires a semantic coherence review across the shared files touched by the work so reviewers confirm the doctrine means the same thing everywhere, not just that strings appear.\n\n## Handoff to execution\n\nWhen the plan is complete:\n\n- leave the repo ready for the repo's canonical execution workflow,\n- if repo-local guidance requires a plan review registration, prefer the Doct-backed `doct-document-ops` flow; use a checked-in\u002Flocal plan server only when the repo or user explicitly requires that legacy surface,\n- `ready for` means handoff-ready, not permission to start execution in the current command,\n- if the active command is planning-only, stop after updating the plan and reporting the next suggested command,\n- ensure the plan reflects repo-specific commands from `AGENTS.md`,\n- keep deviations and migration notes append-only,\n- do not stop with an implicit draft if the user asked for an execution-ready plan.\n","# Writing Implementation Plans\n\nUse this skill as the canonical source of truth for writing executable implementation plans across repos.\n\n## Default: plans stay local\n\nWhen the user asks to create, write, or update a plan, write a local plan file. Do not register it in Doct.\n\nRegister in Doct only when they explicitly ask to send, publish, register, or review the plan in Doct, or invoke `reviewed-html-plan` \u002F `send-plan-to-doct`. Then write HTML, register through `doct-document-ops`, start the comment listener, and share the canonical Doct URL.\n\nResolve the source path from repo-local guidance or an existing plan path supplied by the user. If local guidance does not define the active artifact and the user did not supply an existing plan path, ask one targeted question and stop. Do not assume HTML or Markdown.\n\n## Boundaries\n\n- `plan mode` is for discovery only: inspect the codebase, validate assumptions, gather evidence, and identify ambiguities.\n- `dev:plan` (or equivalent plan-materialization step) writes the actual plan file once discovery has produced enough evidence to choose the correct readiness state: `execution-ready` when foundational decisions are resolved, or a single non-ready `research-ready` artifact when further research is the next handoff. Before that handoff point, the work remains `discovery`.\n- There is no default shared artifact path or extension. Resolve the single-file active plan artifact from repo-local guidance or an existing plan path supplied by the user. If local guidance does not define the active artifact and the user did not supply an existing plan path, ask one targeted question and stop. Do not assume markdown.\n- `dev:plan` ends when the plan artifact is written or updated; execution starts only after a separate explicit execution command or a new user instruction.\n- In Pi-style reviewed-plan workflows, keep the handoff explicit and prefer the repo's canonical workflow skill from repo-local guidance. Keep the plan as a local file. Register it in Doct only when the user explicitly asks to send, publish, register, or review it in Doct, or when they invoke `reviewed-html-plan` \u002F `send-plan-to-doct`. Do not assume a hidden fallback to Claude Code, a local `plan-review` service, or any other alternate review surface.\n- During plan writing, edit only the target plan artifact unless the repo's `AGENTS.md` explicitly allows another planning-side file.\n- Do not change product code, tests, app config, docs, generated files, or environment files while planning.\n- Avoid unrelated side effects: no installs, codegen, migrations, formatting runs, rebases, resets, or destructive commands. Commit the plan artifact when the repository workflow requires it.\n\n## Planning inputs\n\nBefore writing a plan, read in this order:\n\n1. Root `AGENTS.md` for repo-specific commands, quality gates, docs, and skill-routing hints.\n2. `thoughts\u002Fspecs\u002Fproduct_intent.md` when the repo requires product-intent alignment.\n3. Optional `thoughts\u002Fplans\u002FAGENTS.md` only when the repo uses local planning overrides beyond this shared skill.\n4. Existing plan file, legacy plan bundle, task list, issue, or source specification that the plan must preserve.\n\nWhen local guidance defines an active HTML plan workflow, also read its referenced contract\u002Ftemplate docs before writing the plan. Do not create markdown companions for a repo whose active plan authority is HTML.\n\nIf required repo guidance or product intent is missing, stop and ask the user or tell them the repo bootstrap needs to be completed first.\n\n## Skill routing\n\nAlways consider which additional skills are needed before writing the plan.\n\n- Load `doct-document-ops` only when the user explicitly asked to register, publish, update, or monitor a plan in Doct. Use `https:\u002F\u002Fdoct.nodaste.com` as the registration endpoint.\n- Load `product-principles` for planning work that affects user\u002Foperator\u002Fagent workflows, defaults, onboarding, recovery behavior, error handling, architecture, or regression strategy. Use it to define the golden path, safe defaults, self-healing expectations, actionable error guidance, and a quick dissonance audit against repo guidance (`AGENTS.md`, product-intent docs, onboarding docs, config\u002Fstatus surfaces, and tests).\n- Load `tdd-test-writer` when phases will rely on tests-first delivery or when the RED-phase contract needs strengthening.\n- Load repo-recommended skills from `AGENTS.md` for the relevant surface or stack.\n- Load domain-specific skills when the planned work clearly spans those domains (frontend, React\u002FNext, Rust, MCP, browser automation, UI review, etc.).\n\nThe plan should reflect the behavior those skills require, not merely mention them.\n\nWhen product work touches interactions, commands, processes, or operator\u002Fagent workflows, the plan should encode these default beliefs unless repo evidence explicitly requires a different constraint:\n\n- the product should do the obvious right thing by default,\n- routine faults should be detected and healed inside the normal requested flow,\n- normal workflows should not depend on users discovering and running separate status or remediation commands,\n- errors should assume a capable agent is reading them and should explain what happened, what the system already tried, why automation stopped, and what to do next,\n- fail-closed behavior is reserved for ambiguous or high-risk situations such as data loss, security\u002Fprivacy risk, or identity\u002Fauthority uncertainty.\n\n## Research standard\n\nValidate important claims directly against repo reality before writing the plan:\n\n- locate existing files, routes, registries, commands, and patterns,\n- confirm data shapes, schemas, contracts, and constraints,\n- identify integration points, parity surfaces, and likely risks,\n- verify command names, package names, and file paths used in `### Verify` sections,\n- identify the simplest supported workflow and which inputs should be optional because the system can infer or heal them,\n- identify which manual status-check or repair steps currently exist and whether they should instead become built-in behavior on the normal path,\n- check whether repo guidance, onboarding docs, config defaults, status surfaces, and tests are aligned with that default-path contract.\n\nUse targeted `Glob`, `Grep`, and `Read` first. Delegate broad codebase discovery only when targeted search is not enough.\n\n## Integration-integrity planning contract\n\nWhen discovery identifies an exact contract that types cannot fully verify or behavior distributed across production sites, add a **Contract and distributed-integration inventory**. Record the source of truth, producer\u002Fconsumer or source-search-backed operation rows, dependent docs\u002Fexamples, cross-boundary or production-path proof, reconciliation status, and coverage as `exhaustive-by-site`, `exhaustive-by-family`, or `justified representative`.\n\nBefore planning dependent edits, reread the current source definition. Prefer one shared executable definition or contract artifact over duplicated fixtures. A helper, middleware, wrapper, or event-existence test is not completion evidence for a distributed outcome; contractual documented CLI forms must execute through the actual parser. If neither trigger applies, record `None identified, based on \u003Csource search>` rather than inventing an inventory.\n\n## Canonical plan contract\n\nWrite plans as execution artifacts, not brainstorming notes. A ready plan must be executable by another agent without inventing missing semantics.\n\n- Preserve the validated source scope. A ready plan should include only work that is critical to achieving the stated goal and verifying it.\n- When the requested scope is vague, tighten it by sharpening the Goal \u002F Non-goals or other scoped language instead of widening the phase list to absorb adjacent surfaces.\n- Do not promote adjacent cleanup, optional follow-ups, broader parity not required by the source intent, or extra explicitness that does not materially change go\u002Fno-go confidence into required plan work unless source requirements or validated repo evidence show they are necessary for success.\n- Plan complete promised slices, not skeletons. Every claimed functional outcome must be connected, usable, and verifiable within its stated scope, without required stubs, TODO behavior, dead-end surfaces, missing producer\u002Fconsumer wiring, fake success, or verification that bypasses the real implementation.\n- If the requested outcome cannot be completed safely in one change, resize it before implementation to a smaller independently useful complete slice. Independent future enhancements, scale work, optional hardening, and polish may remain out of scope; work required for the current slice to function as claimed may not.\n- When a plan is rendered or delivered as HTML, use the standard reviewer layout by default: a dark-mode visual theme with explicit dark background, light foreground text, readable muted text, accessible link\u002Faccent colors, `color-scheme: dark`, plus 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 reviewers can scan links without sacrificing plan body width. Do not use a permanent left sidebar\u002Frail for navigation. Do not leave color mode or navigation layout to browser, OS, or agent-selected defaults.\n- When the user explicitly asked to register or review a plan in Doct, write HTML and delegate service details to `doct-document-ops`: register through `doct-agent plans register --base-url https:\u002F\u002Fdoct.nodaste.com --source-format html --title '\u003CPlan Title>'`, update through `doct-agent plans update`, share the canonical Doct URL, and process comments\u002Factions through `doct-agent plans queue\u002Fagent\u002Fack\u002Fresolve`.\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\n### Product-owner context contract\n\nNear the top of every implementation plan, before implementation history, current-code detail, progress, phases, or verification mechanics, include a standalone product-owner context section. Write it for a product owner who has no prior issue, Linear, incident, or repository context. It must:\n\n- explain the situation in plain language, defining unavoidable domain terms instead of leading with file paths, symbols, request traces, or issue chronology,\n- explain why the change is needed now and what new evidence, failure, decision, or timing makes the work timely,\n- state the key conclusion unmistakably, especially whether the plan addresses a customer\u002Fruntime product defect, a stale test or evidence problem, an operational\u002Fdocumentation gap, or a combination,\n- separate the impact on `Customers`, `Runtime product behavior`, `Security \u002F permissions`, `Testing \u002F release confidence`, and `Deployment \u002F migration`; explicitly say `No change` or `Not applicable` rather than silently omitting an unaffected dimension,\n- distinguish observed facts from proposed work so a reviewer does not confuse a failing test with a shipped-product failure.\n\nKeep this complexity-aware. A lightweight plan must satisfy the contract with concise labeled prose. A non-trivial plan must use a clearly scannable impact table or an equivalent structured block with those five impact dimensions. This is an authoring and review contract, not a Doct renderer requirement; preserve the standard dark full-width layout and fit the section into that layout.\n\n### What's new contract\n\nFor every full implementation plan, put a standalone `What's new` section after Product-owner context and before Goal. Give it a behavior-focused headline and a one-sentence product promise, then state the concrete audience-visible changes, before\u002Fafter workflow, observable result, and preserved guarantees. It must not restate Goal, rationale, phases, or acceptance criteria; a heading without a distinct product delta does not satisfy the contract. Work already exempt from a full plan remains exempt.\n\nRequired sections for new plans unless repo-local overrides say otherwise:\n\n1. Title\n2. Status\n3. Product-owner context (situation, why now, key conclusion, and impact breakdown)\n4. What's new (standalone product change and preserved guarantees)\n5. Goal\n6. Decision Attention \u002F Low-confidence Areas\n7. Why this plan exists\n8. Authority and inputs\n9. Current implementation reality\n10. Progress\n11. Resume instructions (agent)\n12. Product intent alignment\n13. Locked decisions\n14. Acceptance criteria\n15. BDD scenarios\n16. Phase-by-phase execution plan\n17. Verification strategy\n18. Delivery order\n19. Non-goals\n20. Decisions \u002F Deviations log\n\nDecision Attention must appear near the top of every non-trivial plan, immediately after Product-owner context, `What's new`, and goal\u002Fstatus framing. It indexes blockers, required user input, unresolved or low-confidence decisions, and areas where repo evidence is weak. If none remain, say `None` or `No product decision required` explicitly; do not omit the section or bury the answer in later phases.\n\nLegacy heading aliases may be preserved in historical plans, but new plans should use canonical headings unless the repo explicitly says otherwise.\n\n\n## TDD + BDD rules\n\nFor every acceptance area:\n\n- define acceptance in observable user or system outcomes,\n- define what the system should do automatically before asking the user or agent to intervene,\n- add `Given\u002FWhen\u002FThen` scenarios for happy path, failure path, and relevant edge cases,\n- add counterexample or ambiguity scenarios when matching, routing, identity, parsing, refs, or policies could yield misleading passes,\n- add boundary or scale scenarios when volume, fan-out, or aggregation could change correctness,\n- add cross-surface parity scenarios when behavior must match across HTTP\u002FCLI\u002FMCP\u002FUI or similar interfaces.\n\nFor workflow and product-surface planning, include scenarios that distinguish:\n\n- routine recoverable faults that should self-heal,\n- ambiguous or high-risk faults that should fail closed,\n- and the exact agent-legible error or inline guidance expected when automation must stop.\n\nFor every phase:\n\n- start with failing tests first when practical,\n- map tests to acceptance criteria and BDD scenario IDs,\n- make the RED-phase contract strong enough to catch partial or misleading implementations,\n- if strict TDD is not practical, state why and define compensating verification.\n\n## Phase template\n\nEvery phase must include:\n\n- `### End State`\n- `### Tests first`\n- `### Work`\n- `### Expected files`\n- `### Open questions \u002F decision dependencies`\n- `### Verify`\n\nUse `None` for phase-specific questions only when there are no unresolved decisions. If a dependency changes scope, behavior, data handling, security\u002Fprivacy posture, or compatibility, resolve it before marking the plan execution-ready instead of deferring it to implementation.\n\nPhase guidance:\n\n- keep phases coarse and outcome-oriented,\n- do not hide task lists inside phases,\n- make multi-surface parity inventory explicit in `### Expected files` or `### Work`,\n- lock canonical contracts, schemas, fixtures, payloads, or evidence sources before downstream phases depend on them.\n\n## Resumability rules\n\n- `## Progress` contains the only checkboxes in the plan.\n- Use stable IDs like `P1`, `P2`, ... and keep them aligned to phase headers.\n- Enforce a one-to-one phase\u002Fprogress mapping: every progress checkbox maps to exactly one detailed phase, and every detailed phase maps back to exactly one progress checkbox.\n- Preserve completed items and append-only deviation\u002Fhistory sections when regenerating a plan.\n- `Resume instructions` must tell the next agent to read the document fully, identify the first unchecked progress item, continue phase-by-phase, and ask the user only for truly unresolvable decisions.\n\n## Ready bar\n\nAn `execution-ready` plan is ready only when all of the following are true:\n\n- important questions are resolved,\n- the near-top product-owner context is standalone, plain-language, explicit about why now and the key conclusion, and separates all five impact dimensions,\n- `What's new` appears after Product-owner context and before Goal and states a distinct audience-visible change rather than a heading or restatement,\n- Decision Attention is near the top and truthfully reports blockers, user-input needs, and low-confidence areas,\n- required plan work stays faithful to the validated source scope, with optional adjacent improvements excluded or called out as non-goals rather than required phases,\n- acceptance criteria and BDD scenarios are concrete,\n- every progress checkbox has exactly one matching phase and every phase has exactly one matching progress checkbox,\n- every phase includes explicit `Open questions \u002F decision dependencies`, with `None` only when true,\n- phase `### Verify` steps are executable and current for the real repo,\n- product-intent alignment is explicit when required,\n- parity expectations are explicit for multi-surface work,\n- self-healing expectations and fail-closed boundaries are explicit for workflow-affecting work,\n- plans do not normalize routine manual remediation when the product should absorb that burden instead,\n- UI impact is explicitly triaged and is not `unknown`,\n- UI-impacting work includes repo-appropriate existing\u002Ftarget design evidence and verification gates,\n- no unresolved `Open Questions` remain in a ready plan,\n- no unresolved low-confidence decisions remain,\n- foundational decisions are not deferred into later execution phases,\n- progress and resume instructions are present,\n- review-gated plans have fresh independent, non-self sign-off after the latest material edit and no later non-pass review.\n\nIf any item above is still missing, the plan is `not ready`: stay in `discovery` while evidence is still being gathered, or emit a `research-ready` artifact when research is the explicit next handoff.\n\n## Readiness states\n\n- `discovery` means planning evidence is still being gathered and the work is not yet plan-finalization-ready; it is a pre-handoff state, not a substitute for a written research handoff.\n- `research-ready` means exactly one non-ready plan artifact may be written once discovery has established that research is the next handoff; that artifact must capture unresolved decisions, the next research step, and the condition for later promotion.\n- `execution-ready` means the plan can hand off to execution without inventing missing contracts, rollout semantics, compatibility rules, or other foundational behavior.\n- A plan is `not ready` when foundational decisions are deferred into later execution phases, even if the phase list itself looks complete.\n\n## Low-confidence decision workflow\n\n- Treat any materially outcome-shaping unknown as a `low-confidence` decision: contracts, migrations, rollout semantics, compatibility behavior, safety constraints, or cross-surface behavior.\n- Resolve low-confidence decisions from repo evidence first.\n- If repo evidence is insufficient and the choice changes intended behavior, ask the user before finalizing the plan.\n- If the answer is researchable without user intent input, delegate research immediately or emit a non-ready `research-ready` research plan artifact.\n- A non-ready plan artifact must list the unresolved low-confidence decisions, make the exact next research action explicit, and stay clearly separate from an `execution-ready` handoff.\n- Never bury low-confidence decisions inside future execution phases or assume implementation will resolve them later.\n\n## UI-impact triage\n\nEvery non-trivial plan must state whether it changes UI, reviewer-facing artifacts, operator-facing command output, generated docs, visual design, or interaction behavior.\n\nUse these defaults:\n\n- `UI impact: no` only when no visible\u002Foperator-facing surface changes.\n- `UI impact: text-only` when the visible change is prose, guidance, command output, or plan-artifact structure without runtime UI or styling changes.\n- `UI impact: yes` when the work changes screens, flows, browser artifacts, navigation, forms, visual hierarchy, or interaction behavior.\n- `UI impact: unknown` blocks execution-ready status until resolved.\n\nFor `UI impact: yes`, include high-fidelity existing and target mocks or screenshots when the repo surface supports them, plus repo-appropriate design evidence and verification gates. For `text-only`, include a concise current\u002Ftarget textual rendition and the inspection commands or review checks that prove the guidance changed.\n\n## Complexity-aware completeness\n\n- Keep the doctrine `complexity-aware` and domain-agnostic: scale planning depth to the real task shape, not the stack.\n- Simple local wiring or narrow refactor tasks should stay `lightweight`; they may use concise labeled prose for product-owner context and should not be forced into heavyweight schema, protocol, rollout, or tabular sections when those do not improve confidence.\n- Non-trivial, migration-heavy, compatibility-sensitive, or multi-surface work requires complete contracts before it can be `execution-ready`, including a scannable product-owner impact table or equivalent structured block.\n- Every non-trivial ready plan must include a `test coverage matrix` that maps acceptance criteria and BDD scenarios to planned test layers, intended suites or files, and `### Verify` commands strong enough to catch partial implementations.\n- If task complexity is uncertain, bias toward more explicit contracts and acceptance-to-test mapping until evidence justifies a lighter plan.\n\n## Verification ownership\n\n- Phase `### Verify` checks are agent-run execution gates: they must be runnable during implementation, grounded in repo reality, and expanded with compensating checks when strict TDD is not practical.\n- Final completion still requires a semantic coherence review across the shared files touched by the work so reviewers confirm the doctrine means the same thing everywhere, not just that strings appear.\n\n## Handoff to execution\n\nWhen the plan is complete:\n\n- leave the repo ready for the repo's canonical execution workflow,\n- if repo-local guidance requires a plan review registration, prefer the Doct-backed `doct-document-ops` flow; use a checked-in\u002Flocal plan server only when the repo or user explicitly requires that legacy surface,\n- `ready for` means handoff-ready, not permission to start execution in the current command,\n- if the active command is planning-only, stop after updating the plan and reporting the next suggested command,\n- ensure the plan reflects repo-specific commands from `AGENTS.md`,\n- keep deviations and migration notes append-only,\n- do not stop with an implicit draft if the user asked for an execution-ready plan.\n",{"name":5,"author":54,"license":15,"version":55,"metadata":56,"description":7},"Hermes Agent","2.0.0",{"hermes":57},{"tags":58,"related_skills":61},[44,35,36,48,46,59,60],"doct","html-plans",[62,63,64,65],"planning-workflow","doct-document-ops","reviewed-html-plan","test-driven-development","main","64e2fc9afa7bb3da1138eb73399144d0e7e73e9d","_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fwriting-plans",4,"https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs","https:\u002F\u002Fgithub.com\u002Fadnichols","2026-11-06 00:28:38",{"source":8,"skillName":5,"commands":74,"prompt":84,"zipAvailable":85},[75,78,81],{"tool":76,"command":77},"npx","npx skills add adnichols\u002Fai-configs --skill writing-plans",{"tool":79,"command":80},"bunx","bunx skills add adnichols\u002Fai-configs --skill writing-plans",{"tool":82,"command":83},"pnpm","pnpm dlx skills add adnichols\u002Fai-configs --skill writing-plans","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",true,[],[88,107,131,142,158,177],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":49},"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",[],[95,96,97,98,99,38,100,41,42,101,102,103,104,105,106],"page","recovery","blocked page recovery","fallback","macos","fetch","Citations","waf","windows","research","linux","bot",{"skillNo":108,"name":65,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":121,"publishedAt":49},"01M6CB7JME246KZQHP73Z2STDF","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",[112,115,118],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":119,"categoryName":120,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000037","律师与法务",[122,47,45,123,105,99,124,103,125,126,41,42,127,43,128,129,130],"test driven development","tdd","testing","red-green-refactor","superpowers","quality","refactor","code","debugging",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":49},"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",[137],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},[130,139,99,105,47,103,126,41,42,140,43,141,45],"systematic debugging","troubleshooting","investigation",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":151,"publishedAt":49},"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",[148],{"categoryNo":149,"categoryName":150,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[144,152,153,41,42,43,44,154,103,155,156,104,157,105,99],"prototype","experiment","feasibility","validate","experiments","sketch",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":168,"publishedAt":49},"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",[164,165],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":166,"categoryName":167,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[169,129,170,45,103,47,105,171,99,172,41,42,173,174,43,128,175,176],"simplify","simplify code","review","cleanup","parallel","subagent","code-review","delegation",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":185,"publishedAt":49},"01M6CB71SF58GH5WATE5B1VQ0R","requesting-code-review","Pre-commit review: security scan, quality gates, auto-fix.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Frequesting-code-review\u002FSKILL.md",[183,184],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":166,"categoryName":167,"taxonomyType":29,"taxonomyTypeDesc":30},[171,186,129,187,188,126,189,190,127,43,191,192,175,45,193,103,194,47,105,195],"requesting code review","code review","pre-commit","auto","fix","security scan","verification","quality gates","commit","github"]