sd_scripts_docker

Set up and use an isolated Git worktree for repository implementation tasks. Use unless the user explicitly requests another workspace arrangement.

Review or draft repository commit messages for Conventional Commits format, accurate change summaries, breaking-change footers, and required attribution trailers. Use before creating, amending, or validating a commit.

Maintain a canonical developer changelog and versioned release history. Use when adding or correcting Keep a Changelog entries, prerelease history, compatibility context, or release-source material; not for user-facing release notes or publishing.

Review implementation changes for readability, maintainability, design intent, and verification. Use for source code, tests, scripts, configuration, generated or vendored files, and dependencies; pair with security-check for security- or supply-chain-sensitive changes.

Create or update repository `.gitignore` rules, including pinned upstream template syncs. Use when changing ignored-file behavior or merging `github/gitignore` content.

Review or revise explanatory prose for readability, local structure, audience fit, and preserved nuance. Use for wording in documentation, comments, release notes, issues, pull requests, changelogs, handoff notes, and Agent Skills after the document's purpose and factual ownership are known. Use software-documentation-maintenance instead for repository-wide document maps, canonical ownership, technical evidence, coverage, or migration.

Create or review channel-specific release notes from a canonical changelog. Use when checking destination history or publication readiness.

Review repository changes for practical security and supply-chain risks. Use when work touches secrets, permissions, untrusted input, dependencies, executable or downloaded artifacts, CI or deployment configuration, containers, or vendored/generated files; skip documentation-only changes with no security-sensitive surface.