[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JTH1E9SHR8DVV0SFCSENGQ":3,"skill-same:01M6JTH1E9SHR8DVV0SFCSENGQ":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6JTH1E9SHR8DVV0SFCSENGQ","writing-modpack-devlog",null,"Use when starting or appending to a modpack project dev-log. Creates \u003Cproject>\u002Fdocs\u002Fdev-log.md if absent; appends a dated entry on subsequent calls. Triggers - 'log this', 'add to dev log', 'record what I did', 'note this change', 'devlog'.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FBB-84C\u002Fbgs-modding-superpowers\u002Fskills\u002Fwriting-modpack-devlog\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"writing modpack devlog","devlog","modpack","writing","project","when","entry","calls","note","add","triggers","record","log","use","dev","change","docs","2026-11-10 10:12:30",false,"---\nname: writing-modpack-devlog\ndescription: \"Use when starting or appending to a modpack project dev-log. Creates \u003Cproject>\u002Fdocs\u002Fdev-log.md if absent; appends a dated entry on subsequent calls. Triggers - 'log this', 'add to dev log', 'record what I did', 'note this change', 'devlog'.\"\n---\n\n## Overview\n\nThe modpack dev-log is the durable record of what the curator did to the modpack, in chronological order, with enough context for a future maintainer to understand why a change happened. This skill replaces the deleted `templates\u002Fmodpack\u002Fdev-log.md` template by creating `\u003Cproject>\u002Fdocs\u002Fdev-log.md` at runtime, then appending entries as the modpack evolves.\n\n## When to Use\n\n| Use this skill when... | Result |\n| --- | --- |\n| The user says \"log this\", \"add to dev log\", \"record what I did\", or \"note this change\" | Append a dated entry to the project dev-log. |\n| A mod was added, removed, replaced, upgraded, downgraded, patched, or moved in load order | Record what changed and why. |\n| A conflict-audit session finished | Summarize the finding and link evidence from `xedit-conflict-audit` or `xedit-automation` output. |\n| A CTD, freeze, missing asset, bad facegen, navmesh issue, or broken quest was investigated | Preserve the investigation result, even if the fix is not final. |\n| A modpack release was cut | Add the curator-facing note and cross-link to `writing-modpack-changelog`. |\n| The user made a manual decision that future agents must not re-litigate | Record the decision, context, and evidence. |\n\n## When NOT to Use\n\n| Do not use this skill when... | Use instead |\n| --- | --- |\n| The user is preparing public release notes for players | `writing-modpack-changelog` |\n| The user asks for a one-off explanation without wanting a project record | Answer directly. |\n| The project root is unknown and the user refuses to identify it | Stop after explaining what is missing. |\n| The entry would expose private notes, credentials, or personal information | Ask for a sanitized version first. |\n| The request is to inspect or edit plugin records | `xedit-automation` or `xedit-conflict-audit` first, then log the result. |\n\n## Rules\n\n\u003CEXTREMELY-IMPORTANT>\nThis skill creates or appends documentation inside the user's modpack project. It does not edit game plugins, install mods, change load order, or write into game installation folders. If the user asks for those actions, route to the appropriate modding or xEdit skill before writing the dev-log entry.\n\u003C\u002FEXTREMELY-IMPORTANT>\n\n1. Detect the modpack project root before writing.\n   - If the user provides `\u003Cmodpack_project_root>`, use it.\n   - If the current working directory looks like a modpack directory because it already has `Data\u002F`, `profiles\u002F`, or `docs\u002F`, default to `pwd` and tell the user what default you used.\n   - Otherwise ask once: \"Which modpack project root should I use? I can default to the current directory if this is the project root.\"\n2. Locate `\u003Cproject>\u002Fdocs\u002Fdev-log.md`.\n   - If `\u003Cproject>\u002Fdocs\u002F` does not exist, create it.\n   - If `dev-log.md` is missing, create it before appending.\n3. On first creation, use this header shape:\n   - `# \u003CProject Name> Dev Log`\n   - `Started: \u003Clocal ISO-8601 timestamp with offset>`\n   - A short note that entries are newest-first.\n   - `## Entries`\n4. Use local time with UTC offset for every entry timestamp, and keep that choice consistent throughout the file.\n   - Example: `2026-06-01T14:30:00-04:00`.\n   - Do not mix local dates, UTC dates, and vague dates such as \"today\".\n5. Each entry must include these parts:\n   - ISO-8601 timestamp with offset.\n   - Short title.\n   - Body paragraph or paragraphs explaining what changed and why.\n   - Optional `Mods touched` subsection when specific mods, plugins, patches, or tools were involved.\n   - Optional `Refs` subsection linking evidence, logs, issue threads, release pages, or xEdit captures.\n6. Append entries newest-first under the `## Entries` section.\n   - Insert the new entry immediately below `## Entries`.\n   - Do not append new entries at the bottom unless the file already uses oldest-first and the user explicitly wants to keep it that way.\n7. Do not duplicate the most recent entry.\n   - Read the newest entry timestamp and title.\n   - If the new title and body would be identical or effectively identical within 10 minutes of the newest entry, surface: \"This looks like a duplicate of `\u003Cexisting title>` from `\u003Ctimestamp>`. Append anyway? (y\u002FN)\"\n   - Default to no if the user does not confirm.\n8. Preserve evidence when the user references it.\n   - If the user points at a captured xEdit conflict, crash log, plugin diff, screenshot, text log, or other local evidence file, copy it into `\u003Cproject>\u002Fdocs\u002Fdev-log-artifacts\u002F\u003Centry-slug>\u002F`.\n   - Link the copied artifact from the entry body or `Refs` subsection.\n   - Prefer copying over linking to a fragile temporary path.\n9. Make the entry useful to a future curator.\n   - Include the decision, cause, tradeoff, or unresolved question.\n   - Avoid entries that only say \"fixed stuff\" or \"updated mods\".\n10. Keep private working noise out of the dev-log.\n    - Do not paste entire terminal transcripts unless they are the evidence.\n    - Summarize the result, then link artifacts.\n11. If the user gave rough notes, preserve meaning rather than polishing away operational details.\n    - Keep mod names, plugin names, load-order context, symptoms, and reproduction facts.\n    - Clean up grammar only enough to make the entry readable.\n12. After writing, report the file path, entry title, timestamp, and any artifacts copied.\n\n## Quick Reference\n\n| Field | Canonical shape | Example |\n| --- | --- | --- |\n| File | `\u003Cproject>\u002Fdocs\u002Fdev-log.md` | `docs\u002Fdev-log.md` |\n| Entry heading | `### \u003Ctimestamp> - \u003Cshort title>` | `### 2026-06-01T14:30:00-04:00 - Rebuilt settlement patch after lighting update` |\n| Body | One or more paragraphs explaining what changed and why | `Updated the settlement compatibility patch after the lighting mod changed precombines in the affected cells.` |\n| Mods touched | Optional bullet list | `- Example Lighting Overhaul` |\n| Refs | Optional bullet list of copied artifacts or external references | `- dev-log-artifacts\u002Frebuilt-settlement-patch\u002Fxedit-conflict-summary.md` |\n\nCanonical entry shape:\n\n```markdown\n### 2026-06-01T14:30:00-04:00 - Rebuilt settlement patch after lighting update\n\nUpdated the settlement compatibility patch after the lighting mod changed records in the affected cells. The new patch keeps the visual change while preserving the workshop keyword edits from the settlement overhaul.\n\n#### Mods touched\n\n- Example Lighting Overhaul\n- Example Settlement Overhaul\n- Example Modpack Patch\n\n#### Refs\n\n- dev-log-artifacts\u002Frebuilt-settlement-patch\u002Fxedit-conflict-summary.md\n```\n\n## Examples\n\n### Bad\n\n```markdown\nFixed the lighting thing.\n```\n\nThis entry has no date, no mod names, no context, no evidence, and no explanation of what was fixed.\n\n### Good\n\n```markdown\n### 2026-06-01T14:30:00-04:00 - Resolved lighting and workshop keyword conflict\n\nKept the lighting overhaul's cell image-space change, but restored the settlement overhaul's workshop keyword edits in the patch. This should preserve the intended visual pass without breaking workshop placement in the affected settlement.\n\n#### Mods touched\n\n- Example Lighting Overhaul\n- Example Settlement Overhaul\n- Example Modpack Patch\n\n#### Refs\n\n- dev-log-artifacts\u002Flighting-workshop-keyword-conflict\u002Fxedit-conflict-summary.md\n```\n\nThis entry tells a future curator what changed, why it changed, which mods were involved, and where the evidence lives.\n\n## Common Mistakes\n\n- Writing a loose note without a timestamp.\n- Logging only the action and omitting the reason.\n- Using the dev-log as public release notes instead of curator history.\n- Duplicating the same entry because the user repeated \"log this\" after a tool run.\n- Linking to temporary evidence paths that will disappear.\n- Copying huge raw logs into the main entry instead of summarizing and linking artifacts.\n- Recording \"updated mods\" without naming the mods.\n- Turning rough curator notes into generic prose that loses load-order context.\n- Asking multiple root-location questions instead of one question with a default.\n- Creating the file somewhere outside the actual modpack project root.\n\n## Rationalizations\n\n| Excuse | Reality |\n| --- | --- |\n| \"This is just a tiny note; it does not need structure.\" | Tiny notes become the only record future agents can trust. Date, title, context, and refs are the minimum useful shape. |\n| \"The release changelog will cover it.\" | The changelog is for players. The dev-log is for curators and future agents. They answer different questions. |\n| \"The evidence is in my terminal scrollback.\" | Scrollback is not durable. Copy evidence into `docs\u002Fdev-log-artifacts\u002F\u003Centry-slug>\u002F` and link it. |\n| \"I can append at the bottom; it is easier.\" | Newest-first keeps the current state visible. Insert below `## Entries` unless the user explicitly chose oldest-first. |\n| \"The user knows what they meant by 'lighting thing'.\" | Future maintainers will not. Name the symptom, mod, plugin, cell, record, or decision. |\n| \"I should ask several questions to make sure the entry is perfect.\" | Ask once for the project root if needed. Otherwise write the best entry from available context and flag uncertainties inline. |\n| \"The artifact path is already linked in the conversation.\" | Conversation links are not project records. Copy or preserve the artifact in the project docs tree. |\n| \"I should make this sound polished.\" | Accuracy beats polish. Keep the operational facts and make the wording readable. |\n\n## See also\n\n- `writing-modpack-changelog` - use for player-facing release notes and version sections.\n- `setting-up-bgs-modding-environment` - use when the modpack project structure itself is being created or located.\n","## Overview\n\nThe modpack dev-log is the durable record of what the curator did to the modpack, in chronological order, with enough context for a future maintainer to understand why a change happened. This skill replaces the deleted `templates\u002Fmodpack\u002Fdev-log.md` template by creating `\u003Cproject>\u002Fdocs\u002Fdev-log.md` at runtime, then appending entries as the modpack evolves.\n\n## When to Use\n\n| Use this skill when... | Result |\n| --- | --- |\n| The user says \"log this\", \"add to dev log\", \"record what I did\", or \"note this change\" | Append a dated entry to the project dev-log. |\n| A mod was added, removed, replaced, upgraded, downgraded, patched, or moved in load order | Record what changed and why. |\n| A conflict-audit session finished | Summarize the finding and link evidence from `xedit-conflict-audit` or `xedit-automation` output. |\n| A CTD, freeze, missing asset, bad facegen, navmesh issue, or broken quest was investigated | Preserve the investigation result, even if the fix is not final. |\n| A modpack release was cut | Add the curator-facing note and cross-link to `writing-modpack-changelog`. |\n| The user made a manual decision that future agents must not re-litigate | Record the decision, context, and evidence. |\n\n## When NOT to Use\n\n| Do not use this skill when... | Use instead |\n| --- | --- |\n| The user is preparing public release notes for players | `writing-modpack-changelog` |\n| The user asks for a one-off explanation without wanting a project record | Answer directly. |\n| The project root is unknown and the user refuses to identify it | Stop after explaining what is missing. |\n| The entry would expose private notes, credentials, or personal information | Ask for a sanitized version first. |\n| The request is to inspect or edit plugin records | `xedit-automation` or `xedit-conflict-audit` first, then log the result. |\n\n## Rules\n\n\u003CEXTREMELY-IMPORTANT>\nThis skill creates or appends documentation inside the user's modpack project. It does not edit game plugins, install mods, change load order, or write into game installation folders. If the user asks for those actions, route to the appropriate modding or xEdit skill before writing the dev-log entry.\n\u003C\u002FEXTREMELY-IMPORTANT>\n\n1. Detect the modpack project root before writing.\n   - If the user provides `\u003Cmodpack_project_root>`, use it.\n   - If the current working directory looks like a modpack directory because it already has `Data\u002F`, `profiles\u002F`, or `docs\u002F`, default to `pwd` and tell the user what default you used.\n   - Otherwise ask once: \"Which modpack project root should I use? I can default to the current directory if this is the project root.\"\n2. Locate `\u003Cproject>\u002Fdocs\u002Fdev-log.md`.\n   - If `\u003Cproject>\u002Fdocs\u002F` does not exist, create it.\n   - If `dev-log.md` is missing, create it before appending.\n3. On first creation, use this header shape:\n   - `# \u003CProject Name> Dev Log`\n   - `Started: \u003Clocal ISO-8601 timestamp with offset>`\n   - A short note that entries are newest-first.\n   - `## Entries`\n4. Use local time with UTC offset for every entry timestamp, and keep that choice consistent throughout the file.\n   - Example: `2026-06-01T14:30:00-04:00`.\n   - Do not mix local dates, UTC dates, and vague dates such as \"today\".\n5. Each entry must include these parts:\n   - ISO-8601 timestamp with offset.\n   - Short title.\n   - Body paragraph or paragraphs explaining what changed and why.\n   - Optional `Mods touched` subsection when specific mods, plugins, patches, or tools were involved.\n   - Optional `Refs` subsection linking evidence, logs, issue threads, release pages, or xEdit captures.\n6. Append entries newest-first under the `## Entries` section.\n   - Insert the new entry immediately below `## Entries`.\n   - Do not append new entries at the bottom unless the file already uses oldest-first and the user explicitly wants to keep it that way.\n7. Do not duplicate the most recent entry.\n   - Read the newest entry timestamp and title.\n   - If the new title and body would be identical or effectively identical within 10 minutes of the newest entry, surface: \"This looks like a duplicate of `\u003Cexisting title>` from `\u003Ctimestamp>`. Append anyway? (y\u002FN)\"\n   - Default to no if the user does not confirm.\n8. Preserve evidence when the user references it.\n   - If the user points at a captured xEdit conflict, crash log, plugin diff, screenshot, text log, or other local evidence file, copy it into `\u003Cproject>\u002Fdocs\u002Fdev-log-artifacts\u002F\u003Centry-slug>\u002F`.\n   - Link the copied artifact from the entry body or `Refs` subsection.\n   - Prefer copying over linking to a fragile temporary path.\n9. Make the entry useful to a future curator.\n   - Include the decision, cause, tradeoff, or unresolved question.\n   - Avoid entries that only say \"fixed stuff\" or \"updated mods\".\n10. Keep private working noise out of the dev-log.\n    - Do not paste entire terminal transcripts unless they are the evidence.\n    - Summarize the result, then link artifacts.\n11. If the user gave rough notes, preserve meaning rather than polishing away operational details.\n    - Keep mod names, plugin names, load-order context, symptoms, and reproduction facts.\n    - Clean up grammar only enough to make the entry readable.\n12. After writing, report the file path, entry title, timestamp, and any artifacts copied.\n\n## Quick Reference\n\n| Field | Canonical shape | Example |\n| --- | --- | --- |\n| File | `\u003Cproject>\u002Fdocs\u002Fdev-log.md` | `docs\u002Fdev-log.md` |\n| Entry heading | `### \u003Ctimestamp> - \u003Cshort title>` | `### 2026-06-01T14:30:00-04:00 - Rebuilt settlement patch after lighting update` |\n| Body | One or more paragraphs explaining what changed and why | `Updated the settlement compatibility patch after the lighting mod changed precombines in the affected cells.` |\n| Mods touched | Optional bullet list | `- Example Lighting Overhaul` |\n| Refs | Optional bullet list of copied artifacts or external references | `- dev-log-artifacts\u002Frebuilt-settlement-patch\u002Fxedit-conflict-summary.md` |\n\nCanonical entry shape:\n\n```markdown\n### 2026-06-01T14:30:00-04:00 - Rebuilt settlement patch after lighting update\n\nUpdated the settlement compatibility patch after the lighting mod changed records in the affected cells. The new patch keeps the visual change while preserving the workshop keyword edits from the settlement overhaul.\n\n#### Mods touched\n\n- Example Lighting Overhaul\n- Example Settlement Overhaul\n- Example Modpack Patch\n\n#### Refs\n\n- dev-log-artifacts\u002Frebuilt-settlement-patch\u002Fxedit-conflict-summary.md\n```\n\n## Examples\n\n### Bad\n\n```markdown\nFixed the lighting thing.\n```\n\nThis entry has no date, no mod names, no context, no evidence, and no explanation of what was fixed.\n\n### Good\n\n```markdown\n### 2026-06-01T14:30:00-04:00 - Resolved lighting and workshop keyword conflict\n\nKept the lighting overhaul's cell image-space change, but restored the settlement overhaul's workshop keyword edits in the patch. This should preserve the intended visual pass without breaking workshop placement in the affected settlement.\n\n#### Mods touched\n\n- Example Lighting Overhaul\n- Example Settlement Overhaul\n- Example Modpack Patch\n\n#### Refs\n\n- dev-log-artifacts\u002Flighting-workshop-keyword-conflict\u002Fxedit-conflict-summary.md\n```\n\nThis entry tells a future curator what changed, why it changed, which mods were involved, and where the evidence lives.\n\n## Common Mistakes\n\n- Writing a loose note without a timestamp.\n- Logging only the action and omitting the reason.\n- Using the dev-log as public release notes instead of curator history.\n- Duplicating the same entry because the user repeated \"log this\" after a tool run.\n- Linking to temporary evidence paths that will disappear.\n- Copying huge raw logs into the main entry instead of summarizing and linking artifacts.\n- Recording \"updated mods\" without naming the mods.\n- Turning rough curator notes into generic prose that loses load-order context.\n- Asking multiple root-location questions instead of one question with a default.\n- Creating the file somewhere outside the actual modpack project root.\n\n## Rationalizations\n\n| Excuse | Reality |\n| --- | --- |\n| \"This is just a tiny note; it does not need structure.\" | Tiny notes become the only record future agents can trust. Date, title, context, and refs are the minimum useful shape. |\n| \"The release changelog will cover it.\" | The changelog is for players. The dev-log is for curators and future agents. They answer different questions. |\n| \"The evidence is in my terminal scrollback.\" | Scrollback is not durable. Copy evidence into `docs\u002Fdev-log-artifacts\u002F\u003Centry-slug>\u002F` and link it. |\n| \"I can append at the bottom; it is easier.\" | Newest-first keeps the current state visible. Insert below `## Entries` unless the user explicitly chose oldest-first. |\n| \"The user knows what they meant by 'lighting thing'.\" | Future maintainers will not. Name the symptom, mod, plugin, cell, record, or decision. |\n| \"I should ask several questions to make sure the entry is perfect.\" | Ask once for the project root if needed. Otherwise write the best entry from available context and flag uncertainties inline. |\n| \"The artifact path is already linked in the conversation.\" | Conversation links are not project records. Copy or preserve the artifact in the project docs tree. |\n| \"I should make this sound polished.\" | Accuracy beats polish. Keep the operational facts and make the wording readable. |\n\n## See also\n\n- `writing-modpack-changelog` - use for player-facing release notes and version sections.\n- `setting-up-bgs-modding-environment` - use when the modpack project structure itself is being created or located.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FBB-84C\u002Fbgs-modding-superpowers\u002Fskills\u002Fwriting-modpack-devlog",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill writing-modpack-devlog",{"tool":67,"command":68},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill writing-modpack-devlog",{"tool":70,"command":71},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill writing-modpack-devlog","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FBB-84C\u002Fbgs-modding-superpowers\u002Fskills\u002Fwriting-modpack-devlog\u002FSKILL.md",true,[],[76,84,91,98,123,146],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":83},"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":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":83},"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":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":83},"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":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":46},"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",[],[105,106,107,108,109,110,111,112,113,114,115,34,116,117,118,119,44,120,121,122],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","cli","merge","past",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":46},"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",[],[130,131,132,119,133,40,134,135,136,137,138,139,140,141,110,142,33,143,144,145],"deja reflect","reflect","review","with","github","next","https","node","Rules","decisions","brew","remember","project rules","session","end","reflection",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":161,"publishedAt":46},"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",[152,155,158],{"categoryNo":153,"categoryName":154,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":159,"categoryName":160,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[148,162,163,164,165,166,167,33,168,111,169,170,171,172,34,173,174,175,176,177],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]