[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ME5N05QPCADXE5F65JKX7V":3,"skill-same:01M6ME5N05QPCADXE5F65JKX7V":77},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6ME5N05QPCADXE5F65JKX7V","document",null,"Record a decision, document existing code, or file a supplied research material. Modes: document decision (ADR, RFC, or rule), document code (spec, doc, guide, or scenario for existing behavior), document research (only when a finished report or one external material is already in hand). Use for 'we decided', 'record this decision', 'document why we chose X', 'make it our standard', 'draft an RFC', 'should we switch to Y' proposals, 'resolve the RFC', 'we accepted the proposal', 'document the auth module', 'capture how the payment system works', reference material, how-to instructions, or a user flow with examples over an existing spec. Name the type inside the subject to skip the type question. Planning a feature or an intended user journey → \u002Farchcore:plan. Checking docs against code or docs health → \u002Farchcore:review.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1559,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Farchcore-ai\u002Fplugin\u002Fskills\u002Fdocument\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"question","when","hand","make","proposal","scenario","journey","only","guide","proposals","review","decision","adr","plan","why","how","doc","flow","code","auth","2026-11-10 10:12:30",false,"---\nname: document\nargument-hint: \"[decision|code|research] [subject]\"\ndescription: \"Record a decision, document existing code, or file a supplied research material. Modes: document decision (ADR, RFC, or rule), document code (spec, doc, guide, or scenario for existing behavior), document research (only when a finished report or one external material is already in hand). Use for 'we decided', 'record this decision', 'document why we chose X', 'make it our standard', 'draft an RFC', 'should we switch to Y' proposals, 'resolve the RFC', 'we accepted the proposal', 'document the auth module', 'capture how the payment system works', reference material, how-to instructions, or a user flow with examples over an existing spec. Name the type inside the subject to skip the type question. Planning a feature or an intended user journey → \u002Farchcore:plan. Checking docs against code or docs health → \u002Farchcore:review.\"\n---\n\n# \u002Farchcore:document\n\nRecord the present state: a technical decision, existing code, or a supplied\nresearch material. The first word of the arguments selects the mode; a gate\ninside the mode's track selects the document type. Write affinity: knowledge\ntypes; a filed `research` and the decision cascade's `plan` belong to vision.\nThe standard cascade can add a `cpat` (experience).\n\nCommand tense: `\u002Farchcore:plan` declares a future canon delta, `\u002Farchcore:document`\nrecords the present state — including work that shipped without a plan — and\n`\u002Farchcore:review` reconciles a past declared delta. Δ vocabulary:\n`skills\u002F_shared\u002Fdelta-routing.md`.\n\nLoad `skills\u002F_shared\u002Fgate-contract.md` and `skills\u002F_shared\u002Felicitation-contract.md` before executing any gate.\n\n## Modes\n\n| Mode | Track and entry | Types the entry gate selects |\n|---|---|---|\n| `decision` | `skills\u002F_shared\u002Ftracks\u002Fdecision.md`, `decision.classify` | `adr`, `rfc`; `rule` through the standard cascade; an existing `rfc` draft on the topic → `decision.resolve`, which records an `adr` on an accepted verdict |\n| `code` | `skills\u002F_shared\u002Ftracks\u002Fdescribe.md`, `describe.read` | `spec`, `doc`, `guide`, `scenario` |\n| `research` | `skills\u002F_shared\u002Ftracks\u002Fresearch.md`, `research.frame` | `research`, `rnd` by the closing test; one external material → `evidence` |\n\nA document type name is not a mode. When the subject text names a type (`skills\u002F_shared\u002Fgate-contract.md`,\nEntry terms) that the mode's track produces, the selecting gate treats that type as settled and asks no\ntype question: `document decision rfc for gRPC` reaches the RFC branch. A leading\nword that is not a mode is topic text and goes through classification (Step 3).\nNo mode produces a `journey`; an intended user path belongs to `\u002Farchcore:plan`.\n\n## When to use\n\n- \"We decided to go with microservices\" — settled decision\n- \"Record the decision to use PostgreSQL\"\n- \"Document why we chose JWT over sessions\"\n- \"Make this our team standard for error handling\"\n- \"Draft an RFC for switching from REST to gRPC\"\n- \"Should we switch to Kubernetes?\" — open proposal\n- \"We accepted the proposal — resolve the RFC\" — proposal resolution\n- \"Document the auth module\"\n- \"Capture how the payment system works\"\n- \"Create reference docs for the config system\" — reference material\n- \"Write a guide for the release process\" — how-to instructions\n- `document code scenario for checkout` — a user flow with examples over an existing spec\n- `document research \u003Creport>` — file a ready investigation\n- `document research \u003Cmaterial>` — file one external material as evidence\n\n**Not document:**\n\n- Planning a feature, an initiative, or an intended user journey → `\u002Farchcore:plan`\n- Checking documents against code, reviewing branch changes, or docs health → `\u002Farchcore:review`\n- First-time setup → `\u002Farchcore:init`\n\n## Routing table\n\n| Signal | Route |\n|---|---|\n| No arguments | → git investigation of the branch changes, then one classifying question (Step 3, Unclear) |\n| The first word is a mode — `decision`, `code`, `research` | → mode entry, no routing (Step 2) |\n| Decision signals: \"we decided\", \"record this decision\", \"document why we chose X\", \"make it our standard\", \"draft an RFC\", a \"should we switch to Y\" proposal. A bare \"compare X vs Y\" with no proposed target belongs to `\u002Farchcore:plan`'s research track; a proposal to add a new capability with no named technical target (\"should we add caching?\") is feature framing → `\u002Farchcore:plan`, sdd track | → decision track — `skills\u002F_shared\u002Ftracks\u002Fdecision.md`, entry at `decision.classify` |\n| Resolution signals: \"resolve the RFC\", \"we accepted the proposal\", \"reject the RFC\" — an `rfc` draft exists on the topic | → decision track — `skills\u002F_shared\u002Ftracks\u002Fdecision.md`, entry at `decision.resolve` |\n| Code-doc signals: \"document the auth module\", \"capture how the payment system works\", reference material (registry, glossary, lookup), how-to instructions, a user flow with examples over an existing `spec` | → describe track — `skills\u002F_shared\u002Ftracks\u002Fdescribe.md`, entry at `describe.read` |\n| Research-material signals: a supplied investigation report, benchmark, transcript, or vendor document to file as is | → research track — `skills\u002F_shared\u002Ftracks\u002Fresearch.md`, entry at `research.frame` |\n| Unclear | → git investigation, then one classifying question (Step 3) |\n\n## Execution\n\n### Step 1: Ground\n\nApply `skills\u002F_shared\u002Fresearch-compatibility.md` under its condition 1 — a\nrequest or type naming `research` or `evidence`, the research track, or a\ngrounding result of either type. If this skill has no shell tool and no probe\nresult was supplied, report `needs-vocabulary-probe` with the helper path and\nstop before the first MCP call that names either type.\nBefore delegating research or evidence work, pass the current vocabulary probe\nresult and absolute plugin root to the assistant. If the assistant returns\n`needs-vocabulary-probe`, run the helper and resume the same task.\nBefore delegating any other document write or relation work, pass the absolute\nplugin root to the assistant. The assistant reads\n`skills\u002F_shared\u002Frelation-authoring.md` under that root.\nApply `skills\u002F_shared\u002Factor-subject-compatibility.md` under its own condition 1 —\na request whose subject names `scenario` or `journey`, or a grounding result of\neither type. When that probe returns `yes`, add `scenario` and `journey` to the\ntype filter below. On older engines, keep the legacy filter; a `code` request\nwhose subject names `scenario` then reports the required version and exits\nwithout a write.\nWhen the probe returns `yes`, add `research` and `evidence` to the type filter\nbelow. On older engines, keep the legacy filter.\n\nSearch `.archcore\u002F` on the request topic across all three categories — vision,\nknowledge, experience. Do not exclude a category from reads. Pass a type filter\nmatched to this command's moment (`adr`, `rfc`, `spec`, `doc`, `guide`, `rule`,\nplus `rnd` as decision evidence, and `research` and `evidence` when the probe returned `yes`) instead of relying on the global type ranking. When a found document carries\n`implements`, `depends_on`, or `related` relations, pull the linked documents one hop across\ncategories. Duplicate handling lives in the tracks' check-existing gates — do\nnot resolve duplicates here.\n\nIf `.archcore\u002F` does not exist, announce initialization in one line and call\n`mcp__archcore__init_project` without asking a question. If `.archcore\u002F` exists\nbut contains no documents, proceed on outer-context grounding and report that\nzero documents were found.\n\n**Global sources.** If a `mcp__archcore__list_documents` \u002F\n`mcp__archcore__search_documents` result has `global: true` \u002F `read_only: true` \u002F\n`source_kind: \"global\"`, load `skills\u002F_shared\u002Fglobals.md`. Also load it when a\n`search_documents` response's `coverage` names a source other than `\"local\"` —\neven when `results` is empty: the empty page is exactly where that file's retry\nladder applies. Never modify a global document and never target one with\n`add_relation`. Absent any global match, proceed as usual.\n\n### Step 2: Mode entry\n\nIf the first word is a mode, execute the mapped entry without routing:\n\n- `decision` → decision track. An `rfc` draft on the topic plus resolution\n  wording enters `decision.resolve`; any other request enters\n  `decision.classify`, which selects `adr`, `rfc`, or the standard outcome. A\n  type name in the subject (`adr`, `rfc`, `rule`) satisfies that gate's\n  `skip_when`.\n- `code` → describe track at `describe.read`. `describe.draft` selects `spec`,\n  `doc`, `guide`, or `scenario`; a type name in the subject settles its type\n  question. `describe.read` records `features\u002F*.feature` files as evidence when\n  present; a `scenario` with no covering `spec` routes to the earliest gate that\n  produces the `spec` per `skills\u002F_shared\u002Fgate-contract.md`.\n- `research` → research track at `research.frame`; the supplied report satisfies frame inputs without an interview (investigation versus one external material: `skills\u002F_shared\u002Fgate-contract.md`, Entry terms), and the closing test selects the type — a\n  report that ends in a recommendation is an `rnd`, a report that covers a scope\n  is a `research`. One external material with no investigation enters\n  `research.gather` as standalone evidence, records the request in the evidence\n  draft's Clarifications, and exits after gather. Follow the compatibility\n  contract's no-write exit when the type is unsupported.\n\nThen go to Step 4.\n\n### Step 3: Classify\n\nClassify the target as resolution, decision, code-doc, research material, or unclear:\n\n- **Resolution** — the request names a verdict on an existing open proposal\n  (resolution signals above) and an `rfc` draft on the topic exists → decision\n  track at `decision.resolve`. Check this before Decision: wording that also\n  reads as a settled-decision signal (\"we accepted the proposal\") routes here\n  whenever a matching `rfc` draft exists.\n- **Decision** — the request records a settled choice or an open proposal\n  (decision signals above) → decision track at `decision.classify`.\n- **Code-doc** — the request describes existing code, reference material, a\n  procedure, or a user flow over an existing `spec` (code-doc signals above) →\n  describe track at `describe.read`.\n- **Research material** — the request supplies a ready report or one external\n  material to file (research-material signals above) → research track at\n  `research.frame`.\n- **Unclear** — inspect git state and the working tree first: recent commits and\n  changed files are evidence of what the user has been working on. If the\n  evidence still supports both readings, ask one classifying question — \"Is this\n  a decision to record or existing code to document?\" — with the recommendation\n  drawn from the git evidence.\n\n### Step 4: Execute the track\n\nRun the selected track gate by gate per `skills\u002F_shared\u002Fgate-contract.md`. The\ntrack owns check-existing, per-gate elicitation, composition, and relation\nwiring.\n\nQuestion budget: per `skills\u002F_shared\u002Felicitation-contract.md` — auto mode draws\nfrom the shared per-invocation ceiling; a mode entry raises to the track's\nper-gate maxima.\n\n## Result\n\nReport the produced documents grouped by category:\n\n- **knowledge** — `adr`, `rfc`, `spec`, `doc`, `guide`, `rule`, `evidence`, `scenario`\n- **vision** — `research` (scope-covering report), `rnd` (recommendation-closed report, or compatibility fallback), `plan` (architecture cascade)\n- **experience** — `cpat` (standard cascade opt-in)\n\nList each document's path and relation edges. Name tracks and steps in plain\nwords; do not print a gate address of the form `\u003Ctrack>.\u003Cstage>`. Close with one\nrecommended next action naming only `\u002Farchcore:plan`, `\u002Farchcore:review`, or a\nrepeat `\u002Farchcore:document` invocation with its mode.\n","# \u002Farchcore:document\n\nRecord the present state: a technical decision, existing code, or a supplied\nresearch material. The first word of the arguments selects the mode; a gate\ninside the mode's track selects the document type. Write affinity: knowledge\ntypes; a filed `research` and the decision cascade's `plan` belong to vision.\nThe standard cascade can add a `cpat` (experience).\n\nCommand tense: `\u002Farchcore:plan` declares a future canon delta, `\u002Farchcore:document`\nrecords the present state — including work that shipped without a plan — and\n`\u002Farchcore:review` reconciles a past declared delta. Δ vocabulary:\n`skills\u002F_shared\u002Fdelta-routing.md`.\n\nLoad `skills\u002F_shared\u002Fgate-contract.md` and `skills\u002F_shared\u002Felicitation-contract.md` before executing any gate.\n\n## Modes\n\n| Mode | Track and entry | Types the entry gate selects |\n|---|---|---|\n| `decision` | `skills\u002F_shared\u002Ftracks\u002Fdecision.md`, `decision.classify` | `adr`, `rfc`; `rule` through the standard cascade; an existing `rfc` draft on the topic → `decision.resolve`, which records an `adr` on an accepted verdict |\n| `code` | `skills\u002F_shared\u002Ftracks\u002Fdescribe.md`, `describe.read` | `spec`, `doc`, `guide`, `scenario` |\n| `research` | `skills\u002F_shared\u002Ftracks\u002Fresearch.md`, `research.frame` | `research`, `rnd` by the closing test; one external material → `evidence` |\n\nA document type name is not a mode. When the subject text names a type (`skills\u002F_shared\u002Fgate-contract.md`,\nEntry terms) that the mode's track produces, the selecting gate treats that type as settled and asks no\ntype question: `document decision rfc for gRPC` reaches the RFC branch. A leading\nword that is not a mode is topic text and goes through classification (Step 3).\nNo mode produces a `journey`; an intended user path belongs to `\u002Farchcore:plan`.\n\n## When to use\n\n- \"We decided to go with microservices\" — settled decision\n- \"Record the decision to use PostgreSQL\"\n- \"Document why we chose JWT over sessions\"\n- \"Make this our team standard for error handling\"\n- \"Draft an RFC for switching from REST to gRPC\"\n- \"Should we switch to Kubernetes?\" — open proposal\n- \"We accepted the proposal — resolve the RFC\" — proposal resolution\n- \"Document the auth module\"\n- \"Capture how the payment system works\"\n- \"Create reference docs for the config system\" — reference material\n- \"Write a guide for the release process\" — how-to instructions\n- `document code scenario for checkout` — a user flow with examples over an existing spec\n- `document research \u003Creport>` — file a ready investigation\n- `document research \u003Cmaterial>` — file one external material as evidence\n\n**Not document:**\n\n- Planning a feature, an initiative, or an intended user journey → `\u002Farchcore:plan`\n- Checking documents against code, reviewing branch changes, or docs health → `\u002Farchcore:review`\n- First-time setup → `\u002Farchcore:init`\n\n## Routing table\n\n| Signal | Route |\n|---|---|\n| No arguments | → git investigation of the branch changes, then one classifying question (Step 3, Unclear) |\n| The first word is a mode — `decision`, `code`, `research` | → mode entry, no routing (Step 2) |\n| Decision signals: \"we decided\", \"record this decision\", \"document why we chose X\", \"make it our standard\", \"draft an RFC\", a \"should we switch to Y\" proposal. A bare \"compare X vs Y\" with no proposed target belongs to `\u002Farchcore:plan`'s research track; a proposal to add a new capability with no named technical target (\"should we add caching?\") is feature framing → `\u002Farchcore:plan`, sdd track | → decision track — `skills\u002F_shared\u002Ftracks\u002Fdecision.md`, entry at `decision.classify` |\n| Resolution signals: \"resolve the RFC\", \"we accepted the proposal\", \"reject the RFC\" — an `rfc` draft exists on the topic | → decision track — `skills\u002F_shared\u002Ftracks\u002Fdecision.md`, entry at `decision.resolve` |\n| Code-doc signals: \"document the auth module\", \"capture how the payment system works\", reference material (registry, glossary, lookup), how-to instructions, a user flow with examples over an existing `spec` | → describe track — `skills\u002F_shared\u002Ftracks\u002Fdescribe.md`, entry at `describe.read` |\n| Research-material signals: a supplied investigation report, benchmark, transcript, or vendor document to file as is | → research track — `skills\u002F_shared\u002Ftracks\u002Fresearch.md`, entry at `research.frame` |\n| Unclear | → git investigation, then one classifying question (Step 3) |\n\n## Execution\n\n### Step 1: Ground\n\nApply `skills\u002F_shared\u002Fresearch-compatibility.md` under its condition 1 — a\nrequest or type naming `research` or `evidence`, the research track, or a\ngrounding result of either type. If this skill has no shell tool and no probe\nresult was supplied, report `needs-vocabulary-probe` with the helper path and\nstop before the first MCP call that names either type.\nBefore delegating research or evidence work, pass the current vocabulary probe\nresult and absolute plugin root to the assistant. If the assistant returns\n`needs-vocabulary-probe`, run the helper and resume the same task.\nBefore delegating any other document write or relation work, pass the absolute\nplugin root to the assistant. The assistant reads\n`skills\u002F_shared\u002Frelation-authoring.md` under that root.\nApply `skills\u002F_shared\u002Factor-subject-compatibility.md` under its own condition 1 —\na request whose subject names `scenario` or `journey`, or a grounding result of\neither type. When that probe returns `yes`, add `scenario` and `journey` to the\ntype filter below. On older engines, keep the legacy filter; a `code` request\nwhose subject names `scenario` then reports the required version and exits\nwithout a write.\nWhen the probe returns `yes`, add `research` and `evidence` to the type filter\nbelow. On older engines, keep the legacy filter.\n\nSearch `.archcore\u002F` on the request topic across all three categories — vision,\nknowledge, experience. Do not exclude a category from reads. Pass a type filter\nmatched to this command's moment (`adr`, `rfc`, `spec`, `doc`, `guide`, `rule`,\nplus `rnd` as decision evidence, and `research` and `evidence` when the probe returned `yes`) instead of relying on the global type ranking. When a found document carries\n`implements`, `depends_on`, or `related` relations, pull the linked documents one hop across\ncategories. Duplicate handling lives in the tracks' check-existing gates — do\nnot resolve duplicates here.\n\nIf `.archcore\u002F` does not exist, announce initialization in one line and call\n`mcp__archcore__init_project` without asking a question. If `.archcore\u002F` exists\nbut contains no documents, proceed on outer-context grounding and report that\nzero documents were found.\n\n**Global sources.** If a `mcp__archcore__list_documents` \u002F\n`mcp__archcore__search_documents` result has `global: true` \u002F `read_only: true` \u002F\n`source_kind: \"global\"`, load `skills\u002F_shared\u002Fglobals.md`. Also load it when a\n`search_documents` response's `coverage` names a source other than `\"local\"` —\neven when `results` is empty: the empty page is exactly where that file's retry\nladder applies. Never modify a global document and never target one with\n`add_relation`. Absent any global match, proceed as usual.\n\n### Step 2: Mode entry\n\nIf the first word is a mode, execute the mapped entry without routing:\n\n- `decision` → decision track. An `rfc` draft on the topic plus resolution\n  wording enters `decision.resolve`; any other request enters\n  `decision.classify`, which selects `adr`, `rfc`, or the standard outcome. A\n  type name in the subject (`adr`, `rfc`, `rule`) satisfies that gate's\n  `skip_when`.\n- `code` → describe track at `describe.read`. `describe.draft` selects `spec`,\n  `doc`, `guide`, or `scenario`; a type name in the subject settles its type\n  question. `describe.read` records `features\u002F*.feature` files as evidence when\n  present; a `scenario` with no covering `spec` routes to the earliest gate that\n  produces the `spec` per `skills\u002F_shared\u002Fgate-contract.md`.\n- `research` → research track at `research.frame`; the supplied report satisfies frame inputs without an interview (investigation versus one external material: `skills\u002F_shared\u002Fgate-contract.md`, Entry terms), and the closing test selects the type — a\n  report that ends in a recommendation is an `rnd`, a report that covers a scope\n  is a `research`. One external material with no investigation enters\n  `research.gather` as standalone evidence, records the request in the evidence\n  draft's Clarifications, and exits after gather. Follow the compatibility\n  contract's no-write exit when the type is unsupported.\n\nThen go to Step 4.\n\n### Step 3: Classify\n\nClassify the target as resolution, decision, code-doc, research material, or unclear:\n\n- **Resolution** — the request names a verdict on an existing open proposal\n  (resolution signals above) and an `rfc` draft on the topic exists → decision\n  track at `decision.resolve`. Check this before Decision: wording that also\n  reads as a settled-decision signal (\"we accepted the proposal\") routes here\n  whenever a matching `rfc` draft exists.\n- **Decision** — the request records a settled choice or an open proposal\n  (decision signals above) → decision track at `decision.classify`.\n- **Code-doc** — the request describes existing code, reference material, a\n  procedure, or a user flow over an existing `spec` (code-doc signals above) →\n  describe track at `describe.read`.\n- **Research material** — the request supplies a ready report or one external\n  material to file (research-material signals above) → research track at\n  `research.frame`.\n- **Unclear** — inspect git state and the working tree first: recent commits and\n  changed files are evidence of what the user has been working on. If the\n  evidence still supports both readings, ask one classifying question — \"Is this\n  a decision to record or existing code to document?\" — with the recommendation\n  drawn from the git evidence.\n\n### Step 4: Execute the track\n\nRun the selected track gate by gate per `skills\u002F_shared\u002Fgate-contract.md`. The\ntrack owns check-existing, per-gate elicitation, composition, and relation\nwiring.\n\nQuestion budget: per `skills\u002F_shared\u002Felicitation-contract.md` — auto mode draws\nfrom the shared per-invocation ceiling; a mode entry raises to the track's\nper-gate maxima.\n\n## Result\n\nReport the produced documents grouped by category:\n\n- **knowledge** — `adr`, `rfc`, `spec`, `doc`, `guide`, `rule`, `evidence`, `scenario`\n- **vision** — `research` (scope-covering report), `rnd` (recommendation-closed report, or compatibility fallback), `plan` (architecture cascade)\n- **experience** — `cpat` (standard cascade opt-in)\n\nList each document's path and relation edges. Name tracks and steps in plain\nwords; do not print a gate address of the form `\u003Ctrack>.\u003Cstage>`. Close with one\nrecommended next action naming only `\u002Farchcore:plan`, `\u002Farchcore:review`, or a\nrepeat `\u002Farchcore:document` invocation with its mode.\n",{"name":5,"description":7,"argument-hint":52},"[decision|code|research] [subject]","main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Farchcore-ai\u002Fplugin\u002Fskills\u002Fdocument",474,"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-11 14:40:14",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill document",{"tool":69,"command":70},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill document",{"tool":72,"command":73},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill document","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Farchcore-ai\u002Fplugin\u002Fskills\u002Fdocument\u002FSKILL.md",true,[],[78,86,93,100,126,150],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":85},"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":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":85},"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":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":85},"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":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":47},"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",[],[107,108,109,110,111,112,113,114,115,116,117,28,118,119,120,121,122,123,124,125],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":47},"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",[],[133,134,37,121,135,136,137,138,139,140,141,142,143,144,112,145,146,147,148,149],"deja reflect","reflect","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":165,"publishedAt":47},"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",[156,159,162],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":160,"categoryName":161,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":163,"categoryName":164,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[152,166,167,168,169,170,171,146,172,113,173,174,175,176,28,177,178,179,180,181],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]