[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X7P7TQ5ZSBS7FFQMQSDPCV":3,"skill-same:01M6X7P7TQ5ZSBS7FFQMQSDPCV":100},{"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":34,"publishedAt":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":68,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M6X7P7TQ5ZSBS7FFQMQSDPCV","roadmap-writing",null,"Use when authoring or rewriting a roadmap in agents\u002Froadmaps\u002F — phases, goal, acceptance criteria, council notes; fires even on 'write a plan for X' \u002F 'draft a roadmap'.","event4u-app\u002Fagent-config","event4u-app","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199339632?v=4","01M6X5TWBNCQCE1VDKT4E9KF7N","event4u.app","01M6X5TWF4HRM266RG2Q5VVH1X",19,"MIT","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Froadmap-writing\u002FSKILL.md",[18,23,26,31],{"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},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52],"roadmap writing","roadmap","writing","use","when","for","authoring","draft","acceptance criteria","goal","process","write","plan","Meta","acceptance","council","notes","config","2026-11-10 10:12:30",false,"---\nmodel_tier: inherit\nname: roadmap-writing\ndescription: \"Use when authoring or rewriting a roadmap in agents\u002Froadmaps\u002F — phases, goal, acceptance criteria, council notes; fires even on 'write a plan for X' \u002F 'draft a roadmap'.\"\ndomain: process\nworkspaces:\n  - agent-config-maintainer\npacks:\n  - meta\n---\n\n\u003C!-- cloud_safe: degrade -->\n\n# roadmap-writing\n\n## When to use\n\n* Authoring a new roadmap file in `agents\u002Froadmaps\u002F{name}.md` (or\n  module-scoped under `{module_root}\u002F{Module}\u002F{agent_folder}\u002Froadmaps\u002F` —\n  per `modules.root_paths` + `modules.agent_folder`; Laravel shape:\n  `app\u002FModules\u002F{Module}\u002Fagents\u002Froadmaps\u002F`)\n* Rewriting an existing roadmap (phase restructure, goal pivot,\n  council-pass integration — not a checkbox flip)\n* Drafting a phase block, exit criteria, or rollback section that\n  will land inside an existing roadmap — an operator **symptom** as the input has its own entry procedure: [`symptom-driven harvest`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fsymptom-driven-harvest-loop.md)\n\nDo NOT use this skill when:\n\n* Flipping checkboxes, regenerating the dashboard, archiving on\n  completion → use [`roadmap-management`](..\u002Froadmap-management\u002FSKILL.md)\n* Updating AGENTS.md \u002F module docs \u002F contexts → use\n  [`agent-docs-writing`](..\u002Fagent-docs-writing\u002FSKILL.md)\n* Capturing an architectural decision → use\n  [`adr-create`](..\u002Fadr-create\u002FSKILL.md)\n\n## Roadmap-writing vs roadmap-management — critical test\n\n| Intent | Artifact |\n|---|---|\n| \"I need to write the plan body\" | **roadmap-writing** (this skill) |\n| \"I need to track progress \u002F regenerate dashboard \u002F archive\" | **roadmap-management** |\n\nThis skill owns the **prose authoring** axis: structure, goal\nsentence, phase blocks, acceptance criteria. The execution and\ndashboard-sync axis stays in `roadmap-management`.\n\n## Procedure\n\n### 0. Drafting protocol\n\nAuthoring or materially rewriting a roadmap must go through\nUnderstand → Research → Draft per the\n[`artifact-drafting-protocol`](..\u002F..\u002Frules\u002Fartifact-drafting-protocol.md)\nrule. **Run the probe, do not eyeball the directory:**\n\n```bash\nagent-config roadmap:context\n```\n\nIt reports sibling roadmaps on the same topic across all four roadmap\ndirectories, inbox notes, and open PRs on the cited paths — the semantic axis a\nfilename scan cannot see. Each hit becomes one `relates:` row\n(`extends` \u002F `supersedes` \u002F `depends` \u002F `disjoint`, template rule 18); zero hits\nbecomes `relates: []` carrying the probe's `scanned:` line as its\njustification. **Gate C first** — \"write a\nplan\u002Froadmap\" is a gated surface, so run\n[`plan-confidence-gate`](..\u002F..\u002Fcontexts\u002Fexecution\u002Fplan-confidence-gate.md)\nbefore drafting (95%-conditions, marker, interview-or-degrade, C→R1 handoff).\n\n### 1. Read the canonical template first\n\nThe structure, frontmatter, lifecycle, and complexity-tier rules live\nin [`src\u002Fagent-src\u002Ftemplates\u002Froadmaps.md`](..\u002F..\u002Ftemplates\u002Froadmaps.md).\nRead it before authoring. Do not restate its rules in the roadmap\nbody — link the template if a phase needs to override one.\n\n**Naming:** a lone roadmap is `road-to-\u003Cslug>.md`. When you create **≥2\nrelated** roadmaps in one pass (siblings split from one body of work, or\na follow-up chain), give them a shared `road-to-\u003Cfamily>-\u003Cpart>.md`\nprefix so relatedness is visible and the dashboard groups them — pick\nthe `\u003Cfamily>` slug up front (template rule 21). Follow-ups additionally\ncarry `parent_roadmap:` (rule 17).\n\n### 2. Pick complexity tier honestly\n\nDefault `lightweight` (≤ 6 phases, ≤ 600 lines). Only use\n`structural` when the change touches a contract, kernel rule, or\nbudget invariant — the complexity linter enforces it. Standard:\n[`roadmap-complexity-standard`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Froadmap-complexity-standard.md).\n\n### 3. Write the goal first\n\nOne sentence, top of file, decidable: \"Reduce X by Y on flow Z.\"\nVague goals (\"improve roadmaps\") force every reader to re-derive\nintent. If the goal needs three sentences, the roadmap is two\nroadmaps.\n\n### 3b. Scan sources for discrepancies before drafting phases\n\nWhen the roadmap originates from a ticket\u002Fspec that carries a second\nsource — an attached mockup\u002Fscreenshot, a code reality, or an internal\ncontradiction — run the **cross-source discrepancy scan** (per\n[`cross-source-consistency`](..\u002F..\u002Frules\u002Fcross-source-consistency.md))\nbefore writing phases. A phase plan\nbuilt over a text↔image contradiction or a silent-but-needed behavior\n(weekend\u002Fholiday shift, empty\u002Ferror state) bakes the wrong assumption into\nevery downstream step. Surface each discrepancy as one batched open\nquestion first; an inferred behavior is a scope expansion to confirm, not\nto plan silently. Taxonomy + procedure:\n[`cross-source-consistency-mechanics`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fcross-source-consistency-mechanics.md).\n\n### 4. Phase blocks carry checkboxes\n\nEvery non-intro phase contains at least one `- [ ]`. Decision tables\nand council-pass notes capture the *why*; checkboxes capture the\n*what to do next*. Without checkboxes the phase is invisible to\n`agents\u002Froadmaps-progress.md` — enforced by\n[`roadmap-progress-sync`](..\u002F..\u002Frules\u002Froadmap-progress-sync.md)\nIron Law #2.\n\n**Bind a `verify:` on behavior-changing steps.** A step that changes\nbehavior (a new guard, a migration, a wired endpoint, a mechanism edit)\nSHOULD carry a narrow `verify:` command in an inline annotation —\n`- [ ] Wire the guard \u003C!-- verify: task test -- --filter=GuardTest -->`\n— so its `[x]` flip is machine-checkable, not just agent-asserted (template\nrule 23; enforced by the flip-guard). Bind it only where a single narrow\ncommand (targeted test \u002F grep \u002F build of the touched surface) proves the\nstep; leave it off doc-only \u002F prose steps and never make it the full CI\nsuite (`roadmap-ci-steps-policy`).\n\n### 4b. Declare the execution mode (frontmatter)\n\nEvery new roadmap declares how a later `\u002Froadmap:process-*` run should\ninteract, via `execution.mode:` in frontmatter — `autonomous` (one\nrun-start execution-contract confirmation, then uninterrupted except\nsafety floors), `phase-checkpoints` (halt + compact status per phase\nboundary), or `interactive` (declare it — an omitted field is derived).\nSemantics: [`templates\u002Froadmaps.md` rule 18](..\u002F..\u002Ftemplates\u002Froadmaps.md);\nrun mechanics:\n[`roadmap-execution-contract`](..\u002F..\u002Fcontexts\u002Fexecution\u002Froadmap-execution-contract.md).\nThe field is intent, never a permission grant — grants happen only at\nthe run-start contract. `\u002Froadmap:create` asks this as one question;\nwhen authoring a roadmap directly, ask it too (follow-ups pre-select\nthe parent's mode but always re-ask). **Author every roadmap to be\nautonomy-capable (§ 4c); recommend `autonomous`** when evidence,\nrollback coverage, and risk profile support unattended execution —\nthe mode remains the user's risk preference, not a property of the\ndocument. **Authoring duty for `autonomous`:** steps must be precise\nenough to clear the\n`ask-when-uncertain` vague-trigger patterns — vagueness is resolved at\nauthoring time, not mid-run; pre-existing `[~]` items in an\n`autonomous` roadmap draw a lint warning (they guarantee the archival\ngate fires later).\n\n### 4c. Autonomy-first — zero human gates by default\n\nCanonical rule:\n[`templates\u002Froadmaps.md` rule 22](..\u002F..\u002Fagent-src\u002Ftemplates\u002Froadmaps.md).\nDefault human-checkpoint count: **zero**. Every step is\nagent-executable — `- [ ] User verifies X` steps and \"Review \u002F\nSign-off\" phases are authoring bugs; replace each with an\nagent-verifiable check (a command, a targeted test, a grep). Never\nrestate run-time safety floors as steps.\n\nGate-test — three rungs in order (rule 22 owns the detail): **1.** agent-clearable\nby tool\u002Fcommand → step. **2.** has a technical answer a council could reach → still\na step, first action runs the council; a contested *technical* decision is never a\nhuman gate while one is configured (`agent-config council:status`). **3.** what\nsurvives both → `## Blockers` (§ 5b): **human gate** (only a human can\ndecide\u002Fauthorize — Hard-Floor authorization, billable spend, or preference \u002F risk\nappetite \u002F product intent) vs **external blocker** (agent cannot resolve but CAN\nprobe status — CI run, package release, upstream PR; `Resolved when:` carries the probe, owner is not a human). Merge is never a completion requirement — it may appear\nas a blocker only when later roadmap work depends on the merged state.\n`lint_roadmap_complexity` warns on human-gate patterns in every mode.\n\n### 5. Exit & rollback per phase\n\nEach phase declares **exit criteria** (decidable signals that the\nphase is done) and **rollback** (what to revert if the phase fails).\nA phase without exit criteria is open-ended; a phase without rollback\nassumes success. Exit criteria are **agent-decidable** — exit code,\nfile exists, test passes — never \"user reviews\" \u002F \"looks good\" (§ 4c).\n\n### 5b. Blockers are structured, not free prose\n\nA gate only the user or a maintainer can clear — a decision, an\nexternal dependency, an evidence threshold, a kernel-budget soak\nwindow — is recorded as a `## Blockers` entry (`### blocker: \u003Cid>` with the\nseven fields of rule 20), never a stray \"blocked on X\" sentence. Write it so\nthe owner can decide in one sitting: one option named and why, what the delay\ncosts, a command or path per option rather than prose, and an offer to walk\nthem through it. Ratcheted by `lint_roadmap_blockers`. Full shape:\n[`templates\u002Froadmaps.md` rule 20](..\u002F..\u002Fagent-src\u002Ftemplates\u002Froadmaps.md).\nOmit it entirely when there is no such gate; run the § 4c gate-test first. A **hold** is the publication-side twin — a blocker stops execution, a hold stops publication; ask once whether an intermediate tree state must stay unpublished (default **no**; roadmap incompleteness never is one), walk `re-sequence → guard → hold`, and record the avoided outcome as well as the taken one, per [`templates\u002Froadmaps.md` rule 28](..\u002F..\u002Fagent-src\u002Ftemplates\u002Froadmaps.md) and the § 5c self-check in [`\u002Froadmap:create`](..\u002F..\u002Fdomains\u002Fproduct-basic\u002Froadmap\u002Fcreate\u002Fcommand.md).\n\n### 5c. Risk review (Gate R1) — after draft, before save\n\n- Ready (non-draft) plan → `## Risk Register` before save, self-review; seed\n  from a fresh C→R1 handoff state (never re-ask a resolved branch).\n- Product AND implementation risks ranked descending, one mitigation per row,\n  each anchored to a phase\u002Fstep here; none → exact honest-null grammar.\n- Schema, staleness, grandfather, drafts-exempt: [`plan-review-gates § 1`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Fplan-review-gates.md).\n\n### 6. Step-marker semantics — pick `[~]` (defer) vs `[-]` (cancel) honestly\n\nWhen authoring (and especially when rewriting a roadmap mid-flight),\nthe difference between the two non-`[x]`-non-`[ ]` markers carries\nload:\n\n| Glyph | Semantic | When to use |\n|---|---|---|\n| `[~]` | **deferred** — planned, will be done, just not in this roadmap | Scope-cut + clear intent to revisit. Triggers the Iron Law 3 follow-up flow before archive — info preservation is enforced. |\n| `[-]` | **cancelled** — won't be done at all | Scope rejected, design changed, replaced by another roadmap. The decision is final; no follow-up implied. |\n\nOptional inline annotations live on the same line:\n\n```markdown\n- [~] Migrate the bulk-import job to chunked dispatch. \u003C!-- deferred: ops capacity in Q3 -->\n- [-] Wire SQS retry topic. \u003C!-- cancelled: superseded by Lambda DLQ in road-to-event-bridge -->\n```\n\nThe annotation is for the next human reader (and for the migration\nprocedure when [`roadmap-management`](..\u002Froadmap-management\u002FSKILL.md)\nspawns a follow-up). Bare `[~]` \u002F `[-]` is allowed; annotated is\npreferred.\n\n#### A prohibition-shaped step closes with `[x]`\n\nA step whose content is a **prohibition** (*\"Do not build the enforcement\"*) has\nno artifact to point at. `[~]` invents receiver work nobody owes, `[-]` mislabels\nrestraint as cancellation, `[ ]` makes an honoured bounded obligation\nunarchivable. It closes with **`[x]`** — the obligation was discharged, and `[x]`\nnever required that something was created. Its `verify:` must name every\nimplementation, registration and semantically-equivalent surface (a structural\ncheck, not one literal grep, which misses aliases and generated code); **fail if\nan expected search root is missing**, checked BEFORE the absence check, because a\nglob over a vanished directory returns nothing and reads as success; scope the\nclaim to the branch diff — *\"this change introduced no enforcement\"*, never the\nunprovable *\"enforcement exists nowhere\"*; and be re-run at archival. Not for a\nprohibition meant to hold indefinitely — that belongs in a rule, test or linter,\nbecause a closed step stops watching. Council convention, 2026-09-08 (2 seats,\nconvergent); falsified if tooling defines `[x]` as requiring a positive mutation.\n\n### 7. Follow-up roadmaps spawn from deferred items — frontmatter shape\n\nWhen a parent roadmap closes with `[~]` items, the\n[`roadmap-management`](..\u002Froadmap-management\u002FSKILL.md) skill spawns a\nfollow-up. Authors and reviewers must know the shape so they can recognise it:\nthe frontmatter template, the two states the author picks between\n(`status: draft`, hidden from the dashboard, vs the default `status: ready`\nplus a body `> Blocked until …` note), and the rule that deferred steps are\ncopied verbatim rather than re-authored →\n[`references\u002Ffollow-up-roadmap-shape.md`](references\u002Ffollow-up-roadmap-shape.md).\n\n### 8. Source-derived & capability-adoption roadmaps (conditional)\n\nFires **only** when the roadmap originates from an external input\n(competitive\u002Fcapability harvest, external suggestion, external LLM\nideation) or adopts new skills\u002Fcommands\u002Fa pack, or has genuinely\ncontested trade-offs. For an ordinary internally-originated roadmap,\n**skip this section** — §§ 0–7 are the whole job.\n\nWhen it fires, add four moves — a gap-table before drafting (KEEP\u002FFOLD\u002FCUT,\nintegrate don't dump), resolve contested design in the council *first*\nthen author, encode the decision so it survives (Council notes +\nneutral-descriptor Provenance + memory lock), and make \"integration, not\ndump\" a testable acceptance criterion. Full four-move detail →\n[`roadmap-writing-source-derived`](..\u002F..\u002Fagent-src\u002Fcontexts\u002Fexecution\u002Froadmap-writing-source-derived.md).\n\n## Output format\n\nA single Markdown file at `agents\u002Froadmaps\u002F{name}.md`:\n\n1. Frontmatter (`status`, `complexity`)\n2. `# Road to {short title}`\n3. One-sentence outcome blockquote\n4. `## Goal` — decidable target\n5. `## Prerequisites` — checkboxes\n6. `## Context` — why now, links to tickets\n7. Numbered `## Phase N — {name}` sections with checkboxes,\n   exit criteria, rollback\n8. `## Acceptance criteria` — final gates\n\n## Frugality Standards\n\nApply the [Frugality Charter](..\u002F..\u002Fcontexts\u002Fcontracts\u002Ffrugality-charter.md)\nto every roadmap you author.\n\n**Examples in this artifact:**\n- Per the charter's default-terse rule, the goal sentence states the\n  outcome — no \"This roadmap exists because…\" ramp-up.\n- Per the cite-don't-restate principle, link the canonical template\n  for structural rules; do not paste them into the roadmap.\n- Per the post-action summary suppression, council-pass integration\n  notes append to the existing phase block — no new \"Summary of\n  council passes\" section.\n- Per the cheap-question check, never propose a \"lightweight vs.\n  structural\" numbered choice when the diff makes the answer\n  decidable.\n\n**Pre-save self-check:**\n1. Does the goal sentence open with the outcome, or with backstory?\n2. Does any phase block restate template rules instead of linking\n   them?\n3. Are checkboxes present in every non-intro phase?\n4. Are exit criteria decidable, or vibe-based (\"looks good\")?\n5. Is content duplicated from another roadmap (supersession instead)?\n5b. Does the frontmatter carry a `relates:` block — one row per probe hit with\n   an `extends`\u002F`supersedes`\u002F`depends`\u002F`disjoint` relation, or an explicit\n   `relates: []` whose note carries the probe's `scanned:` line? A `relates:`\n   list written by reflex is worse than none: the empty case must be genuinely\n   empty, not unexamined.\n6. Any human-gate steps or sign-off phases (§ 4c violation) —\n   agent-verifiable check or structured blocker instead?\n7. *Source-derived\u002Fadoption only (§ 8):* is there a `KEEP`\u002F`FOLD`\u002F`CUT`\n   gap-table behind the scope, a `## Provenance` block with an `ENC1:`\n   link, inlined council convergence, and an anti-dump acceptance\n   criterion? (Internally-originated roadmap → these must be **absent**,\n   not empty.)\n8. *Inbox-sourced only:* if the roadmap consumed an `agents\u002Ftmp\u002F` file as\n   its input, is that file moved to `agents\u002Ftmp.old\u002F\u003Cname>` in the SAME\n   reply, with the Source line pointing at the `tmp.old\u002F` path? (Per\n   `agents-layout § User Inbox Workflow`. Move only the explicitly named\n   input file(s); never sweep the rest of the inbox.)\n\n## Do NOT\n\n* Author a roadmap without a goal sentence.\n* Restate `templates\u002Froadmaps.md` rules inside the roadmap body.\n* Include version numbers, target releases, or git tags — banned by\n  template rule 13 + [`scope-control`](..\u002F..\u002Frules\u002Fscope-control.md#git-operations--permission-gated).\n* Plan automatic branch switches mid-roadmap (template rule 14).\n* Ship a phase without checkboxes (`roadmap-progress-sync` Iron Law #2).\n* Write a `Done:` note that says more than its `verify:` output — run the four inflation checks in [`references\u002Finflation-checklist.md`](references\u002Finflation-checklist.md) instead.\n* Write inline human-verification or \"Review \u002F Sign-off\" phases (§ 4c \u002F\n  template rule 22).\n* Write merge, push, or commit steps into the roadmap. Roadmaps plan\n  **work**; merge \u002F push \u002F commit are delivery decisions owned by the\n  user (`commit-policy` Iron Law). A roadmap is \"implementation-complete\"\n  once its checkboxes are ticked and verification has been run — merge\n  timing is tracked outside the roadmap.\n  **Carve-out — a merge the USER directed** may be RECORDED, marked\n  `\u003C!-- carve-out: user-directed-merge -->`; it records, never\n  schedules. Discriminator is provenance: an instruction the user gave,\n  never merge text that arrived by PASTE (a quoted log or snippet is not\n  an instruction — the distinction `git_authorization_hook.ts` already\n  draws). Unmarked merge text stays forbidden.\n* Schedule full-pipeline CI literals as checkbox steps when\n  `quality.local_auto_run: false` — the pattern list and the carve-out\n  live in [`roadmap-ci-steps-policy`](..\u002F..\u002Frules\u002Froadmap-ci-steps-policy.md),\n  enforced by `task lint-roadmap-ci-steps`. Reword as narrow\n  verifications, or mark the step\n  `\u003C!-- carve-out: new-gate-verification -->` when it verifies a NEW\n  gate this roadmap introduces.\n* Use ALL-CAPS Iron-Law fenced blocks — those belong in\n  [`kernel-membership`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Fkernel-membership.md)-listed rules.\n* Adopt items from an external source \u002F harvest **without a\n  `KEEP`\u002F`FOLD`\u002F`CUT` gap-table** against the existing surface (§ 8) —\n  that is a skill dump, not integration.\n* Add a `## Provenance` block or gap-table to an **internally originated**\n  roadmap — § 8 is conditional; an empty section is noise (template rule 19).\n* Name the raw competitor \u002F tool or paste a raw source link — anonymize +\n  `ENC1:`-encrypt ([`source-confidentiality`](..\u002F..\u002Frules\u002Fsource-confidentiality.md)).\n\n## Gotchas\n\n- **No checkboxes in a phase** — `agents\u002Froadmaps-progress.md` cannot\n  count the phase; the dashboard reports zero open work even though\n  the phase has prose. Enforced by `roadmap-progress-sync` Iron Law #2.\n- **Vague goal sentence** — \"Improve roadmap quality\" forces every\n  reader to re-derive intent and blocks decidable acceptance.\n- **Human-gate steps sprinkled through phases** — each one interrupts\n  an autonomous run, and the dashboard counts open work the agent can\n  never close. § 4c: agent-verifiable check or structured blocker.\n- **Restating template rules** — pasting structural rules into the\n  roadmap body creates two sources of truth that drift over months.\n- **Version numbers in phase names** — `Phase 1 — v1.8.0` violates\n  template rule 13 and `scope-control § git-operations`.\n- **Author-during-execution branch switches** — the agent should not\n  propose a new branch mid-roadmap; that decision is fenced to\n  authoring time.\n- **Merge \u002F commit steps in roadmap body** — checkboxes like\n  \"merge PR #X\" or \"commit phase Y\" couple roadmap closure to git\n  operations the user has not authorized. Roadmap completion is\n  decoupled from delivery; ship-the-PR is its own decision.\n- **Adopting an external suggestion verbatim** — a harvest\u002Fsuggestion\n  roadmap that copies the source's proposed item list without the § 8\n  `KEEP`\u002F`FOLD`\u002F`CUT` audit becomes a skill dump: items that already\n  exist get rebuilt, items that should fold into an existing artefact\n  spawn a duplicate. The gap-table is the integration discipline.\n- **Council-as-afterthought** — running the council only *after* a\n  contested roadmap is written wastes the convergence: the plan still\n  reads as open questions. For source-derived\u002Fcontested plans, council\n  *first* (§ 8.B), then author the verdicts.\n\n## Examples & the \"already tried?\" check\n\nBrowse `agents\u002Froadmaps\u002F` (active set) for canonical structural \u002F tactical examples. For closed\nwork — and for every already-tried \u002F closed \u002F refuted question — read the generated `INDEX.md` in\n`agents\u002Froadmaps\u002Farchive\u002F` first; open an archived file only for a row it marks `not-extractable`.\n","\u003C!-- cloud_safe: degrade -->\n\n# roadmap-writing\n\n## When to use\n\n* Authoring a new roadmap file in `agents\u002Froadmaps\u002F{name}.md` (or\n  module-scoped under `{module_root}\u002F{Module}\u002F{agent_folder}\u002Froadmaps\u002F` —\n  per `modules.root_paths` + `modules.agent_folder`; Laravel shape:\n  `app\u002FModules\u002F{Module}\u002Fagents\u002Froadmaps\u002F`)\n* Rewriting an existing roadmap (phase restructure, goal pivot,\n  council-pass integration — not a checkbox flip)\n* Drafting a phase block, exit criteria, or rollback section that\n  will land inside an existing roadmap — an operator **symptom** as the input has its own entry procedure: [`symptom-driven harvest`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fsymptom-driven-harvest-loop.md)\n\nDo NOT use this skill when:\n\n* Flipping checkboxes, regenerating the dashboard, archiving on\n  completion → use [`roadmap-management`](..\u002Froadmap-management\u002FSKILL.md)\n* Updating AGENTS.md \u002F module docs \u002F contexts → use\n  [`agent-docs-writing`](..\u002Fagent-docs-writing\u002FSKILL.md)\n* Capturing an architectural decision → use\n  [`adr-create`](..\u002Fadr-create\u002FSKILL.md)\n\n## Roadmap-writing vs roadmap-management — critical test\n\n| Intent | Artifact |\n|---|---|\n| \"I need to write the plan body\" | **roadmap-writing** (this skill) |\n| \"I need to track progress \u002F regenerate dashboard \u002F archive\" | **roadmap-management** |\n\nThis skill owns the **prose authoring** axis: structure, goal\nsentence, phase blocks, acceptance criteria. The execution and\ndashboard-sync axis stays in `roadmap-management`.\n\n## Procedure\n\n### 0. Drafting protocol\n\nAuthoring or materially rewriting a roadmap must go through\nUnderstand → Research → Draft per the\n[`artifact-drafting-protocol`](..\u002F..\u002Frules\u002Fartifact-drafting-protocol.md)\nrule. **Run the probe, do not eyeball the directory:**\n\n```bash\nagent-config roadmap:context\n```\n\nIt reports sibling roadmaps on the same topic across all four roadmap\ndirectories, inbox notes, and open PRs on the cited paths — the semantic axis a\nfilename scan cannot see. Each hit becomes one `relates:` row\n(`extends` \u002F `supersedes` \u002F `depends` \u002F `disjoint`, template rule 18); zero hits\nbecomes `relates: []` carrying the probe's `scanned:` line as its\njustification. **Gate C first** — \"write a\nplan\u002Froadmap\" is a gated surface, so run\n[`plan-confidence-gate`](..\u002F..\u002Fcontexts\u002Fexecution\u002Fplan-confidence-gate.md)\nbefore drafting (95%-conditions, marker, interview-or-degrade, C→R1 handoff).\n\n### 1. Read the canonical template first\n\nThe structure, frontmatter, lifecycle, and complexity-tier rules live\nin [`src\u002Fagent-src\u002Ftemplates\u002Froadmaps.md`](..\u002F..\u002Ftemplates\u002Froadmaps.md).\nRead it before authoring. Do not restate its rules in the roadmap\nbody — link the template if a phase needs to override one.\n\n**Naming:** a lone roadmap is `road-to-\u003Cslug>.md`. When you create **≥2\nrelated** roadmaps in one pass (siblings split from one body of work, or\na follow-up chain), give them a shared `road-to-\u003Cfamily>-\u003Cpart>.md`\nprefix so relatedness is visible and the dashboard groups them — pick\nthe `\u003Cfamily>` slug up front (template rule 21). Follow-ups additionally\ncarry `parent_roadmap:` (rule 17).\n\n### 2. Pick complexity tier honestly\n\nDefault `lightweight` (≤ 6 phases, ≤ 600 lines). Only use\n`structural` when the change touches a contract, kernel rule, or\nbudget invariant — the complexity linter enforces it. Standard:\n[`roadmap-complexity-standard`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Froadmap-complexity-standard.md).\n\n### 3. Write the goal first\n\nOne sentence, top of file, decidable: \"Reduce X by Y on flow Z.\"\nVague goals (\"improve roadmaps\") force every reader to re-derive\nintent. If the goal needs three sentences, the roadmap is two\nroadmaps.\n\n### 3b. Scan sources for discrepancies before drafting phases\n\nWhen the roadmap originates from a ticket\u002Fspec that carries a second\nsource — an attached mockup\u002Fscreenshot, a code reality, or an internal\ncontradiction — run the **cross-source discrepancy scan** (per\n[`cross-source-consistency`](..\u002F..\u002Frules\u002Fcross-source-consistency.md))\nbefore writing phases. A phase plan\nbuilt over a text↔image contradiction or a silent-but-needed behavior\n(weekend\u002Fholiday shift, empty\u002Ferror state) bakes the wrong assumption into\nevery downstream step. Surface each discrepancy as one batched open\nquestion first; an inferred behavior is a scope expansion to confirm, not\nto plan silently. Taxonomy + procedure:\n[`cross-source-consistency-mechanics`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fcross-source-consistency-mechanics.md).\n\n### 4. Phase blocks carry checkboxes\n\nEvery non-intro phase contains at least one `- [ ]`. Decision tables\nand council-pass notes capture the *why*; checkboxes capture the\n*what to do next*. Without checkboxes the phase is invisible to\n`agents\u002Froadmaps-progress.md` — enforced by\n[`roadmap-progress-sync`](..\u002F..\u002Frules\u002Froadmap-progress-sync.md)\nIron Law #2.\n\n**Bind a `verify:` on behavior-changing steps.** A step that changes\nbehavior (a new guard, a migration, a wired endpoint, a mechanism edit)\nSHOULD carry a narrow `verify:` command in an inline annotation —\n`- [ ] Wire the guard \u003C!-- verify: task test -- --filter=GuardTest -->`\n— so its `[x]` flip is machine-checkable, not just agent-asserted (template\nrule 23; enforced by the flip-guard). Bind it only where a single narrow\ncommand (targeted test \u002F grep \u002F build of the touched surface) proves the\nstep; leave it off doc-only \u002F prose steps and never make it the full CI\nsuite (`roadmap-ci-steps-policy`).\n\n### 4b. Declare the execution mode (frontmatter)\n\nEvery new roadmap declares how a later `\u002Froadmap:process-*` run should\ninteract, via `execution.mode:` in frontmatter — `autonomous` (one\nrun-start execution-contract confirmation, then uninterrupted except\nsafety floors), `phase-checkpoints` (halt + compact status per phase\nboundary), or `interactive` (declare it — an omitted field is derived).\nSemantics: [`templates\u002Froadmaps.md` rule 18](..\u002F..\u002Ftemplates\u002Froadmaps.md);\nrun mechanics:\n[`roadmap-execution-contract`](..\u002F..\u002Fcontexts\u002Fexecution\u002Froadmap-execution-contract.md).\nThe field is intent, never a permission grant — grants happen only at\nthe run-start contract. `\u002Froadmap:create` asks this as one question;\nwhen authoring a roadmap directly, ask it too (follow-ups pre-select\nthe parent's mode but always re-ask). **Author every roadmap to be\nautonomy-capable (§ 4c); recommend `autonomous`** when evidence,\nrollback coverage, and risk profile support unattended execution —\nthe mode remains the user's risk preference, not a property of the\ndocument. **Authoring duty for `autonomous`:** steps must be precise\nenough to clear the\n`ask-when-uncertain` vague-trigger patterns — vagueness is resolved at\nauthoring time, not mid-run; pre-existing `[~]` items in an\n`autonomous` roadmap draw a lint warning (they guarantee the archival\ngate fires later).\n\n### 4c. Autonomy-first — zero human gates by default\n\nCanonical rule:\n[`templates\u002Froadmaps.md` rule 22](..\u002F..\u002Fagent-src\u002Ftemplates\u002Froadmaps.md).\nDefault human-checkpoint count: **zero**. Every step is\nagent-executable — `- [ ] User verifies X` steps and \"Review \u002F\nSign-off\" phases are authoring bugs; replace each with an\nagent-verifiable check (a command, a targeted test, a grep). Never\nrestate run-time safety floors as steps.\n\nGate-test — three rungs in order (rule 22 owns the detail): **1.** agent-clearable\nby tool\u002Fcommand → step. **2.** has a technical answer a council could reach → still\na step, first action runs the council; a contested *technical* decision is never a\nhuman gate while one is configured (`agent-config council:status`). **3.** what\nsurvives both → `## Blockers` (§ 5b): **human gate** (only a human can\ndecide\u002Fauthorize — Hard-Floor authorization, billable spend, or preference \u002F risk\nappetite \u002F product intent) vs **external blocker** (agent cannot resolve but CAN\nprobe status — CI run, package release, upstream PR; `Resolved when:` carries the probe, owner is not a human). Merge is never a completion requirement — it may appear\nas a blocker only when later roadmap work depends on the merged state.\n`lint_roadmap_complexity` warns on human-gate patterns in every mode.\n\n### 5. Exit & rollback per phase\n\nEach phase declares **exit criteria** (decidable signals that the\nphase is done) and **rollback** (what to revert if the phase fails).\nA phase without exit criteria is open-ended; a phase without rollback\nassumes success. Exit criteria are **agent-decidable** — exit code,\nfile exists, test passes — never \"user reviews\" \u002F \"looks good\" (§ 4c).\n\n### 5b. Blockers are structured, not free prose\n\nA gate only the user or a maintainer can clear — a decision, an\nexternal dependency, an evidence threshold, a kernel-budget soak\nwindow — is recorded as a `## Blockers` entry (`### blocker: \u003Cid>` with the\nseven fields of rule 20), never a stray \"blocked on X\" sentence. Write it so\nthe owner can decide in one sitting: one option named and why, what the delay\ncosts, a command or path per option rather than prose, and an offer to walk\nthem through it. Ratcheted by `lint_roadmap_blockers`. Full shape:\n[`templates\u002Froadmaps.md` rule 20](..\u002F..\u002Fagent-src\u002Ftemplates\u002Froadmaps.md).\nOmit it entirely when there is no such gate; run the § 4c gate-test first. A **hold** is the publication-side twin — a blocker stops execution, a hold stops publication; ask once whether an intermediate tree state must stay unpublished (default **no**; roadmap incompleteness never is one), walk `re-sequence → guard → hold`, and record the avoided outcome as well as the taken one, per [`templates\u002Froadmaps.md` rule 28](..\u002F..\u002Fagent-src\u002Ftemplates\u002Froadmaps.md) and the § 5c self-check in [`\u002Froadmap:create`](..\u002F..\u002Fdomains\u002Fproduct-basic\u002Froadmap\u002Fcreate\u002Fcommand.md).\n\n### 5c. Risk review (Gate R1) — after draft, before save\n\n- Ready (non-draft) plan → `## Risk Register` before save, self-review; seed\n  from a fresh C→R1 handoff state (never re-ask a resolved branch).\n- Product AND implementation risks ranked descending, one mitigation per row,\n  each anchored to a phase\u002Fstep here; none → exact honest-null grammar.\n- Schema, staleness, grandfather, drafts-exempt: [`plan-review-gates § 1`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Fplan-review-gates.md).\n\n### 6. Step-marker semantics — pick `[~]` (defer) vs `[-]` (cancel) honestly\n\nWhen authoring (and especially when rewriting a roadmap mid-flight),\nthe difference between the two non-`[x]`-non-`[ ]` markers carries\nload:\n\n| Glyph | Semantic | When to use |\n|---|---|---|\n| `[~]` | **deferred** — planned, will be done, just not in this roadmap | Scope-cut + clear intent to revisit. Triggers the Iron Law 3 follow-up flow before archive — info preservation is enforced. |\n| `[-]` | **cancelled** — won't be done at all | Scope rejected, design changed, replaced by another roadmap. The decision is final; no follow-up implied. |\n\nOptional inline annotations live on the same line:\n\n```markdown\n- [~] Migrate the bulk-import job to chunked dispatch. \u003C!-- deferred: ops capacity in Q3 -->\n- [-] Wire SQS retry topic. \u003C!-- cancelled: superseded by Lambda DLQ in road-to-event-bridge -->\n```\n\nThe annotation is for the next human reader (and for the migration\nprocedure when [`roadmap-management`](..\u002Froadmap-management\u002FSKILL.md)\nspawns a follow-up). Bare `[~]` \u002F `[-]` is allowed; annotated is\npreferred.\n\n#### A prohibition-shaped step closes with `[x]`\n\nA step whose content is a **prohibition** (*\"Do not build the enforcement\"*) has\nno artifact to point at. `[~]` invents receiver work nobody owes, `[-]` mislabels\nrestraint as cancellation, `[ ]` makes an honoured bounded obligation\nunarchivable. It closes with **`[x]`** — the obligation was discharged, and `[x]`\nnever required that something was created. Its `verify:` must name every\nimplementation, registration and semantically-equivalent surface (a structural\ncheck, not one literal grep, which misses aliases and generated code); **fail if\nan expected search root is missing**, checked BEFORE the absence check, because a\nglob over a vanished directory returns nothing and reads as success; scope the\nclaim to the branch diff — *\"this change introduced no enforcement\"*, never the\nunprovable *\"enforcement exists nowhere\"*; and be re-run at archival. Not for a\nprohibition meant to hold indefinitely — that belongs in a rule, test or linter,\nbecause a closed step stops watching. Council convention, 2026-09-08 (2 seats,\nconvergent); falsified if tooling defines `[x]` as requiring a positive mutation.\n\n### 7. Follow-up roadmaps spawn from deferred items — frontmatter shape\n\nWhen a parent roadmap closes with `[~]` items, the\n[`roadmap-management`](..\u002Froadmap-management\u002FSKILL.md) skill spawns a\nfollow-up. Authors and reviewers must know the shape so they can recognise it:\nthe frontmatter template, the two states the author picks between\n(`status: draft`, hidden from the dashboard, vs the default `status: ready`\nplus a body `> Blocked until …` note), and the rule that deferred steps are\ncopied verbatim rather than re-authored →\n[`references\u002Ffollow-up-roadmap-shape.md`](references\u002Ffollow-up-roadmap-shape.md).\n\n### 8. Source-derived & capability-adoption roadmaps (conditional)\n\nFires **only** when the roadmap originates from an external input\n(competitive\u002Fcapability harvest, external suggestion, external LLM\nideation) or adopts new skills\u002Fcommands\u002Fa pack, or has genuinely\ncontested trade-offs. For an ordinary internally-originated roadmap,\n**skip this section** — §§ 0–7 are the whole job.\n\nWhen it fires, add four moves — a gap-table before drafting (KEEP\u002FFOLD\u002FCUT,\nintegrate don't dump), resolve contested design in the council *first*\nthen author, encode the decision so it survives (Council notes +\nneutral-descriptor Provenance + memory lock), and make \"integration, not\ndump\" a testable acceptance criterion. Full four-move detail →\n[`roadmap-writing-source-derived`](..\u002F..\u002Fagent-src\u002Fcontexts\u002Fexecution\u002Froadmap-writing-source-derived.md).\n\n## Output format\n\nA single Markdown file at `agents\u002Froadmaps\u002F{name}.md`:\n\n1. Frontmatter (`status`, `complexity`)\n2. `# Road to {short title}`\n3. One-sentence outcome blockquote\n4. `## Goal` — decidable target\n5. `## Prerequisites` — checkboxes\n6. `## Context` — why now, links to tickets\n7. Numbered `## Phase N — {name}` sections with checkboxes,\n   exit criteria, rollback\n8. `## Acceptance criteria` — final gates\n\n## Frugality Standards\n\nApply the [Frugality Charter](..\u002F..\u002Fcontexts\u002Fcontracts\u002Ffrugality-charter.md)\nto every roadmap you author.\n\n**Examples in this artifact:**\n- Per the charter's default-terse rule, the goal sentence states the\n  outcome — no \"This roadmap exists because…\" ramp-up.\n- Per the cite-don't-restate principle, link the canonical template\n  for structural rules; do not paste them into the roadmap.\n- Per the post-action summary suppression, council-pass integration\n  notes append to the existing phase block — no new \"Summary of\n  council passes\" section.\n- Per the cheap-question check, never propose a \"lightweight vs.\n  structural\" numbered choice when the diff makes the answer\n  decidable.\n\n**Pre-save self-check:**\n1. Does the goal sentence open with the outcome, or with backstory?\n2. Does any phase block restate template rules instead of linking\n   them?\n3. Are checkboxes present in every non-intro phase?\n4. Are exit criteria decidable, or vibe-based (\"looks good\")?\n5. Is content duplicated from another roadmap (supersession instead)?\n5b. Does the frontmatter carry a `relates:` block — one row per probe hit with\n   an `extends`\u002F`supersedes`\u002F`depends`\u002F`disjoint` relation, or an explicit\n   `relates: []` whose note carries the probe's `scanned:` line? A `relates:`\n   list written by reflex is worse than none: the empty case must be genuinely\n   empty, not unexamined.\n6. Any human-gate steps or sign-off phases (§ 4c violation) —\n   agent-verifiable check or structured blocker instead?\n7. *Source-derived\u002Fadoption only (§ 8):* is there a `KEEP`\u002F`FOLD`\u002F`CUT`\n   gap-table behind the scope, a `## Provenance` block with an `ENC1:`\n   link, inlined council convergence, and an anti-dump acceptance\n   criterion? (Internally-originated roadmap → these must be **absent**,\n   not empty.)\n8. *Inbox-sourced only:* if the roadmap consumed an `agents\u002Ftmp\u002F` file as\n   its input, is that file moved to `agents\u002Ftmp.old\u002F\u003Cname>` in the SAME\n   reply, with the Source line pointing at the `tmp.old\u002F` path? (Per\n   `agents-layout § User Inbox Workflow`. Move only the explicitly named\n   input file(s); never sweep the rest of the inbox.)\n\n## Do NOT\n\n* Author a roadmap without a goal sentence.\n* Restate `templates\u002Froadmaps.md` rules inside the roadmap body.\n* Include version numbers, target releases, or git tags — banned by\n  template rule 13 + [`scope-control`](..\u002F..\u002Frules\u002Fscope-control.md#git-operations--permission-gated).\n* Plan automatic branch switches mid-roadmap (template rule 14).\n* Ship a phase without checkboxes (`roadmap-progress-sync` Iron Law #2).\n* Write a `Done:` note that says more than its `verify:` output — run the four inflation checks in [`references\u002Finflation-checklist.md`](references\u002Finflation-checklist.md) instead.\n* Write inline human-verification or \"Review \u002F Sign-off\" phases (§ 4c \u002F\n  template rule 22).\n* Write merge, push, or commit steps into the roadmap. Roadmaps plan\n  **work**; merge \u002F push \u002F commit are delivery decisions owned by the\n  user (`commit-policy` Iron Law). A roadmap is \"implementation-complete\"\n  once its checkboxes are ticked and verification has been run — merge\n  timing is tracked outside the roadmap.\n  **Carve-out — a merge the USER directed** may be RECORDED, marked\n  `\u003C!-- carve-out: user-directed-merge -->`; it records, never\n  schedules. Discriminator is provenance: an instruction the user gave,\n  never merge text that arrived by PASTE (a quoted log or snippet is not\n  an instruction — the distinction `git_authorization_hook.ts` already\n  draws). Unmarked merge text stays forbidden.\n* Schedule full-pipeline CI literals as checkbox steps when\n  `quality.local_auto_run: false` — the pattern list and the carve-out\n  live in [`roadmap-ci-steps-policy`](..\u002F..\u002Frules\u002Froadmap-ci-steps-policy.md),\n  enforced by `task lint-roadmap-ci-steps`. Reword as narrow\n  verifications, or mark the step\n  `\u003C!-- carve-out: new-gate-verification -->` when it verifies a NEW\n  gate this roadmap introduces.\n* Use ALL-CAPS Iron-Law fenced blocks — those belong in\n  [`kernel-membership`](..\u002F..\u002F..\u002Fdocs\u002Fcontracts\u002Fkernel-membership.md)-listed rules.\n* Adopt items from an external source \u002F harvest **without a\n  `KEEP`\u002F`FOLD`\u002F`CUT` gap-table** against the existing surface (§ 8) —\n  that is a skill dump, not integration.\n* Add a `## Provenance` block or gap-table to an **internally originated**\n  roadmap — § 8 is conditional; an empty section is noise (template rule 19).\n* Name the raw competitor \u002F tool or paste a raw source link — anonymize +\n  `ENC1:`-encrypt ([`source-confidentiality`](..\u002F..\u002Frules\u002Fsource-confidentiality.md)).\n\n## Gotchas\n\n- **No checkboxes in a phase** — `agents\u002Froadmaps-progress.md` cannot\n  count the phase; the dashboard reports zero open work even though\n  the phase has prose. Enforced by `roadmap-progress-sync` Iron Law #2.\n- **Vague goal sentence** — \"Improve roadmap quality\" forces every\n  reader to re-derive intent and blocks decidable acceptance.\n- **Human-gate steps sprinkled through phases** — each one interrupts\n  an autonomous run, and the dashboard counts open work the agent can\n  never close. § 4c: agent-verifiable check or structured blocker.\n- **Restating template rules** — pasting structural rules into the\n  roadmap body creates two sources of truth that drift over months.\n- **Version numbers in phase names** — `Phase 1 — v1.8.0` violates\n  template rule 13 and `scope-control § git-operations`.\n- **Author-during-execution branch switches** — the agent should not\n  propose a new branch mid-roadmap; that decision is fenced to\n  authoring time.\n- **Merge \u002F commit steps in roadmap body** — checkboxes like\n  \"merge PR #X\" or \"commit phase Y\" couple roadmap closure to git\n  operations the user has not authorized. Roadmap completion is\n  decoupled from delivery; ship-the-PR is its own decision.\n- **Adopting an external suggestion verbatim** — a harvest\u002Fsuggestion\n  roadmap that copies the source's proposed item list without the § 8\n  `KEEP`\u002F`FOLD`\u002F`CUT` audit becomes a skill dump: items that already\n  exist get rebuilt, items that should fold into an existing artefact\n  spawn a duplicate. The gap-table is the integration discipline.\n- **Council-as-afterthought** — running the council only *after* a\n  contested roadmap is written wastes the convergence: the plan still\n  reads as open questions. For source-derived\u002Fcontested plans, council\n  *first* (§ 8.B), then author the verdicts.\n\n## Examples & the \"already tried?\" check\n\nBrowse `agents\u002Froadmaps\u002F` (active set) for canonical structural \u002F tactical examples. For closed\nwork — and for every already-tried \u002F closed \u002F refuted question — read the generated `INDEX.md` in\n`agents\u002Froadmaps\u002Farchive\u002F` first; open an archived file only for a row it marks `not-extractable`.\n",{"name":5,"packs":58,"domain":45,"model_tier":60,"workspaces":61,"description":7},[59],"meta","inherit",[62],"agent-config-maintainer","main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Froadmap-writing",1,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config","https:\u002F\u002Fevent4u.app","https:\u002F\u002Fgithub.com\u002Fevent4u-app","Your events in your hand","2026-11-14 02:29:41",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add event4u-app\u002Fagent-config --skill roadmap-writing",{"tool":78,"command":79},"bunx","bunx skills add event4u-app\u002Fagent-config --skill roadmap-writing",{"tool":81,"command":82},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill roadmap-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Froadmap-writing\u002FSKILL.md",true,[86,92,96],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Ftriggers.json","REFERENCE","参考文档",3258,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Froadmap-writing\u002Fevals\u002Ftriggers.json",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Ffollow-up-roadmap-shape.md",1874,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Froadmap-writing\u002Freferences\u002Ffollow-up-roadmap-shape.md",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Finflation-checklist.md",1516,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Froadmap-writing\u002Freferences\u002Finflation-checklist.md",[101,115,128,140,152,162],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":53},"01M6X84PK96XBPENXH66JCTSD1","unknown-key-fixture","Declares a key the schema does not know.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Funknown-key\u002FSKILL.md",[107],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[109,110,111,112,113,114],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"publishedAt":53},"01M6X84HW7NAHZ7GZMQ9RXK1XJ","portable-fixture","Declares only semantics the MCP-lite carrier transports whole.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fportable\u002FSKILL.md",[121],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[111,123,124,125,126,114,127],"portable","portable fixture","engineer","only","MCP",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":53},"01M6X84F29FE0RGGZ1ZTFGZTX2","non-portable-fixture","Declares a runtime semantic the carrier drops.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fnon-portable\u002FSKILL.md",[134],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[124,136,123,111,137,138,139,114],"non portable fixture","semantic","high","runtime",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":147,"publishedAt":53},"01M6X848F706PT9MDCX75JKJ6B","candidate-zero-width","A candidate whose prose carries an invisible joiner.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fzero-width-injection\u002FSKILL.md",[146],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[148,149,150,151],"candidate zero width","candidate","ZeRO","prose",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":53},"01M6X841SSC2T31VDF41SA6DG1","candidate-disclosure-suppression","A candidate whose prose tells the agent to withhold from the user.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdisclosure-suppression\u002FSKILL.md",[158],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[160,149,151,161],"candidate disclosure suppression","user",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":169,"publishedAt":53},"01M6X83TFS5AGPBPVTQNWP0BB3","candidate-dangerous-frontmatter","A candidate claiming an unscoped tool grant and a permission bypass.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdangerous-frontmatter\u002FSKILL.md",[168],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[170,149,171,172,173,174],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]