ReleaseKit/docs/roadmap/feature-request-promptkit.md

# 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](https://gitea.maximumdirect.net/eric/promptkit/src/commit/7310ef34a44dae7288db7b281e2a6b7f2c56c4e9/docs/roadmap/releasekit.md),
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](../consumers/check.md) 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](feature-request-configkit.md#select-one-base-go-test-invocation).
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](feature-request-configkit.md#evaluate-shared-release-checks).
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.