A prompt with input parameters injected is a reusable prompt after the values for a particular task have replaced its placeholders. The role, instructions, constraints, and output format remain in place; the task facts change. The result is ready to use without rewriting the prompt structure. section 5.2.3 section 5.3.3
A practical injection workflow is:
- Define stable instructions: assign the engineering role, state the planning task, and specify what facts the response may use. section 5.2.3
- Fill the task-specific fields. A feature plan uses a business goal, acceptance criteria, constraints, and target release; a refactor plan uses assessment answers, goal, timeline, capacity, and risk tolerance. section 5.2.3 section 5.3.3
- Keep the output contract explicit: named headings, required phases or steps, risks, and a checkpoint where requested. section 5.2.3 section 5.3.3
Feature-planning instance
An injected feature request names a team-level API key rotation policy, sets the goal of reducing risk from long-lived credentials, and requires configurable intervals, reminders, and blocking after a grace period. It also forbids schema-breaking API changes that quarter, protects existing keys during migration, and sets target release 2026.07. The prompt asks for a two-sentence scope, three implementation steps, risks, and a one-sentence delivery checkpoint. Check the resulting plan against those supplied facts and format requirements rather than treating plausible implementation details as established requirements. section 5.2.3
Refactor-planning instance
A refactor template’s `{{assessment_answers}}` slot becomes concrete findings about downstream call-order assumptions, a retry-flag side effect, analytics event consumers, and manual-only rollback. Other slots become a two-sprint goal, a team of three backend engineers and one QA engineer, and low tolerance for production regressions. Those values give the requested phased plan and rollout and rollback logic specific constraints to address. section 5.3.3
