9.1 KiB
Feature Request From PromptKit: Shared Release Validation
Status: Requested by a prospective downstream consumer; not yet adopted by ReleaseKit.
Date: 2026-10-07.
This request derives from PromptKit's
ReleaseKit adoption assessment,
which reviewed ReleaseKit v0.1.0. It describes downstream needs and leaves
public API design, shared defaults, and implementation choices to ReleaseKit.
Consumer Context And Goal
PromptKit is a source-only Go library with concurrent LLM execution and backend-capacity management. It would like to adopt ReleaseKit's common source-publication process and reduce its own release infrastructure to product settings and a few substantive project checks. Its existing release scripts contain 209 lines, most of which implement validation rather than publication.
PromptKit accepts changes to its release process in exchange for a common standard and lower maintenance. The opportunity is to share useful validation capabilities, rather than preserve every existing shell command or local rule. Its consumer-example assertions and compatibility decisions remain meaningful project responsibilities.
The four primary requests below concern reusable validation. Two additional candidates are included for evaluation if their wider value justifies shared support. PromptKit's choices about race testing, full vet, and credential scanning remain under review; these requests describe useful capabilities without making their acceptance a prerequisite for adoption.
Primary Requests
1. Shared Go Formatting Validation
Please make Go formatting validation available through ReleaseKit's public validation API and release profile, so the shared candidate workflow can report tracked Go source that needs formatting.
PromptKit currently owns a shell check that identifies its tracked Go files and verifies their formatting. The operation is common to Go repositories; maintaining that mechanism independently adds little project-specific value. A useful shared capability would inspect source, report the affected files, and leave formatting changes to ordinary development.
The benefit is consistent validation and diagnostics with less local script maintenance. PromptKit can follow ReleaseKit's selected formatting convention without requiring preservation of its current enumeration or command loop.
2. Shared Offline Markdown-Link Validation
Please make validation of local Markdown links available through the public validation API and release profile. PromptKit needs checks for local file destinations and heading fragments, with enough diagnostic context to locate and correct a broken link.
Documentation is part of PromptKit's consumer interface. Broken navigation between its guides, formats, policies, and examples makes otherwise correct documentation harder to use. Its current local Markdown checker is the largest generic block in its release-validation script.
Shared support would remove a locally maintained parser and standardize the supported Markdown behavior across consumers. ReleaseKit can establish the supported link and heading conventions; PromptKit does not require its exact current parsing or anchor rules. Repository-specific choices about links to material outside the checkout should remain distinguishable from generally useful local-link validation.
The desired operation is offline and reports problems without changing documentation. External website availability is a separate concern and adds no value to this request.
3. Race Detection Within One Standard Test Run
Please provide a supported public API and profile choice for race-enabled execution of the standard full Go suite during candidate validation.
PromptKit's concurrent execution and capacity management make race detection useful: ordinary successful tests can miss unsafe shared-state access. Its current release validation runs the full suite with the race detector. ReleaseKit's current candidate workflow always runs the ordinary suite; expressing a race run as an additional check would execute the complete suite twice.
The desired capability selects race-enabled execution for that one suite run, while ReleaseKit continues to own the candidate workflow. The selection should work consistently through the public API and CLI/profile forms of candidate checking and publication. A consumer can select the ordinary suite when that is sufficient.
This overlaps with ConfigKit's base-test invocation request. PromptKit would benefit from the same shared capability; it does not need a separate PromptKit-specific test mechanism. ReleaseKit can decide the smallest appropriate public expression of the choice and whether race testing belongs among its common defaults.
4. Shared Full Go Vet Validation
Please consider exposing full Go vet analysis as part of ReleaseKit's public validation API and release profile, coordinated with the standard suite.
PromptKit currently runs full vet separately. Ordinary Go test execution includes only a subset of vet analyses, so replacing the current procedure with the standard test run does not provide equivalent static analysis. The additional analyses can detect defects that are not exercised by tests.
PromptKit can temporarily retain a configured full-vet command. A shared capability would let consumers express that validation choice directly and let ReleaseKit coordinate the analysis with testing to avoid unnecessary overlap. The desired outcome is full selected analysis and one complete suite execution; PromptKit leaves the means of achieving that outcome to ReleaseKit.
This also overlaps with ConfigKit's shared-check request. Full vet may be useful as a common default or as an explicit selection. PromptKit is asking for a shared capability, not prescribing additional gates for every ReleaseKit consumer.
Additional Candidates For Evaluation
5. Optional Go Module Distribution Checks
PromptKit's architecture keeps committed workspace files and local filesystem module replacements out of its released source. These rules help a shared library remain independent of neighboring checkouts. Disabling workspace discovery during validation controls the test environment but does not check the files being distributed.
If other consumers have the same need, optional public validation capabilities could check for committed workspace files and local filesystem replacements. Consumers should be able to select the distribution rules relevant to them; a versioned module replacement is different from a local filesystem dependency, and Go applications may deliberately distribute workspace files.
The potential benefit is reusable inspection and consistent diagnostics without each library owning its own checks. PromptKit can also keep a small local check if that is simpler than introducing shared support. This is a lower-priority candidate, not a request for universal bans on workspaces, replacement directives, or vendoring.
6. Optional Recognizable-Credential Checks
PromptKit's assessment recommends retiring its mandatory credential-pattern scan, while retaining ordinary credential-aware change review. A viable alternative is to keep a lightweight automated signal for recognizable accidentally committed credential formats.
If ReleaseKit finds broader consumer value in that alternative, please consider an optional public validation capability for such checks. A useful offering would make its detection scope clear and account for the possibility of matching synthetic examples or fixtures. It would complement ordinary review rather than imply comprehensive detection.
Shared support could centralize maintenance of the selected detection behavior and remove another local script fragment. PromptKit is not requesting a general security-scanning subsystem, preservation of its current regex, or a mandatory credential gate. This candidate warrants adoption only if its additional protection justifies its maintenance and false-positive costs.
Desired Adoption Outcome
The strongest opportunities are shared formatting and Markdown validation, followed by useful race/vet choices within a single candidate-validation flow. The module-distribution and credential candidates merit separate evaluation because their policies and benefits vary between consumers.
For accepted capabilities, availability through both the public Go API and the maintained CLI/profile would let PromptKit select them without creating its own release executable. PromptKit can retain its consumer-example assertions as additional checks and use ReleaseKit's supported conventions for shared validation and diagnostics.
PromptKit would continue to prepare its release note and publish its candidate
to authoritative main before invoking source publication. Confirmed tag
publication completes the source release; CI and hosted delivery remain
separate. Those responsibilities already fit ReleaseKit's common workflow
and do not require new features for this request.