[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K592CXEPZ8726W0WC64BEP":3,"skill-same:01M6K592CXEPZ8726W0WC64BEP":61},{"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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6K592CXEPZ8726W0WC64BEP","release-changelog",null,"Generate the stable Paperclip release changelog at releases\u002FvYYYY.MDD.P.md by reading commits, changesets, and merged PR context since the last stable tag.","kangnam7654\u002Fstapler","kangnam7654","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F70181315?v=4","01M6K57VNJ3PFBHBRQNBTYTSJM","Kangnam Kim","01M6K57VT1NK9FARCSD23JGTMY",1,"MIT","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-changelog\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"release","release changelog","changelog","pr","generate","paperclip","commits","context","releases","changesets","reading","last","at","pr context","2026-11-10 10:12:30",false,"---\nname: release-changelog\ndescription: >\n  Generate the stable Paperclip release changelog at releases\u002FvYYYY.MDD.P.md by\n  reading commits, changesets, and merged PR context since the last stable tag.\n---\n\n# Release Changelog Skill\n\nGenerate the user-facing changelog for the **stable** Paperclip release.\n\n## Versioning Model\n\nPaperclip uses **calendar versioning (calver)**:\n\n- Stable releases: `YYYY.MDD.P` (e.g. `2026.318.0`)\n- Canary releases: `YYYY.MDD.P-canary.N` (e.g. `2026.318.1-canary.0`)\n- Git tags: `vYYYY.MDD.P` for stable, `canary\u002FvYYYY.MDD.P-canary.N` for canary\n\nThere are no major\u002Fminor\u002Fpatch bumps. The stable version is derived from the\nintended release date (UTC) plus the next same-day stable patch slot.\n\nOutput:\n\n- `releases\u002FvYYYY.MDD.P.md`\n\nImportant rules:\n\n- even if there are canary releases such as `2026.318.1-canary.0`, the changelog file stays `releases\u002Fv2026.318.1.md`\n- do not derive versions from semver bump types\n- do not create canary changelog files\n\n## Step 0 — Idempotency Check\n\nBefore generating anything, check whether the file already exists:\n\n```bash\nls releases\u002FvYYYY.MDD.P.md 2>\u002Fdev\u002Fnull\n```\n\nIf it exists:\n\n1. read it first\n2. present it to the reviewer\n3. ask whether to keep it, regenerate it, or update specific sections\n4. never overwrite it silently\n\n## Step 1 — Determine the Stable Range\n\nFind the last stable tag:\n\n```bash\ngit tag --list 'v*' --sort=-version:refname | head -1\ngit log v{last}..HEAD --oneline --no-merges\n```\n\nThe stable version comes from one of:\n\n- an explicit maintainer request\n- `.\u002Fscripts\u002Frelease.sh stable --date YYYY-MM-DD --print-version`\n- the release plan already agreed in `doc\u002FRELEASING.md`\n\nDo not derive the changelog version from a canary tag or prerelease suffix.\nDo not derive major\u002Fminor\u002Fpatch bumps from API intent — calver uses the date and same-day stable slot.\n\n## Step 2 — Gather the Raw Inputs\n\nCollect release data from:\n\n1. git commits since the last stable tag\n2. `.changeset\u002F*.md` files\n3. merged PRs via `gh` when available\n\nUseful commands:\n\n```bash\ngit log v{last}..HEAD --oneline --no-merges\ngit log v{last}..HEAD --format=\"%H %s\" --no-merges\nls .changeset\u002F*.md | grep -v README.md\ngh pr list --state merged --search \"merged:>={last-tag-date}\" --json number,title,body,labels\n```\n\n## Step 3 — Detect Breaking Changes\n\nLook for:\n\n- destructive migrations\n- removed or changed API fields\u002Fendpoints\n- renamed or removed config keys\n- `BREAKING:` or `BREAKING CHANGE:` commit signals\n\nKey commands:\n\n```bash\ngit diff --name-only v{last}..HEAD -- packages\u002Fdb\u002Fsrc\u002Fmigrations\u002F\ngit diff v{last}..HEAD -- packages\u002Fdb\u002Fsrc\u002Fschema\u002F\ngit diff v{last}..HEAD -- server\u002Fsrc\u002Froutes\u002F server\u002Fsrc\u002Fapi\u002F\ngit log v{last}..HEAD --format=\"%s\" | rg -n 'BREAKING CHANGE|BREAKING:|^[a-z]+!:' || true\n```\n\nIf breaking changes are detected, flag them prominently — they must appear in the\nBreaking Changes section with an upgrade path.\n\n## Step 4 — Categorize for Users\n\nUse these stable changelog sections:\n\n- `Breaking Changes`\n- `Highlights`\n- `Improvements`\n- `Fixes`\n- `Upgrade Guide` when needed\n\nExclude purely internal refactors, CI changes, and docs-only work unless they materially affect users.\n\nGuidelines:\n\n- group related commits into one user-facing entry\n- write from the user perspective\n- keep highlights short and concrete\n- spell out upgrade actions for breaking changes\n\n### Inline PR and contributor attribution\n\nWhen a bullet item clearly maps to a merged pull request, add inline attribution at the\nend of the entry in this format:\n\n```\n- **Feature name** — Description. ([#123](https:\u002F\u002Fgithub.com\u002Fpaperclipai\u002Fpaperclip\u002Fpull\u002F123), @contributor1, @contributor2)\n```\n\nRules:\n\n- Only add a PR link when you can confidently trace the bullet to a specific merged PR.\n  Use merge commit messages (`Merge pull request #N from user\u002Fbranch`) to map PRs.\n- List the contributor(s) who authored the PR. Use GitHub usernames, not real names or emails.\n- If multiple PRs contributed to a single bullet, list them all: `([#10](url), [#12](url), @user1, @user2)`.\n- If you cannot determine the PR number or contributor with confidence, omit the attribution\n  parenthetical — do not guess.\n- Core maintainer commits that don't have an external PR can omit the parenthetical.\n\n## Step 5 — Write the File\n\nTemplate:\n\n```markdown\n# vYYYY.MDD.P\n\n> Released: YYYY-MM-DD\n\n## Breaking Changes\n\n## Highlights\n\n## Improvements\n\n## Fixes\n\n## Upgrade Guide\n\n## Contributors\n\nThank you to everyone who contributed to this release!\n\n@username1, @username2, @username3\n```\n\nOmit empty sections except `Highlights`, `Improvements`, and `Fixes`, which should usually exist.\n\nThe `Contributors` section should always be included. List every person who authored\ncommits in the release range, @-mentioning them by their **GitHub username** (not their\nreal name or email). To find GitHub usernames:\n\n1. Extract usernames from merge commit messages: `git log v{last}..HEAD --oneline --merges` — the branch prefix (e.g. `from username\u002Fbranch`) gives the GitHub username.\n2. For noreply emails like `user@users.noreply.github.com`, the username is the part before `@`.\n3. For contributors whose username is ambiguous, check `gh api users\u002F{guess}` or the PR page.\n\n**Never expose contributor email addresses.** Use `@username` only.\n\nExclude bot accounts (e.g. `lockfile-bot`, `dependabot`) from the list. List contributors\nin alphabetical order by GitHub username (case-insensitive).\n\n## Step 6 — Review Before Release\n\nBefore handing it off:\n\n1. confirm the heading is the stable version only\n2. confirm there is no `-canary` language in the title or filename\n3. confirm any breaking changes have an upgrade path\n4. present the draft for human sign-off\n\nThis skill never publishes anything. It only prepares the stable changelog artifact.\n","# Release Changelog Skill\n\nGenerate the user-facing changelog for the **stable** Paperclip release.\n\n## Versioning Model\n\nPaperclip uses **calendar versioning (calver)**:\n\n- Stable releases: `YYYY.MDD.P` (e.g. `2026.318.0`)\n- Canary releases: `YYYY.MDD.P-canary.N` (e.g. `2026.318.1-canary.0`)\n- Git tags: `vYYYY.MDD.P` for stable, `canary\u002FvYYYY.MDD.P-canary.N` for canary\n\nThere are no major\u002Fminor\u002Fpatch bumps. The stable version is derived from the\nintended release date (UTC) plus the next same-day stable patch slot.\n\nOutput:\n\n- `releases\u002FvYYYY.MDD.P.md`\n\nImportant rules:\n\n- even if there are canary releases such as `2026.318.1-canary.0`, the changelog file stays `releases\u002Fv2026.318.1.md`\n- do not derive versions from semver bump types\n- do not create canary changelog files\n\n## Step 0 — Idempotency Check\n\nBefore generating anything, check whether the file already exists:\n\n```bash\nls releases\u002FvYYYY.MDD.P.md 2>\u002Fdev\u002Fnull\n```\n\nIf it exists:\n\n1. read it first\n2. present it to the reviewer\n3. ask whether to keep it, regenerate it, or update specific sections\n4. never overwrite it silently\n\n## Step 1 — Determine the Stable Range\n\nFind the last stable tag:\n\n```bash\ngit tag --list 'v*' --sort=-version:refname | head -1\ngit log v{last}..HEAD --oneline --no-merges\n```\n\nThe stable version comes from one of:\n\n- an explicit maintainer request\n- `.\u002Fscripts\u002Frelease.sh stable --date YYYY-MM-DD --print-version`\n- the release plan already agreed in `doc\u002FRELEASING.md`\n\nDo not derive the changelog version from a canary tag or prerelease suffix.\nDo not derive major\u002Fminor\u002Fpatch bumps from API intent — calver uses the date and same-day stable slot.\n\n## Step 2 — Gather the Raw Inputs\n\nCollect release data from:\n\n1. git commits since the last stable tag\n2. `.changeset\u002F*.md` files\n3. merged PRs via `gh` when available\n\nUseful commands:\n\n```bash\ngit log v{last}..HEAD --oneline --no-merges\ngit log v{last}..HEAD --format=\"%H %s\" --no-merges\nls .changeset\u002F*.md | grep -v README.md\ngh pr list --state merged --search \"merged:>={last-tag-date}\" --json number,title,body,labels\n```\n\n## Step 3 — Detect Breaking Changes\n\nLook for:\n\n- destructive migrations\n- removed or changed API fields\u002Fendpoints\n- renamed or removed config keys\n- `BREAKING:` or `BREAKING CHANGE:` commit signals\n\nKey commands:\n\n```bash\ngit diff --name-only v{last}..HEAD -- packages\u002Fdb\u002Fsrc\u002Fmigrations\u002F\ngit diff v{last}..HEAD -- packages\u002Fdb\u002Fsrc\u002Fschema\u002F\ngit diff v{last}..HEAD -- server\u002Fsrc\u002Froutes\u002F server\u002Fsrc\u002Fapi\u002F\ngit log v{last}..HEAD --format=\"%s\" | rg -n 'BREAKING CHANGE|BREAKING:|^[a-z]+!:' || true\n```\n\nIf breaking changes are detected, flag them prominently — they must appear in the\nBreaking Changes section with an upgrade path.\n\n## Step 4 — Categorize for Users\n\nUse these stable changelog sections:\n\n- `Breaking Changes`\n- `Highlights`\n- `Improvements`\n- `Fixes`\n- `Upgrade Guide` when needed\n\nExclude purely internal refactors, CI changes, and docs-only work unless they materially affect users.\n\nGuidelines:\n\n- group related commits into one user-facing entry\n- write from the user perspective\n- keep highlights short and concrete\n- spell out upgrade actions for breaking changes\n\n### Inline PR and contributor attribution\n\nWhen a bullet item clearly maps to a merged pull request, add inline attribution at the\nend of the entry in this format:\n\n```\n- **Feature name** — Description. ([#123](https:\u002F\u002Fgithub.com\u002Fpaperclipai\u002Fpaperclip\u002Fpull\u002F123), @contributor1, @contributor2)\n```\n\nRules:\n\n- Only add a PR link when you can confidently trace the bullet to a specific merged PR.\n  Use merge commit messages (`Merge pull request #N from user\u002Fbranch`) to map PRs.\n- List the contributor(s) who authored the PR. Use GitHub usernames, not real names or emails.\n- If multiple PRs contributed to a single bullet, list them all: `([#10](url), [#12](url), @user1, @user2)`.\n- If you cannot determine the PR number or contributor with confidence, omit the attribution\n  parenthetical — do not guess.\n- Core maintainer commits that don't have an external PR can omit the parenthetical.\n\n## Step 5 — Write the File\n\nTemplate:\n\n```markdown\n# vYYYY.MDD.P\n\n> Released: YYYY-MM-DD\n\n## Breaking Changes\n\n## Highlights\n\n## Improvements\n\n## Fixes\n\n## Upgrade Guide\n\n## Contributors\n\nThank you to everyone who contributed to this release!\n\n@username1, @username2, @username3\n```\n\nOmit empty sections except `Highlights`, `Improvements`, and `Fixes`, which should usually exist.\n\nThe `Contributors` section should always be included. List every person who authored\ncommits in the release range, @-mentioning them by their **GitHub username** (not their\nreal name or email). To find GitHub usernames:\n\n1. Extract usernames from merge commit messages: `git log v{last}..HEAD --oneline --merges` — the branch prefix (e.g. `from username\u002Fbranch`) gives the GitHub username.\n2. For noreply emails like `user@users.noreply.github.com`, the username is the part before `@`.\n3. For contributors whose username is ambiguous, check `gh api users\u002F{guess}` or the PR page.\n\n**Never expose contributor email addresses.** Use `@username` only.\n\nExclude bot accounts (e.g. `lockfile-bot`, `dependabot`) from the list. List contributors\nin alphabetical order by GitHub username (case-insensitive).\n\n## Step 6 — Review Before Release\n\nBefore handing it off:\n\n1. confirm the heading is the stable version only\n2. confirm there is no `-canary` language in the title or filename\n3. confirm any breaking changes have an upgrade path\n4. present the draft for human sign-off\n\nThis skill never publishes anything. It only prepares the stable changelog artifact.\n",{"name":5,"description":7},"main","83f8367d44a638ab2f3cefa0eb4f2e55cf128411",".agents\u002Fskills\u002Frelease-changelog",0,"https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler","https:\u002F\u002Fgithub.com\u002Fkangnam7654","kangnam7654.github.io","AI Engineer","2026-04-21 01:56:05",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add kangnam7654\u002Fstapler --skill release-changelog",{"tool":53,"command":54},"bunx","bunx skills add kangnam7654\u002Fstapler --skill release-changelog",{"tool":56,"command":57},"pnpm","pnpm dlx skills add kangnam7654\u002Fstapler --skill release-changelog","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-changelog\u002FSKILL.md",true,[],[62,88,115,141,164,171],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":33},"01M6K5BEQC9HE20WYMESKVC8FS","para-memory-files","File-based memory system using Tiago Forte's PARA method. Use this skill whenever you need to store, retrieve, update, or organize knowledge across sessions. Covers three memory layers: (1) Knowledge graph in PARA folders with atomic YAML facts, (2) Daily notes as raw timeline, (3) Tacit knowledge about user patterns. Also handles planning files, memory decay, weekly synthesis, and recall via qmd. Trigger on any memory operation: saving facts, writing daily notes, creating entities, running weekly synthesis, recalling past context, or managing plans.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpara-memory-files\u002FSKILL.md",[],[69,70,71,72,73,74,75,76,77,78,79,80,81,26,82,83,84,85,86,87],"para","para memory files","files","memory","patterns","weekly","past","you","memory system","as","across","organize","weekly synthesis","knowledge","knowledge graph","graph","update","notes","writing",{"skillNo":89,"name":24,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":98,"publishedAt":33},"01M6K5BAA23289JDBBR8R1WSJN","Interact with the Paperclip control plane API to manage tasks, coordinate with other agents, and follow company governance. Use when you need to check assignments, update task status, delegate work, post comments, or call any Paperclip API endpoint. Do NOT use for the actual domain work itself (writing code, research, etc.) — only for Paperclip coordination.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip\u002FSKILL.md",[93],{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,99,76,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,87,85],"only","domain","update task","plane","coordinate","do","api endpoint","code","delegate","work","coordination","api","endpoint","for","tasks","status",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":33},"01M6K5B48SE9AFAM77SEPJ8R5K","paperclip-create-plugin","Create new Paperclip plugins with the current alpha SDK\u002Fruntime. Use when scaffolding a plugin package, adding a new example plugin, or updating plugin authoring docs. Covers the supported worker\u002FUI surface, route conventions, scaffold flow, and verification steps.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip-create-plugin\u002FSKILL.md",[],[122,123,124,24,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140],"create plugin","plugin","create","paperclip create plugin","worker","sdk","route","with","authoring","runtime","scaffolding","plugin authoring","example","use","flow","alpha","plugins","package","verification",{"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":148,"publishedAt":33},"01M6K5AZ86H1RMTNDC5XCYCEVE","paperclip-create-agent","Create new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt\u002Fconfig, and submit a hire request.","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fskills\u002Fpaperclip-create-agent\u002FSKILL.md",[147],{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},[149,24,124,150,151,152,153,76,129,154,155,156,157,158,159,135,160,161,162,163],"paperclip create agent","create agent","new agent","Existing","inspect","hire","compare","adapter","submit","draft","options","prompt","Hiring","governance","config",{"skillNo":165,"name":166,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":33},"01M6K5AVNJ2YWX6A4YB8RM0VNW","Workspace Skill","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fnative\u002Fskills-scanner\u002Ftests\u002Ffixtures\u002Fws_project_root\u002FSKILL.md",[],[166,170],"workspace",{"skillNo":172,"name":173,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":33},"01M6K5AQYTEY5GYM79GYVYKZDG","Inline Metadata Skill","https:\u002F\u002Fgithub.com\u002Fkangnam7654\u002Fstapler\u002Fblob\u002Fmain\u002Fnative\u002Fskills-scanner\u002Ftests\u002Ffixtures\u002Fws_inline_yaml\u002FSKILL.md",[],[173,177,178,24,179],"inline","metadata","github"]