[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CW1X5455SWPRBDYVGAB0MX":3,"skill-same:01M7CW1X5455SWPRBDYVGAB0MX":45},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":29,"updatedAt":30,"install":31,"resources":44},"01M7CW1X5455SWPRBDYVGAB0MX","dsh-pre-push-checks",null,"Use before pushing, force-pushing, marking ready for review, or claiming checks pass on a deepseek-harness branch, and immediately after gh stack sync publishes rewritten branches, to select the smallest tests and checks that cover the outgoing or just-published diff without reflexively running the full repository suite.","ryasrk\u002Fdsh-expert-agents","ryasrk","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F115061102?v=4","01M7CW079PK1VJJZPP5KXWFRXN","Ryas Rafi Karim","01M7CW07AKNEJV8913PZB163JK",0,"MIT","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fdsh-pre-push-checks\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: dsh-pre-push-checks\ndescription: Use before pushing, force-pushing, marking ready for review, or claiming checks pass on a deepseek-harness branch, and immediately after gh stack sync publishes rewritten branches, to select the smallest tests and checks that cover the outgoing or just-published diff without reflexively running the full repository suite.\n---\n\n# DSH Pre-Push Checks\n\nUse this skill to run relevant local evidence once before a `deepseek-harness` push. The sole ordering exception is `gh stack sync`, which may publish a cascading rebase before the rewritten layers can be validated; validate them immediately afterward and do not merge until the evidence passes. Git hooks are intentionally narrow: pre-commit fixes staged lint, checks staged whitespace, and guards vendored-source metadata; pre-push runs only the incremental repository typecheck. CI owns exhaustive coverage and the platform matrix.\n\n## Inspect the outgoing change\n\n1. Confirm the checkout and branch.\n\n```sh\ngit status --short --branch\ngit rev-parse --show-toplevel\n```\n\n2. Verify the live PR base or stack parent, fetch that ref, and inspect the complete scope against it.\n\n```sh\npnpm --silent run change-scope --base \u003Cverified-base-ref>\n```\n\nThe command never guesses or fetches a base. Supply the ref verified from current remote or stack state; use `--head \u003Cref>` when inspecting a commit other than `HEAD`. Its versioned JSON records committed paths relative to the resolved merge base, while staged, unstaged, and untracked paths describe the current worktree. After merging a changed base, rerun the report, reassess which behavior the combined scope can affect, and rerun only checks invalidated by the merge.\n\n## Select relevant evidence\n\nThere is no universal local baseline beyond the hooks. Every behavior change needs the narrowest available test or purpose-built check that would fail for its regression; add broader checks only for surfaces the diff actually reaches.\n\nWhen the outgoing change adds or changes a resource-owning or asynchronous test, fixture, helper, or CI execution path, use [dsh-ci-test-reliability](..\u002Fdsh-ci-test-reliability\u002FSKILL.md) first to decide whether restoration, negative-control, quiescent-teardown, or concurrent-process evidence applies. This skill still selects the commands and avoids repeating evidence that already passed.\n\n- **Package or script behavior:** run the owning Vitest file or focused test name. Add adjacent package tests when a shared contract changes; leave repository-wide coverage to CI unless the change is genuinely cross-cutting or the user requests it.\n- **Remote mock typing:** unbuilt `any` is an explicit local fallback, not strict evidence. Run `pnpm run typecheck` before handing off Remote\u002Fmock changes; rebuild missing, stale, or partial generated declarations before diagnosing remaining errors. Keep the exception in the [test proxy](..\u002F..\u002F..\u002Fpackages\u002Ftest-support\u002Fremote-mock\u002FREADME.md#remote-proxy), never in production Remote types, ambient flags, or copied signatures.\n- **Documentation, Agent Notes, catalogs, or doc-linked comments:** run `pnpm run doc-sync`; run full lint when the documentation workflow requires it.\n- **Model-, editor-, CLI-, or terminal-visible output:** run the focused keyless snapshot or real runnable-example scenario that owns the output.\n- **Expected-output placement:** a test whose selected recorded Session generation is replay input and expected persisted output belongs under top-level `snapshots\u002F`, with `snapshot.yml` naming its shipped `dsh` profile and composition\u002Fheader pin. Canonical parent files are `session[.vN].jsonl`, children are `session.\u003Cordinal>[.vN].jsonl`, and the harness selects the highest generation per role. ARIA, geometry, generator, CLI, and unit expectations without that Session round trip stay beside their owning test under `tests\u002Fexpected\u002F`; do not place them in `snapshots\u002F` or give them a `*.snapshot.ts` owner. Use the owning `test:expected`, `test:web`, or `test` lane.\n- **Profile and configuration placement:** cross-package behavior of a shipped `dsh` profile belongs under `apps\u002Fcli\u002Ftests\u002Fprofiles\u002F`; a package-specific Loader composition belongs under that package's `tests\u002Ffixtures\u002F`. User-facing optional overlays live under `apps\u002Fcli\u002Fconfig\u002Fexamples\u002F` and pair with a guide under `docs\u002Fuser\u002F`.\n- **Package manifests, public exports, build configuration, worker\u002Fbin entries, or built runtime paths:** run `pnpm run build`, the relevant hygiene checks, and the owning built-artifact smoke.\n- **Real provider or agent behavior:** run the relevant `pnpm run test:e2e` target when credentials are available; never print secrets.\n\nDo not manually repeat a passing check merely because commit or push follows. In particular, do not run typecheck immediately before pushing solely to duplicate the pre-push hook.\n\nPass Vitest file and name filters directly after the script name with `pnpm run`; do not insert a standalone `--`, which reaches Vitest and can disable `-t` filtering. For example, this command runs one headless snapshot scenario:\n\n```sh\npnpm run test:snapshot snapshots\u002Fsession\u002Fheadless.snapshot.ts -t 'cordis-inspect-jsdoc'\n```\n\nThis applies to these pnpm scripts; npm and other launchers retain their own argument-forwarding syntax. Check the reported selected test count before treating a filtered run as focused evidence.\n\n### Focus unit coverage on the affected source\n\nTest selection and coverage selection are separate. A Vitest file filter chooses which tests run, while the repository configuration otherwise measures every `packages\u002F*\u002F*\u002Fsrc\u002F**\u002F*.ts` file. When unit coverage is relevant, name both the owning tests and the source files or package whose coverage those tests must prove:\n\n```sh\npnpm exec vitest run packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Ftests\u002F\u003Cbehavior>.spec.ts \\\n  --coverage \\\n  --coverage.include='packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Fsrc\u002F**\u002F*.ts'\n```\n\nUse an exact source file when the behavior is truly confined to one module. Repeat `--coverage.include` for multiple affected files or packages, and pass every owning test file needed to exercise that scope. The configured per-file 100% thresholds still apply inside the selected source scope.\n\nWhen the owning tests are unclear, use Vitest's dependency graph to discover a candidate set, then inspect the selected tests before treating the run as evidence:\n\n```sh\npnpm exec vitest related packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Fsrc\u002F\u003Cchanged>.ts \\\n  --run \\\n  --coverage \\\n  --coverage.include='packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Fsrc\u002F\u003Cchanged>.ts'\n```\n\n`vitest related` cannot discover behavior reached only through configuration, dynamic loading, subprocesses, workers, built artifacts, or external providers; select those owning tests explicitly. Do not use `--passWithNoTests`, lower coverage thresholds, or narrow `--coverage.include` merely to hide an uncovered affected file. If a selected package scope fails because one focused test does not cover it, add its other relevant owning tests or narrow the source scope only when the excluded modules cannot be affected by the change.\n\n## Full local rehearsal\n\nRun the complete local approximation only when the user explicitly requests it, while diagnosing a CI failure, or when the change spans the repository so broadly that no narrower set is credible. Use the current workflow and package scripts as the inventory; do not recreate the removed `check:pre-push` aggregate.\n\n## Protect history-rewriting pushes\n\nRebase is allowed for standalone and stacked PR branches, including after review. Before a standalone history rewrite, fetch the current remote branch and record its exact OID; publish with `--force-with-lease=\u003Cbranch>:\u003Cobserved-oid>` so a concurrent update aborts the push. `gh stack push` and `gh stack sync` supply lease protection for their managed branches. Raw `--force` is never allowed.\n\nAfter any rewritten push, fetch the live heads again and re-audit unresolved review threads, approvals, mergeability, and checks. Commit hashes and inline-comment anchors from before the rewrite are not current evidence.\n\n### Post-sync validation\n\n`gh stack sync` fetches, cascade-rebases, and pushes as one operation, so it cannot place local validation between rewrite and publication. Before running it, require a clean worktree and record the official stack order and exact remote heads. After it returns:\n\n1. Re-query every branch head and the official GitHub stack order.\n2. Inspect the changed scope of every rewritten layer against its live PR base.\n3. Run the relevant evidence selected by this skill for each affected layer.\n4. Keep every PR unmerged and report validation as pending until all selected checks pass.\n\nIf post-sync evidence fails, leave the lease-protected published heads in place, repair the failure, validate the repair, and publish the correction. Do not claim the sync made the stack ready merely because the command succeeded.\n\n## Handle failures\n\nIf a relevant check fails before an ordinary push, stop and fix or explain the blocker. Do not push and hope CI differs. For the post-sync exception, block the merge and follow the repair procedure above.\n\nIf a failure looks environment-specific, prove it:\n\n- Record the exact command, failing test, and platform-specific mismatch.\n- Confirm the relevant non-platform evidence.\n- Prefer fixing cross-platform nondeterminism when the check is required.\n- Bypass a local hook only when the user explicitly asks or agrees, and report exactly what failed and why CI is expected to differ.\n\n## Push procedure\n\nFor ordinary and standalone rebase pushes:\n\n1. Run the selected relevant checks once.\n2. Commit normally and inspect any files changed by the pre-commit fixer before continuing.\n3. Push normally, or use the exact lease for an authorized rewritten branch, so the incremental typecheck hook runs.\n4. Verify the remote ref matches local `HEAD`.\n\n```sh\ngit rev-parse HEAD origin\u002F$(git branch --show-current)\n```\n\nFor GitHub PRs, inspect remote CI after the push:\n\n```sh\ngh pr checks\n```\n\nReport pending checks as pending. Inspect failures before attributing them to the branch or the environment.\n\nWhen `gh pr checks` reports \"no checks reported\" and `\u002Factions\u002Fruns?head_sha=\u003Csha>` returns `total_count: 0`, read mergeability before suspecting the push or a dropped GitHub event:\n\n```sh\ngh pr view \u003Cnumber> --json mergeable,mergeStateStatus\n```\n\nGitHub creates no `pull_request` workflow runs while a PR is `CONFLICTING`\u002F`DIRTY`, so the absent signal is the conflict, not infrastructure. Resolving the conflict is the only fix; empty commits, `--allow-empty` pushes, draft\u002Fready toggles, and revert-and-restore bounces all leave `total_count` at zero and add junk history. Confirm the conflicting paths with `git merge-tree --write-tree HEAD origin\u002F\u003Cbase>` when the branch cannot be merged locally yet.\n\nFor `gh stack sync`, use the post-sync validation sequence instead of pretending the ordinary order was possible.\n","# DSH Pre-Push Checks\n\nUse this skill to run relevant local evidence once before a `deepseek-harness` push. The sole ordering exception is `gh stack sync`, which may publish a cascading rebase before the rewritten layers can be validated; validate them immediately afterward and do not merge until the evidence passes. Git hooks are intentionally narrow: pre-commit fixes staged lint, checks staged whitespace, and guards vendored-source metadata; pre-push runs only the incremental repository typecheck. CI owns exhaustive coverage and the platform matrix.\n\n## Inspect the outgoing change\n\n1. Confirm the checkout and branch.\n\n```sh\ngit status --short --branch\ngit rev-parse --show-toplevel\n```\n\n2. Verify the live PR base or stack parent, fetch that ref, and inspect the complete scope against it.\n\n```sh\npnpm --silent run change-scope --base \u003Cverified-base-ref>\n```\n\nThe command never guesses or fetches a base. Supply the ref verified from current remote or stack state; use `--head \u003Cref>` when inspecting a commit other than `HEAD`. Its versioned JSON records committed paths relative to the resolved merge base, while staged, unstaged, and untracked paths describe the current worktree. After merging a changed base, rerun the report, reassess which behavior the combined scope can affect, and rerun only checks invalidated by the merge.\n\n## Select relevant evidence\n\nThere is no universal local baseline beyond the hooks. Every behavior change needs the narrowest available test or purpose-built check that would fail for its regression; add broader checks only for surfaces the diff actually reaches.\n\nWhen the outgoing change adds or changes a resource-owning or asynchronous test, fixture, helper, or CI execution path, use [dsh-ci-test-reliability](..\u002Fdsh-ci-test-reliability\u002FSKILL.md) first to decide whether restoration, negative-control, quiescent-teardown, or concurrent-process evidence applies. This skill still selects the commands and avoids repeating evidence that already passed.\n\n- **Package or script behavior:** run the owning Vitest file or focused test name. Add adjacent package tests when a shared contract changes; leave repository-wide coverage to CI unless the change is genuinely cross-cutting or the user requests it.\n- **Remote mock typing:** unbuilt `any` is an explicit local fallback, not strict evidence. Run `pnpm run typecheck` before handing off Remote\u002Fmock changes; rebuild missing, stale, or partial generated declarations before diagnosing remaining errors. Keep the exception in the [test proxy](..\u002F..\u002F..\u002Fpackages\u002Ftest-support\u002Fremote-mock\u002FREADME.md#remote-proxy), never in production Remote types, ambient flags, or copied signatures.\n- **Documentation, Agent Notes, catalogs, or doc-linked comments:** run `pnpm run doc-sync`; run full lint when the documentation workflow requires it.\n- **Model-, editor-, CLI-, or terminal-visible output:** run the focused keyless snapshot or real runnable-example scenario that owns the output.\n- **Expected-output placement:** a test whose selected recorded Session generation is replay input and expected persisted output belongs under top-level `snapshots\u002F`, with `snapshot.yml` naming its shipped `dsh` profile and composition\u002Fheader pin. Canonical parent files are `session[.vN].jsonl`, children are `session.\u003Cordinal>[.vN].jsonl`, and the harness selects the highest generation per role. ARIA, geometry, generator, CLI, and unit expectations without that Session round trip stay beside their owning test under `tests\u002Fexpected\u002F`; do not place them in `snapshots\u002F` or give them a `*.snapshot.ts` owner. Use the owning `test:expected`, `test:web`, or `test` lane.\n- **Profile and configuration placement:** cross-package behavior of a shipped `dsh` profile belongs under `apps\u002Fcli\u002Ftests\u002Fprofiles\u002F`; a package-specific Loader composition belongs under that package's `tests\u002Ffixtures\u002F`. User-facing optional overlays live under `apps\u002Fcli\u002Fconfig\u002Fexamples\u002F` and pair with a guide under `docs\u002Fuser\u002F`.\n- **Package manifests, public exports, build configuration, worker\u002Fbin entries, or built runtime paths:** run `pnpm run build`, the relevant hygiene checks, and the owning built-artifact smoke.\n- **Real provider or agent behavior:** run the relevant `pnpm run test:e2e` target when credentials are available; never print secrets.\n\nDo not manually repeat a passing check merely because commit or push follows. In particular, do not run typecheck immediately before pushing solely to duplicate the pre-push hook.\n\nPass Vitest file and name filters directly after the script name with `pnpm run`; do not insert a standalone `--`, which reaches Vitest and can disable `-t` filtering. For example, this command runs one headless snapshot scenario:\n\n```sh\npnpm run test:snapshot snapshots\u002Fsession\u002Fheadless.snapshot.ts -t 'cordis-inspect-jsdoc'\n```\n\nThis applies to these pnpm scripts; npm and other launchers retain their own argument-forwarding syntax. Check the reported selected test count before treating a filtered run as focused evidence.\n\n### Focus unit coverage on the affected source\n\nTest selection and coverage selection are separate. A Vitest file filter chooses which tests run, while the repository configuration otherwise measures every `packages\u002F*\u002F*\u002Fsrc\u002F**\u002F*.ts` file. When unit coverage is relevant, name both the owning tests and the source files or package whose coverage those tests must prove:\n\n```sh\npnpm exec vitest run packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Ftests\u002F\u003Cbehavior>.spec.ts \\\n  --coverage \\\n  --coverage.include='packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Fsrc\u002F**\u002F*.ts'\n```\n\nUse an exact source file when the behavior is truly confined to one module. Repeat `--coverage.include` for multiple affected files or packages, and pass every owning test file needed to exercise that scope. The configured per-file 100% thresholds still apply inside the selected source scope.\n\nWhen the owning tests are unclear, use Vitest's dependency graph to discover a candidate set, then inspect the selected tests before treating the run as evidence:\n\n```sh\npnpm exec vitest related packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Fsrc\u002F\u003Cchanged>.ts \\\n  --run \\\n  --coverage \\\n  --coverage.include='packages\u002F\u003Cgroup>\u002F\u003Cpackage>\u002Fsrc\u002F\u003Cchanged>.ts'\n```\n\n`vitest related` cannot discover behavior reached only through configuration, dynamic loading, subprocesses, workers, built artifacts, or external providers; select those owning tests explicitly. Do not use `--passWithNoTests`, lower coverage thresholds, or narrow `--coverage.include` merely to hide an uncovered affected file. If a selected package scope fails because one focused test does not cover it, add its other relevant owning tests or narrow the source scope only when the excluded modules cannot be affected by the change.\n\n## Full local rehearsal\n\nRun the complete local approximation only when the user explicitly requests it, while diagnosing a CI failure, or when the change spans the repository so broadly that no narrower set is credible. Use the current workflow and package scripts as the inventory; do not recreate the removed `check:pre-push` aggregate.\n\n## Protect history-rewriting pushes\n\nRebase is allowed for standalone and stacked PR branches, including after review. Before a standalone history rewrite, fetch the current remote branch and record its exact OID; publish with `--force-with-lease=\u003Cbranch>:\u003Cobserved-oid>` so a concurrent update aborts the push. `gh stack push` and `gh stack sync` supply lease protection for their managed branches. Raw `--force` is never allowed.\n\nAfter any rewritten push, fetch the live heads again and re-audit unresolved review threads, approvals, mergeability, and checks. Commit hashes and inline-comment anchors from before the rewrite are not current evidence.\n\n### Post-sync validation\n\n`gh stack sync` fetches, cascade-rebases, and pushes as one operation, so it cannot place local validation between rewrite and publication. Before running it, require a clean worktree and record the official stack order and exact remote heads. After it returns:\n\n1. Re-query every branch head and the official GitHub stack order.\n2. Inspect the changed scope of every rewritten layer against its live PR base.\n3. Run the relevant evidence selected by this skill for each affected layer.\n4. Keep every PR unmerged and report validation as pending until all selected checks pass.\n\nIf post-sync evidence fails, leave the lease-protected published heads in place, repair the failure, validate the repair, and publish the correction. Do not claim the sync made the stack ready merely because the command succeeded.\n\n## Handle failures\n\nIf a relevant check fails before an ordinary push, stop and fix or explain the blocker. Do not push and hope CI differs. For the post-sync exception, block the merge and follow the repair procedure above.\n\nIf a failure looks environment-specific, prove it:\n\n- Record the exact command, failing test, and platform-specific mismatch.\n- Confirm the relevant non-platform evidence.\n- Prefer fixing cross-platform nondeterminism when the check is required.\n- Bypass a local hook only when the user explicitly asks or agrees, and report exactly what failed and why CI is expected to differ.\n\n## Push procedure\n\nFor ordinary and standalone rebase pushes:\n\n1. Run the selected relevant checks once.\n2. Commit normally and inspect any files changed by the pre-commit fixer before continuing.\n3. Push normally, or use the exact lease for an authorized rewritten branch, so the incremental typecheck hook runs.\n4. Verify the remote ref matches local `HEAD`.\n\n```sh\ngit rev-parse HEAD origin\u002F$(git branch --show-current)\n```\n\nFor GitHub PRs, inspect remote CI after the push:\n\n```sh\ngh pr checks\n```\n\nReport pending checks as pending. Inspect failures before attributing them to the branch or the environment.\n\nWhen `gh pr checks` reports \"no checks reported\" and `\u002Factions\u002Fruns?head_sha=\u003Csha>` returns `total_count: 0`, read mergeability before suspecting the push or a dropped GitHub event:\n\n```sh\ngh pr view \u003Cnumber> --json mergeable,mergeStateStatus\n```\n\nGitHub creates no `pull_request` workflow runs while a PR is `CONFLICTING`\u002F`DIRTY`, so the absent signal is the conflict, not infrastructure. Resolving the conflict is the only fix; empty commits, `--allow-empty` pushes, draft\u002Fready toggles, and revert-and-restore bounces all leave `total_count` at zero and add junk history. Confirm the conflicting paths with `git merge-tree --write-tree HEAD origin\u002F\u003Cbase>` when the branch cannot be merged locally yet.\n\nFor `gh stack sync`, use the post-sync validation sequence instead of pretending the ordinary order was possible.\n",{"name":5,"description":7},"main","b608340412f02546f13b1b29976daf33bec72bef","assets\u002Fskills\u002Fdsh-pre-push-checks","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents","https:\u002F\u002Fgithub.com\u002Fryasrk","Passionate about Machine Learning, Deep Learning, and LLMs. Skilled in Computer Vision, NLP, and AI model development.","2026-09-29 12:47:36",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add ryasrk\u002Fdsh-expert-agents --skill dsh-pre-push-checks",{"tool":37,"command":38},"bunx","bunx skills add ryasrk\u002Fdsh-expert-agents --skill dsh-pre-push-checks",{"tool":40,"command":41},"pnpm","pnpm dlx skills add ryasrk\u002Fdsh-expert-agents --skill dsh-pre-push-checks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fdsh-pre-push-checks\u002FSKILL.md",true,[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7CW5A9FJK1C6BQKKMYHKWBD","writing-shape","Writing, exploit: shape raw material into an article, paragraph by paragraph.","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fwriting-shape\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7CW58T8BYGMCTKQW60DFM7K","writing-fragments","Writing, explore: mine raw fragments, no structure yet.","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fwriting-fragments\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7CW56PXKJ31Y8AGJ31W1SHT","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M7CW54P3DQJKVA9GBQBMXE00","writing-beats","Writing, exploit; assemble raw material into a journey of beats, grounding each term before a beat leans on it.","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fwriting-beats\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7CW50RQRS31BHTKJ7JZM21A","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fwizard\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7CW4Y3E85C06AZD2VANK40Q","wayfinder","Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002Fryasrk\u002Fdsh-expert-agents\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[]]