Source profileQuality 64/100

dyoshikawa/rulesync/.rulesync/skills/draft-release/SKILL.md

draft-release

Draft a new release of the project.

Source repository stars
1,263
Declared platforms
0
Static risk flags
0
Last source update
2026-07-28
Source checked
2026-07-28

Decision brief

What it does—and where it fits

Draft a new release of the project.

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/dyoshikawa/rulesync --skill ".rulesync/skills/draft-release"
    Safe inspection promptEditorial

    Inspect the Agent Skill "draft-release" from https://github.com/dyoshikawa/rulesync/blob/310b711fbe8cffc14debb276ade8a384c2b89083/.rulesync/skills/draft-release/SKILL.md at commit 310b711fbe8cffc14debb276ade8a384c2b89083. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    The source does not provide enough structured workflow evidence for a step-by-step guide.

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score64/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars1,263SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guidecatalog recordEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    dyoshikawa/rulesync
    Skill path
    .rulesync/skills/draft-release/SKILL.md
    Commit
    310b711fbe8cffc14debb276ade8a384c2b89083
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

    First, let's work on the following steps.

    1. Confirm that you are currently on the main branch and pull the latest changes. If not on main branch, switch to main branch.
    2. Compare code changes between the previous version tag and the latest commit to prepare the release description.
    • Write in English.
    • Do not include confidential information.
    • Sections, What's Changed, Contributors and Full Changelog are needed.
    • ./tmp/release-notes/*.md will be used as the release notes.

    Then, from $ARGUMENTS, get the new version without v prefix, and assign it to $new_version. For example, if $ARGUMENTS is "v1.0.0", the new version is "1.0.0".

    If $ARGUMENTS is empty, determine the new version automatically by performing the release-dry-run skill.

    Let's resume the release process.

    1. Run git pull.
    2. Run git checkout -b release/v${new_version}.
    3. Update getVersion() function to return the ${new_version} in src/cli/index.ts, and run pnpm cicheck. If the checks fail, fix the code until pass. Then, execute git add, git commit and git push.
    4. Update the version with pnpm version ${new_version} --no-git-tag-version.
    5. Since package.json will be modified, execute git commit and git push.
    6. As a precaution, verify that getVersion() in src/cli/index.ts is updated to the ${new_version}.
    7. Run gh pr create to the main branch.
    8. Create a draft release using gh release create v${new_version} --draft --title v${new_version} --notes-file ./tmp/release-notes/*.md command on the github.com/dyoshikawa/rulesync repository. This creates a draft release so that the publish-assets workflow can upload assets later.

    Note: the Homebrew tap formula (Formula/rulesync.rb) is NOT updated here. It embeds sha256 checksums of the release binaries, which only exist after the release PR merges and the Publish Assets workflow uploads them. The goal-release skill performs that update as its post-merge step (regenerate with scripts/generate-homebrew-formula.ts from the release's SHA256SUMS and land it via an immediately merged PR). When releasing manually without the goal-release skill, run that step yourself after the assets are published.

    Alternatives

    Compare before choosing