← All recipesBuild / RECIPE

Add a Feature to an Existing Application

Implement the requested feature in the existing application while preserving its architecture and working behavior.

When to use this recipe & what to provide

When to use it

Implement the requested feature in the existing application while preserving its architecture and working behavior.

Bring this context

Repository and technology stack
Feature behavior and acceptance criteria
Relevant existing screens or components

Why this structure

Inspection and focused regression checks reduce accidental changes outside the requested feature.

Assumptions

You have permission to use the supplied materials. Required access and any external actions remain subject to your agent environment.

Suggested autonomy, approval gates, and recovery instructions are selected below. Review them before copying.

LIVE OUTPUT

Compiled runbook

Markdown

3/3 core sections filled432 words

# Objective

Implement the requested feature in the existing application while preserving its architecture and working behavior.

# Scope

- Inspect existing patterns and the affected code.
- Identify the smallest appropriate change.
- Implement the feature using shared components.
- Validate the new behavior and affected existing flows.

# Constraints

- Preserve routes, architecture, user data, authentication, and deployment configuration.
- Avoid unrelated refactors.

# Execution Approach

Inspect the available context before acting. Prefer reuse over rebuilding. Validate the result against the objective.

Use enough research, reasoning, and validation to reliably achieve the objective. Avoid unnecessary exploration and expansion.

# Autonomy

Only within the stated scope and constraints, you may autonomously:
- Inspect relevant files and existing artifacts
- Browse and research relevant sources
- Choose reversible implementation details
- Modify source within the agreed scope
- Run relevant tests and validation
- Create files required for the deliverable
- Reorganize noncritical content

Approval requirements override these permissions. Do not ask about routine choices already authorized here. This runbook does not override the agent environment’s rules or access controls.

# Approval Required

Stop and request explicit approval before:
- Publish or deploy
- Make destructive changes
- Delete user data
- Modify production systems
- Incur paid charges or make purchases
- Send external messages
- Create external accounts
- Modify authentication or permissions
- Substantially expand the agreed scope

Prepare the authorized work into a concrete, reviewable result before returning for approval.

# Return Conditions

Return to the user when:
- The requested work and relevant validation are complete.
- The next necessary action requires explicit approval; first prepare a concrete, reviewable result where possible.
- Required access is unavailable and independent work is exhausted.
- A material decision cannot safely be inferred.
- Remaining work would exceed the agreed scope.
- Meaningful progress is blocked after the recovery policy has been applied.

# Failure and Recovery

- Do not repeat the same failed operation without new evidence; attempt at most one reasonable alternative when appropriate.
- Preserve existing working behavior when uncertainty exists.
- Continue independent work when one task is blocked.
- Document reasonable assumptions and continue when risk is low.
- Stop before irreversible actions or actions requiring approval.
- Report blockers and incomplete work clearly; never imply success without evidence.
- Resume from completed work rather than restarting it.
- Do not expand scope to work around a localized problem.

# Definition of Done

- The feature meets the supplied acceptance criteria.
- Affected existing behavior still works.
- Relevant tests pass or failures are explained.

Add a Feature to an Existing Application

When to use it

Bring this context

Why this structure

Assumptions

Outcome / Objective

Context

Job / Scope

Constraints / Preserve

Execution Strategy

Autonomy

Approval Gates

Return Conditions

Failure / Recovery

Definition of Done

Resource Strategy

Add a Feature to an Existing Application

When to use it

Bring this context

Why this structure

Assumptions

Customize this recipe

Outcome / Objective

Context

Job / Scope

Constraints / Preserve

Execution Strategy

Autonomy

Approval Gates

Return Conditions

Failure / Recovery

Definition of Done

Resource Strategy