go-authcrunch: Skill for Codex

Source Code Management

Change Inspection

Inspect status, staged diff, and unstaged diff separately. Never change the index unless asked. Default a commit-message request to staged changes when the index is nonempty and state which unstaged changes are excluded. If the index is empty, describe the working-tree changes and say they must be staged before committing.

Commit Message Rules

All commits must have a proper commit message.

A hand-written commit message subject line must conform to the following rules:

• The first line of each commit message is the subject.
• The subject line MUST be less than 87 characters long.
• The subject line MUST NOT terminate with a period (.).
• The subject line MUST start with a change indicator followed by a colon (:).

Change Indicators

This repository uses change indicators as package and subsystem labels, plus a small set of maintenance labels. Prefer the most specific AuthCrunch package, CLI, provider, store, or runtime surface when the change is clearly anchored in one component. Use a maintenance label when the change is repository plumbing, documentation, tests, release work, or a deliberately cross-cutting fix.

Selection rules:

• Use exactly one indicator. Do not combine indicators or add parenthesized scopes.
• Prefer names that match repository packages, CLI names, or externally visible AuthCrunch concepts. For example, use authn, authz, oauth, ldap, kms, or authdbctl when a change is anchored there.
• Use config only for top-level authcrunch.Config, Server wiring, cross-surface validation, reload plumbing, or shared config exposure. For package-local config parsing, use the package indicator.
• Use authn for authentication portal behavior and portal API or HTTP handlers. Use ui for embedded portal/profile UI assets, templates, static assets, icons, profile UI bundles, and UI-specific serving behavior. Use cookie for cookie-specific issuing, reading, deletion, domain, and name config, even when the code lives under pkg/authn/cookie.
• Use authz for authorization gatekeepers and policies. Use acl when the change is really the shared ACL engine, and authproxy when it is remote/basic/API-key auth proxy configuration or authenticators.
• Use idp and ids for shared identity provider or identity store config, interfaces, and dispatch. Use oauth, saml, ldap, or local when the change is specific to that provider or store implementation.
• Use identity for identity and user data models, local user database records, roles, passwords, MFA tokens, API keys, WebAuthn/U2F/GPG/SSH keys, lockouts, QR codes, and pkg/user.
• Use registry for user registration providers, local registry behavior, and domain restriction rules.
• Use kms for crypto keys, keystores, token encryption/decryption, and crypto config parsing. Use system for system API protocol messages, request parsing, generated keys, and system API auth messages.
• Use redirects, authchal, credentials, messaging, translate, waf, apiauth, errors, requests, shared, tagging, or util when the primary change is in that package or its testdata.
• Use authdbctl for the CLI under cmd/authdbctl, including its README, config, commands, output, and command behavior. Use build only when build output or Makefile build behavior changes.
• Use breakfix for a reported break-fix issue, regression, panic, or shipped behavior that is visibly broken for users. Use fix for narrower correctness fixes that are not tied to known user breakage.
• Use security for vulnerability fixes, hardening, dependency-audit work, or disclosure-policy changes. If a security fix is tightly scoped to one runtime surface, prefer the surface only when the issue is being handled as ordinary correctness rather than as a vulnerability.
• Use tests, not unittest, for Go tests, fixtures, golden data, testdata, and coverage-only changes. If tests accompany a product change, choose the product indicator instead.
• Use skills for AI agent skills, skill metadata, or agent-facing repository instructions. Prefer it over docs or ops when the primary purpose is helping AI agents work with this repository.
• Use ops for dependency, Go toolchain, generated license/version metadata, release, or repository maintenance changes. Use github for GitHub Actions, issue templates, CLA workflow/assets, Funding metadata, or other GitHub repository metadata.
• Automated patch and minor releases use ops: released v<VERSION>. Use release-and-versioning for the release workflow. Hand-written release workflow changes also use ops.
• Use various only when a commit intentionally spans unrelated surfaces and no more specific indicator is honest.
• Normalize older repository labels when creating new messages: use feat for feature, fix or breakfix for bug/bugfix, authdbctl for cmd changes to the CLI, github for cla bot/workflow metadata, and a specific package indicator instead of auth, api, hosting, misc, or chore.
• Use colon form for new dependency bumps, such as ops: upgrade golang.org/x/crypto to v0.48.0, even though older history has subjects without a change indicator.