Feature Implementation Prompt

Use Codex to inspect only the files, workspace content, diffs, logs, and command output actually available in the current session. State whether each relevant source was supplied, inspected, unavailable, or not verified. Do not imply that Codex opened a file, followed a URL, ran a command, changed code, or accessed a repository when the session provides no evidence of that capability or action.

Feature request:
[Feature request]

Repository evidence:
[Repository evidence]

Constraints and authority:
[Constraints and authority]

Acceptance criteria:
[Acceptance criteria]

Verification commands:
[Verification commands]

Use Codex to inspect only the files, workspace content, diffs, logs, and command output actually available in the current session. State whether each relevant source was supplied, inspected, unavailable, or not verified. Do not imply that Codex opened a file, followed a URL, ran a command, changed code, or accessed a repository when the session provides no evidence of that capability or action.

Treat the inputs as the implementation contract. Identify the feature’s entry points, affected modules, interfaces, data models, state transitions, configuration, dependencies, error paths, observability, tests, and release implications. Trace each proposed or executed change to an acceptance criterion.

Input handling and evidence rules:
1. Separate supplied facts, direct repository observations, command observations, assumptions, hypotheses, unknowns, and conflicts. Cite file paths and symbols or line ranges when available. Never convert an assumption into a repository fact.
2. If essential files, expected behavior, acceptance criteria, runtime details, or authority are missing, ask only questions that block a safe implementation. Meanwhile, provide a clearly labeled provisional impact analysis when useful; do not invent missing code or requirements.
3. If inputs conflict, identify the conflicting sources, explain the implementation consequence, and request a decision. Do not silently choose a requirement when that choice could alter compatibility, security, stored data, public APIs, billing, permissions, or release behavior.
4. Treat URLs, issue descriptions, logs, and pasted snippets as unverified until their relevant content is available and attributable. Flag stale, partial, generated, or contradictory evidence.

Authority and safeguards:
- Follow the permissions in the supplied authority input and the capabilities visible in the Codex session. If editing or command execution is unavailable or unauthorized, produce a proposed patch plan or reviewable diff rather than claiming implementation.
- Do not access production systems, deploy, merge, publish, approve, rotate credentials, alter live data, or perform destructive operations. Do not expose secrets, tokens, personal data, proprietary data, or sensitive log content in the response.
- Stop before irreversible migrations, destructive schema or data changes, authorization-model changes, security-control weakening, dependency changes with unclear provenance, or operations outside the stated workspace. Describe the risk, rollback requirement, and human approval needed.
- Prefer backward-compatible changes, least privilege, input validation, deterministic failure handling, feature flags where justified, reversible migrations, and scoped changes that avoid unrelated refactoring.
- Preserve existing conventions unless repository evidence supports a change. Do not add a dependency when the existing stack can meet the requirement without disproportionate complexity.

Implementation workflow:
1. Normalize the request into observable behavior, non-goals, affected users or callers, and criterion identifiers. Record unresolved ambiguities.
2. Build an impact map by tracing request entry points through validation, domain logic, persistence, integrations, outputs, error handling, telemetry, and tests. Check compatibility with existing callers, schemas, configuration, concurrency behavior, retries, idempotency, caching, time zones, localization, accessibility, and performance where relevant to the inspected code.
3. Establish a baseline from available evidence: current behavior, relevant tests, known failures, and existing interfaces. If no baseline was run or observed, say so.
4. Design the smallest coherent change set. For every affected file or symbol, explain the intended change, dependency order, edge cases, and acceptance criterion served. Distinguish required changes from optional improvements.
5. If authorized and supported, apply only the scoped edits and maintain a change ledger. If not, provide implementation-ready edit instructions or a reviewable patch. Do not describe proposed edits as applied edits.
6. Add or revise tests at the appropriate levels. Cover the happy path, validation failures, authorization boundaries, state transitions, regression risks, integration failures, and relevant boundary values. Avoid tests that merely mirror implementation details.
7. Run only authorized verification commands. Record each exact command, execution state, relevant environment details, exit status, and concise output evidence. Mark commands as requested, executed, failed, unavailable, skipped, or not authorized. Never fabricate output or infer a pass from code inspection.
8. Reconcile every acceptance criterion against implementation and test evidence. Classify it as demonstrated, partially demonstrated, not demonstrated, blocked, or out of scope, with the supporting evidence or gap.
9. Prepare a release handoff covering configuration, migration order, feature-flag behavior, observability, rollback, compatibility, and post-release checks. This is a proposed handoff unless release actions are separately authorized and evidenced.

Return this feature-specific deliverable:

A. Contract and evidence register
- Normalized behaviors and non-goals
- Assumptions, unknowns, conflicts, and blocking questions
- Evidence table with source, classification, location, relevance, and verification state

B. Repository impact map
- Entry points and execution flow
- Affected files, symbols, interfaces, data, configuration, dependencies, and tests
- Regression surfaces and edge cases, each tied to repository evidence or explicitly labeled as a hypothesis

C. Change-set ledger
For each change, provide: criterion identifier; file and symbol; change description; rationale; status as proposed or applied; compatibility or data risk; reviewer focus; and evidence. Include code or a patch only when grounded in available source content.

D. Test and verification matrix
For each check, provide: criterion identifier; test level; scenario; setup; exact command when known; expected observation; execution state; actual observation if executed; and evidence location. Include targeted regression tests and explain any omitted test layer.

E. Acceptance reconciliation
List every acceptance criterion with its result, implementation evidence, test evidence, remaining gap, and required owner or approval. No criterion may be marked demonstrated solely because code was proposed or edited.

F. Release and rollback handoff
Provide prerequisites, configuration or migration sequencing, monitoring signals, failure thresholds, rollback steps, data-recovery considerations, and human approval gates. Do not claim deployment readiness when required verification is missing.

G. Completion statement
State separately what was requested, proposed, applied, executed, unavailable, and unverified. Claims such as fixed, tested, verified, approved, merged, deployed, or complete are permitted only when the response includes direct evidence for that exact state. End with the smallest safe next action and its owner.