GitHub Copilot Plan Mode: Scope a CSV Schema Change Before Editing Code

A volunteer organization maintains a Python importer that reads registration forms exported as CSV. A new optional ‘preferred contact method’ column is coming, but older files must continue to load unchanged. GitHub Copilot Plan Mode can read the repository and propose work before code is altered. That separation is the point: the developer should approve a migration strategy, edge cases, and a test matrix before asking any coding agent to edit parser logic. This is a teaching scenario, not a claim that a real repository was inspected.

Write a narrow change request

Define the current schema and the desired new behavior in a short issue. For the hypothetical importer, existing files contain volunteer_id, event_date, and email; new exports may also include preferred_contact_method. The new field is optional and must not cause older rows to fail. State accepted values, behavior for blanks, and how an unknown value should be reported. Specify that no source CSV is to be changed or deleted by the plan. A model cannot infer backwards-compatibility requirements from a vague instruction to ‘support the new form.’

Record the baseline constraints before prompting: which CLI command is used, current tests, how errors are surfaced, and who approves schema changes. Decide whether the new field affects any downstream notification logic, not merely the parser. A safe task description makes the boundary explicit: analyze and propose, but do not implement. If the project includes real participant data, use a synthetic fixture and follow organizational repository access policies.

Open Plan Mode and inspect the repository

GitHub documents a Plan selection in supported Copilot Chat IDEs, with a read-only planning phase that drafts an implementation strategy. Open Copilot Chat in a supported editor and choose Plan from the agents menu. Prompt it to identify CSV parsing entry points, test fixtures, downstream consumers of the data object, and risks of adding an optional field. Ask the plan to cite files and functions to be examined, rather than summarizing the repository at a high level.

Plan Mode is available in various IDEs but the exact interface and preview status vary; the GitHub documentation explicitly distinguishes it from Agent and Ask modes. Check the supported editor and organization settings. Read the proposed affected-file list against the actual repository tree. If a file or class does not exist, mark that part of the plan incorrect and request a correction before moving further.

Separate schema acceptance from business decisions

The importer may parse the new column without being authorized to act on it. A preferred contact method is a communication preference, not blanket permission to send marketing messages. The plan should separate input validation, normalization, data storage, and use by a downstream service. For example, missing values could map to an explicit unknown status while retaining old behavior; they should not be silently converted into consent for email.

Have Copilot propose a small schema table with column name, required status, type, allowed values, and error behavior. Compare it to the form owner’s approved specification. Do not let a generated plan decide which channels are legally appropriate or override an existing consent policy. Human stakeholders approve semantic changes, while automated tests confirm that the software does what was specified.

Demand a compatibility test matrix

Request tests for old headers with no new field, new headers with the optional field, blank and unexpected values, reordered columns, blank lines, UTF-8 text, and duplicate header names. Include negative tests for missing required columns and mismatched delimiters. Make sure the plan defines expected results for each case and describes which existing tests are preserved. A schema migration is not successful merely because the newest export parses.

Add a test verifying that importing the same data twice does not create accidental duplicates if the existing application promises idempotency. If not, identify it as an open question rather than inserting a new guarantee. Ask which fixtures are generated and which are committed. The plan should state that any real names or addresses in sample data must be replaced with synthetic values.

Review failures before approving implementation

A good plan explains how errors reach the operator. For example, an unsupported contact-method value should produce a row-level warning with a safe identifier; a malformed header should produce a clear stop condition. Test whether the importer skips an invalid row or rejects the whole batch, based on existing approved behavior. Do not accept a plan that proposes silently dropping invalid records or making logs disclose personal information.

Read the planned file edits line by line, especially changes to model classes, validators, CLI flags, and export formats. Confirm no unrelated refactor has been slipped into the change. Request a smaller plan if the assistant suggests rewriting the whole loader. An incremental implementation with rollback is more reviewable than a broad change that mixes feature work with cleanup and changes the behavior of old files.

Choose what must remain read-only

The value of Plan Mode is its separation from implementation. GitHub states that planning uses read-only tools and requires review before a user hands the plan to an agent. Treat that as an interaction contract: do not ask the planning assistant to commit, deploy, modify production fixtures, or expose credentials. Confirm the proposed work can be carried out in a branch with controlled permissions once approved.

If an agent later implements the plan, review its diff against the approved file list and run the tests independently. A green test suite is necessary but insufficient when the acceptance criteria have changed. Require an operator check using a tiny pair of old and new CSV files, plus a rollback plan. Do not claim the planning mode itself validates code execution or ensures security correctness.

Record unknowns instead of guessing

Some requirements may remain unresolved: Is an empty preferred contact method allowed? Is the field exported to a CRM? What happens to old records when the form changes its wording? The plan should list these as questions with accountable owners. Ask Copilot to stop short of inventing answers and identify which design choices depend on each response. Put decision dates and references in the issue tracker.

Compare the proposed plan with the documented current behavior. If a suggested edge case contradicts an existing constraint, edit the plan manually or request targeted revision. Keep original design discussions available for reviewers. The point is not to produce the longest possible plan; it is to produce the shortest plan that makes data-loss risks, behavioral changes, and tests easy to challenge before implementation.

Approve a bounded plan, then verify the change

A maintainer should sign off on the change request, schema table, compatibility matrix, failure behavior, and exact file scope. Save the approved plan to the issue or repository documentation before choosing Start Implementation or a comparable handoff action. Make sure any subsequent agent action is reviewed under normal branch protection and code-review rules. Run both the old and new CSV fixtures after the change and inspect the resulting records.

The example here is conceptual and no Copilot session, code deployment, or security test is claimed. A successful output is a plan that prevents a seemingly simple column addition from altering consent behavior or breaking historic imports. If implementation departs from the approved plan, stop and return for human review. Planning is a quality gate, not an automatic authorization to modify production code.

How We Research

We consulted the current primary product documentation: GitHub Docs: Using plan mode in your IDE, GitHub Docs: Asking Copilot questions in an IDE, GitHub Docs: Using agent mode in your IDE. These sources support the described controls, prerequisites, and known limitations as documented for this November 2026 editorial review. We distinguished documented feature behavior from the hypothetical example and designed each check around source records, observable editing stages, and the authority of the human reviewer. We did not log into a customer workspace, process real donor or staff records, grade real footage, run a controlled model benchmark, or measure service accuracy. Product interfaces, feature availability, pricing, and account permissions can change; readers should verify current vendor guidance and use local organizational policies before performing a real workflow.

Frequently Asked Questions