At a glance
- Problem
- A reusable prompt loses its usefulness when filling it means retyping context or quietly accepting guessed details.
- My contribution
- I built an MCP app that connects a structured template library to the host conversation, with explicit field provenance and an editable review step.
- Outcome
- A working implementation with 35 templates across eight categories and public source on GitHub. ChatGPT directory approval and public installation are still pending.
Context can help fill a template. The review boundary keeps its assumptions visible before the prompt leaves the app.
In words
- Choose a reusable template from the catalog or your own library.
- The host fills a structured draft from its available context.
- Provided, inferred, and missing fields remain visible for review.
- The user edits the result and chooses when to copy it. The app does not execute the completed prompt.
Derived from the implemented template, draft, and host-message boundaries.
Engineering decisions
01decision
Keep the origin of every field visible
The draft separates values explicitly provided by the user, values inferred from available context, and fields that are still missing. Evidence accompanies the filled values so a reviewer can see what the draft rests on.
TradeoffA source label is a review aid. It does not prove that an inference is correct, so the user can edit it before copying.
02decision
Let the host supply context deliberately
The app requests field filling through the host chat. The server receives structured template and draft data; it does not fetch the full conversation transcript. A revision request can include the current values and a specific instruction for the host to consider.
TradeoffThe result depends on the context actually available to the host. Missing facts stay visible rather than becoming invented requirements.
03decision
Stop at a prompt the user can review
The final step is an editable, rendered prompt and an explicit copy action. The app does not run the completed prompt or automatically send its contents to another service.
TradeoffCopying remains a deliberate handoff. That extra step gives the user a clear point to check the instruction before using it.
04decision
Separate storage by the authenticated owner
Custom templates and saved drafts are scoped to the authenticated Site owner. Drafts retain a template snapshot and version so later template changes do not silently rewrite an earlier draft.
TradeoffPersistence makes reopening work possible, and it also creates data-management responsibilities. Storage behavior, privacy disclosures, and release readiness need to be checked together.
What is implemented
- The published source revision is available for inspection.
- The catalog contains 35 starter templates in eight categories, plus a custom-template workflow.
- The review model distinguishes provided, inferred, and missing fields and preserves an editable result.
- The core host workflow has been exercised privately. Public installation and directory approval are separate release checks.
- Product overview and current availability.
Source and release links checked .
Scope and limits
Template coverage is a catalog count, not evidence of improved model performance. A provenance label does not establish factual accuracy. Private host testing does not establish compatibility with every host or a public directory approval.
The review loop
- 01
Choose a starter template or save your own reusable structure.
- 02
Ask the host to fill the fields using the available conversation context.
- 03
Inspect provided and inferred values, and supply any missing details.
- 04
Edit the rendered prompt, then copy it when it is ready to use.