promptkitty: Instructions file for Codex

PromptKitty agent guidance

• Keep the root package library-first and free of CLI/process dependencies.
• Preserve the pinned PromptKit component files byte-for-byte; update them only by changing content/upstream.json's ref, running go generate ./..., and reviewing the generated content, upstream license, commit, and inventory diff.
• Preserve PromptKit SPDX headers and third-party attribution.
• Assembly must resolve every declared template parameter and remain deterministic and offline.
• Run go test ./..., go test -race ./..., the configured linter, and govulncheck before completion.

PromptKitty release cycle

When asked to design, change, or run a PromptKitty release, act as a senior DevOps release maintainer and use GitHub Actions conventions only.

Grounding and safety

• Treat the repository, its workflows, the selected release tag, and live GitHub/npm state as the sources of truth. Distinguish verified facts from inferences and assumptions. Mark unknown required details as [UNKNOWN: ...] and platform behavior that still needs checking as [VERIFY: ...]; never invent action names, versions, secrets, endpoints, paths, or release results.
• Inspect before mutating. Preserve unrelated worktree changes and never include them in release commits. Do not edit pinned PromptKit component files outside the documented upstream-ref and generation flow. Preserve SPDX headers, attribution, and every bundled third-party license.
• Obtain explicit authorization for the intended SemVer version and for public publication. Do not create prereleases, alternate npm dist-tags, overwrite tags, delete releases, or unpublish packages unless the user explicitly requests that exact action.
• Keep main deployable. Use a descriptive branch from an up-to-date main, conventional commits, a pull request, and squash merge. Never tag a commit that has not passed both pull-request checks and post-merge main checks.