Feature Implementation Prompt

Public field comparison

Feature Implementation Prompt

Feature Implementation Prompt

Turn a feature request into a safe implementation plan with file changes, edge cases, tests, and acceptance checks.

Turn a feature request into an evidence-backed implementation or change plan with repository impact analysis, bounded code changes, regression coverage, and release verification.

—

Use this to turn a feature request into a bounded, evidence-backed implementation that maps repository impact, applies only authorized changes, verifies acceptance criteria, and prepares a rollback-aware release handoff.

Code Review Planning
Regression Testing
Debugging Plan
Release Verification

Implementing a new feature in an existing application
Adding feature behavior without breaking existing callers
Extending validation, domain logic, persistence, or integrations
Implementing authorization-sensitive feature changes
Adding features that require schema or configuration coordination
Building feature changes with explicit regression coverage
Reconciling implementation against acceptance criteria
Preparing feature work for code review and release
Planning rollback for production-facing feature changes
Investigating incomplete or partially implemented feature requests

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Feature request
Repository evidence
Constraints and authority
Acceptance criteria
Verification commands

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In Codex, replace each variable with the actual feature request, repository evidence, constraints and authority, acceptance criteria, and permitted verification commands. Provide relevant source files, repository tree, interfaces, schemas, configuration, diffs, errors, logs, existing tests, runtime details, and release rules where available. Remove or redact secrets and private data. Then run the prompt in the authorized workspace. Review Codex’s evidence register and status labels before accepting any claim that files were changed or tests were executed; obtain human approval for migrations, security-sensitive changes, dependency changes, merges, deployments, or production operations.

Use this when you need a production-ready feature build result in Codex & Coding, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

Use Codex to assess and implement an authorized change to an existing application’s request-validation flow. Supply the relevant handlers, domain services, schemas, tests, failure logs, acceptance criteria, repository conventions, and permitted test commands. The expected proposal or session output maps the execution path, identifies compatibility and regression risks, records proposed versus applied edits, adds boundary and authorization tests, captures actual command evidence only if execution occurs, and prepares a rollback-aware release handoff without claiming deployment.

Expert

Expert

Codex

Codex

feature build

feature build

codex
Codex & Coding
feature
implementation
tests

codex
feature implementation
code-review
regression-testing
release verification

Feature Implementation Prompt | AMO.ng

Feature Implementation Prompt for Codex | AMO.ng

Turn a feature request into a safe implementation plan with file changes, edge cases, tests, and acceptance checks.

Plan or implement a feature in Codex with repository evidence, bounded changes, regression tests, acceptance reconciliation, and release safeguards.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Codex & Coding specialist using Codex. Your task is: [Goal or task].
+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.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Feature request:
+[Feature request]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Feature Implementation Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Repository evidence:
+[Repository evidence]
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Constraints and authority:
+[Constraints and authority]
 
−Do not give generic advice. Optimize for a production-quality feature build outcome.
+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.