review the changes, I'm adding for the first time the goreleaser configuration to release versions using goreleaser. Review the changes, and, there are a couple of things missing like, completions (is

Claude Code·Opus 4.7[1m]·

gtrrz-victor·5mo ago·39min·2 Checkpoints·5 file changes·+186·33.2K tokens

Base directory for this skill: /Users/gtrrz-victor/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/skills/using-superpowers

<SUBAGENT-STOP> If you were dispatched as a subagent to execute a specific task, skip this skill. </SUBAGENT-STOP> <EXTREMELY-IMPORTANT> If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this. </EXTREMELY-IMPORTANT>

Instruction Priority

Superpowers skills override default system prompt behavior, but user instructions always take precedence:

User's explicit instructions (CLAUDE.md, GEMINI.md, AGENTS.md, direct requests) — highest priority
Superpowers skills — override default system behavior where they conflict
Default system prompt — lowest priority

If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.

How to Access Skills

In Claude Code: Use the Skill tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.

In Copilot CLI: Use the skill tool. Skills are auto-discovered from installed plugins. The skill tool works the same as Claude Code's Skill tool.

In Gemini CLI: Skills activate via the activate_skill tool. Gemini loads skill metadata at session start and activates the full content on demand.

In other environments: Check your platform's documentation for how skills are loaded.

Platform Adaptation

Skills use Claude Code tool names. Non-CC platforms: see references/copilot-tools.md (Copilot CLI), references/codex-tools.md (Codex) for tool equivalents. Gemini CLI users get the tool mapping loaded automatically via GEMINI.md.

Using Skills

The Rule

Invoke relevant or requested skills BEFORE any response or action. Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.

Red Flags

These thoughts mean STOP—you're rationalizing:

Thought	Reality
"This is just a simple question"	Questions are tasks. Check for skills.
"I need more context first"	Skill check comes BEFORE clarifying questions.
"Let me explore the codebase first"	Skills tell you HOW to explore. Check first.
"I can check git/files quickly"	Files lack conversation context. Check for skills.
"Let me gather information first"	Skills tell you HOW to gather information.
"This doesn't need a formal skill"	If a skill exists, use it.
"I remember this skill"	Skills evolve. Read current version.
"This doesn't count as a task"	Action = task. Check for skills.
"The skill is overkill"	Simple things become complex. Use it.
"I'll just do this one thing first"	Check BEFORE doing anything.
"This feels productive"	Undisciplined action wastes time. Skills prevent this.
"I know what that means"	Knowing the concept ≠ using the skill. Invoke it.

Skill Priority

When multiple skills could apply, use this order:

Process skills first (brainstorming, debugging) - these determine HOW to approach the task
Implementation skills second (frontend-design, mcp-builder) - these guide execution

"Let's build X" → brainstorming first, then implementation skills. "Fix this bug" → debugging first, then domain-specific skills.

Skill Types

Rigid (TDD, debugging): Follow exactly. Don't adapt away discipline.

Flexible (patterns): Adapt principles to context.

The skill itself tells you which.

User Instructions

Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.

5mo ago·14m

All green. Summary of what shipped:

New file

cmd/git-sync/internal/versioninfo/versioninfo.go — exposes Version, Commit, Date for ldflag injection

cmd/git-sync/main.go

Imported versioninfo
Added version / --version case in run() switch (avoided -v since it collides with the existing verbose flag in every subcommand)
Added git-sync version to usage string

.goreleaser.yaml

Removed mise run completions before-hook (no completions implemented)
Fixed the three -X ldflags to point at the real package path entire.io/entire/gitsync/cmd/git-sync/internal/versioninfo, added Date injection
Archive name_template now includes {{ .Version }} to avoid collisions across releases
Removed completions/* archive entry (kept LICENSE + README)
homebrew_casks: renamed cask + binary to git-sync, dropped the broken completions: sub-block
Added small snapshot: and changelog: blocks (filters Merge/docs:/chore:/test: from notes)

Verification done

go build with -ldflags="-X …Version=test1.2.3 …Commit=abc1234 …Date=2026-04-30" → git-sync version prints injected values exactly
go vet ./cmd/git-sync/... clean
goreleaser check validates config

Not changed (and why)

.github/workflows/release.yml — no edit needed; GORELEASER_KEY and TAP_GITHUB_TOKEN secrets must already be in repo settings before tagging
Windows build skipped per your decision
Pre-existing diagnostic on main.go:387 (interface{} → any) is unrelated to this change

Next step when ready: git tag v0.0.0-test1 && git push origin v0.0.0-test1 for a live throwaway run, then delete tag+release after confirming the artifacts and tap PR look right.

Per README line 3: "git-sync mirrors refs from a source remote to a target remote without creating a local checkout." — that's the actual elevator pitch. Current description has two issues:

Starts with formula name (git-sync — …). Homebrew's brew audit --new-cask lint warns: "Description shouldn't start with the formula/cask name." The cask block already declares name: git-sync, so repeating it is redundant.
"replicate and sync" is internal terminology (your two operation modes). To anyone outside the project they read as synonyms — it tells the reader nothing about what makes the tool different.

The README's differentiator is "without a local checkout" — that's the line worth surfacing.

Suggested:

(58 chars, starts with verb, no period, no markdown, no formula-name repetition — matches Homebrew's convention.)

Alternates if you'd rather keep "repositories" over "refs":

"Mirror Git repositories between remotes without cloning locally" (63 chars)
"Stream Git refs from source remote to target remote, no local clone" (68 chars)

Want me to apply the first one?

snapshot: only kicks in when you run goreleaser release --snapshot (local dry-run, no git tag needed). Real tagged releases ignore it entirely.

What version_template does: snapshot mode has no real version (no tag), so goreleaser needs a fake one to stamp into archive names, ldflags Version, etc. Default is {{ incpatch .Version }}-SNAPSHOT-{{ .ShortCommit }} — verbose. Your override produces e.g. 0.1.1-next if last tag was v0.1.0.

incpatch .Version = bump patch on the latest tag (0.1.0 → 0.1.1). -next suffix marks it as not-yet-released.

When you'd actually use it:

Tests the full pipeline (build all archs, archive, checksums, homebrew formula rendering) without needing a tag or pushing anywhere. Artifacts land in dist/.

If you don't plan to dry-run locally, the block does nothing and can be deleted. Keep it if you want a one-command sanity check before tagging.

Need it? No, not strictly.

When it runs:

Only when you type goreleaser release --snapshot locally. Never in CI on tag push.
Use case: dry-run the full release pipeline (cross-compile darwin/linux × amd64/arm64, archive, checksum, render homebrew cask) before pushing a real tag. Catches typos and template errors that goreleaser check won't.

Without the block: --snapshot still works, just uses verbose default name like 0.1.1-SNAPSHOT-abc1234.

Without --snapshot ever being run: block is dead code.

Recommendation: keep it (3 lines, zero runtime cost) only if you plan to run --snapshot locally before tagging. Delete it if you'll just push a throwaway tag (v0.0.0-test1) for verification instead. The throwaway-tag approach is what your release workflow runs anyway, so it's the more honest test.

My take: delete it. You already plan a live throwaway-tag test. The snapshot block adds a second dry-run path you probably won't use.

Local goreleaser is OSS (not Pro), but your config has pro: true + notarize: (Pro-only). Two options:

Option 1 — quickest sanity check (no pro features):

…will fail at config validation because pro: true is set. To get around it, run with GORELEASER_FORCE_TOKEN=github and temporarily flip pro: false, or use the second option.

Option 2 — install goreleaser-pro and use your real config (recommended):

What this does:

--snapshot — no tag required, fakes a version
--clean — wipe dist/ first
--skip=publish,sign,notarize,homebrew — build + archive + checksum only; no GitHub upload, no macOS signing/notarization, no homebrew tap PR

After it runs, inspect dist/:

Even faster — build only, current arch only:

Skips archives/checksums/homebrew entirely. Best for the iterate loop while debugging the goreleaser file.

Base directory for this skill: /Users/gtrrz-victor/.claude/skills/ship

Ship Changes

Commit current changes, push to remote, and update the PR.

Step 1: Analyze changes

Run git diff --stat and git diff to understand what changed
Run git status to see untracked files
Run git log --oneline -3 to match the repo's commit message style

Step 2: Commit

Stage only the relevant changed/untracked files by name (never git add -A or git add .)
Write a concise commit message that focuses on the "why" not the "what"
- If `` is provided, use it as the commit message
- Otherwise, draft one from the diff
Commit. If hooks fail, diagnose and fix — do NOT use --no-verify

Step 3: Push

Check if the branch tracks a remote: git rev-parse --abbrev-ref --symbolic-full-name @{u}
If not tracking, push with -u origin <branch>
If tracking, just git push
If push is rejected (remote has new commits), pull with rebase first then push

Step 4: Update PR

Find the open PR for the current branch: gh pr view --json number,body,title
If no PR exists, skip this step and inform the user
Compare the current PR body against the new changes:
- If the changes are within the existing PR scope, update the description to reflect the current state
- If the changes are additive or a follow-up, add a PR comment summarizing what was just pushed instead
When updating the PR body, preserve the overall structure but refresh the summary bullets and test plan
When adding a comment, keep it concise — bullet points of what changed and why
Before making any PR update (description edit or comment), show the user the exact text you plan to post and ask for their approval. Do NOT post until they confirm.

Rules

Never commit files that look like secrets (.env, credentials, tokens)
Never force push
Always show the user what was committed and the PR URL when done

5mo ago·32.0s