3.1 KiB
Future Feature Ideas
Purpose
This document catalogs reasonably specific ideas that may be useful in future Promptkit development. It is an idea pool, not a commitment, schedule, or description of current behavior.
Ideas belong here while they are worth retaining but have not been selected for active development. Keep each entry at the level of intended capability, consumer value, and important scope boundaries. Defer API design, implementation details, sequencing, and acceptance criteria until an idea is selected.
Using This Catalog
- Add an idea when its purpose and likely value can be stated clearly.
- Keep entries independent enough that maintainers can evaluate and select them individually.
- Note significant dependencies or boundary concerns, but do not turn entries into implementation plans.
- Treat inclusion as an invitation to evaluate, not as approval or priority.
- When an idea is selected, move its active planning to a focused roadmap or, when it requires a durable architectural decision, an ADR. Update current-state documentation only when implementation lands.
- Remove ideas that are no longer relevant. Retain a rejected idea only when its rationale is likely to prevent repeated reconsideration.
Future capabilities must continue to respect the architecture policy, particularly Promptkit's role as an application-neutral library and its boundary with downstream consumers.
Ideas
Prompt-definition inspection
Provide exact prompt-definition lookup without rendering, placeholder inputs, profile resolution, or model generation, as requested by Weatherreporter.
- Return caller-owned identity, version, input definitions, default-profile, output-contract, and opaque definition-equality information.
- Apply ordinary prompt-source precedence and exact ID/version selection.
- Validate the selected definition and referenced prompt content structurally, without returning source bodies or rendered messages.
- Leave complete cross-source corpus validation and enumeration outside the initial inspection contract.
Structured capacity errors
Add safe structured context to backend admission rejection, as requested by Notarius and Weatherreporter.
- Preserve compatibility with
errors.Is(err, ErrCapacityExceeded). - Support
errors.Asto obtain the stable backend ID. - Do not expose endpoints, credential configuration or values, request content, or speculative retry timing.
- Keep retry and backoff policy with downstream consumers.
Entry Format
Use a short heading followed by a concise summary. Add focused bullets when they help preserve important scope boundaries without becoming an implementation plan:
### Idea name
Describe the intended capability, who benefits, and the most important scope
boundary or dependency.
- Optionally record an important behavior or boundary.