Alien-Libgit2

 view release on metacpan or  search on metacpan

.claude/agents/alien-libgit2-worker.md  view on Meta::CPAN

A single unforced `dzil test` is not verification for anything that touches the
alienfile: on a machine with libgit2 installed it never enters the share build,
and on Debian it never enters the probe path. Run the forced pair.

## Out of lane

- Do not lower `minimum_version` to make a probe succeed — the floor is the ssh
  hang fix, and a Debian probe failure is the designed outcome.
- Do not add a second tarball to `share/`, and do not add a network `start_url`.
  Offline install is a promise this distribution makes.
- Never run `dzil release` or upload to CPAN. Pre-release audit goes through
  `alien-libgit2-release-checker`.

.claude/rules/alien-libgit2-rules.md  view on Meta::CPAN

`refs/karr/*` of this repo: `karr board` / `karr list --compact` to see open work,
`karr create "Title" --priority high`, `karr move ID in-progress --claim NAME`,
`karr handoff ID --claim NAME`. Full surface: that skill.

Work owned by `Git::Libgit2` or `Git::Native` becomes a ticket on that repo's board —
never a direct edit there. **Serialize board mutations when fanning out**: implementation
may run parallel, the `karr move`/`handoff`/`sync` calls run sequentially.

## Release — never without permission

`dzil build` / `dzil test` are fine anytime. `dzil release` and any CPAN upload are
STRICTLY forbidden without the maintainer's explicit go-ahead — even if a plan lists
"release" as the next step. A libgit2 version change is always its own release, and
`Git::Libgit2` / `Git::Native` get told. Pre-release audit goes through
`alien-libgit2-release-checker`.

## Public issues (GitHub) — never act without instruction

**karr** is the internal agent board, churned freely. **GitHub issues**
(`github.com/Getty/p5-alien-libgit2`) are the public tracker: real humans, published under
the maintainer's account. Never act on one on your own initiative — not even to read it —

.claude/skills/getty-perl-release-author-getty/SKILL.md  view on Meta::CPAN

- `adoptme` - Add x_adoptme metadata
- `no_github` - Skip GithubMeta and GitHub::CreateRelease, use Repository instead. Auto-set to 1 when `.git/config` has no github.com remote; set `no_github = 0` to force GitHub plugins on anyway
- `no_github_release` - Skip only GitHub::CreateRelease. Same auto-detection; when active, `dzil release` creates a GitHub Release and attaches the tarball, which needs `~/.github-identity` (login + token)
- `gitea` - Treat the remote host as Gitea/Forgejo (repository/bugtracker/homepage via GiteaMeta). Only needed for self-hosted instances — codeberg.org and the author's own are auto-detected. No effect when a GitHub remote exists
- `include_readme` - Ship README.md (excluded from the tarball by default)
- `no_install` - Resulting distribution can't be installed
- `generate_license` - Go back to a generated LICENSE: `@Basic` keeps its License plugin, no LicenseFile check is added. Default 0 — the bundle expects a committed LICENSE (see above)

### Identity & Metadata
- `author` - CPAN author name used for the authority
- `authority` - Override the authority, e.g. `authority = ETHER` when uploading modules owned by another author (default: the `author` value)

### XS with Alien
- `xs_alien = Alien::Foo` - Auto-configures MakeMaker::Awesome for XS+Alien
- `xs_object = Name` - Override XS object name (default: derived from Alien name)

### Versioning
- `task = 1` - TaskWeaver + AutoVersion
- `manual_version = x.x` - Manual version
- `major_version = 2` - Major version for AutoVersion
- `version_finder` - multi-value; forwarded as the `finder` option of RewriteVersion::Transitional + BumpVersionAfterRelease (default path) and PkgVersion (task/manual_version path). Defaults to `:MainModule` when `no_cpan` is set, otherwise unset.

.claude/skills/getty-perl-release-author-getty/SKILL.md  view on Meta::CPAN

**Executables belong in `bin/`, never `script/`.** The bundle sets no `ExecDir`, so
Dist::Zilla's default of `bin` applies: files under `script/` are not installed as
executables and their `$VERSION` is never rewritten. A distribution with a `script/`
directory should have it renamed to `bin/` — otherwise none of the above takes
effect.

## Release Workflow

```bash
dzil release        # Builds, tests, uploads to CPAN, bumps version, commits, tags
```

Read the `{{$NEXT}}` section of `Changes` once as a whole first. It was written bullet
by bullet over weeks, so this is where entries circling one topic get merged into one
and over-detailed ones get cut back (skill `getty-git-commit-style`). It is not only a
changelog: `GitHub::CreateRelease` runs with `notes_from = ChangeLog` and publishes the
section verbatim as the release notes.

Fix it in its own commit *before* `dzil release`. `Changes` sits in the release commit's
`allow_dirty` list, so an uncommitted edit stops nothing — it is folded into the release