[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7ER074PQSDJSJ2WAV5ACA67":3,"skill-same:01M7ER074PQSDJSJ2WAV5ACA67":52},{"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":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":30,"updatedAt":31,"install":32,"resources":45},"01M7ER074PQSDJSJ2WAV5ACA67","release",null,"Prepare, verify, publish, or diagnose a Proqi release through the repository's protected tag workflow. Use only when explicitly invoked for this repository.","lza6\u002FArmor-piercing-system-prompts","lza6","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F128880206?v=4","01M7EB3K7WPX5T28EJ2NVHE6EG","Chinese-tingfeng","01M7EB3K97E1KQ16QWKJMFNGX8",11,"MIT","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F04-安全渗透\u002Frelease-proqi\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: release\ndescription: Prepare, verify, publish, or diagnose a Proqi release through the repository's protected tag workflow. Use only when explicitly invoked for this repository.\n---\n\n# Proqi Release\n\nThis is a repository-local maintainer skill. Act only after explicit invocation.\nNever advertise, install, or publish this skill as an end-user Proqi skill.\n\n## Begin safely\n\n1. Read the repository instructions and `docs\u002FRELEASING.md` completely. The\n   runbook and checked-in workflows are authoritative over this skill.\n2. Verify the branch, `HEAD`, remotes, tags, and complete worktree state. Never\n   discard, hide, or publish unexpected changes.\n3. Determine whether the user asked to prepare a release, inspect release\n   status, diagnose a failure, or proceed toward publication. Preparing files,\n   committing them, or pushing `main` does not authorize a tag or release.\n4. Read [references\u002Frelease-notes.md](references\u002Frelease-notes.md) before\n   drafting or reviewing release notes.\n\n## Prepare\n\n1. Derive the change set from the previous stable tag through `HEAD`. Inspect\n   commits, user-visible diffs, tests, documentation, and known limitations.\n   Do not infer a shipped capability from a commit title alone.\n2. Recommend the next semantic version with reasons. Before `1.0`, use a minor\n   increase for a new capability or intentional compatibility break, and a\n   patch increase for compatible fixes and operational hardening. The user owns\n   the final version choice.\n3. Update the workspace version in `Cargo.toml`, refresh `Cargo.lock` through\n   normal Cargo tooling, create `.github\u002Frelease-notes\u002FvX.Y.Z.md`, and add or\n   update one exact matching entry with three to six concise user-facing items\n   in `release-highlights.json`. GitHub notes remain the only changelog. The\n   manifest is the bounded in-product projection of those reviewed notes.\n4. Run focused checks appropriate to the changed code. Routine release\n   preparation then runs the cheap `cargo xtask release-plan vX.Y.Z` contract\n   and Git diff hygiene. Run workflow lint only when workflows changed. Full\n   check, PTY, coverage, audit, package, crate dry run, full MSRV, rehearsal,\n   and Linux parity remain milestone or diagnostic gates as documented in\n   `docs\u002FRELEASING.md`; do not repeat them merely because metadata is prepared.\n5. Review generated or changed release artifacts explicitly. Never weaken a\n   gate, accept snapshots automatically, or claim an unavailable platform check\n   passed.\n6. Review the exact GitHub notes and matching packaged highlights together.\n   Never draft highlights from commit titles alone. Show both texts, the version\n   diff, gate results, and any limitations before committing or pushing release\n   preparation unless the current instruction already authorizes those exact\n   local and remote changes.\n\n## Pre-publication checks\n\nBefore asking for publication confirmation:\n\n1. Require the release commit on `main`, its required CI result and immutable\n   candidate workflow to be green, and the exact `vX.Y.Z` tag to match the Cargo\n   version, notes filename, and reviewed highlights.\n2. Confirm that the exact tag is absent locally and remotely and that no\n   conflicting GitHub Release or crates.io version exists.\n3. Record the full release commit SHA and verify that the worktree contains no\n   unreviewed release input.\n\n## Mandatory publication confirmation\n\nAlways stop immediately before creating or pushing the release tag. Ask the\nuser to confirm one exact action in this form:\n\n```text\nCreate and push the annotated tag vX.Y.Z at \u003Cfull-commit-sha>, triggering the\npublic GitHub Release, crates.io publication, and Homebrew tap update?\n```\n\nThis confirmation is mandatory even if the user previously asked to prepare,\nfinish, cut, or publish a release, approved the release notes, or approved the\nrelease preparation commit. Do not infer it from earlier authority. Do not\ncreate a local tag, push a tag, call a release workflow, or create a GitHub\nRelease before the user answers affirmatively to the exact tag and commit.\n\n## Publish after confirmation\n\n1. Revalidate that the commit, CI result, version, notes, and tag state have not\n   changed since confirmation. If any changed, stop and ask again with the new\n   exact tag and commit. Never move, recreate, or force a public release tag.\n2. Create and push one annotated stable tag. Do not create or publish a GitHub\n   Release manually. The protected tag is the workflow's sole publication\n   trigger.\n3. Monitor the tag-triggered `Release` workflow. It selects the exact prior main\n   candidate without rebuilding native binaries, publishes crates.io through\n   OIDC, publishes and verifies GitHub assets, then notifies the Homebrew tap.\n4. If promotion fails, inspect the exact failing step. Rerun the same promotion\n   when safe. If the candidate is missing or expired, manually run the\n   non-publishing candidate workflow for the exact main SHA or protected tag,\n   then retry promotion. Never publish around a failed verification.\n5. Verify the public GitHub Release, exact crates.io version, Homebrew formula,\n   and installed `proqi --version`. Report each channel independently.\n\n## Recovery boundaries\n\n- The manual `Release candidate` workflow is diagnostic or recovery tooling. It\n  never publishes and is not part of an ordinary release.\n- If crates.io or any immutable public artifact exists, recover with a new\n  semantic version. Never overwrite, delete, yank, or retag merely to make the\n  workflow green.\n- A failed or ambiguous external operation is not success. Preserve the command\n  output and current public state before proposing a retry.\n- Do not merge dependency pull requests, alter protection rules, change\n  repository settings, or expand distribution channels as a side effect of a\n  release.\n\nFinish with the released version, commit and tag, workflow URL and result,\nGitHub Release URL, crates.io result, Homebrew result, installed version, and\nany skipped or failed verification.\n","# Proqi Release\n\nThis is a repository-local maintainer skill. Act only after explicit invocation.\nNever advertise, install, or publish this skill as an end-user Proqi skill.\n\n## Begin safely\n\n1. Read the repository instructions and `docs\u002FRELEASING.md` completely. The\n   runbook and checked-in workflows are authoritative over this skill.\n2. Verify the branch, `HEAD`, remotes, tags, and complete worktree state. Never\n   discard, hide, or publish unexpected changes.\n3. Determine whether the user asked to prepare a release, inspect release\n   status, diagnose a failure, or proceed toward publication. Preparing files,\n   committing them, or pushing `main` does not authorize a tag or release.\n4. Read [references\u002Frelease-notes.md](references\u002Frelease-notes.md) before\n   drafting or reviewing release notes.\n\n## Prepare\n\n1. Derive the change set from the previous stable tag through `HEAD`. Inspect\n   commits, user-visible diffs, tests, documentation, and known limitations.\n   Do not infer a shipped capability from a commit title alone.\n2. Recommend the next semantic version with reasons. Before `1.0`, use a minor\n   increase for a new capability or intentional compatibility break, and a\n   patch increase for compatible fixes and operational hardening. The user owns\n   the final version choice.\n3. Update the workspace version in `Cargo.toml`, refresh `Cargo.lock` through\n   normal Cargo tooling, create `.github\u002Frelease-notes\u002FvX.Y.Z.md`, and add or\n   update one exact matching entry with three to six concise user-facing items\n   in `release-highlights.json`. GitHub notes remain the only changelog. The\n   manifest is the bounded in-product projection of those reviewed notes.\n4. Run focused checks appropriate to the changed code. Routine release\n   preparation then runs the cheap `cargo xtask release-plan vX.Y.Z` contract\n   and Git diff hygiene. Run workflow lint only when workflows changed. Full\n   check, PTY, coverage, audit, package, crate dry run, full MSRV, rehearsal,\n   and Linux parity remain milestone or diagnostic gates as documented in\n   `docs\u002FRELEASING.md`; do not repeat them merely because metadata is prepared.\n5. Review generated or changed release artifacts explicitly. Never weaken a\n   gate, accept snapshots automatically, or claim an unavailable platform check\n   passed.\n6. Review the exact GitHub notes and matching packaged highlights together.\n   Never draft highlights from commit titles alone. Show both texts, the version\n   diff, gate results, and any limitations before committing or pushing release\n   preparation unless the current instruction already authorizes those exact\n   local and remote changes.\n\n## Pre-publication checks\n\nBefore asking for publication confirmation:\n\n1. Require the release commit on `main`, its required CI result and immutable\n   candidate workflow to be green, and the exact `vX.Y.Z` tag to match the Cargo\n   version, notes filename, and reviewed highlights.\n2. Confirm that the exact tag is absent locally and remotely and that no\n   conflicting GitHub Release or crates.io version exists.\n3. Record the full release commit SHA and verify that the worktree contains no\n   unreviewed release input.\n\n## Mandatory publication confirmation\n\nAlways stop immediately before creating or pushing the release tag. Ask the\nuser to confirm one exact action in this form:\n\n```text\nCreate and push the annotated tag vX.Y.Z at \u003Cfull-commit-sha>, triggering the\npublic GitHub Release, crates.io publication, and Homebrew tap update?\n```\n\nThis confirmation is mandatory even if the user previously asked to prepare,\nfinish, cut, or publish a release, approved the release notes, or approved the\nrelease preparation commit. Do not infer it from earlier authority. Do not\ncreate a local tag, push a tag, call a release workflow, or create a GitHub\nRelease before the user answers affirmatively to the exact tag and commit.\n\n## Publish after confirmation\n\n1. Revalidate that the commit, CI result, version, notes, and tag state have not\n   changed since confirmation. If any changed, stop and ask again with the new\n   exact tag and commit. Never move, recreate, or force a public release tag.\n2. Create and push one annotated stable tag. Do not create or publish a GitHub\n   Release manually. The protected tag is the workflow's sole publication\n   trigger.\n3. Monitor the tag-triggered `Release` workflow. It selects the exact prior main\n   candidate without rebuilding native binaries, publishes crates.io through\n   OIDC, publishes and verifies GitHub assets, then notifies the Homebrew tap.\n4. If promotion fails, inspect the exact failing step. Rerun the same promotion\n   when safe. If the candidate is missing or expired, manually run the\n   non-publishing candidate workflow for the exact main SHA or protected tag,\n   then retry promotion. Never publish around a failed verification.\n5. Verify the public GitHub Release, exact crates.io version, Homebrew formula,\n   and installed `proqi --version`. Report each channel independently.\n\n## Recovery boundaries\n\n- The manual `Release candidate` workflow is diagnostic or recovery tooling. It\n  never publishes and is not part of an ordinary release.\n- If crates.io or any immutable public artifact exists, recover with a new\n  semantic version. Never overwrite, delete, yank, or retag merely to make the\n  workflow green.\n- A failed or ambiguous external operation is not success. Preserve the command\n  output and current public state before proposing a retry.\n- Do not merge dependency pull requests, alter protection rules, change\n  repository settings, or expand distribution channels as a side effect of a\n  release.\n\nFinish with the released version, commit and tag, workflow URL and result,\nGitHub Release URL, crates.io result, Homebrew result, installed version, and\nany skipped or failed verification.\n",{"name":5,"description":7},"main","d69096e239f2a89aabc2cd078c47664a9d3b1e11","04-安全渗透\u002Frelease-proqi",3,"https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts","https:\u002F\u002Fgithub.com\u002Flza6","个人vx：Tf00798\r\n个人✈：@TFGY999","2026-10-08 14:29:22",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add lza6\u002FArmor-piercing-system-prompts --skill release",{"tool":38,"command":39},"bunx","bunx skills add lza6\u002FArmor-piercing-system-prompts --skill release",{"tool":41,"command":42},"pnpm","pnpm dlx skills add lza6\u002FArmor-piercing-system-prompts --skill release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F04-安全渗透\u002Frelease-proqi\u002FSKILL.md",true,[46],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"references\u002Frelease-notes.md","REFERENCE","参考文档",4583,"https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F04-安全渗透\u002Frelease-proqi\u002Freferences\u002Frelease-notes.md",[53,60,67,74,82,89],{"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},"01M7EXRM12046G0GM1WGMMFXCN","ci-cd-and-automation","Automates CI\u002FCD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fci-cd-and-automation\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},"01M7EXRFYYSJ3Y15AGPDDEWWQD","chrome-devtools","Uses Chrome DevTools via MCP for efficient debugging, troubleshooting and browser automation. Use when debugging web pages, automating browser interactions, analyzing performance, or inspecting network requests. This skill does not apply to `--slim` mode (MCP configuration).","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-devtools\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},"01M7EXR6EYPE4X5X1BTAE6QJRV","chrome-cdp","Drive a real Chrome via the Chrome DevTools Protocol (CDP). Ensures a\ndebuggable Chrome is running (launching it if needed) so the agent can\nnavigate, read page content, inspect the DOM, run JavaScript, and take\nscreenshots — without the user typing any launch command. Includes a\nfirst-class \"review a live running app\" flow: point Chrome at the app under\ndevelopment and inspect\u002Fscreenshot the REAL page (what a static-artifact tool\ncannot do). Backed by Glimpse and the chrome-devtools MCP server. Use when\nasked to \"use chrome\", \"open chrome\", \"drive my browser\", \"read the page in\nchrome\", \"review the running app\", \"screenshot the app\", or \"\u002Fchrome-cdp\".","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-cdp\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":78,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7EXR1Y7E79KQKG4J798XGH6","check-identity-pack","Run an AFP 100-point or AUSTRAC safe-harbour identity check over a set of documents, and report exactly what's missing. Use when the user asks to check identity documents, verify someone's ID for onboarding, or assess whether a document pack satisfies Australian identity requirements.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcheck-identity-pack\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M7EXQXW7C7PGREJW9ZZTZ16H","changelog","Auto-generates a changelog from git commits, sprint data, and design documents. Produces both internal and player-facing versions.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchangelog\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M7EXQMH2ZME3ANN8Q8MEWPFB","cellxgene-census","Query the CZ CELLxGENE Census programmatically for versioned public single-cell and spatial transcriptomics data. Use when you need population-scale cell metadata, gene expression slices, Census summary counts, source H5AD URIs\u002Fdownloads, embeddings, spatial Census data, or reference atlas comparisons across organisms, tissues, diseases, assays, and cell types. For analyzing your own local single-cell data use scanpy, anndata, or scvi-tools.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcellxgene-census\u002FSKILL.md",[],[]]