[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MP8BH6NFST5S92DZF16GMP":3,"skill-same:01M6MP8BH6NFST5S92DZF16GMP":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":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6MP8BH6NFST5S92DZF16GMP","document-review",null,"Optional utility for reviewing existing docs, external specs, hand-authored notes, or non-HOTL documents. HOTL design docs and workflows get structural lint + AI review; other documents get AI-only review with a generic rubric.","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\u002Fyimwoo\u002Fhotl-plugin\u002Fskills\u002Fdocument-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"review","document","document review","generic","design","hotl","Existing","for","hand","with","utility","design docs","structural","get","only","rubric","lint","notes","documents","workflows","docs","2026-11-10 10:12:30",false,"---\nname: document-review\ndescription: Optional utility for reviewing existing docs, external specs, hand-authored notes, or non-HOTL documents. HOTL design docs and workflows get structural lint + AI review; other documents get AI-only review with a generic rubric.\n---\n\n# HOTL Document Review\n\n## Overview\n\nOptional utility for ad hoc document review. Use this to review existing docs, external specs, hand-authored plans, or any non-HOTL document. HOTL documents get structural lint (hard gate) followed by AI review. Non-HOTL documents skip lint and go straight to AI review with a generic rubric.\n\n**Note:** This skill is not required in the standard HOTL flow. Writing-plans includes a built-in self-check, and execution preflight runs structural lint automatically. Use this skill when you want to review a document outside of the normal plan-then-execute cycle.\n\n**Announce:** \"Running document review. Classifying input...\"\n\n## Step 0 — Classify the Input\n\nBefore doing anything else, classify the input into one of four categories:\n\n| Category | Detection | Review Path |\n|---|---|---|\n| **HOTL workflow** | Canonical `docs\u002Fplans\u002F*-workflow.md` or legacy `hotl-workflow-*.md` | Phase 1 (HOTL lint, hard gate) → Phase 2 (HOTL AI review) |\n| **HOTL design doc (marked)** | A design-doc-shaped file (canonical `docs\u002Fdesigns\u002F*.md` or legacy `*-design.md` \u002F `*-plan.md`) whose YAML frontmatter declares `design_type:` (one of `feature \\| phase \\| initiative \\| architecture \\| contract \\| reference`) OR `hotl_managed: true` | Phase 1 (HOTL lint) → Phase 2 (HOTL AI review) |\n| **Generic text\u002Fmarkdown** | Any other `.md`, `.txt`, or pasted text — including design-shaped files in `docs\u002Fdesigns\u002F` that lack an HOTL marker | Skip Phase 1 → Phase 2 (generic AI review) |\n| **PDF** | `.pdf` extension | If the current runtime can read\u002Fextract the content, treat as generic text and review. Otherwise, ask the user for a text, markdown, or PDF-text export. |\n| **DOCX \u002F PPTX \u002F binary** | `.docx`, `.pptx`, or other binary formats | **STOP.** Ask the user for a markdown, plain text, or PDF export. Do not attempt conversion. |\n\n**Phase 1.6 opt-in rule:** Path alone does NOT classify a file as HOTL. A design-shaped Markdown file in `docs\u002Fdesigns\u002F` without an HOTL frontmatter marker (`design_type:` or `hotl_managed: true`) is treated as generic markdown — `document-lint.sh` will SKIP it cleanly, and this skill routes it through Phase 2's generic-rubric AI review. To opt a hand-authored design doc into HOTL strict review, add `design_type: \u003Crecognized-value>` or `hotl_managed: true` to its frontmatter.\n\n**Announce the classification:** e.g., \"Classified as HOTL design doc (marked via design_type) — running lint + HOTL review.\" or \"Classified as generic markdown — skipping lint, running generic review.\"\n\n## Phase 1: Structural Lint (HOTL Documents Only)\n\n**Skip this phase entirely for non-HOTL documents.** If the input was classified as generic text\u002Fmarkdown or PDF, go directly to Phase 2 (generic AI review).\n\nFor HOTL documents only, run the deterministic lint script:\n\n```bash\nbash scripts\u002Fdocument-lint.sh \u003Cfile>\n```\n\nResolve `document-lint.sh` in this order:\n\n1. If you are working in the `hotl-plugin` repo itself, use `scripts\u002Fdocument-lint.sh`\n2. Codex native-skills install: `~\u002F.codex\u002Fhotl\u002Fscripts\u002Fdocument-lint.sh`\n3. Codex plugin install: `~\u002F.codex\u002Fplugins\u002Fhotl-source\u002Fscripts\u002Fdocument-lint.sh`\n4. Codex plugin cache fallback: `~\u002F.codex\u002Fplugins\u002Fcache\u002Fcodex-plugins\u002Fhotl\u002F*\u002Fscripts\u002Fdocument-lint.sh`\n5. Cline install fallback: `~\u002F.cline\u002Fhotl\u002Fscripts\u002Fdocument-lint.sh`\n6. Claude Code plugin fallback: `~\u002F.claude\u002Fplugins\u002Fhotl\u002Fscripts\u002Fdocument-lint.sh`\n\nDo not assume `scripts\u002Fdocument-lint.sh` exists in the repo being reviewed. The lint script lives in the HOTL install, not in arbitrary user projects.\n\n#### Resolving `hotl-config.sh`\n\n`hotl-config.sh` (the canonical reader for `.hotl\u002Fconfig.yml`) follows the same six-location resolution order as `document-lint.sh`:\n\n1. If you are working in the `hotl-plugin` repo itself, use `scripts\u002Fhotl-config.sh`\n2. Codex native-skills install: `~\u002F.codex\u002Fhotl\u002Fscripts\u002Fhotl-config.sh`\n3. Codex plugin install: `~\u002F.codex\u002Fplugins\u002Fhotl-source\u002Fscripts\u002Fhotl-config.sh`\n4. Codex plugin cache fallback: `~\u002F.codex\u002Fplugins\u002Fcache\u002Fcodex-plugins\u002Fhotl\u002F*\u002Fscripts\u002Fhotl-config.sh`\n5. Cline install fallback: `~\u002F.cline\u002Fhotl\u002Fscripts\u002Fhotl-config.sh`\n6. Claude Code plugin fallback: `~\u002F.claude\u002Fplugins\u002Fhotl\u002Fscripts\u002Fhotl-config.sh`\n\nDo not assume `scripts\u002Fhotl-config.sh` exists in the repo being reviewed. Callers that do not know their install location should invoke `scripts\u002Fhotl-config-resolve.sh` (a thin command proxy that locates `hotl-config.sh` and forwards argv).\n\n**If lint FAILS:** STOP. Show all errors. The author MUST fix structural issues before AI review runs. Do not proceed.\n\n**If lint PASSES:** Continue to Phase 2 (HOTL AI review).\n\n### What Lint Checks\n\n**Design docs (canonical `docs\u002Fdesigns\u002F*.md`, plus legacy `*-design.md` \u002F `*-plan.md` tactical docs):**\n- Intent Contract with intent, constraints, success_criteria, risk_level\n- Verification Contract with at least one verify step\n- Governance Contract with approval_gates and rollback\n- risk_level is low, medium, or high\n\n**Workflow files (canonical `docs\u002Fplans\u002F*-workflow.md`, plus legacy `hotl-workflow-*.md`):**\n- YAML frontmatter with intent, success_criteria, risk_level\n- Every step has action and loop fields\n- Every looped step (loop: until) has verify and max_iterations\n- Preferred workflow step syntax is `- [ ] **Step N: ...**`, though legacy `### N.` headings may still appear\n- High-risk steps with security keywords have gate: human\n\n## Phase 2: AI-Driven Review (Soft Gate)\n\nRead the full document and evaluate using the rubric that matches the classification:\n\n### For Design Docs\n\n1. **Internal consistency** — Do the three contracts align with each other? Does the verification contract actually test the intent?\n2. **YAGNI** — Is anything speculative, overbuilt, or solving problems that don't exist yet?\n3. **Risk assessment** — Is the risk_level appropriate? Are high-risk areas (auth, encryption, billing) correctly identified?\n4. **Success criteria** — Are they concrete and testable, or vague?\n5. **Scope** — Does this cross too many subsystems? Should it be decomposed?\n\n### For Workflow Files\n\n1. **Step sizing** — Are steps atomic (2-5 minutes each)? Flag steps that are too large or vague.\n2. **Verify coverage** — Do verify commands actually test what the step claims to do?\n3. **Gate placement** — Are human gates placed at the right points? Any risky steps missing gates?\n4. **Loop safety** — Are max_iterations reasonable? Any infinite-loop risks?\n5. **Ordering** — Do steps build on each other logically? Any missing dependencies?\n\n### For Generic Documents\n\n1. **Clarity** — Is the writing clear, specific, and unambiguous?\n2. **Completeness** — Are important details, assumptions, or decisions missing?\n3. **Internal consistency** — Does the document contradict itself anywhere?\n4. **Actionability** — Are decisions, next steps, owners, or open questions clearly stated?\n5. **Risk \u002F Ambiguity** — Are there risky assumptions, vague areas, or likely points of confusion?\n\n## Review Outcomes\n\nAfter completing the review, output exactly one of the following. Use `Lint: PASSED` for HOTL documents or `Lint: SKIPPED (non-HOTL document)` for all other inputs.\n\n### PASS\nAll checks satisfied. Document is ready.\n\n```\nREVIEW: PASS\nDocument: \u003Cfilename>\nLint: PASSED | SKIPPED (non-HOTL document)\nAI Review: No issues found.\nReady for execution.\n```\n\n### REVISE\nIssues found that should be fixed. List each with a specific suggestion.\n\n```\nREVIEW: REVISE\nDocument: \u003Cfilename>\nLint: PASSED | SKIPPED (non-HOTL document)\nAI Review: \u003CN> issue(s) found.\n\nIssues:\n1. [ISSUE]: \u003Cdescription>\n   Suggestion: \u003Chow to fix>\n2. [ISSUE]: \u003Cdescription>\n   Suggestion: \u003Chow to fix>\n\nFix these issues and re-run document review.\n```\n\n### HUMAN_OVERRIDE_REQUIRED\nSerious concerns that the AI cannot resolve. Human must decide whether to proceed.\n\n```\nREVIEW: HUMAN_OVERRIDE_REQUIRED\nDocument: \u003Cfilename>\nLint: PASSED | SKIPPED (non-HOTL document)\nAI Review: Serious concern(s) requiring human judgment.\n\nConcerns:\n1. [CONCERN]: \u003Cdescription>\n   Risk: \u003Cwhat could go wrong>\n2. [CONCERN]: \u003Cdescription>\n   Risk: \u003Cwhat could go wrong>\n\nDo not continue until a human explicitly says to override these concerns.\n```\n\n## Rules\n\n- Always classify the input before choosing a review path.\n- For HOTL documents: never skip lint; never continue to execution when lint fails.\n- For non-HOTL documents: skip lint entirely (no structural validation).\n- For DOCX\u002FPPTX\u002Fbinary: do not attempt conversion; ask for an export.\n- If review outcome is `REVISE`, the author fixes the document first.\n- If review outcome is `HUMAN_OVERRIDE_REQUIRED`, only an explicit human decision allows execution to proceed.\n","# HOTL Document Review\n\n## Overview\n\nOptional utility for ad hoc document review. Use this to review existing docs, external specs, hand-authored plans, or any non-HOTL document. HOTL documents get structural lint (hard gate) followed by AI review. Non-HOTL documents skip lint and go straight to AI review with a generic rubric.\n\n**Note:** This skill is not required in the standard HOTL flow. Writing-plans includes a built-in self-check, and execution preflight runs structural lint automatically. Use this skill when you want to review a document outside of the normal plan-then-execute cycle.\n\n**Announce:** \"Running document review. Classifying input...\"\n\n## Step 0 — Classify the Input\n\nBefore doing anything else, classify the input into one of four categories:\n\n| Category | Detection | Review Path |\n|---|---|---|\n| **HOTL workflow** | Canonical `docs\u002Fplans\u002F*-workflow.md` or legacy `hotl-workflow-*.md` | Phase 1 (HOTL lint, hard gate) → Phase 2 (HOTL AI review) |\n| **HOTL design doc (marked)** | A design-doc-shaped file (canonical `docs\u002Fdesigns\u002F*.md` or legacy `*-design.md` \u002F `*-plan.md`) whose YAML frontmatter declares `design_type:` (one of `feature \\| phase \\| initiative \\| architecture \\| contract \\| reference`) OR `hotl_managed: true` | Phase 1 (HOTL lint) → Phase 2 (HOTL AI review) |\n| **Generic text\u002Fmarkdown** | Any other `.md`, `.txt`, or pasted text — including design-shaped files in `docs\u002Fdesigns\u002F` that lack an HOTL marker | Skip Phase 1 → Phase 2 (generic AI review) |\n| **PDF** | `.pdf` extension | If the current runtime can read\u002Fextract the content, treat as generic text and review. Otherwise, ask the user for a text, markdown, or PDF-text export. |\n| **DOCX \u002F PPTX \u002F binary** | `.docx`, `.pptx`, or other binary formats | **STOP.** Ask the user for a markdown, plain text, or PDF export. Do not attempt conversion. |\n\n**Phase 1.6 opt-in rule:** Path alone does NOT classify a file as HOTL. A design-shaped Markdown file in `docs\u002Fdesigns\u002F` without an HOTL frontmatter marker (`design_type:` or `hotl_managed: true`) is treated as generic markdown — `document-lint.sh` will SKIP it cleanly, and this skill routes it through Phase 2's generic-rubric AI review. To opt a hand-authored design doc into HOTL strict review, add `design_type: \u003Crecognized-value>` or `hotl_managed: true` to its frontmatter.\n\n**Announce the classification:** e.g., \"Classified as HOTL design doc (marked via design_type) — running lint + HOTL review.\" or \"Classified as generic markdown — skipping lint, running generic review.\"\n\n## Phase 1: Structural Lint (HOTL Documents Only)\n\n**Skip this phase entirely for non-HOTL documents.** If the input was classified as generic text\u002Fmarkdown or PDF, go directly to Phase 2 (generic AI review).\n\nFor HOTL documents only, run the deterministic lint script:\n\n```bash\nbash scripts\u002Fdocument-lint.sh \u003Cfile>\n```\n\nResolve `document-lint.sh` in this order:\n\n1. If you are working in the `hotl-plugin` repo itself, use `scripts\u002Fdocument-lint.sh`\n2. Codex native-skills install: `~\u002F.codex\u002Fhotl\u002Fscripts\u002Fdocument-lint.sh`\n3. Codex plugin install: `~\u002F.codex\u002Fplugins\u002Fhotl-source\u002Fscripts\u002Fdocument-lint.sh`\n4. Codex plugin cache fallback: `~\u002F.codex\u002Fplugins\u002Fcache\u002Fcodex-plugins\u002Fhotl\u002F*\u002Fscripts\u002Fdocument-lint.sh`\n5. Cline install fallback: `~\u002F.cline\u002Fhotl\u002Fscripts\u002Fdocument-lint.sh`\n6. Claude Code plugin fallback: `~\u002F.claude\u002Fplugins\u002Fhotl\u002Fscripts\u002Fdocument-lint.sh`\n\nDo not assume `scripts\u002Fdocument-lint.sh` exists in the repo being reviewed. The lint script lives in the HOTL install, not in arbitrary user projects.\n\n#### Resolving `hotl-config.sh`\n\n`hotl-config.sh` (the canonical reader for `.hotl\u002Fconfig.yml`) follows the same six-location resolution order as `document-lint.sh`:\n\n1. If you are working in the `hotl-plugin` repo itself, use `scripts\u002Fhotl-config.sh`\n2. Codex native-skills install: `~\u002F.codex\u002Fhotl\u002Fscripts\u002Fhotl-config.sh`\n3. Codex plugin install: `~\u002F.codex\u002Fplugins\u002Fhotl-source\u002Fscripts\u002Fhotl-config.sh`\n4. Codex plugin cache fallback: `~\u002F.codex\u002Fplugins\u002Fcache\u002Fcodex-plugins\u002Fhotl\u002F*\u002Fscripts\u002Fhotl-config.sh`\n5. Cline install fallback: `~\u002F.cline\u002Fhotl\u002Fscripts\u002Fhotl-config.sh`\n6. Claude Code plugin fallback: `~\u002F.claude\u002Fplugins\u002Fhotl\u002Fscripts\u002Fhotl-config.sh`\n\nDo not assume `scripts\u002Fhotl-config.sh` exists in the repo being reviewed. Callers that do not know their install location should invoke `scripts\u002Fhotl-config-resolve.sh` (a thin command proxy that locates `hotl-config.sh` and forwards argv).\n\n**If lint FAILS:** STOP. Show all errors. The author MUST fix structural issues before AI review runs. Do not proceed.\n\n**If lint PASSES:** Continue to Phase 2 (HOTL AI review).\n\n### What Lint Checks\n\n**Design docs (canonical `docs\u002Fdesigns\u002F*.md`, plus legacy `*-design.md` \u002F `*-plan.md` tactical docs):**\n- Intent Contract with intent, constraints, success_criteria, risk_level\n- Verification Contract with at least one verify step\n- Governance Contract with approval_gates and rollback\n- risk_level is low, medium, or high\n\n**Workflow files (canonical `docs\u002Fplans\u002F*-workflow.md`, plus legacy `hotl-workflow-*.md`):**\n- YAML frontmatter with intent, success_criteria, risk_level\n- Every step has action and loop fields\n- Every looped step (loop: until) has verify and max_iterations\n- Preferred workflow step syntax is `- [ ] **Step N: ...**`, though legacy `### N.` headings may still appear\n- High-risk steps with security keywords have gate: human\n\n## Phase 2: AI-Driven Review (Soft Gate)\n\nRead the full document and evaluate using the rubric that matches the classification:\n\n### For Design Docs\n\n1. **Internal consistency** — Do the three contracts align with each other? Does the verification contract actually test the intent?\n2. **YAGNI** — Is anything speculative, overbuilt, or solving problems that don't exist yet?\n3. **Risk assessment** — Is the risk_level appropriate? Are high-risk areas (auth, encryption, billing) correctly identified?\n4. **Success criteria** — Are they concrete and testable, or vague?\n5. **Scope** — Does this cross too many subsystems? Should it be decomposed?\n\n### For Workflow Files\n\n1. **Step sizing** — Are steps atomic (2-5 minutes each)? Flag steps that are too large or vague.\n2. **Verify coverage** — Do verify commands actually test what the step claims to do?\n3. **Gate placement** — Are human gates placed at the right points? Any risky steps missing gates?\n4. **Loop safety** — Are max_iterations reasonable? Any infinite-loop risks?\n5. **Ordering** — Do steps build on each other logically? Any missing dependencies?\n\n### For Generic Documents\n\n1. **Clarity** — Is the writing clear, specific, and unambiguous?\n2. **Completeness** — Are important details, assumptions, or decisions missing?\n3. **Internal consistency** — Does the document contradict itself anywhere?\n4. **Actionability** — Are decisions, next steps, owners, or open questions clearly stated?\n5. **Risk \u002F Ambiguity** — Are there risky assumptions, vague areas, or likely points of confusion?\n\n## Review Outcomes\n\nAfter completing the review, output exactly one of the following. Use `Lint: PASSED` for HOTL documents or `Lint: SKIPPED (non-HOTL document)` for all other inputs.\n\n### PASS\nAll checks satisfied. Document is ready.\n\n```\nREVIEW: PASS\nDocument: \u003Cfilename>\nLint: PASSED | SKIPPED (non-HOTL document)\nAI Review: No issues found.\nReady for execution.\n```\n\n### REVISE\nIssues found that should be fixed. List each with a specific suggestion.\n\n```\nREVIEW: REVISE\nDocument: \u003Cfilename>\nLint: PASSED | SKIPPED (non-HOTL document)\nAI Review: \u003CN> issue(s) found.\n\nIssues:\n1. [ISSUE]: \u003Cdescription>\n   Suggestion: \u003Chow to fix>\n2. [ISSUE]: \u003Cdescription>\n   Suggestion: \u003Chow to fix>\n\nFix these issues and re-run document review.\n```\n\n### HUMAN_OVERRIDE_REQUIRED\nSerious concerns that the AI cannot resolve. Human must decide whether to proceed.\n\n```\nREVIEW: HUMAN_OVERRIDE_REQUIRED\nDocument: \u003Cfilename>\nLint: PASSED | SKIPPED (non-HOTL document)\nAI Review: Serious concern(s) requiring human judgment.\n\nConcerns:\n1. [CONCERN]: \u003Cdescription>\n   Risk: \u003Cwhat could go wrong>\n2. [CONCERN]: \u003Cdescription>\n   Risk: \u003Cwhat could go wrong>\n\nDo not continue until a human explicitly says to override these concerns.\n```\n\n## Rules\n\n- Always classify the input before choosing a review path.\n- For HOTL documents: never skip lint; never continue to execution when lint fails.\n- For non-HOTL documents: skip lint entirely (no structural validation).\n- For DOCX\u002FPPTX\u002Fbinary: do not attempt conversion; ask for an export.\n- If review outcome is `REVISE`, the author fixes the document first.\n- If review outcome is `HUMAN_OVERRIDE_REQUIRED`, only an explicit human decision allows execution to proceed.\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Fyimwoo\u002Fhotl-plugin\u002Fskills\u002Fdocument-review",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-review",{"tool":69,"command":70},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill document-review",{"tool":72,"command":73},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill document-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyimwoo\u002Fhotl-plugin\u002Fskills\u002Fdocument-review\u002FSKILL.md",true,[],[78,86,93,100,126,149],{"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":48},"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,31,116,117,118,119,120,121,122,123,124,125],"search","deja search","never","error","ready","memory","re","decide","fix","debugging","when","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":48},"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,27,121,36,135,136,137,138,139,140,141,142,143,112,144,145,146,147,148],"deja reflect","reflect","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":164,"publishedAt":48},"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",[155,158,161],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":159,"categoryName":160,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[151,165,166,167,168,169,170,145,171,113,172,173,174,175,117,176,177,178,179,180],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]