[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MR4VPKDWZFS9857JWHQ4MC":3,"skill-same:01M6MR4VPKDWZFS9857JWHQ4MC":55},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":14,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":40,"install":41,"resources":54},"01M6MR4VPKDWZFS9857JWHQ4MC","release-preparation",null,"Use this skill when the user wants to prepare, document, version, tag, or validate a software release.","tschmz\u002Fimp","tschmz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F250745188?v=4","01M6MR47EQHGG14Z0BE94P1XPY","Thomas Schmitz","01M6MR47K8ZV2H8T8Y5N0CAPQY",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp\u002Fblob\u002Fmain\u002Fplugins\u002Fimp-agents\u002Fskills\u002Frelease-preparation\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"release","release preparation","preparation","validate","prepare","user","use","version","document","software release","software","2026-11-10 10:12:30",false,"---\nname: release-preparation\ndescription: Use this skill when the user wants to prepare, document, version, tag, or validate a software release.\n---\n\n# Release Preparation\n\nUse this skill for release preparation in any software repository. Fit the repository's existing release process first; only propose a new process when there is no established one.\n\n## Core Rules\n\n- Do not invent release notes. Ground every user-facing release note in commits, tags, changelog history, pull requests, or the relevant diff.\n- Prefer repository-local conventions over generic templates when they exist.\n- Cover all relevant commits since the previous release. A commit should either be represented in the release notes or intentionally excluded with a short reason in the final report.\n- Do not push, publish, deploy, or create a public release unless the user explicitly asks.\n- Do not rewrite release history, retag an existing published version, or delete tags unless the user explicitly asks and the risk is clear.\n\n## Find The Existing Release Pattern\n\nBefore editing release files, inspect the repository for prior release conventions:\n\n1. Find release tags:\n\n   ```sh\n   git tag --sort=-creatordate\n   git describe --tags --abbrev=0\n   ```\n\n2. Inspect recent release commits and tags:\n\n   ```sh\n   git log --decorate --oneline --max-count=50\n   git show --no-patch \u003Ctag>\n   git show \u003Ctag>:package.json\n   ```\n\n   Adapt the package\u002Fversion file to the repository, for example `pyproject.toml`, `Cargo.toml`, `.csproj`, `pom.xml`, or a language-specific lockfile.\n\n3. Check release documentation and changelog style:\n\n   ```sh\n   ls\n   find . -maxdepth 3 -iname '*changelog*' -o -iname '*release*'\n   sed -n '1,160p' CHANGELOG.md\n   ```\n\n4. Inspect commits since the previous release:\n\n   ```sh\n   git log --reverse --format='%H%x09%s' \u003Clast_tag>..HEAD\n   git diff --stat \u003Clast_tag>..HEAD\n   ```\n\nUse the discovered pattern for section names, date format, version prefixes, tag format, release commit message, validation commands, and whether generated files or lockfiles are updated.\n\n## First Release\n\nIf there is no prior release pattern, pause before making release-file changes and propose a best-practice format to the user. Keep it concrete and discuss the tradeoffs.\n\nRecommended default:\n\n- Semantic Versioning for version numbers.\n- Annotated Git tags named `vX.Y.Z`.\n- A `CHANGELOG.md` using a \"Keep a Changelog\" style shape:\n  - `## X.Y.Z - YYYY-MM-DD`\n  - `### Added`\n  - `### Changed`\n  - `### Fixed`\n  - `### Removed`\n  - `### Security`\n- Release notes derived from commits since the previous release point, not from memory.\n- A release commit named `chore: release X.Y.Z`, unless the repository uses another convention.\n\nAsk the user to confirm or adjust this format before creating the first release metadata.\n\n## Prepare The Release\n\n1. Determine the release range.\n   - Use `\u003Clast_tag>..HEAD` when a previous tag exists.\n   - For a first release, use the full project history or the user-confirmed baseline.\n\n2. Classify every relevant commit.\n   - `feat:` usually maps to `Added`.\n   - `fix:` usually maps to `Fixed`.\n   - `refactor:`, `perf:`, and behavior-changing internal work usually map to `Changed`.\n   - `docs:`, `test:`, `build:`, and `chore:` are usually omitted unless they affect user, operator, packaging, or release behavior.\n   - If the repository already uses different categories, follow them.\n\n3. Choose the next version.\n   - If the user gives a target version, use it.\n   - Otherwise infer a version from the established repository policy.\n   - If no policy exists, recommend a SemVer bump and explain the reason.\n\n4. Update release files.\n   - Update changelog or release notes in the existing style.\n   - Update version files and lockfiles consistently.\n   - Keep unrelated cleanup out of the release commit.\n\n5. Validate using repository conventions.\n   - Prefer documented commands from `README`, `CONTRIBUTING`, `AGENTS.md`, CI config, package scripts, or previous release notes.\n   - If no commands are documented, propose a reasonable minimal validation set and state the assumption.\n\n6. Before committing or tagging, audit coverage.\n   - Compare the commit list against the release notes.\n   - Confirm version files agree.\n   - Confirm the tag name matches the version.\n\n7. Create release metadata only when requested or when it is clearly part of the task.\n   - Release commit example: `git commit -am \"chore: release X.Y.Z\"`\n   - Annotated tag example: `git tag -a vX.Y.Z -m \"vX.Y.Z\"`\n\n8. Verify the result:\n\n   ```sh\n   git show --no-patch \u003Ctag>\n   git show \u003Ctag>:\u003Cversion-file>\n   git status --short\n   ```\n\n## Final Report\n\nReport:\n\n- release range and target version\n- files changed\n- validation commands run and their results\n- commits intentionally omitted from release notes, with reasons\n- whether a release commit, tag, push, publish, or deploy was performed\n","# Release Preparation\n\nUse this skill for release preparation in any software repository. Fit the repository's existing release process first; only propose a new process when there is no established one.\n\n## Core Rules\n\n- Do not invent release notes. Ground every user-facing release note in commits, tags, changelog history, pull requests, or the relevant diff.\n- Prefer repository-local conventions over generic templates when they exist.\n- Cover all relevant commits since the previous release. A commit should either be represented in the release notes or intentionally excluded with a short reason in the final report.\n- Do not push, publish, deploy, or create a public release unless the user explicitly asks.\n- Do not rewrite release history, retag an existing published version, or delete tags unless the user explicitly asks and the risk is clear.\n\n## Find The Existing Release Pattern\n\nBefore editing release files, inspect the repository for prior release conventions:\n\n1. Find release tags:\n\n   ```sh\n   git tag --sort=-creatordate\n   git describe --tags --abbrev=0\n   ```\n\n2. Inspect recent release commits and tags:\n\n   ```sh\n   git log --decorate --oneline --max-count=50\n   git show --no-patch \u003Ctag>\n   git show \u003Ctag>:package.json\n   ```\n\n   Adapt the package\u002Fversion file to the repository, for example `pyproject.toml`, `Cargo.toml`, `.csproj`, `pom.xml`, or a language-specific lockfile.\n\n3. Check release documentation and changelog style:\n\n   ```sh\n   ls\n   find . -maxdepth 3 -iname '*changelog*' -o -iname '*release*'\n   sed -n '1,160p' CHANGELOG.md\n   ```\n\n4. Inspect commits since the previous release:\n\n   ```sh\n   git log --reverse --format='%H%x09%s' \u003Clast_tag>..HEAD\n   git diff --stat \u003Clast_tag>..HEAD\n   ```\n\nUse the discovered pattern for section names, date format, version prefixes, tag format, release commit message, validation commands, and whether generated files or lockfiles are updated.\n\n## First Release\n\nIf there is no prior release pattern, pause before making release-file changes and propose a best-practice format to the user. Keep it concrete and discuss the tradeoffs.\n\nRecommended default:\n\n- Semantic Versioning for version numbers.\n- Annotated Git tags named `vX.Y.Z`.\n- A `CHANGELOG.md` using a \"Keep a Changelog\" style shape:\n  - `## X.Y.Z - YYYY-MM-DD`\n  - `### Added`\n  - `### Changed`\n  - `### Fixed`\n  - `### Removed`\n  - `### Security`\n- Release notes derived from commits since the previous release point, not from memory.\n- A release commit named `chore: release X.Y.Z`, unless the repository uses another convention.\n\nAsk the user to confirm or adjust this format before creating the first release metadata.\n\n## Prepare The Release\n\n1. Determine the release range.\n   - Use `\u003Clast_tag>..HEAD` when a previous tag exists.\n   - For a first release, use the full project history or the user-confirmed baseline.\n\n2. Classify every relevant commit.\n   - `feat:` usually maps to `Added`.\n   - `fix:` usually maps to `Fixed`.\n   - `refactor:`, `perf:`, and behavior-changing internal work usually map to `Changed`.\n   - `docs:`, `test:`, `build:`, and `chore:` are usually omitted unless they affect user, operator, packaging, or release behavior.\n   - If the repository already uses different categories, follow them.\n\n3. Choose the next version.\n   - If the user gives a target version, use it.\n   - Otherwise infer a version from the established repository policy.\n   - If no policy exists, recommend a SemVer bump and explain the reason.\n\n4. Update release files.\n   - Update changelog or release notes in the existing style.\n   - Update version files and lockfiles consistently.\n   - Keep unrelated cleanup out of the release commit.\n\n5. Validate using repository conventions.\n   - Prefer documented commands from `README`, `CONTRIBUTING`, `AGENTS.md`, CI config, package scripts, or previous release notes.\n   - If no commands are documented, propose a reasonable minimal validation set and state the assumption.\n\n6. Before committing or tagging, audit coverage.\n   - Compare the commit list against the release notes.\n   - Confirm version files agree.\n   - Confirm the tag name matches the version.\n\n7. Create release metadata only when requested or when it is clearly part of the task.\n   - Release commit example: `git commit -am \"chore: release X.Y.Z\"`\n   - Annotated tag example: `git tag -a vX.Y.Z -m \"vX.Y.Z\"`\n\n8. Verify the result:\n\n   ```sh\n   git show --no-patch \u003Ctag>\n   git show \u003Ctag>:\u003Cversion-file>\n   git status --short\n   ```\n\n## Final Report\n\nReport:\n\n- release range and target version\n- files changed\n- validation commands run and their results\n- commits intentionally omitted from release notes, with reasons\n- whether a release commit, tag, push, publish, or deploy was performed\n",{"name":5,"description":7},"main","5c55adc9bc538ca2feda7f1e3cc1ed32de1d472a","plugins\u002Fimp-agents\u002Fskills\u002Frelease-preparation","https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp","https:\u002F\u002Fgithub.com\u002Ftschmz","2026-08-23 22:45:40",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add tschmz\u002Fimp --skill release-preparation",{"tool":47,"command":48},"bunx","bunx skills add tschmz\u002Fimp --skill release-preparation",{"tool":50,"command":51},"pnpm","pnpm dlx skills add tschmz\u002Fimp --skill release-preparation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp\u002Fblob\u002Fmain\u002Fplugins\u002Fimp-agents\u002Fskills\u002Frelease-preparation\u002FSKILL.md",true,[],[56,74,90,101,112],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":30},"01M6MR4QWADESAXV08P0BBSX73","imp-administration","Use this skill to inspect, configure, diagnose, back up, restore, or manage the live Imp installation.","https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp\u002Fblob\u002Fmain\u002Fplugins\u002Fimp-agents\u002Fskills\u002Fimp-administration\u002FSKILL.md",[],[63,64,65,66,67,68,69,70,71,25,72,73],"imp administration","administration","inspect","live","installation","back","manage","restore","up","configure","diagnose",{"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":85,"publishedAt":30},"01M6MR4NDSXEY5CDR6RK5DASAC","skill-creator","Use this skill to create a skill for yourself.","https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fskill-creator\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[86,87,88,25,89],"creator","skill creator","for","create",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":30},"01M6MR4J402XBC5JWEE4SEECMY","plugin-creator","Use this skill to create or debug a plugin that adds tools for yourself.","https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fplugin-creator\u002FSKILL.md",[],[86,97,98,88,25,99,89,100],"plugin","plugin creator","Tools","debug",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":30},"01M6MR4FZ0XT2R11JRHH3G4YHK","current-time","Use this skill to get the current local date and time.","https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp\u002Fblob\u002Fmain\u002Fassets\u002Fskills\u002Fcurrent-time\u002FSKILL.md",[],[108,109,25,110,111],"time","current time","get","local",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":30},"01M6MR4C14YA6CPH620RM6KPPK","commit","Use this skill when creating commits in this repository; enforce the repository commit message format.","https:\u002F\u002Fgithub.com\u002Ftschmz\u002Fimp\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcommit\u002FSKILL.md",[],[114,119,120,121,122,25,123,124],"commit message","repository","commits","format","message","enforce"]