Turn a project specification into a coding agent prompt

Start with one observable outcome

Suppose a small inventory application needs to import a supplier's CSV. 'Add CSV support' leaves the agent to decide the fields, duplicates, validation, persistence and user experience. Start with an outcome instead: an operator can preview a CSV, see invalid rows and explicitly confirm an import. This gives you a boundary for both implementation and review.

Record the current behavior and the smallest desired change. Identify who uses it and whether the repository already has upload, validation and table components. Ask the agent to inspect those components before choosing a new dependency. If you do not know an existing implementation detail, label it as something to discover; invented file paths or database columns create unnecessary mistakes.

Prepare representative examples on your device

Create a tiny fictional CSV with two valid rows and one invalid row. Include a quoted comma in a product name and a SKU with a leading zero. Decide whether quantity accepts zero and whether a duplicate SKU updates an existing item or produces an error. Choose the behavior deliberately instead of allowing parser defaults to define the product.

Use the local CSV-to-JSON tool to inspect the intended row shape, then the JSON formatter to check the example is valid JSON. Keep identifiers as strings. A formatter validates structure; it does not prove that a price, quantity or access rule is correct. Supply expected values alongside the example so the agent can tell the difference between a parsing change and data corruption.

Define acceptance checks before implementation

A concrete check describes an input, an action and an observable result. For this example, a well-formed file produces a preview and changes no records until confirmation. An invalid quantity is shown against the relevant row. A user without inventory-edit permission cannot import even if they call the server directly. Confirming the same submitted import twice should not create duplicate records.

Separate requirements from suggested implementation. You may require atomic import behavior without dictating a table name or framework-specific transaction helper. Tell the agent to use the repository's existing authorization, schema and testing conventions. Where a business decision remains unresolved, have it surface that decision before making a migration or exposing new behavior.

• Quoted commas and leading-zero identifiers survive the round trip.
• Previewing, cancelling and invalid input leave persisted records unchanged.
• Authorization is enforced on the server and existing items remain accessible.
• A repeated confirmation has an explicitly defined, tested outcome.

Assemble a prompt the agent can act on

Put the goal first, followed by repository context, example input, expected behavior, exclusions and checks. Ask for a short implementation plan after repository inspection. Require the final report to distinguish commands actually run from checks that could not be completed. This makes the result reviewable without treating a fluent explanation as evidence that the feature works.

When the implementation is substantial, split it into a preview slice and a confirmed-write slice. The first slice can establish parsing and validation without changing stored data. The second can add authorization, idempotent confirmation and transactional persistence. Keep the shared acceptance checks with both slices so the agent does not optimize one stage at the expense of the complete workflow.

Remove sensitive information before using AI

Run any configuration or log excerpt through the local secret scanner and inspect the redacted copy yourself. Pattern matching can miss unfamiliar secrets and personal data, so a clean report is not proof that an excerpt is safe to share. Prefer synthetic examples and replace private URLs, names and internal identifiers when they are unnecessary for the task.

PipFoxy's free transformations run locally. Its AI Prompt Improver and Project Builder use an external provider only after you explicitly submit input. Moving from a free tool to an AI page does not automatically transfer your result. Read the provider disclosure and cost estimate, then paste only the reviewed brief you want processed. Availability and account requirements are shown on the AI page.

Review the delivered change against the brief

Use text comparison to inspect revisions to the brief or generated plan. Look for changed requirements, newly introduced dependencies, omitted authorization and claims of completed checks. Then review the actual code diff and run the repository's relevant tests in an appropriate development environment. A generated test list is a proposal until the tests have been executed and their results observed.

Try the fictional valid file, an invalid quantity, a duplicate confirmation and an unauthorized request. Check that cancellation leaves data unchanged. If a result fails, revise the smallest unclear requirement or supply the failing example instead of expanding the prompt into an unrelated rewrite. Keep the reviewed brief with the project so later iterations have a stable starting point.

Put this guide into practice

These free PipFoxy tools are directly related to the method above. No account is required, and current tool content stays in your browser.

Or browse the full developer tools category.