[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M75MHVCQHWDQMWQSHZBGM4JS":3,"skill-same:01M75MHVCQHWDQMWQSHZBGM4JS":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":26,"repositoryHtmlUrl":27,"repositoryHomepageUrl":28,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M75MHVCQHWDQMWQSHZBGM4JS","gate-before-push",null,"Use before opening a pull request. Reproduce the repository's OWN CI gates locally and make them green first — including its bespoke checks — so the PR arrives green and merges first-try instead of burning scarce CI iterations.","selamy-labs\u002Fagent-skills","selamy-labs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F287832944?v=4","01M75MDKJ0CKAM94KZ7TWQJM5Q","01M75MDKJNP3TATHAW1MX1FWM6",0,"MIT","https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fgate-before-push\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: gate-before-push\ndescription: Use before opening a pull request. Reproduce the repository's OWN CI gates locally and make them green first — including its bespoke checks — so the PR arrives green and merges first-try instead of burning scarce CI iterations.\n---\n\n# gate-before-push\n\nOpen a PR only after it would already go green. Every red CI iteration costs a full runner cycle plus review latency; when runner capacity is constrained, a push-and-pray PR steals capacity from everyone. The fix is to run the **repository's own gates** locally before the push — not \"I ran some tests,\" but the exact checks CI will run.\n\n## Read the gate list from CI — don't guess\n\nThe trap is running the obvious checks (build, unit tests) and missing the **bespoke** ones that only this repo enforces — the gates you'd otherwise discover failing only after a runner picks the PR up.\n\n1. **Open the CI definition** (the workflow \u002F pipeline config) and enumerate every gate step in order: lint, format, type-check, tests + coverage threshold, and the project-specific scanners — secret\u002Fprivacy scanners, dependency\u002Fdenylist drift, license checks, API-stability checks, and PR-title\u002Fcommit-message validators for squash-release repos.\n2. **Run each locally reproducible step's exact command**, in the same order. Use the repo's own scripts (the same entrypoints CI calls), not a paraphrase. Identify platform-only checks explicitly, record the hosted run needed, and keep them pending until they actually pass; do not claim they were reproduced locally.\n3. **Fix locally until all are green.** A bespoke scanner often false-positives on innocent text (e.g. a phrase that resembles a secret pattern); reword and re-run rather than pushing and hoping.\n4. **Match the metadata gates too** — if CI validates the PR title or commit format (conventional commits, squash-release prefixes), confirm yours conforms before opening the PR.\n\n## Validate the input each check actually reads\n\nBefore trusting a passing result, identify whether the check reads the working\ntree, the index, committed `HEAD`, or a composed merge tree. Confirm that its\nfile selection includes every new or renamed path in its scope.\n\nStage intended paths before index-based checks. Run `HEAD`-enumerating checks\nafter the local commit and before pushing or opening the PR: a scanner using\n`git ls-tree HEAD` cannot see an uncommitted addition. When CI validates a\ncomposed merge tree, use the repository's existing check for that result.\n\nFor qualification or preparation, follow wrappers and package scripts to the\ngate they actually invoke. Verify its input preconditions, including base\u002Fhead\nidentity and required ancestry; accepted CLI arguments alone do not establish\nvalid inputs. A receipt consumer's narrower predicate does not waive an\ninvoked gate's requirement. Preserve valid evidence and use the repository's\nsupported branch-history preparation.\n\nPrefer existing cheap native filename, structure, and metadata validators.\nWhen file inclusion is unclear, use a focused control to verify the changed\npath is checked. Reuse valid results for unchanged inputs where repository\npolicy permits; do not repeat a full suite merely to rerun a cheap enumeration\ncheck.\n\nFor changes to a shared boundary, identify its affected consumers and run their\nrelevant existing suites, even outside the edited package. A success fixture\nmust satisfy the boundary's production contract; use small valid artifacts and\nreserve malformed data for rejection cases. Passing each gate category does\nnot establish that the affected test scope ran.\n\n## Why bespoke-first\n\nGeneric checks rarely fail twice; the **repo-specific** scanners and validators are where push-and-pray loses. Those are exactly the cheap-to-run, expensive-to-discover-remotely gates — running them locally is the highest-leverage minute you spend.\n\n## Tell the visual story when the evidence already exists\n\nWhen a UI change naturally produces useful before\u002Fafter screenshots, golden images, or rendered design evidence, embed those images directly in the PR description with clear **Before** and **After** labels and one concise sentence explaining the visible outcome. Use durable GitHub-renderable URLs so the comparison remains visible after temporary CI artifacts expire.\n\nDo not assume that a durable source URL is renderable. In access-controlled repositories, direct `raw.githubusercontent.com` and repository blob URLs may resolve for an authenticated contributor while GitHub's image renderer receives no authorization and shows a broken image. Upload evidence through GitHub's attachment flow when necessary and embed the resulting `github.com\u002Fuser-attachments` URL, or use another durable URL that the rendered PR can retrieve.\n\nAfter saving the PR description, inspect the rendered PR page rather than only the Markdown source or API response. Verify that each expected image completed loading with non-zero rendered dimensions (for example, `naturalWidth > 0` and `naturalHeight > 0`) and that the Before\u002FAfter labels still map to the intended files. Repair broken evidence before calling the PR ready.\n\nTreat this as a high-value opportunity, not a universal gate. Do not manufacture low-signal screenshots for every PR or delay delivery to create them. The rule is to surface strong visual evidence that already exists instead of burying it in CI artifacts, files, or comments.\n\n## Pairs with\n\n- `stacked-diff-discipline`: validate each layer on its actual parent and the selected stack's cumulative result. Bound runner use with verified workflow controls; draft status alone does not suppress CI. Qualify a ready prefix before group merge rather than waiting for every parent to merge first.\n- Green locally is **not** done: done is merged + the artifact verified on the default branch, not a passing local run.\n\n## DONE means\n\nBefore the PR opened, locally reproducible gates passed using the repository's\nown entrypoints, including bespoke scanners and metadata validators.\nPlatform-only checks have explicit pending runs and must succeed before merge.\nAvoid CI iterations on failures discoverable locally; investigate hosted or\ninfrastructure failures from actual evidence rather than claiming local proof.\nWhen visual evidence was embedded, inspect the saved rendered PR and verify\nevery expected image loaded with non-zero dimensions.\n\nSources: shift-left \u002F fail-fast testing practice; trunk-based development pre-merge checks; conventional-commit release gating.\n","# gate-before-push\n\nOpen a PR only after it would already go green. Every red CI iteration costs a full runner cycle plus review latency; when runner capacity is constrained, a push-and-pray PR steals capacity from everyone. The fix is to run the **repository's own gates** locally before the push — not \"I ran some tests,\" but the exact checks CI will run.\n\n## Read the gate list from CI — don't guess\n\nThe trap is running the obvious checks (build, unit tests) and missing the **bespoke** ones that only this repo enforces — the gates you'd otherwise discover failing only after a runner picks the PR up.\n\n1. **Open the CI definition** (the workflow \u002F pipeline config) and enumerate every gate step in order: lint, format, type-check, tests + coverage threshold, and the project-specific scanners — secret\u002Fprivacy scanners, dependency\u002Fdenylist drift, license checks, API-stability checks, and PR-title\u002Fcommit-message validators for squash-release repos.\n2. **Run each locally reproducible step's exact command**, in the same order. Use the repo's own scripts (the same entrypoints CI calls), not a paraphrase. Identify platform-only checks explicitly, record the hosted run needed, and keep them pending until they actually pass; do not claim they were reproduced locally.\n3. **Fix locally until all are green.** A bespoke scanner often false-positives on innocent text (e.g. a phrase that resembles a secret pattern); reword and re-run rather than pushing and hoping.\n4. **Match the metadata gates too** — if CI validates the PR title or commit format (conventional commits, squash-release prefixes), confirm yours conforms before opening the PR.\n\n## Validate the input each check actually reads\n\nBefore trusting a passing result, identify whether the check reads the working\ntree, the index, committed `HEAD`, or a composed merge tree. Confirm that its\nfile selection includes every new or renamed path in its scope.\n\nStage intended paths before index-based checks. Run `HEAD`-enumerating checks\nafter the local commit and before pushing or opening the PR: a scanner using\n`git ls-tree HEAD` cannot see an uncommitted addition. When CI validates a\ncomposed merge tree, use the repository's existing check for that result.\n\nFor qualification or preparation, follow wrappers and package scripts to the\ngate they actually invoke. Verify its input preconditions, including base\u002Fhead\nidentity and required ancestry; accepted CLI arguments alone do not establish\nvalid inputs. A receipt consumer's narrower predicate does not waive an\ninvoked gate's requirement. Preserve valid evidence and use the repository's\nsupported branch-history preparation.\n\nPrefer existing cheap native filename, structure, and metadata validators.\nWhen file inclusion is unclear, use a focused control to verify the changed\npath is checked. Reuse valid results for unchanged inputs where repository\npolicy permits; do not repeat a full suite merely to rerun a cheap enumeration\ncheck.\n\nFor changes to a shared boundary, identify its affected consumers and run their\nrelevant existing suites, even outside the edited package. A success fixture\nmust satisfy the boundary's production contract; use small valid artifacts and\nreserve malformed data for rejection cases. Passing each gate category does\nnot establish that the affected test scope ran.\n\n## Why bespoke-first\n\nGeneric checks rarely fail twice; the **repo-specific** scanners and validators are where push-and-pray loses. Those are exactly the cheap-to-run, expensive-to-discover-remotely gates — running them locally is the highest-leverage minute you spend.\n\n## Tell the visual story when the evidence already exists\n\nWhen a UI change naturally produces useful before\u002Fafter screenshots, golden images, or rendered design evidence, embed those images directly in the PR description with clear **Before** and **After** labels and one concise sentence explaining the visible outcome. Use durable GitHub-renderable URLs so the comparison remains visible after temporary CI artifacts expire.\n\nDo not assume that a durable source URL is renderable. In access-controlled repositories, direct `raw.githubusercontent.com` and repository blob URLs may resolve for an authenticated contributor while GitHub's image renderer receives no authorization and shows a broken image. Upload evidence through GitHub's attachment flow when necessary and embed the resulting `github.com\u002Fuser-attachments` URL, or use another durable URL that the rendered PR can retrieve.\n\nAfter saving the PR description, inspect the rendered PR page rather than only the Markdown source or API response. Verify that each expected image completed loading with non-zero rendered dimensions (for example, `naturalWidth > 0` and `naturalHeight > 0`) and that the Before\u002FAfter labels still map to the intended files. Repair broken evidence before calling the PR ready.\n\nTreat this as a high-value opportunity, not a universal gate. Do not manufacture low-signal screenshots for every PR or delay delivery to create them. The rule is to surface strong visual evidence that already exists instead of burying it in CI artifacts, files, or comments.\n\n## Pairs with\n\n- `stacked-diff-discipline`: validate each layer on its actual parent and the selected stack's cumulative result. Bound runner use with verified workflow controls; draft status alone does not suppress CI. Qualify a ready prefix before group merge rather than waiting for every parent to merge first.\n- Green locally is **not** done: done is merged + the artifact verified on the default branch, not a passing local run.\n\n## DONE means\n\nBefore the PR opened, locally reproducible gates passed using the repository's\nown entrypoints, including bespoke scanners and metadata validators.\nPlatform-only checks have explicit pending runs and must succeed before merge.\nAvoid CI iterations on failures discoverable locally; investigate hosted or\ninfrastructure failures from actual evidence rather than claiming local proof.\nWhen visual evidence was embedded, inspect the saved rendered PR and verify\nevery expected image loaded with non-zero dimensions.\n\nSources: shift-left \u002F fail-fast testing practice; trunk-based development pre-merge checks; conventional-commit release gating.\n",{"name":5,"description":7},"main","54007b08157feb09e5bb9d7ff5ce4ddd21625dbf","skills\u002Fgate-before-push",3,"https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills","https:\u002F\u002Fselamy.dev","https:\u002F\u002Fgithub.com\u002Fselamy-labs","2026-11-15 03:50:58",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add selamy-labs\u002Fagent-skills --skill gate-before-push",{"tool":37,"command":38},"bunx","bunx skills add selamy-labs\u002Fagent-skills --skill gate-before-push",{"tool":40,"command":41},"pnpm","pnpm dlx skills add selamy-labs\u002Fagent-skills --skill gate-before-push","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fgate-before-push\u002FSKILL.md",true,[],[46,53,60,67,73,80],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":18},"01M75MY70JMSNFHQX63G90SKZ7","silence-phrase","A seemingly normal skill.","https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsilence-phrase\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":18},"01M75MY5PKVKY60M8H2DFTW58C","selamy-bad-skill","This skill has a vendor prefix that should be rejected.","https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fprefixed-name\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":18},"01M75MY1TKXCH6WYN9ET0W4T02","oversized-description","This is a very long description that contains way too many words and should be rejected by the validator because it exceeds the forty five word limit that is enforced by the naming lint checker which ensures skill descriptions stay concise and readable for humans and machines alike without unnecessary verbosity or padding","https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Foversized-description\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":18},"01M75MY0SZ7EKT99NWJEJ8HKS2","missing-frontmatter","https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmissing-frontmatter\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":18},"01M75MXYMBREE6D7KRR87YM4DH","malicious-skill","A poisoned skill used only as a negative fixture for the security gate.","https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmalicious-skill\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":18},"01M75MXX2B7AC2QSSRRQQXTA0N","leaking-org-name","A skill about something.","https:\u002F\u002Fgithub.com\u002Fselamy-labs\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fleaking-org-name\u002FSKILL.md",[],[]]