[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JVT4DZZTF12PQ751BFRGSH":3,"skill-same:01M6JVT4DZZTF12PQ751BFRGSH":88},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6JVT4DZZTF12PQ751BFRGSH","writing-plans",null,"Use when you have an approved spec or written requirements for a multi-step task that needs a durable plan document before touching code. Small, single-owner, or fast-path tasks do not need this skill.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1571,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"writing plans","plans","writing","single","when","multi-step task","fast","spec","multi","task","requirements","document","use","for","do","path","plan","tasks","code","you","2026-11-10 10:12:30",false,"---\nname: writing-plans\ndescription: \"Use when you have an approved spec or written requirements for a multi-step task that needs a durable plan document before touching code. Small, single-owner, or fast-path tasks do not need this skill.\"\n---\n\n\u003CEXPLICIT-MODE-GATE>\nIf activation mode is explicit (`~\u002F.config\u002Faegis\u002Fconfig.toml` has\n`activation_mode = \"explicit\"`, or `AEGIS_ACTIVATION_MODE=explicit` is visible\nin the environment) and the current user request did not explicitly invoke\nAegis or this skill by name, exit back to the fast path: answer concisely\nwithout this workflow's checklist, ceremony, or document requirements. If the\nuser explicitly named Aegis or this skill, proceed normally.\n\u003C\u002FEXPLICIT-MODE-GATE>\n\n# Execute\n\n→ Existing parent plan\u002Fspec and a tiny execution slice? → **Use Planless Slice Lane.**\n→ Mechanical or bounded change with no durable boundary (no new owner,\n  contract, schema, public API, migration, or compat surface)? → **Use\n  Planless Slice Lane without a parent document.**\n→ Approved spec\u002Frequirements for a new workstream or an escalation trigger? →\n  **Write an implementation plan for an engineer with no prior task context.**\n\nFor a durable plan: confirm scope and acceptance, map current owners\u002Ffiles,\nrecord the TDD route, decompose into executable tasks, define verification and\nretirement, self-review, save, then select the execution route. Proceed unless\na real authorization or safety boundary requires the user.\n\nBind tasks to the requested user outcomes: object, actions, conditions, and\ndeliverables. Include the final delivery step and evidence at the user-visible\nseam, not only implementation\u002Ftests. Keep unmet needs and dependencies explicit;\nproject-wide goals do not authorize work outside this request. Reuse the\nexisting scope\u002Facceptance slots; no extra goal artifact is required.\n\nThis plan is method-pack guidance, not authoritative completion.\n\n## TDD Route Guard\n\nBefore task decomposition, record `TDD Route` with mode (`off | auto`), decision\n(`strict | light | skipped`), authority, test posture, reason, and verification.\n\nStrict RED \u002F GREEN steps belong only to an explicit user\u002Fproject TDD request or\n`TDD Route: strict`. In `off`, use `skipped` unless explicit strict authority\noverrides it. An approved plan or a risk label alone is not strict authority.\n\nIn `auto`, select `strict` for behavior, bugfix, shared\u002Fcore, contract,\npersistence, permission, migration, producer\u002Fconsumer, or meaningful\nregression signals. Select `light` only when the work is tiny, low-risk,\nsingle-owner, has no behavior change or strict signal, and has an obvious\nfocused check. Absence of an explicit user TDD request is never evidence for\n`light`; the auto decision itself must be recorded.\n\nIf risk remains unknown, return to requirements, debugging, or plan review\nbefore task decomposition; do not infer a TDD route from uncertainty.\n\nOnly a `strict` decision with stated authority may prescribe failing-test,\nRED, GREEN, and REFACTOR steps. Otherwise plan the minimum change plus\ndiagnostic reproduction or post-change regression. A missing auto decision\nreturns to route selection before implementation tasks.\n\n## Entry And Artifact Choice\n\n**Announce at start:** on the plan-writing route, say that this skill is\ncreating the implementation plan. On `Planless Slice Lane`, announce the lane instead and do not claim a plan is being created.\n\n**Execution context:** Reuse the current branch\u002Fworkspace by default. A branch\nneeds independent history; a worktree needs concurrent checkout, blocking\nunrelated dirty state, or explicit user\u002Frepository authority.\n\n**Input:** approved requirements, a Spec Brief, or a Design Spec.\n\n**Default plan path:** `docs\u002Faegis\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`. Plans do\nnot go in `work\u002F`; user and repository authority override the default.\n\n## Planless Slice Lane\n\nUse `Planless Slice Lane` before writing or saving a plan when one of these\nentry conditions holds:\n\n- a parent spec or parent plan already defines the workstream, and the current\n  request is executing or refining one bounded task from that parent\n- the change is mechanical or bounded and needs no parent document (the\n  no-parent branch under `# Execute`)\n\nand both of these are true:\n\n- no new owner, contract, schema, public API, architecture boundary, migration,\n  persistence, security\u002Fpermission, distribution\u002Frelease surface, or unclear\n  verification boundary appears\n- the slice can be described by a `Slice Card`\n\nThe lane preserves long-task continuity without turning execution bookkeeping\ninto durable planning artifacts. A parent scope or acceptance mismatch returns\nto the parent plan\u002Fspec instead of spawning a micro-plan.\n\nDo not save a new plan. Emit a compact `Slice Card`:\n\n```text\nSlice Card:\n- Goal:\n- Parent plan\u002Fspec:\n- Files:\n- Boundary:\n- Verification:\n- Stop:\n```\n\nOn the no-parent branch, `Parent plan\u002Fspec:` is `none — direct bounded request`.\n\n## Aegis Project Workspace\n\nWorkspace creation is lazy and follows project authority. The Aegis Method\nPack repository must not create or ship a live `docs\u002Faegis\u002F` workspace. When a\ndurable plan must initialize or update another project's workspace, read the\n`## Workspace Save Detail` section of `expanded-planning-guidance.md`. It owns the\n`\u003Caegis-workspace-helper>` and `INDEX.md` command detail, not the decision to\ncreate a plan.\n\n## Default Plan Surface\n\nCompact output contract: express these as natural plan content, not a stack of\ncards: `Aegis Visibility`, approved scope and plan basis, required baseline\nrefs, files\u002Fowners, compatibility boundary, `Change Necessity`, TDD route,\ntasks, verification, risks, and retirement. Keep conditional structures silent unless their trigger below fires.\n\n`Aegis Visibility` is normally one sentence explaining which owner, contract,\nretirement, compatibility, or verification pressure makes a durable plan\nuseful. Structured trace belongs only to audit, debug, release, long-task\nreview, or explicit request.\n\nBefore tasks, perform a `Requirement Ready Check`: identify the approved source,\nscope, scenarios, and acceptance evidence. If any decision-changing item is\nmissing, do not create implementation tasks; return the smallest gap to the\nrequirement\u002Fspec owner.\n\nPerform `Change Necessity` before any non-trivial source edit or any new source-code path. This is behavior-triggered, not prompt-triggered. State\nnaturally why no-change\u002Fdocs\u002Fconfig is insufficient and name the minimum code\nboundary. A tiny helper, guard, branch, fallback, adapter, or owner is not\nexempt. A `no-change`, `docs\u002Fconfig-only`, or `needs-clarification` result\nnarrows or stops the code plan.\n\nRun `Ripple Signal Triage` before tasks when the change touches shared\u002Fcore or\ncross-module behavior; a public API, schema, contract, compatibility,\npersistence, cache, export\u002Freadback, fallback, adapter, duplicate\u002Flegacy owner,\nretirement path, or both producer and consumer. If no signal fires, add no\noutput. If one fires, identify the canonical owner and affected downstream consumers,\nstate source-of-truth\u002Fcontract\u002Ffallback\u002Fretirement risk, and carry expanded verification\ninto the relevant task. A required owner\u002Fpublic-contract\u002Fsource-of-truth change,\nretaining two owners, or adding a fallback, adapter, or compatibility branch\nreturns to design or requires explicit prior alignment before implementation.\n\nRun a compact `Plan Pressure Test` before task decomposition: test owner \u002F contract \u002F retirement fit, higher-level architecture path, verification scope,\nand task executability. It may proceed, revise the plan, or return to design;\nit is not an approval authority.\n\n## Conditional Detailed Guidance\n\nFor interface\u002Finteraction work, compose `ui-ux-governance` and carry the accepted\nexperience criteria and corresponding checks into affected tasks. Include API\nchanges that alter visible states or recovery; keep backend-only work scoped.\n\nFor maintained source, screen file shape, owner fit, add-in-place risk, and a\nbetter boundary. With no pressure signal, a compact edit-in-place decision is\nenough. For an ordinary medium\u002Fhigh handoff, state Intent Lock, Scope Fence, Baseline Lock, tests, and drift stop naturally. Load the expanded `Execution Readiness View` only for the auditable handoff triggers below. Neither form is a\n`GateDecision`, `PolicySnapshot`, approval gate, or completion authority.\n\nRead only the trigger-matched section of `expanded-planning-guidance.md`, never\nthe whole file. This map owns conditional activation, not another planning pass.\nDo not load references merely to announce a route or describe a Planless slice.\n\n| Evidence trigger | Exact section and required action |\n| --- | --- |\n| Specific baseline acknowledgement needs structure, or requirement readiness is incomplete\u002Fdisputed | `## Baseline And Requirement Detail`; retain the task-blocking Requirement Ready Check above |\n| A new surface or new owner is proposed | `## New-Surface And Architecture Detail`; run `Existence Check` and `docs\u002Fcurrent\u002FAEGIS_MINIMALITY_REFERENCE.md` before tasks, reusing an existing owner when sufficient |\n| Owner\u002Fcontract, responsibility overlap, higher-level simplification, fallback or retirement remains risky | `## New-Surface And Architecture Detail`; use `Architecture Integrity Lens` and `first-principles-review` before decomposition |\n| Material file-size, mixed-owner, add-in-place, adapter, fallback or shared-core complexity pressure appears | `## Complexity Detail`; use `Plan-Time Complexity Check` and `Complexity Budget`. An over-budget result must change the boundary, add governance work, or stop for follow-up |\n| Long-running, handoff-prone, subagent-driven, high-risk architecture\u002Fcontract\u002Fcompatibility\u002Fretirement handoff | `## Execution Readiness Detail`; expand the existing plan inputs into the auditable readiness view |\n| Saving requires workspace initialization or `INDEX.md` updates | `## Workspace Save Detail` |\n| Execution-route evidence needs a structured handoff | `## Execution Route Detail` |\n| An independent high-risk or handoff-heavy review is needed | `## Expanded Plan Review` |\n\nThe reference supplies detail only. This main file owns routing, plan versus\nPlanless selection, task blocking, and execution handoff.\n\nIf the plan must choose among deleting an old internal path, retaining a proven\nexternal compatibility boundary, or stopping for persistent-state\nconfirmation, compose `anti-entropy-governance`. It does not authorize\ndestructive execution.\n\nPreserve approved ADR signal preservation, source refs, alternatives,\ncompatibility, and baseline-sync questions for completion; do not create\naccepted architecture memory from an unexecuted plan.\n\n## Plan And Task Quality\n\nMap files before tasks. Follow existing ownership and naming. For non-trivial\nplans, passively use relevant current terms from `CONTEXT-MAP.md` or `CONTEXT.md`;\nroute a real semantic conflict to `establishing-project-context`.\n\nEvery durable plan starts with Goal, Architecture, Tech Stack,\nBaseline\u002FAuthority Refs, Compatibility Boundary, TDD Route, and Verification.\nThen define small, ordered tasks with exact files, purpose, minimum necessary\nchange, compatibility impact, and commands\u002Foutcomes that prove the task.\nInclude code excerpts only when a signature, contract, or transformation would\notherwise remain ambiguous; do not duplicate the implementation inside the\nplan.\n\nFor bug fixes, refactors, contract changes, or governance cleanup, keep Repair\nTrack and Retirement Track explicit in the affected task. A retained old owner\nor fallback needs a reason and retirement trigger.\n\nSelf-review once for approved-scope coverage, placeholders, owner\u002Ftype\nconsistency, minimum change boundary, compatibility, exact verification,\nconditional trigger handling, and retirement. Fix defects inline. Tasks are\nexecution units, not Git history units: the coordinator captures\n`TaskStartSnapshot` and creates one scoped commit only after the whole Task is\nreviewed and freshly verified.\n\n## Execution Handoff\n\nThe agent owns the execution-route decision. Select `subagent-driven` only for\ngenuinely independent tasks with bounded ownership when coordination pays for\nit; otherwise select `inline`. Unavailable subagents falls back to inline execution. A dirty workspace alone does not select either route.\n\nAsk the user only for unresolved authorization, privacy, paid-resource,\nexternal-action, irreversible-action, scope, acceptance, or workspace-ownership\nboundaries. Otherwise proceed immediately. State the decision, evidence,\nfallback, and `User confirmation required: no | yes — \u003Cboundary>` compactly;\nload the reference only when the full `Execution Route` schema is useful.\n\nFor `subagent-driven`, use `aegis:subagent-driven-development`. For `inline`,\nuse `aegis:executing-plans`.\n","\u003CEXPLICIT-MODE-GATE>\nIf activation mode is explicit (`~\u002F.config\u002Faegis\u002Fconfig.toml` has\n`activation_mode = \"explicit\"`, or `AEGIS_ACTIVATION_MODE=explicit` is visible\nin the environment) and the current user request did not explicitly invoke\nAegis or this skill by name, exit back to the fast path: answer concisely\nwithout this workflow's checklist, ceremony, or document requirements. If the\nuser explicitly named Aegis or this skill, proceed normally.\n\u003C\u002FEXPLICIT-MODE-GATE>\n\n# Execute\n\n→ Existing parent plan\u002Fspec and a tiny execution slice? → **Use Planless Slice Lane.**\n→ Mechanical or bounded change with no durable boundary (no new owner,\n  contract, schema, public API, migration, or compat surface)? → **Use\n  Planless Slice Lane without a parent document.**\n→ Approved spec\u002Frequirements for a new workstream or an escalation trigger? →\n  **Write an implementation plan for an engineer with no prior task context.**\n\nFor a durable plan: confirm scope and acceptance, map current owners\u002Ffiles,\nrecord the TDD route, decompose into executable tasks, define verification and\nretirement, self-review, save, then select the execution route. Proceed unless\na real authorization or safety boundary requires the user.\n\nBind tasks to the requested user outcomes: object, actions, conditions, and\ndeliverables. Include the final delivery step and evidence at the user-visible\nseam, not only implementation\u002Ftests. Keep unmet needs and dependencies explicit;\nproject-wide goals do not authorize work outside this request. Reuse the\nexisting scope\u002Facceptance slots; no extra goal artifact is required.\n\nThis plan is method-pack guidance, not authoritative completion.\n\n## TDD Route Guard\n\nBefore task decomposition, record `TDD Route` with mode (`off | auto`), decision\n(`strict | light | skipped`), authority, test posture, reason, and verification.\n\nStrict RED \u002F GREEN steps belong only to an explicit user\u002Fproject TDD request or\n`TDD Route: strict`. In `off`, use `skipped` unless explicit strict authority\noverrides it. An approved plan or a risk label alone is not strict authority.\n\nIn `auto`, select `strict` for behavior, bugfix, shared\u002Fcore, contract,\npersistence, permission, migration, producer\u002Fconsumer, or meaningful\nregression signals. Select `light` only when the work is tiny, low-risk,\nsingle-owner, has no behavior change or strict signal, and has an obvious\nfocused check. Absence of an explicit user TDD request is never evidence for\n`light`; the auto decision itself must be recorded.\n\nIf risk remains unknown, return to requirements, debugging, or plan review\nbefore task decomposition; do not infer a TDD route from uncertainty.\n\nOnly a `strict` decision with stated authority may prescribe failing-test,\nRED, GREEN, and REFACTOR steps. Otherwise plan the minimum change plus\ndiagnostic reproduction or post-change regression. A missing auto decision\nreturns to route selection before implementation tasks.\n\n## Entry And Artifact Choice\n\n**Announce at start:** on the plan-writing route, say that this skill is\ncreating the implementation plan. On `Planless Slice Lane`, announce the lane instead and do not claim a plan is being created.\n\n**Execution context:** Reuse the current branch\u002Fworkspace by default. A branch\nneeds independent history; a worktree needs concurrent checkout, blocking\nunrelated dirty state, or explicit user\u002Frepository authority.\n\n**Input:** approved requirements, a Spec Brief, or a Design Spec.\n\n**Default plan path:** `docs\u002Faegis\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`. Plans do\nnot go in `work\u002F`; user and repository authority override the default.\n\n## Planless Slice Lane\n\nUse `Planless Slice Lane` before writing or saving a plan when one of these\nentry conditions holds:\n\n- a parent spec or parent plan already defines the workstream, and the current\n  request is executing or refining one bounded task from that parent\n- the change is mechanical or bounded and needs no parent document (the\n  no-parent branch under `# Execute`)\n\nand both of these are true:\n\n- no new owner, contract, schema, public API, architecture boundary, migration,\n  persistence, security\u002Fpermission, distribution\u002Frelease surface, or unclear\n  verification boundary appears\n- the slice can be described by a `Slice Card`\n\nThe lane preserves long-task continuity without turning execution bookkeeping\ninto durable planning artifacts. A parent scope or acceptance mismatch returns\nto the parent plan\u002Fspec instead of spawning a micro-plan.\n\nDo not save a new plan. Emit a compact `Slice Card`:\n\n```text\nSlice Card:\n- Goal:\n- Parent plan\u002Fspec:\n- Files:\n- Boundary:\n- Verification:\n- Stop:\n```\n\nOn the no-parent branch, `Parent plan\u002Fspec:` is `none — direct bounded request`.\n\n## Aegis Project Workspace\n\nWorkspace creation is lazy and follows project authority. The Aegis Method\nPack repository must not create or ship a live `docs\u002Faegis\u002F` workspace. When a\ndurable plan must initialize or update another project's workspace, read the\n`## Workspace Save Detail` section of `expanded-planning-guidance.md`. It owns the\n`\u003Caegis-workspace-helper>` and `INDEX.md` command detail, not the decision to\ncreate a plan.\n\n## Default Plan Surface\n\nCompact output contract: express these as natural plan content, not a stack of\ncards: `Aegis Visibility`, approved scope and plan basis, required baseline\nrefs, files\u002Fowners, compatibility boundary, `Change Necessity`, TDD route,\ntasks, verification, risks, and retirement. Keep conditional structures silent unless their trigger below fires.\n\n`Aegis Visibility` is normally one sentence explaining which owner, contract,\nretirement, compatibility, or verification pressure makes a durable plan\nuseful. Structured trace belongs only to audit, debug, release, long-task\nreview, or explicit request.\n\nBefore tasks, perform a `Requirement Ready Check`: identify the approved source,\nscope, scenarios, and acceptance evidence. If any decision-changing item is\nmissing, do not create implementation tasks; return the smallest gap to the\nrequirement\u002Fspec owner.\n\nPerform `Change Necessity` before any non-trivial source edit or any new source-code path. This is behavior-triggered, not prompt-triggered. State\nnaturally why no-change\u002Fdocs\u002Fconfig is insufficient and name the minimum code\nboundary. A tiny helper, guard, branch, fallback, adapter, or owner is not\nexempt. A `no-change`, `docs\u002Fconfig-only`, or `needs-clarification` result\nnarrows or stops the code plan.\n\nRun `Ripple Signal Triage` before tasks when the change touches shared\u002Fcore or\ncross-module behavior; a public API, schema, contract, compatibility,\npersistence, cache, export\u002Freadback, fallback, adapter, duplicate\u002Flegacy owner,\nretirement path, or both producer and consumer. If no signal fires, add no\noutput. If one fires, identify the canonical owner and affected downstream consumers,\nstate source-of-truth\u002Fcontract\u002Ffallback\u002Fretirement risk, and carry expanded verification\ninto the relevant task. A required owner\u002Fpublic-contract\u002Fsource-of-truth change,\nretaining two owners, or adding a fallback, adapter, or compatibility branch\nreturns to design or requires explicit prior alignment before implementation.\n\nRun a compact `Plan Pressure Test` before task decomposition: test owner \u002F contract \u002F retirement fit, higher-level architecture path, verification scope,\nand task executability. It may proceed, revise the plan, or return to design;\nit is not an approval authority.\n\n## Conditional Detailed Guidance\n\nFor interface\u002Finteraction work, compose `ui-ux-governance` and carry the accepted\nexperience criteria and corresponding checks into affected tasks. Include API\nchanges that alter visible states or recovery; keep backend-only work scoped.\n\nFor maintained source, screen file shape, owner fit, add-in-place risk, and a\nbetter boundary. With no pressure signal, a compact edit-in-place decision is\nenough. For an ordinary medium\u002Fhigh handoff, state Intent Lock, Scope Fence, Baseline Lock, tests, and drift stop naturally. Load the expanded `Execution Readiness View` only for the auditable handoff triggers below. Neither form is a\n`GateDecision`, `PolicySnapshot`, approval gate, or completion authority.\n\nRead only the trigger-matched section of `expanded-planning-guidance.md`, never\nthe whole file. This map owns conditional activation, not another planning pass.\nDo not load references merely to announce a route or describe a Planless slice.\n\n| Evidence trigger | Exact section and required action |\n| --- | --- |\n| Specific baseline acknowledgement needs structure, or requirement readiness is incomplete\u002Fdisputed | `## Baseline And Requirement Detail`; retain the task-blocking Requirement Ready Check above |\n| A new surface or new owner is proposed | `## New-Surface And Architecture Detail`; run `Existence Check` and `docs\u002Fcurrent\u002FAEGIS_MINIMALITY_REFERENCE.md` before tasks, reusing an existing owner when sufficient |\n| Owner\u002Fcontract, responsibility overlap, higher-level simplification, fallback or retirement remains risky | `## New-Surface And Architecture Detail`; use `Architecture Integrity Lens` and `first-principles-review` before decomposition |\n| Material file-size, mixed-owner, add-in-place, adapter, fallback or shared-core complexity pressure appears | `## Complexity Detail`; use `Plan-Time Complexity Check` and `Complexity Budget`. An over-budget result must change the boundary, add governance work, or stop for follow-up |\n| Long-running, handoff-prone, subagent-driven, high-risk architecture\u002Fcontract\u002Fcompatibility\u002Fretirement handoff | `## Execution Readiness Detail`; expand the existing plan inputs into the auditable readiness view |\n| Saving requires workspace initialization or `INDEX.md` updates | `## Workspace Save Detail` |\n| Execution-route evidence needs a structured handoff | `## Execution Route Detail` |\n| An independent high-risk or handoff-heavy review is needed | `## Expanded Plan Review` |\n\nThe reference supplies detail only. This main file owns routing, plan versus\nPlanless selection, task blocking, and execution handoff.\n\nIf the plan must choose among deleting an old internal path, retaining a proven\nexternal compatibility boundary, or stopping for persistent-state\nconfirmation, compose `anti-entropy-governance`. It does not authorize\ndestructive execution.\n\nPreserve approved ADR signal preservation, source refs, alternatives,\ncompatibility, and baseline-sync questions for completion; do not create\naccepted architecture memory from an unexecuted plan.\n\n## Plan And Task Quality\n\nMap files before tasks. Follow existing ownership and naming. For non-trivial\nplans, passively use relevant current terms from `CONTEXT-MAP.md` or `CONTEXT.md`;\nroute a real semantic conflict to `establishing-project-context`.\n\nEvery durable plan starts with Goal, Architecture, Tech Stack,\nBaseline\u002FAuthority Refs, Compatibility Boundary, TDD Route, and Verification.\nThen define small, ordered tasks with exact files, purpose, minimum necessary\nchange, compatibility impact, and commands\u002Foutcomes that prove the task.\nInclude code excerpts only when a signature, contract, or transformation would\notherwise remain ambiguous; do not duplicate the implementation inside the\nplan.\n\nFor bug fixes, refactors, contract changes, or governance cleanup, keep Repair\nTrack and Retirement Track explicit in the affected task. A retained old owner\nor fallback needs a reason and retirement trigger.\n\nSelf-review once for approved-scope coverage, placeholders, owner\u002Ftype\nconsistency, minimum change boundary, compatibility, exact verification,\nconditional trigger handling, and retirement. Fix defects inline. Tasks are\nexecution units, not Git history units: the coordinator captures\n`TaskStartSnapshot` and creates one scoped commit only after the whole Task is\nreviewed and freshly verified.\n\n## Execution Handoff\n\nThe agent owns the execution-route decision. Select `subagent-driven` only for\ngenuinely independent tasks with bounded ownership when coordination pays for\nit; otherwise select `inline`. Unavailable subagents falls back to inline execution. A dirty workspace alone does not select either route.\n\nAsk the user only for unresolved authorization, privacy, paid-resource,\nexternal-action, irreversible-action, scope, acceptance, or workspace-ownership\nboundaries. Otherwise proceed immediately. State the decision, evidence,\nfallback, and `User confirmation required: no | yes — \u003Cboundary>` compactly;\nload the reference only when the full `Execution Route` schema is useful.\n\nFor `subagent-driven`, use `aegis:subagent-driven-development`. For `inline`,\nuse `aegis:executing-plans`.\n",{"name":5,"description":7},"main","cebc3dce495d7eb80d3b1d5841f877a4a92e162d","plugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fwriting-plans",490,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 02:12:02",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill writing-plans",{"tool":70,"command":71},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill writing-plans",{"tool":73,"command":74},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill writing-plans","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fwriting-plans\u002FSKILL.md",true,[78,84],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"expanded-planning-guidance.md","REFERENCE","参考文档",6855,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fwriting-plans\u002Fexpanded-planning-guidance.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"plan-document-reviewer-prompt.md",1714,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FGanyuanRan\u002FAegis\u002Fskills\u002Fwriting-plans\u002Fplan-document-reviewer-prompt.md",[89,97,104,111,136,161],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":96},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":96},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":96},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":49},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[118,119,120,121,122,123,124,125,126,127,128,33,48,129,130,131,132,133,134,135],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","done","reviewer","io","change","cli","merge","past",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":49},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[143,144,145,131,146,147,148,149,150,151,152,153,154,155,123,156,157,158,159,160],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":176,"publishedAt":49},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[167,170,173],{"categoryNo":168,"categoryName":169,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":171,"categoryName":172,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":174,"categoryName":175,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[163,177,178,179,180,181,182,157,183,124,184,185,186,187,33,188,189,190,191,192],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]