App-karr

 view release on metacpan or  search on metacpan

.claude/agents/karr-board-worker.md  view on Meta::CPAN

  their existing specialists.

## Working loop

When a ticket id is supplied, inspect it with `karr show ID` (or
`perl -Ilib bin/karr show ID` when `karr` is not installed), reproduce before fixing, and
handoff with the exact test command and result. Use `karr create` only for genuinely separate
drift; do not expand the assigned ticket.

Tests must use temporary repositories and must never mutate the developer's real board.
Run the smallest relevant test first, then `prove -l t/`. Never run `dzil release` or upload
to CPAN.

.claude/agents/karr-foundation-worker.md  view on Meta::CPAN

  their existing specialists.

## Working loop

When a ticket id is supplied, inspect it with `karr show ID` (or
`perl -Ilib bin/karr show ID` when needed), reproduce with temporary repositories and an
obviously harmless fake agent command, then handoff with the exact test command and result.
Never run a real unattended agent drain merely to test scheduling, and clean up every process
you start.

Run the narrow foundation test first, then `prove -l t/`. Never run `dzil release`, upload to
CPAN, or push Docker images.

.claude/agents/karr-ref-worker.md  view on Meta::CPAN

## Working loop

When a ticket id is supplied, inspect it with `karr show ID` (or
`perl -Ilib bin/karr show ID` when needed), reproduce before fixing, and handoff with the
exact test command and result. New storage failures discovered out of scope become separate
`karr create` tickets.

Every test must use an isolated temporary Git repository. Never point destructive commands,
ref deletion, restore, or remote sync at the developer's real board. Run the narrow test,
then `prove -l t/`. Never run `dzil release` or upload to CPAN.

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

Workflow when fixing bugs:
1. `karr list` / `karr show <id>` to read the open ticket
2. Reproduce the bug locally before changing code
3. Fix root cause, not symptom
4. Write a regression test under `t/`
5. Run `prove -l t/` until clean
6. `karr handoff <id>` with note describing fix + commit refs

Use `karr` itself for ticket coordination — dogfood.

**Never** run `dzil release` or upload to CPAN — that needs the maintainer's explicit go-ahead. `dzil build` / `dzil test` are fine.

.claude/rules/karr-rules.md  view on Meta::CPAN

- `karr move ID in-progress --claim NAME` — start · `karr handoff ID --claim NAME --note "…"` — to review
- `NAME=$(karr agentname)` — mint a claim name **once** and reuse that same `$NAME` for move,
  handoff and `--claimed-by`; every call returns a different name, so a fresh one at handoff time
  no longer matches the claim (`karr show ID` reads the held name back off the card)

Bugs found while dogfooding become tickets on this board. Full command surface (pick / context /
set-refs / multi-agent): skill `kanban-issues-karr-cli`.

## Release — never without permission

`dzil build` / `dzil test` / `prove -l t/` are fine anytime. `dzil release` and any CPAN upload
are STRICTLY forbidden without the maintainer's explicit go-ahead — even if a plan or roadmap
lists "release" as the next step. For anything heading toward release: stop and ask. After a
release the `$VERSION` bump is a separate, deliberate commit, and it touches every file
under `lib/` and `bin/` — each one carries its own `our $VERSION`, not just
`lib/App/karr.pm`.

## Perl specifics — reference, don't restate

Module loading, Moo/Moose patterns, cpanfile pinning for Getty-authored deps, and house style
live in skill `getty-perl-core` (force-loaded for `karr-*` agents). Do not duplicate that content here.

.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