GitHub Copilot for Svelte: Context and Code Checks

Use GitHub Copilot for Svelte by supplying the project's installed versions, component conventions and one clear behavior change before requesting code. Review the patch and run the project's relevant checks; a component that looks plausible can still use the wrong syntax or behave incorrectly.

The useful starting point includes why the component exists and what was agreed in earlier sessions. fenbs can keep that project brief and reusable prompts alongside the work, so the next connected coding session can read them before proposing another change.

How should you start a Svelte coding task?

1. Inspect the package file and lockfile to identify the installed Svelte version, whether the app uses SvelteKit and which package manager it expects.
2. Open the component, its caller and a nearby example that follows the project's preferred conventions. Include relevant types and existing tests.
3. Write one observable requirement, such as showing a helpful empty state when a filtered list has no results.
4. Ask Copilot to explain the intended files and behavior before editing. Keep unrelated refactoring and dependency changes outside this task.
5. Review the resulting changes, run the applicable checks and try the user interaction in a browser.

Start with a small component change whose success you can describe without reading the implementation. For example, a filter should update the visible results, display a useful empty state and remain usable with a keyboard. That is easier to assess than a request to improve the entire application.

For choosing where to run the assistant, see the GitHub Copilot app guide. Student access, organization setup and licensing belong to their respective guides rather than this component workflow.

Which Svelte conventions does Copilot need to see?

State whether the affected code follows legacy syntax or Svelte's runes, the special syntax used to declare reactive state and related behavior. Svelte's migration guide↗ (opens in a new tab) explains the differences and allows gradual adoption. Do not ask the assistant to migrate neighboring components just because newer examples look different.

Give it the actual local pattern for component inputs, events, styles and data access. If the task touches a SvelteKit route, include the relevant route files and explain which work belongs on the server. A nearby working component is often clearer than a long list of abstract preferences.

• Versions and syntax: the installed framework versions and the conventions used in this part of the app.
• Component contract: required inputs, allowed empty values and how the parent learns about changes.
• Interface behavior: loading, empty, error, disabled and successful states.
• Project boundaries: existing design components, approved dependencies and files outside the requested change.
• Verification: the commands and user behaviors that establish the task is complete.

Keep the requirement separate from the suggested solution. Asking for an accessible filter describes the outcome; ordering a particular implementation before inspecting the existing component can lock the assistant into a poor fit.

Where should reusable project instructions go?

For supported editor workflows, GitHub documents repository guidance in custom instructions↗ (opens in a new tab). In VS Code, repository-wide guidance can live in .github/copilot-instructions.md, and the response references help you check whether it was included. Follow the instructions for your actual editor.

Keep repository instructions short and stable: how to find the app, which conventions to follow and how to validate a change. Put the current task's acceptance criteria in the task prompt. A permanent file saying the filter is unfinished becomes misleading after someone finishes it.

Use Skills and prompts in fenbs for a reusable review request that supported connected assistants can read across sessions. Keep source files as the authority for implementation, and update the project brief when people change the intended behavior.

What does a useful component prompt look like?

A useful prompt connects a specific user action to the expected visible result. It also tells the assistant what evidence to inspect and when to ask a question. Adapt this example to the files and commands your project actually has.

Read the project instructions, package file, target component and its caller.
Explain the Svelte conventions already used here.
Task: add an empty state when the filtered list has no results.
Keep the current component contract and use existing styles.
The filter must remain keyboard accessible.
Do not migrate syntax, add dependencies or edit unrelated routes.
Propose the files to change, then make the smallest useful patch.
Run the relevant project checks and report what you actually tested.
If a requirement conflicts with existing behavior, ask before changing it.

After the patch, ask the assistant to explain how the empty state differs from the loading state and what happens when the filter is cleared. Compare that explanation with the code and browser behavior. A confident explanation is useful for review, but it does not establish that the interaction works.

Choosing a different model is a separate decision covered in the GitHub Copilot models guide. First fix missing project context, because changing the model does not supply an absent requirement.

Which checks catch plausible but incorrect code?

Read the changed files before running anything. Look for new dependencies, unrelated syntax migrations, weakened types and changes to server code that the task never required. Confirm that event handling, component inputs and styles match the surrounding application.

Run the repository's established check command. Svelte documents sv check↗ (opens in a new tab) for reporting errors and warnings, including accessibility hints and JavaScript or TypeScript errors. Passing a static check does not establish that filtering, focus or an error message behaves correctly.

Use the existing test setup for meaningful behavior checks. The Svelte testing guide↗ (opens in a new tab) covers unit, component and end-to-end approaches. For this example, verify the empty result, clearing the filter and the normal populated result; do not settle for a test that merely confirms the component renders.

Try the interaction at a narrow browser width and with keyboard input. If a check cannot run, say why and leave it outstanding. Save the tested state and remaining checks in project context for the next session.

How to keep Svelte prompts and context with fenbs?

1. Create a free account and add your Svelte project with its goal and repository reference.
2. Add the component task and its expected user behavior. Record the current plan and the checks needed to finish.
3. Save the reusable component request in Skills and prompts, and add people's agreed development rules in Decisions and rules.
4. Follow the GitHub Copilot connection guide for your supported setup. MCP is a standard way for an assistant to read and update an outside tool.
5. Ask the connected assistant to read the project context before work and save actual progress, test results and next steps before stopping.

fenbs does not compile Svelte or replace source control and your test runner. If all you need is a local instruction file for a one-off component edit, that file may be enough. Use fenbs when reusable prompts and current work need to remain available across coding sessions.

The wider AI at work collection covers the surrounding work habits; GitHub Copilot memory owns the broader question of what the coding assistant retains.