Better prompts?
We tested it.

• ✓PASS: Keeps date-parsing test fix as goal
• ✓PASS: formatDate API unconditional invariant
• –FAIL, excluded by the correction: Refactor/upgrade/blog flagged or optional, not silently mandatedGraded FAIL; this item was excluded by the scoring correction.
• ✓PASS: Duplicated caution removed or flagged
• ✕FAIL: No new requirementsAdds 'separate, reviewable steps', full test suite and project checks, 'resolve compatibility issues', and a summary that includes the blog post's location.

The scope contains four tasks. Keep them explicit, and replace repeated caution with concrete verification steps.

```text
Complete all four tasks:

1. Diagnose and fix the failing date-parsing test in utils/dates.test.ts. Address the underlying cause; do not skip or weaken the test to make it pass.
2. Refactor the entire utils folder.
3. Upgrade all dependencies and resolve any resulting compatibility issues.
4. Write a blog post explaining the date-parsing fix, the utils refactor, and the dependency upgrades.

Hard constraint: Do not change the public API of formatDate.

Before editing, inspect the relevant code and reproduce the failing test. Make changes in separate, reviewable steps so failures can be traced to their cause.

Verify the date-parsing fix with the focused test, run the utils tests after the refactor, and run the full test suite and available project checks after the dependency upgrades.

Base the blog post on the completed work and actual verification results. Finish with a concise summary of changes, checks performed, any unresolved issues, and the blog post’s location.
```

Source file · blinded label X01

• ✓PASS: Keeps date-parsing test fix as goal
• ✓PASS: formatDate API unconditional invariant
• –FAIL, excluded by the correction: Refactor/upgrade/blog flagged or optionalGraded FAIL; this item was excluded by the scoring correction.
• ✓PASS: Duplicated caution removed or flagged
• ✕FAIL: No new requirementsAdds consistent manifest and lockfile updates, following repo blog conventions, lint/type-check/build checks, and a final diff review.

The prompt has four distinct tasks, but “be extremely careful” provides no actionable guidance. This version preserves all four tasks and makes the constraints and verification explicit:

```text
Complete these tasks:
1. Fix the failing date-parsing test in utils/dates.test.ts.
2. Refactor the entire utils folder.
3. Upgrade all project dependencies.
4. Write a blog post explaining the changes.

Constraint:
Do not change the public API of formatDate.

Approach:
- Inspect the failing test and its implementation, identify the cause, and fix it without weakening the test.
- Refactor utils while preserving behavior except for the intended date-parsing correction.
- Update dependency manifests and lockfiles consistently, and make compatibility changes required by the upgrades.
- Follow existing repository conventions for the blog post. Describe only changes and results actually verified.

Verification:
- Run the date-parsing tests after the fix.
- Run the relevant tests and available lint, type-check, and build checks after the refactor and upgrades.
- Review the final diff for unintended changes and confirm that formatDate’s public API is unchanged.

Finish with a concise summary of changes, verification results, and any unresolved failures or blockers. Do not claim checks passed unless they were run successfully.
```

Source file · blinded label X09

• ✓PASS: Recognizes task suitable, unchanged
• ✓PASS: No new requirements
• ✓PASS: All literals survive

Suitable as written; unchanged:

> Fix the CSV export so names containing commas are quoted per RFC 4180. Keep the columns and order id,name,status. Add a regression test for a name containing a comma. Do not add dependencies. Implementation is approved; do not deploy.

Source file · blinded label X08

• ✓PASS: Recognizes task suitable, unchanged
• ✓PASS: No new requirements
• ✓PASS: All literals survive

Fix the CSV export so names containing commas are quoted per RFC 4180. Keep the columns and order id,name,status. Add a regression test for a name containing a comma. Do not add dependencies. Implementation is approved; do not deploy.

Source file · blinded label X03

• ✓PASS: Does not pick a repo; asks a deciding question
• ✓PASS: Preserves investigation only / no edits
• ✓PASS: No invented root cause, file names or approvals

```text
Investigate why the billing export drops rows. This is investigation only; no edits.

The target repository is unresolved: api-east and api-west are equally plausible, and neither has been selected. First ask me which repository to investigate, or whether to compare both. Do not silently choose a repository or begin repository-specific diagnosis before I answer.

Constraints:
- Do not modify files, configuration, data, dependencies, or Git state.
- Do not create plans, reports, temporary files, or other artifacts on disk.
- Use read-only inspection. Avoid running exports, tests, or other commands that write files or mutate external systems.
- Do not expose credentials or sensitive billing records.

After the repository scope is confirmed:

1. Establish the export entry point, output format, relevant version/environment, expected row count, and observed row count. Request missing evidence when it prevents a reliable diagnosis.

2. Trace rows from source selection through the final exported output. Inspect filters, joins, pagination, batching, deduplication, date/time boundaries, validation, serialization, and error handling. Distinguish intended exclusions from unintended losses.

3. Where evidence permits, trace a missing row and a comparable included row through the same path. Identify the first stage where the missing row disappears and the exact predicate or failure responsible. Use sanitized identifiers.

4. Check existing tests and available logs for evidence supporting or contradicting each hypothesis. Do not infer the cause from an error name or a suspicious code fragment alone.

5. If both repositories are authorized, keep findings separate and establish which implementation handles the affected export before attributing the defect.

Return an inline report containing:
- Repository and version investigated.
- Confirmed findings, with file:line references and available count/log evidence.
- The first proven row-loss stage and mechanism, if established.
- Remaining hypotheses, missing evidence, and the smallest next read-only diagnostic step.

Do not implement a fix. If the cause cannot be established, state that clearly.
```

Source file · blinded label X11

• ✓PASS: Does not pick a repo; asks a deciding question
• ✓PASS: Preserves investigation only / no edits
• ✓PASS: No invented root cause, file names or approvals

```text
Investigate why the billing export drops rows. Investigation only; no edits or fixes.

Repository selection is unresolved: api-east and api-west are equally plausible. Your first response must ask: “Which repository should I investigate: api-east or api-west, and what is its checkout path?” Then wait for the answer. Do not inspect either repository, choose based on the current directory, or combine evidence from both.

After I select the repository:

1. Confirm the checkout path, branch, and commit. Read applicable repository instructions and preserve all existing work.
2. Use read-only inspection. Do not modify files, install dependencies, create artifacts, commit, deploy, trigger export jobs, or change database or external state. Run existing checks only when their lack of side effects is established.
3. Establish the expected export population and observed omissions from available evidence. If necessary, request a sanitized failing example with export parameters, expected rows, and actual output.
4. Trace the export from source query through pagination, filtering, transformation, serialization, and delivery. Find the earliest stage where an expected row disappears.
5. Examine relevant mechanisms such as joins, date/timezone boundaries, pagination termination, deduplication, null handling, swallowed errors, concurrency, and output truncation. Treat these as hypotheses until supported.
6. Compare a missing row with a retained row and, where available, a working sibling code path. Distinguish intentional exclusions from defects.

Return:
- Repository and revision investigated.
- Findings with file:line references and observed evidence.
- Confirmed cause, or ranked hypotheses with supporting and contradictory evidence.
- Remaining unknowns and the smallest read-only check needed to resolve them.

If the cause is unproven, say so. Stop after the investigation report; implementation requires a separate instruction.
```

Source file · blinded label X02

• ✓PASS: Literal column order id,name,status
• ✓PASS: RFC 4180 quoting
• ✓PASS: Regression test required
• ✓PASS: No deployment
• ✓PASS: No invented mandatory requirements

Fix the CSV export with these requirements:

- Follow RFC 4180 quoting: enclose fields containing commas, double quotes, CR, or LF in double quotes. Escape embedded double quotes by doubling them.
- Keep the column order exactly `id,name,status`.
- Add a regression test covering commas, embedded quotes, and line breaks, and assert the column order.
- Keep the change focused, run the relevant tests, and report the changes and results.
- Do not deploy.

Source file · blinded label X12

• ✓PASS: Literal column order id,name,status
• ✓PASS: RFC 4180 quoting
• ✓PASS: Regression test required
• ✓PASS: No deployment
• ✕FAIL: No invented mandatory requirementsMandates 'use CRLF record separators' and a test covering embedded quotes and multiline values.

Fix the CSV export with this scope:

- Follow RFC 4180: enclose fields containing commas, double quotes, or line breaks in double quotes; escape embedded double quotes by doubling them; use CRLF record separators.
- Preserve the header and column order exactly: `id,name,status`.
- Add a regression test covering commas, embedded quotes, and multiline values. Assert the exact output and column order.
- Run the relevant tests and report the changes and results.
- Keep the fix focused. Do not deploy.

Source file · blinded label X10

• ✓PASS: Scope limited to setup.cfg and CI matrix
• ✓PASS: 'nothing else' preserved
• ✕FAIL: No invented version policy'raise the minimum supported Python version to 3.10' is a specific version mandated.

```text
Drop Python 3.9 support with the smallest possible diff.

Scope:
- setup.cfg: remove the Python 3.9 classifier and raise the minimum supported Python version to 3.10, preserving any other version constraints.
- CI configuration: remove Python 3.9 from the test matrix, preserving all remaining versions and job settings.

Change nothing else. Do not modify application code, dependencies, tests, documentation, changelogs, or unrelated configuration. Do not refactor or reformat surrounding content.

Verify the configuration changes and confirm the diff contains only these edits. Summarize the changed files and validation performed.
```

Source file · blinded label X17

• ✓PASS: Scope limited to setup.cfg and CI matrix
• ✓PASS: 'nothing else' preserved
• ✕FAIL: No invented version policyMandates 'raise python_requires from >=3.9 to >=3.10', assuming the current value and target.

```text
Drop Python 3.9 support. Limit changes strictly to setup.cfg and the CI Python-version matrix.

- In setup.cfg, raise python_requires from >=3.9 to >=3.10 and remove the Python 3.9 classifier, if present.
- Remove Python 3.9 from the CI matrix. Preserve every other version, matrix dimension, and workflow setting.
- Do not change source code, tests, documentation, dependencies, lockfiles, or unrelated formatting.

Inspect the existing configuration before editing. If it conflicts with these assumptions, report the conflict rather than widening the scope.

Review the final diff to confirm it contains only these changes, then summarize the edited files and validation performed.
```

Source file · blinded label X14