[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6M956JG7CXB5XWB65DR4DA2":3,"skill-same:01M6M956JG7CXB5XWB65DR4DA2":93},{"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":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6M956JG7CXB5XWB65DR4DA2","suede-ci-gate",null,"Suede AI CI Gate Skills. Use when asked to \"fix a required check stuck pending\" or set up branch protection and path-aware CI, runtime\u002Flockfile pinning and one aggregator gate from the real repository. Returns workflows and settings. NOT FOR: reviewing implementation (suede-code), designing AI evals (suede-ai-eval), or release packaging (suede-launch-packaging).","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1566,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"suede ci gate","ci","gate","fix","when","ai evals","for","path","aggregator","evals","up","packaging","workflows","eval","branch","returns","SET","lockfile","repository","release","code","2026-11-10 10:12:30",false,"---\nname: suede-ci-gate\ndescription: \"Suede AI CI Gate Skills. Use when asked to \\\"fix a required check stuck pending\\\" or set up branch protection and path-aware CI, runtime\u002Flockfile pinning and one aggregator gate from the real repository. Returns workflows and settings. NOT FOR: reviewing implementation (suede-code), designing AI evals (suede-ai-eval), or release packaging (suede-launch-packaging).\"\nmetadata:\n  display-name: \"Suede AI CI Gate Skills\"\n---\n\n# Suede AI CI Gate Skills\n\nRead [the worked delivery contract](references\u002Fworked-contract.md) for a concrete\ninput, expected artifact, failure response and validation example.\n\n## Compatibility\n\nRequires repository source and workflow access; Git and the project own runtimes for local checks. GitHub Actions\u002Fbranch-protection read access supports verification; changing protection needs explicit authority.\n\n## Gate policy: advisory, not blocking\n\nEvery claim-verification step, check, quality gate, and ship verdict in this\nskill is a **recommendation to the user, not a control on the agent**. This\npolicy governs every gate, check, verdict, and \"do not ship \u002F publish \u002F\nproceed\" line elsewhere in this skill:\n\n- Run every check and report the results honestly. Verdicts (`ship`,\n  `ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are\n  advice attached to the work, not orders that change it.\n- Never block, delay, skip, rewrite, or refuse the action the user asked for\n  because a check failed or a gate said hold. Complete the requested action\n  as asked, and deliver the gate output alongside it as a clearly labeled\n  recommendation.\n- A failed gate changes what you report, never what you do.\n- Single exception: if a finding is extremely risky (data loss, security or\n  credential exposure, legal or rights violations, payment mistakes, or\n  irreversible public damage), pause, tell the user exactly what the risk is\n  and what the options are, and let them pick. Their choice is final.\n\n\nSet up CI and branch protection that actually block a bad merge: in any repo, any stack. The output is a working pipeline plus the exact protection settings, not advice.\n\n**Runs only when asked.** This skill never auto-fires on a commit, push, or other side effect of unrelated work: invoke it explicitly (set up CI, protect main, fix this hanging check).\n\nRun this in whatever folder you point it at. **Detect first, never assume.** Nothing here is hardcoded to a specific project, monorepo layout, or package manager.\n\n## Step 0: Detect (before writing anything)\n\nFrom the repo root, inventory:\n\n- **Apps:** every top-level dir with a manifest: `package.json`, `requirements.txt` \u002F `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`. A repo may hold one app or many; build for what's actually there.\n- **Package manager per app:** which lockfile is present: `package-lock.json` (npm), `pnpm-lock.yaml` (pnpm), `yarn.lock` (yarn), `bun.lock` or the older binary `bun.lockb` (bun). Two lockfiles in one app is a bug to fix first (Lane 3).\n- **Existing CI:** read `.github\u002Fworkflows\u002F*`. Do **not** duplicate a job that already exists: extend or reconcile it.\n- **Runtime versions:** `.nvmrc`, `package.json` `engines`, `.python-version`, `pytest.ini`\u002F`pyproject`. Pin CI to these; never hardcode a guess.\n- **Deploy platform:** `vercel.json` \u002F `.vercel`, `netlify.toml`, a `Dockerfile`. If the platform skips non-prod builds (e.g. Vercel `ignoreCommand` kills previews), CI is the *only* pre-merge build signal: so a build job is mandatory.\n- **Real scripts:** read each app's `scripts` \u002F test config and use the real ones (`test`, `test:run`, `lint`, `build`). Don't invent commands.\n\nDo not write a single workflow line until this inventory is complete.\n\n## The gate (the part everyone gets wrong)\n\nPath-filtered jobs **skip** when their paths aren't touched. A skipped job that is a *required* status check leaves the PR pending forever. So never require the path-filtered jobs directly. Instead add one **aggregator** that depends on all of them:\n\n```yaml\n  ci-success:\n    if: always()\n    needs: [\u003Cevery app job>]\n    runs-on: ubuntu-latest\n    steps:\n      - name: Gate on all jobs\n        run: |\n          for r in ${{ join(needs.*.result, ' ') }}; do\n            [ \"$r\" = \"success\" ] || [ \"$r\" = \"skipped\" ] || { echo \"blocked by: $r\"; exit 1; }\n          done\n```\n\nIn branch protection, require **only `ci-success`**: never the individual jobs. This is the single thing that makes \"protect main\" work with change-based CI.\n\n## Lanes\n\n1. **Path-aware jobs**: one job per app, gated by a `changes` job (`dorny\u002Fpaths-filter` or native `paths:`). Add an escape hatch so edits to the workflow file itself run everything.\n2. **Aggregator gate**: as above. The only required check is `ci-success`.\n3. **Lockfile hygiene**: exactly one lockfile per app, and the install command must match it (`npm ci`, `pnpm i --frozen-lockfile`, `yarn --immutable`, `bun install --frozen-lockfile`). Two lockfiles means CI can install a different tree than ships: resolve before wiring CI.\n4. **Pin runtimes from the repo**: Node\u002FPython\u002Fetc. read from `.nvmrc` \u002F `engines` \u002F `.python-version`, falling back to the platform default. Never a hardcoded guess that drifts from prod.\n5. **Don't duplicate existing CI**: if a workflow already covers an app (e.g. a backend test workflow), extend it; never stack a second, weaker job on top.\n6. **Least privilege**: `permissions: contents: read` unless a job genuinely needs more.\n7. **Build is a gate when previews are off**: if the deploy platform skips non-prod builds, the CI build is your only pre-merge proof the app compiles. Keep it.\n8. **Branch protection**: output the exact settings: require `ci-success`, require branches up to date before merge, optional required PR review, block force-push and deletion, optionally include administrators. GitHub offers two mechanisms: classic branch protection and repository rulesets (Settings → Rules → Rulesets), which can target many branches and stack. Match whichever the repo already uses; for a new setup on GitHub, prefer a ruleset with `ci-success` as the required status check.\n\n## Instant-fail patterns (CI that looks green but isn't)\n\n- A required check that is a path-filtered job → deadlocks every unrelated PR. Use the aggregator.\n- `npm ci` with no committed lockfile, or a lockfile for a different manager → fails or installs the wrong tree.\n- A second job duplicating an existing workflow → wasted minutes and conflicting signal.\n- Hardcoded `node-version` \u002F `python-version` that doesn't match the app → green in CI, broken in prod.\n- A job whose `paths:` never match → always skipped → a \"green\" check that tested nothing.\n\n## Red flags: stop\n\nThe excuses that precede a broken gate:\n\n- \"Just require each job directly\": a skipped path-filtered job deadlocks every unrelated PR. The aggregator is the only required check.\n- \"CI is green\": green because it ran, or green because everything skipped? Name what actually executed.\n- \"One big workflow that builds everything is simpler\": it also builds the world on a README typo. Path-filter it.\n- \"We'll protect main after launch\": the riskiest merges happen before launch.\n- \"The deploy platform builds it anyway\": if previews are off, CI is the only pre-merge proof the app compiles.\n\n## Output\n\n1. The workflow file(s) under `.github\u002Fworkflows\u002F`.\n2. The exact branch-protection settings to apply (and the `gh api` calls, if asked).\n3. A short report: apps detected, package manager per app, what each job runs, what is required, and anything to fix first (dual lockfiles, duplicate workflows, runtime mismatches).\n4. **Readback, once the settings have been applied** (the user applies them, this skill does not): verify rather than assume. `gh api repos\u002F:owner\u002F:repo\u002Fbranches\u002Fmain\u002Fprotection --jq '.required_status_checks.contexts'` must return exactly `[\"ci-success\"]` (any path-filtered job in that list is the deadlock above); for a ruleset, `gh api repos\u002F:owner\u002F:repo\u002Frules\u002Fbranches\u002Fmain` must show a `required_status_checks` rule naming only `ci-success`; and `gh run list --branch \u003Cpr-branch>` must show `ci-success` actually ran, not skipped. If the settings are not applied yet or the token lacks admin scope, report the gate as **unverified**; never claim protection is live from the settings you emitted.\n\nEnd with a **Simple explanation (plain, for a 10-year-old)**: one short paragraph, no jargon, saying what the gate now does and what it blocks: e.g. \"Before anyone's changes join the main project, a robot builds and tests them. If the robot fails, the merge button locks.\"\n\n## Worked Example\n\nA full pass on one repository (from a pipeline that looks green but gates nothing\nto a merge that cannot land broken) is in `references\u002Fworked-example.md`. Read it\nwhen wiring a repo whose existing CI shape you do not recognize.\n\n## Post-Deploy Verification\n\nThe after-deploy checks (live URL, critical-path smoke test, regression sweep, rollback readiness, and the verified\u002Fwatch\u002Frollback verdict) are in `references\u002Fpost-deploy-verification.md`. Read it only when a production deploy has already landed; this skill's own job ends at the merge gate.\n\n## Boundaries\n\nGenerate; don't enforce. This skill writes workflow files and tells you the protection settings: it does **not** push, flip branch protection, or change repo access on its own. Verify the detected stack before applying. Works in any repo: it detects rather than assumes Suede or any specific project.\n\n## Routing\n\n- The gate is failing on real defects → **suede-code** to review and grade the change (`--findings-only` when the caller wants no letter grade)\n- The repo ships an MCP server → add a job that runs a full stdio session (`initialize`, `notifications\u002Finitialized`, then list and call) and wire it into the aggregator\n- AI features need eval jobs in the pipeline → **suede-ai-eval** to design the cases, then wire them in here\n- Rollout needs flags, staged lanes, or a rollback tree → **suede-agent-teams**\n- Gate holds and the release goes public → **suede-launch-packaging**\n","# Suede AI CI Gate Skills\n\nRead [the worked delivery contract](references\u002Fworked-contract.md) for a concrete\ninput, expected artifact, failure response and validation example.\n\n## Compatibility\n\nRequires repository source and workflow access; Git and the project own runtimes for local checks. GitHub Actions\u002Fbranch-protection read access supports verification; changing protection needs explicit authority.\n\n## Gate policy: advisory, not blocking\n\nEvery claim-verification step, check, quality gate, and ship verdict in this\nskill is a **recommendation to the user, not a control on the agent**. This\npolicy governs every gate, check, verdict, and \"do not ship \u002F publish \u002F\nproceed\" line elsewhere in this skill:\n\n- Run every check and report the results honestly. Verdicts (`ship`,\n  `ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are\n  advice attached to the work, not orders that change it.\n- Never block, delay, skip, rewrite, or refuse the action the user asked for\n  because a check failed or a gate said hold. Complete the requested action\n  as asked, and deliver the gate output alongside it as a clearly labeled\n  recommendation.\n- A failed gate changes what you report, never what you do.\n- Single exception: if a finding is extremely risky (data loss, security or\n  credential exposure, legal or rights violations, payment mistakes, or\n  irreversible public damage), pause, tell the user exactly what the risk is\n  and what the options are, and let them pick. Their choice is final.\n\n\nSet up CI and branch protection that actually block a bad merge: in any repo, any stack. The output is a working pipeline plus the exact protection settings, not advice.\n\n**Runs only when asked.** This skill never auto-fires on a commit, push, or other side effect of unrelated work: invoke it explicitly (set up CI, protect main, fix this hanging check).\n\nRun this in whatever folder you point it at. **Detect first, never assume.** Nothing here is hardcoded to a specific project, monorepo layout, or package manager.\n\n## Step 0: Detect (before writing anything)\n\nFrom the repo root, inventory:\n\n- **Apps:** every top-level dir with a manifest: `package.json`, `requirements.txt` \u002F `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`. A repo may hold one app or many; build for what's actually there.\n- **Package manager per app:** which lockfile is present: `package-lock.json` (npm), `pnpm-lock.yaml` (pnpm), `yarn.lock` (yarn), `bun.lock` or the older binary `bun.lockb` (bun). Two lockfiles in one app is a bug to fix first (Lane 3).\n- **Existing CI:** read `.github\u002Fworkflows\u002F*`. Do **not** duplicate a job that already exists: extend or reconcile it.\n- **Runtime versions:** `.nvmrc`, `package.json` `engines`, `.python-version`, `pytest.ini`\u002F`pyproject`. Pin CI to these; never hardcode a guess.\n- **Deploy platform:** `vercel.json` \u002F `.vercel`, `netlify.toml`, a `Dockerfile`. If the platform skips non-prod builds (e.g. Vercel `ignoreCommand` kills previews), CI is the *only* pre-merge build signal: so a build job is mandatory.\n- **Real scripts:** read each app's `scripts` \u002F test config and use the real ones (`test`, `test:run`, `lint`, `build`). Don't invent commands.\n\nDo not write a single workflow line until this inventory is complete.\n\n## The gate (the part everyone gets wrong)\n\nPath-filtered jobs **skip** when their paths aren't touched. A skipped job that is a *required* status check leaves the PR pending forever. So never require the path-filtered jobs directly. Instead add one **aggregator** that depends on all of them:\n\n```yaml\n  ci-success:\n    if: always()\n    needs: [\u003Cevery app job>]\n    runs-on: ubuntu-latest\n    steps:\n      - name: Gate on all jobs\n        run: |\n          for r in ${{ join(needs.*.result, ' ') }}; do\n            [ \"$r\" = \"success\" ] || [ \"$r\" = \"skipped\" ] || { echo \"blocked by: $r\"; exit 1; }\n          done\n```\n\nIn branch protection, require **only `ci-success`**: never the individual jobs. This is the single thing that makes \"protect main\" work with change-based CI.\n\n## Lanes\n\n1. **Path-aware jobs**: one job per app, gated by a `changes` job (`dorny\u002Fpaths-filter` or native `paths:`). Add an escape hatch so edits to the workflow file itself run everything.\n2. **Aggregator gate**: as above. The only required check is `ci-success`.\n3. **Lockfile hygiene**: exactly one lockfile per app, and the install command must match it (`npm ci`, `pnpm i --frozen-lockfile`, `yarn --immutable`, `bun install --frozen-lockfile`). Two lockfiles means CI can install a different tree than ships: resolve before wiring CI.\n4. **Pin runtimes from the repo**: Node\u002FPython\u002Fetc. read from `.nvmrc` \u002F `engines` \u002F `.python-version`, falling back to the platform default. Never a hardcoded guess that drifts from prod.\n5. **Don't duplicate existing CI**: if a workflow already covers an app (e.g. a backend test workflow), extend it; never stack a second, weaker job on top.\n6. **Least privilege**: `permissions: contents: read` unless a job genuinely needs more.\n7. **Build is a gate when previews are off**: if the deploy platform skips non-prod builds, the CI build is your only pre-merge proof the app compiles. Keep it.\n8. **Branch protection**: output the exact settings: require `ci-success`, require branches up to date before merge, optional required PR review, block force-push and deletion, optionally include administrators. GitHub offers two mechanisms: classic branch protection and repository rulesets (Settings → Rules → Rulesets), which can target many branches and stack. Match whichever the repo already uses; for a new setup on GitHub, prefer a ruleset with `ci-success` as the required status check.\n\n## Instant-fail patterns (CI that looks green but isn't)\n\n- A required check that is a path-filtered job → deadlocks every unrelated PR. Use the aggregator.\n- `npm ci` with no committed lockfile, or a lockfile for a different manager → fails or installs the wrong tree.\n- A second job duplicating an existing workflow → wasted minutes and conflicting signal.\n- Hardcoded `node-version` \u002F `python-version` that doesn't match the app → green in CI, broken in prod.\n- A job whose `paths:` never match → always skipped → a \"green\" check that tested nothing.\n\n## Red flags: stop\n\nThe excuses that precede a broken gate:\n\n- \"Just require each job directly\": a skipped path-filtered job deadlocks every unrelated PR. The aggregator is the only required check.\n- \"CI is green\": green because it ran, or green because everything skipped? Name what actually executed.\n- \"One big workflow that builds everything is simpler\": it also builds the world on a README typo. Path-filter it.\n- \"We'll protect main after launch\": the riskiest merges happen before launch.\n- \"The deploy platform builds it anyway\": if previews are off, CI is the only pre-merge proof the app compiles.\n\n## Output\n\n1. The workflow file(s) under `.github\u002Fworkflows\u002F`.\n2. The exact branch-protection settings to apply (and the `gh api` calls, if asked).\n3. A short report: apps detected, package manager per app, what each job runs, what is required, and anything to fix first (dual lockfiles, duplicate workflows, runtime mismatches).\n4. **Readback, once the settings have been applied** (the user applies them, this skill does not): verify rather than assume. `gh api repos\u002F:owner\u002F:repo\u002Fbranches\u002Fmain\u002Fprotection --jq '.required_status_checks.contexts'` must return exactly `[\"ci-success\"]` (any path-filtered job in that list is the deadlock above); for a ruleset, `gh api repos\u002F:owner\u002F:repo\u002Frules\u002Fbranches\u002Fmain` must show a `required_status_checks` rule naming only `ci-success`; and `gh run list --branch \u003Cpr-branch>` must show `ci-success` actually ran, not skipped. If the settings are not applied yet or the token lacks admin scope, report the gate as **unverified**; never claim protection is live from the settings you emitted.\n\nEnd with a **Simple explanation (plain, for a 10-year-old)**: one short paragraph, no jargon, saying what the gate now does and what it blocks: e.g. \"Before anyone's changes join the main project, a robot builds and tests them. If the robot fails, the merge button locks.\"\n\n## Worked Example\n\nA full pass on one repository (from a pipeline that looks green but gates nothing\nto a merge that cannot land broken) is in `references\u002Fworked-example.md`. Read it\nwhen wiring a repo whose existing CI shape you do not recognize.\n\n## Post-Deploy Verification\n\nThe after-deploy checks (live URL, critical-path smoke test, regression sweep, rollback readiness, and the verified\u002Fwatch\u002Frollback verdict) are in `references\u002Fpost-deploy-verification.md`. Read it only when a production deploy has already landed; this skill's own job ends at the merge gate.\n\n## Boundaries\n\nGenerate; don't enforce. This skill writes workflow files and tells you the protection settings: it does **not** push, flip branch protection, or change repo access on its own. Verify the detected stack before applying. Works in any repo: it detects rather than assumes Suede or any specific project.\n\n## Routing\n\n- The gate is failing on real defects → **suede-code** to review and grade the change (`--findings-only` when the caller wants no letter grade)\n- The repo ships an MCP server → add a job that runs a full stdio session (`initialize`, `notifications\u002Finitialized`, then list and call) and wire it into the aggregator\n- AI features need eval jobs in the pipeline → **suede-ai-eval** to design the cases, then wire them in here\n- Rollout needs flags, staged lanes, or a rollback tree → **suede-agent-teams**\n- Gate holds and the release goes public → **suede-launch-packaging**\n",{"name":5,"metadata":45,"description":7},{"display-name":46},"Suede AI CI Gate Skills","main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate",483,"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-13 02:16:32",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill suede-ci-gate",{"tool":63,"command":64},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill suede-ci-gate",{"tool":66,"command":67},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill suede-ci-gate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate\u002FSKILL.md",true,[71,77,81,85,89],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"agents\u002Fopenai.yaml","REFERENCE","参考文档",346,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate\u002Fagents\u002Fopenai.yaml",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"CARD.md",4193,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate\u002FCARD.md",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fpost-deploy-verification.md",1420,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate\u002Freferences\u002Fpost-deploy-verification.md",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fworked-contract.md",2026,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate\u002Freferences\u002Fworked-contract.md",{"path":90,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fworked-example.md",4698,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJasonColapietro\u002Fsuede-creator-skills\u002Fskills\u002Fsuede-ci-gate\u002Freferences\u002Fworked-example.md",[94,102,109,116,141,166],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":101},"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":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":101},"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":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":101},"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":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":40},"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",[],[123,124,125,126,127,128,129,130,22,131,132,23,133,134,135,136,137,138,139,140],"search","deja search","never","error","ready","memory","re","decide","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":40},"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",[],[148,149,150,136,151,152,153,154,155,156,157,158,159,160,128,161,162,163,164,165],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":183,"publishedAt":40},"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",[172,177,180],{"categoryNo":173,"categoryName":174,"taxonomyType":175,"taxonomyTypeDesc":176},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":178,"categoryName":179,"taxonomyType":175,"taxonomyTypeDesc":176},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":181,"categoryName":182,"taxonomyType":175,"taxonomyTypeDesc":176},"01JBSEEDCAT000000000000010","后端与接口",[168,184,185,186,187,188,189,162,190,129,191,192,193,194,23,195,196,197,198,199],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]