[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FE4QYB436ZS8H3SWWHA4F":3,"skill-same:01M71FE4QYB436ZS8H3SWWHA4F":71},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":22,"commitSha":44,"skillDirectory":45,"forksCount":14,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M71FE4QYB436ZS8H3SWWHA4F","reorganize-branch-commits",null,"Reorganize the commits on a non-default git branch into a clean, logical history by rewriting the branch — `git reset` + re-commit by default, `git rebase -i` when commit boundaries already align. Propose groupings based on the actual work done (features, refactors, tests, fixes, docs), get explicit user approval, back the branch up, then rewrite history. Use this skill whenever the user wants to tidy up, clean up, reorganize, restructure, squash, or curate commits on a feature branch — even if they phrase it as \"my branch is a mess\", \"squash this down\", \"combine these commits\", \"fix up the commit log before I open a PR\", or \"make the commits presentable for review\". Trigger proactively when the user is about to open or push a PR and the branch has scrappy\u002FWIP\u002F\"fix\" commits to collapse. Refuses to operate on default or release-shaped branches (main, master, develop, trunk, production, release, or the repo default) — a feature-branch-only tool.","esond\u002Fskills","esond","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4650644?v=4","01M71FCJGKDH30JSHK6XJZXN8Y","Eric Sondergard","01M71FCJHP4WCJVP4HVMEW1KB2",0,"MIT","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Freorganize-branch-commits\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"reorganize branch commits","commits","branch","main","when","operate","re","get","done","align","branches","back","commit","clean","default","up","only","fix","tidy","open","2026-11-10 10:12:30",false,"---\nname: reorganize-branch-commits\ndescription: >-\n  Reorganize the commits on a non-default git branch into a clean, logical\n  history by rewriting the branch — `git reset` + re-commit by default,\n  `git rebase -i` when commit boundaries already align. Propose groupings\n  based on the actual work done (features, refactors, tests, fixes, docs), get\n  explicit user approval, back the branch up, then rewrite history. Use this\n  skill whenever the user wants to tidy up, clean up, reorganize, restructure,\n  squash, or curate commits on a feature branch — even if they phrase it as\n  \"my branch is a mess\", \"squash this down\", \"combine these commits\", \"fix up\n  the commit log before I open a PR\", or \"make the commits presentable for\n  review\". Trigger proactively when the user is about to open or push a PR and\n  the branch has scrappy\u002FWIP\u002F\"fix\" commits to collapse. Refuses to operate on\n  default or release-shaped branches (main, master, develop, trunk,\n  production, release, or the repo default) — a feature-branch-only tool.\n---\n\n# reorganize-branch-commits\n\nRewrite the commits on a feature branch into a clean, logical history. Every commit from the base forward gets a new hash.\n\n## Step 1 — check the branch\n\nThe repo default is `git symbolic-ref refs\u002Fremotes\u002Forigin\u002FHEAD --short | sed 's@^origin\u002F@@'`. The base is `git merge-base HEAD origin\u002F\u003Cdefault>`, unless the user names another (a branch stacked on another feature branch).\n\nStop and tell the user if any of these hold:\n\n- HEAD is detached, or the branch is `main`, `master`, `trunk`, `develop`, `production`, `release`, or the repo default.\n- `git status` shows uncommitted changes or an in-progress rebase, merge, or cherry-pick. A reset would fold uncommitted edits into the new commits.\n- The branch has fewer than two commits past the base.\n\n## Step 2 — propose a history\n\nRead `git log --name-status \u003Cbase>..HEAD` and the diffs behind it. Group by what the diffs actually do, not by the existing messages: one logical change per commit, refactors before the feature that needs them, and \"wip\" \u002F \"fix typo\" \u002F \"address review\" commits folded into the change they serve. Match the subject style of recent commits on the default branch.\n\nPresent a numbered list of new commits, each with its subject, the source commits folded into it, and the files it touches. Every existing commit must be accounted for. Flag merge commits (they'll be flattened) and commits by other authors (a reset re-attributes them to the current user).\n\nIf the branch has an upstream, say that finishing will need a force push. Don't rewrite anything until the user approves the proposal.\n\n## Step 3 — back up\n\n```bash\ngit branch \"backup\u002F\u003Cbranch>\u002F$(date -u +%Y%m%dT%H%M%SZ)\"\n```\n\nTell the user the backup's name; `git reset --hard \u003Cbackup>` restores the original branch.\n\n## Step 4 — rewrite\n\n`git reset \u003Cbase>`, then stage and commit each group in order. Use `git add -p` when one file's hunks belong to different groups. Let hooks run; never pass `--no-verify`.\n\nUse `git rebase -i \u003Cbase>` instead when the existing commit boundaries already match the groups, or when other authors' commits must keep their authorship. If it stops on a conflict, report the paths and let the user decide whether to resolve or abort.\n\n## Step 5 — verify and hand off\n\n`git diff \u003Cbackup> HEAD` must be empty. If it isn't, show the user the difference: a missed hunk goes into a commit, while hook output (formatters, codegen) needs the user's OK. Then show `git log --oneline \u003Cbase>..HEAD`.\n\nOnce the diff is empty or the user has accepted what's left, ask whether to push, and push only on a yes: `git push --force-with-lease` if the branch has an upstream, otherwise `git push -u origin \u003Cbranch>`. Never use plain `--force`.\n\nAfter the push succeeds, offer to delete the backup with `git branch -D \u003Cbackup>`, and keep it if the user declines.\n","# reorganize-branch-commits\n\nRewrite the commits on a feature branch into a clean, logical history. Every commit from the base forward gets a new hash.\n\n## Step 1 — check the branch\n\nThe repo default is `git symbolic-ref refs\u002Fremotes\u002Forigin\u002FHEAD --short | sed 's@^origin\u002F@@'`. The base is `git merge-base HEAD origin\u002F\u003Cdefault>`, unless the user names another (a branch stacked on another feature branch).\n\nStop and tell the user if any of these hold:\n\n- HEAD is detached, or the branch is `main`, `master`, `trunk`, `develop`, `production`, `release`, or the repo default.\n- `git status` shows uncommitted changes or an in-progress rebase, merge, or cherry-pick. A reset would fold uncommitted edits into the new commits.\n- The branch has fewer than two commits past the base.\n\n## Step 2 — propose a history\n\nRead `git log --name-status \u003Cbase>..HEAD` and the diffs behind it. Group by what the diffs actually do, not by the existing messages: one logical change per commit, refactors before the feature that needs them, and \"wip\" \u002F \"fix typo\" \u002F \"address review\" commits folded into the change they serve. Match the subject style of recent commits on the default branch.\n\nPresent a numbered list of new commits, each with its subject, the source commits folded into it, and the files it touches. Every existing commit must be accounted for. Flag merge commits (they'll be flattened) and commits by other authors (a reset re-attributes them to the current user).\n\nIf the branch has an upstream, say that finishing will need a force push. Don't rewrite anything until the user approves the proposal.\n\n## Step 3 — back up\n\n```bash\ngit branch \"backup\u002F\u003Cbranch>\u002F$(date -u +%Y%m%dT%H%M%SZ)\"\n```\n\nTell the user the backup's name; `git reset --hard \u003Cbackup>` restores the original branch.\n\n## Step 4 — rewrite\n\n`git reset \u003Cbase>`, then stage and commit each group in order. Use `git add -p` when one file's hunks belong to different groups. Let hooks run; never pass `--no-verify`.\n\nUse `git rebase -i \u003Cbase>` instead when the existing commit boundaries already match the groups, or when other authors' commits must keep their authorship. If it stops on a conflict, report the paths and let the user decide whether to resolve or abort.\n\n## Step 5 — verify and hand off\n\n`git diff \u003Cbackup> HEAD` must be empty. If it isn't, show the user the difference: a missed hunk goes into a commit, while hook output (formatters, codegen) needs the user's OK. Then show `git log --oneline \u003Cbase>..HEAD`.\n\nOnce the diff is empty or the user has accepted what's left, ask whether to push, and push only on a yes: `git push --force-with-lease` if the branch has an upstream, otherwise `git push -u origin \u003Cbranch>`. Never use plain `--force`.\n\nAfter the push succeeds, offer to delete the backup with `git branch -D \u003Cbackup>`, and keep it if the user declines.\n",{"name":5,"description":7},"029bf6d49f3d270442ace55a01cccb40113f7efa","plugins\u002Feng\u002Fskills\u002Freorganize-branch-commits","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills","https:\u002F\u002Fgithub.com\u002Fesond","https:\u002F\u002Flinktr.ee\u002Fesond0","Serial pragmatist.\r\n\r\nCheck out my other repos at @hexagram-solutions! ","2026-11-07 00:00:12",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add esond\u002Fskills --skill reorganize-branch-commits",{"tool":57,"command":58},"bunx","bunx skills add esond\u002Fskills --skill reorganize-branch-commits",{"tool":60,"command":61},"pnpm","pnpm dlx skills add esond\u002Fskills --skill reorganize-branch-commits","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Freorganize-branch-commits\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"agents\u002Fopenai.yaml","REFERENCE","参考文档",133,"https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Freorganize-branch-commits\u002Fagents\u002Fopenai.yaml",[72,96,121,147,159,195],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":39},"01M71FF0KCP66CRNT9AT1T18Z9","work-item-voice","Write or edit the user's issues in their own voice, in any work tracker — Jira, Linear, GitHub Issues, Azure DevOps. Covers features (new behavior), tasks (work that needs doing), and bugs (behavior that does not match expectation). Load this whenever the deliverable is an issue body, whether they say \"file a bug\", \"write a ticket\", \"draft a story\", \"create an issue for this\", \"turn this into a Jira\", \"write this up in Linear\", or paste a thread and ask for an issue out of it. Load it too whenever text goes into an issue that already exists — \"record this in the issue\", \"add what we found to the ticket\", \"note this on the card\", \"update the one about refunds\", or naming an issue by its key and asking for a fact to go in it — and when writing or updating one is a step inside a larger task. Features get behavior-driven framing with no implementation prescribed, and bugs get expected versus actual. Not for a comment on an issue, which is a conversation turn.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fesond\u002Fskills\u002Fwork-item-voice\u002FSKILL.md",[],[79,80,81,82,83,84,26,85,86,34,87,88,89,90,23,91,92,93,94,95],"work","work item voice","work item","voice","conversation","which","card","ticket","issues","new","writing","azure devops","ask","tasks","text","create","tracker",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":107,"publishedAt":39},"01M71FETV1H7JPCTSKMW3XZV1T","conversational-voice","Write the user's side of a conversation with another person, in the user's own voice: Slack messages and replies, DMs, email, PR and code-review comments, Linear or Jira comments, and any other turn in an exchange that goes out under the user's name. Load this whenever the deliverable is a message a human will read as written by the user, whether they say \"draft a Slack message\", \"reply to this\", \"how should I word this\", \"tell the team\", \"ask them about X\", \"send a note to\", or just paste a thread and ask what to say back. Load it too when tightening, shortening, or sanity-checking a message they already wrote, and when a message is one step of a larger task. The register is direct and informal, the way they'd talk to a friend or acquaintance, with the answer up front for a reader who skims. Not for something the user authors rather than sends — an issue body, a PR description, a commit message — even though a person reads those too.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fesond\u002Fskills\u002Fconversational-voice\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[108,82,30,83,109,110,34,111,23,91,112,31,113,114,115,116,117,118,119,120],"conversational voice","messages","send","slack messages","code","team","code-review","review","sanity","message","slack","human","how",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":132,"publishedAt":39},"01M71FEN36NS9Y4RVX6KQ704TB","sync-core-repo-docs","Create or audit a repo's three core doc files — README.md, the agent instructions file (AGENTS.md or CLAUDE.md), and REVIEW.md — in that dependency order. If a file is missing, generate it from the codebase; if it exists, audit it against the current code and apply targeted fixes after confirmation. README.md gets a developer from clone to running the project; AGENTS.md captures coding guidance for the agent (delegating to \u002Finit or claude-md-improver); REVIEW.md holds guidance for code reviewers, human or automated, without duplicating AGENTS.md. Target files with --readme, --claude, and --review, or run all three. Use whenever the user wants to set up, bootstrap, scaffold, refresh, audit, update, or sync a repo's docs, or says things like \"create a README\", \"is my README still accurate\", \"write a CLAUDE.md\", \"write an AGENTS.md\", \"audit our docs\", or \"get this repo ready for contributors\" — even when only one file is named. Prefer it over claude-md-improver when README or REVIEW are also in scope.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Fsync-core-repo-docs\u002FSKILL.md",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[133,134,135,136,137,138,139,140,141,26,142,143,34,144,35,145,146,23,112,115],"sync","sync core repo docs","repo docs","core","repo","docs","agent instructions","SET","ready","scope","project","init","files","confirmation",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":39},"01M71FEKJQ2G2NQ4NCXRR9SD63","sync-core-docs","Create or audit a repo's README.md, AGENTS.md\u002FCLAUDE.md, and REVIEW.md docs.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Fsync-core-docs\u002FSKILL.md",[],[154,138,136,133,94,155,156,157,158,137,115],"sync core docs","true","md docs","audit","README",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":174,"publishedAt":39},"01M71FEAWPC8BM27EE0A90VT8T","righting-software-system-design","Opt-in, collaborative system-design workflow based on Juval Löwy's iDesign methodology in *Righting Software*. Conducts a multi-phase interview (framing → use cases → volatility analysis → components → call-chain validation → report) that surfaces unknown-unknowns and produces a written recommendation at `decompositions\u002F{system-name}\u002Freport.md`. **Run only when the user explicitly invites this workflow** — not for general architecture questions, lightweight design conversations, or quick \"where should X live?\" questions. Valid triggers: the user names the skill directly, references *Righting Software* \u002F Juval Löwy \u002F iDesign \u002F \"The Method\" \u002F volatility-based decomposition and asks to run a full session, asks for a \"deep\" or \"structured\" or \"Löwy-style\" system design session, or accepts a prior suggestion to run it. Wait for an explicit yes before entering Phase 0. The skill is interrogative — a back-and-forth interview that challenges each volatility candidate and proposes ones the user hasn't considered.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Frighting-software-system-design\u002FSKILL.md",[165,168,171],{"categoryNo":166,"categoryName":167,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":169,"categoryName":170,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":172,"categoryName":173,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000032","设计师",[175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194],"system design","design","software","system","righting software","righting software system design","deep","quick","wait for","unknown","components","candidate","architecture","phase","valid","run","at","wait","live","full",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":39},"01M71FE0TZQXH44K88DSFDEA98","pr-review-resolver","Address outstanding review feedback on a GitHub pull request: unresolved review threads, submitted review bodies, and general PR comments. Triages each critically, fixes what it agrees with, and pushes back on the rest. Use whenever the user wants to address, fix, resolve, or work through PR review comments or feedback, even if they just say \"handle the PR comments\", \"fix what the reviewers said\", or \"go through the PR\", or pastes a PR URL and asks you to act on the feedback there.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Fpr-review-resolver\u002FSKILL.md",[],[202,203,115,204,205,30,206,207,208,209,210,36,211,212,213,214,215,216,91,217],"pr","pr review","resolver","pr review resolver","pull","feedback","pr review comments","fixes","just","general","review feedback","use","number","URL","you","comments"]