Exclude-Prompt-Data

# Exclude Prompt Data

When a prompt contains instructional or contextual data used to guide a change,

that data must not appear in the file being updated. The output must reflect

only the *result* of the instruction — not the instruction itself, the

reasoning behind it, or any acknowledgment that it was applied.

Core Rule

> **Never echo prompt content into the file being changed.**

>

> Only write the outcome. Strip any meta-commentary, rationale, or framing that

> originated in the prompt.

What Counts as Prompt Data

Prompt data is any content the user provides as instruction or context rather

than as intended file content:

- Descriptions of what to add or change (`"add a --verbose flag that..."`)

- Inline rationale or motivation (`"because the old behavior caused..."`)

- References to the prompt itself (`"as requested"`, `"per the prompt"`,

`"the new feature has been added as"`)

- Meta-commentary about the update

(`"This section has been updated to reflect..."`)

- Code comments that narrate a change rather than describe the code

(`"// Added email validation as requested"`,

`"// Now validates the input per the new requirement"`)

- Structural scaffold labels used as section markers or template slots

(the word `this` in `## this Title` is scaffolding, not heading text)

What Belongs in the Output

The output file should contain only:

- The feature, fix, or content the prompt requested — written as if it always

belonged there

- Documentation or code that a reader would find useful independent of how the

change was requested

- Generic, cliche placeholder data in examples (e.g., `Jane Doe`,

`jane.doe@example.com`, `Acme Corp`, `example.com`) — never real names,

emails, domains, or organization identifiers pulled from the prompt or local

configuration

- Language formatting applied to terms in the prompt carries through to the

output — if the prompt wraps a term in backticks or uses a specific syntax

convention, follow that same convention in the output

Output Quality

The prompt's writing quality does not set the bar for the output. Regardless

of how a prompt is phrased, the result must be polished and production-ready:

- Correct grammar, capitalization, and punctuation throughout

- No draft-quality prose or casually written sections

- Informal or sloppy phrasing in the prompt must not carry into the output

Use Cases

Adding a Feature Flag to Documentation

**Prompt**

Update file.ext with new feature --new-opt <argument>, documenting the new
feature in features.md

**Acceptable result — `features.md`**

### --new-opt

Enables extended output. Requires a value argument. Example:

    ```bash
    file --new-opt foo
    ```

**Unacceptable result — `features.md`**

### --new-opt

The new feature `--new-opt` requiring an argument has now been added as
requested. The feature is documented as such.

Enables extended output. Requires a value argument. Example:

    ```bash
    file --new-opt foo
    ```

The unacceptable version echoes the prompt's framing

(`"has now been added as requested"`, `"The feature is documented as such"`).

That language belongs in the prompt, not the file.

---

Updating a Code File

**Prompt**

Add input validation to the createUser function — email must be a valid format.

**Acceptable result**

function createUser(name, email) {
  // Rejects addresses missing a local part, @ sign, or domain
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    throw new Error('Invalid email address.');
  }
  // ...
}

**Unacceptable result**

// Added email validation as requested in the prompt
function createUser(name, email) {
  // Per the instruction, we now validate that email must be a valid format
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    throw new Error('Invalid email address.');
  }
  // ...
}

The unacceptable version leaks prompt phrasing into code comments. Code

comments and documentation up