Connect Your Editor: VS Code, Cursor, Bob, Kiro

Changing editors should not require changing how your team owns its work. A project can remain in GitHub while one contributor uses Visual Studio Code, another uses IBM Bob, and another prefers Cursor or Kiro. The shared foundation is a Git repository, a contribution branch, and a pull request that other people can review.

The confusing part is the word “connect.” An editor may ask you to sign in to an AI service, authenticate to GitHub, authorize an extension, and install a cloud integration. Those prompts do different jobs. Completing one does not necessarily complete the others.

This article explains a local workflow for all four editors. We will use the same documentation improvement as the other articles in this series: clarify the project's download instructions. Cloud agents have their own connection guide because they work in a separate environment with separate access.

Three connections, three different purposes

The editor opens a local folder. Git connects that folder's repository to a remote host. An AI service supplies assistance within the editor. Those responsibilities can cooperate without becoming the same connection.

Connection	What it enables	What it does not establish
Local folder opened in the editor	Reading and editing project files	Permission to push to GitHub
Git authentication to the repository host	Authorized fetch and push operations	An AI subscription or entitlement
Sign-in to the AI tool	Use of that tool's assistant	Access to every repository you can see in a browser
Optional hosted-agent integration	Access from a separate agent environment	Access to your laptop's unsaved files or local VPN

For a local workflow, begin by proving Git access. If you can open and edit the cloned project, you can choose an assistant later. This also gives you a clear troubleshooting boundary: a model sign-in failure should not require rebuilding the repository connection.

Prepare one working copy

Install Git if you will use the editor's Git integration or terminal commands. Set your commit identity according to your team's instructions. Obtain the clone URL from the repository's Code menu; copy the actual hostname, including an enterprise hostname when applicable.

You can clone through GitHub Desktop, as explained in the preceding article, and open that same folder in any of these editors. This is the simplest route when you already have Desktop working. Do not download another ZIP for the editor: it would create a second copy without the same Git history.

For a terminal route, the following example uses placeholders. Replace the URL with your writable repository or fork before running it:

git clone https://github.com/YOUR-ACCOUNT/YOUR-REPOSITORY.git
cd YOUR-REPOSITORY
git switch -c docs/clarify-downloads
git status
git remote -v

The expected state is a clean working tree on docs/clarify-downloads, with origin pointing to the intended repository. If you cloned an upstream project you cannot write to, arrange an authorized fork or contribution destination before publishing.

GitHub's clone instructions explain HTTPS and SSH choices. Use your organization's supported authentication method. Do not paste passwords or tokens into the clone URL or into an assistant's chat to make an error disappear.

Visual Studio Code: built-in Git, optional GitHub features

VS Code's Git operations and its GitHub pull-request features are separate capabilities. Basic clone, fetch, pull, and push support is built in; the GitHub Pull Requests and Issues extension adds review and issue workflows. A virtual repository opened without cloning is another mode again, with different execution limitations. See Work with GitHub in VS Code.

For a fresh local checkout:

Open the Command Palette with Ctrl+Shift+P on Windows/Linux or Command+Shift+P on macOS.
Run Git: Clone, paste the repository URL, and choose a destination folder.
Complete the GitHub authentication flow if prompted, then open the clone.
Review the workspace-trust prompt based on the project's source and whether you intend to execute its tasks.
Create your contribution branch through the branch control, or use the terminal command above.

Alternatively, use File → Open Folder for a clone you already created. The Source Control view should recognize it. VS Code documents the clone and remote workflow in Working with repositories and remotes.

Edit the README, save it, and select it in Source Control to inspect the diff. Stage the intended changes, write a commit message, and commit. Publish the branch or push it. Then create the pull request in GitHub's browser interface, or install the official pull-request extension if you want to manage that step inside VS Code.

For a first contribution, explicit fetch, commit, and push operations are easier to reason about than an undifferentiated “sync.” Read what a sync action will do before using it on work you have not reviewed.

IBM Bob: open the repository, then choose how Bob helps

IBM Bob is a standalone IDE, not a VS Code extension. IBM's Bob quickstart documents its clone workflow and its Ask, Plan, and Agent modes.

Install and sign in to Bob through the IBM route available to your account or organization.
From the files view, select Clone Repository, paste the Git URL, and choose a local destination. If the project is already cloned, open that folder instead.
Open the clone when prompted. Confirm the repository and current branch before requesting edits.
Start in Ask mode to understand the relevant README section.
Move to an editing-capable mode when you are ready for the bounded change, and review the requested actions.

Bob sign-in supplies Bob access. Git still needs access to the remote repository. For an enterprise host, prove the clone or fetch independently if the IDE reports an authentication failure.

For this exercise, ask Bob to identify where a new user would learn which download to choose. Have it propose revised wording before applying it. A full application plan would be unnecessary overhead for a paragraph correction; a behavioral change across several components would justify more planning.

Bob can initialize project instructions, but generating new instruction files is a separate repository change. Inspect existing instructions first. Do not casually add an initialization output to a narrowly scoped README pull request.

Cursor: keep local editing separate from cloud delegation

For the local route, clone the repository with Desktop or Git and open the cloned project folder in Cursor. Sign in to Cursor for its AI capabilities, then confirm the branch and remotes using the integrated terminal. This avoids making a cloud integration a prerequisite for local work.

Open the README and ask Cursor's agent to propose the focused documentation change. Review the affected files in the editor and through Git. If you prefer, return to Desktop to select and commit the changes; both applications are looking at the same working copy.

Cursor's GitHub integration supports additional services such as cloud agents and Bugbot. That integration is distinct from opening a local clone. The Cursor GitHub integration documentation describes repository authorization; the companion cloud-agent page covers the hosted workflow.

This distinction is useful when a company permits local IDE assistance but has not yet configured hosted agents. You can establish the supported local workflow without treating missing cloud repository access as a broken editor.

Also avoid assuming that every VS Code extension is interchangeable across editors. Use the publisher's stated supported-editor route. Cursor publishes its own extension guidance, and the assistant vendors document their supported integrations.

Kiro: open the clone and keep the task proportional

Install Kiro and complete its sign-in. Its authentication guide covers personal and organizational providers. Signing in with GitHub identifies you to Kiro; do not treat that alone as proof that local Git can push to a private project.

For a predictable local setup:

Clone with Git or Desktop and create your contribution branch.
In Kiro, select File → Open Folder and choose the repository folder.
Open the Kiro panel and start a chat about the README section.
Ask for the small revision, inspect it, and use Git or Desktop to commit and publish.

Kiro's first-project guide documents opening an existing folder, project steering, and its requirements/design/tasks approach to specifications. Steering can give recurring work useful context; specifications can make larger changes easier to inspect. Neither needs to be generated merely to correct a download paragraph.

If Kiro proposes new steering or specification files, decide whether those belong in this contribution. Keep useful work, but do not let a tool's onboarding ceremony silently widen the pull request.

Use the same first prompt in each assistant

The following is a complete example prompt, not a claim that any of these tools were run against a live project for this article:

We are improving the download instructions for first-time users.
Read README.md and any contribution or project instructions that apply.
Identify the existing installation guidance and any release/package links.

Propose a small README-only change distinguishing packaged distributions
from source archives. Preserve the project's documented installation route.
Do not invent asset names, supported platforms, or installation commands.
If the repository does not establish which download is intended, explain
what is missing instead of filling in the answer.

Show the proposed wording first. After I approve it, apply only that change.
Report the files changed and the checks actually performed.
Do not commit, push, open a pull request, or modify other files yet.

The prompt supplies the audience, evidence, scope, and completion criteria. Those are useful instructions, but they are not an access-control mechanism. The tool's configured permissions govern what operations it can execute.

After the edit, check git status and git diff, or inspect the equivalent view in Desktop. Confirm the target file, preview its Markdown, and check its links. Then commit, push, and open the pull request through your preferred Git interface.

Enterprise troubleshooting starts with the host

When repository access fails, compare the URL in git remote -v with the URL your organization supplied. Then check the active Git identity, SSO requirements, network reachability, and approved authentication method. An editor connected to GitHub.com may need separate configuration for an enterprise host.

When the AI service fails but Git works, investigate the assistant's account, entitlement, endpoint, or organizational policy. When a cloud agent fails but local editing works, investigate the cloud environment. Your laptop's VPN connection does not automatically become the agent's network route.

Keep one canonical working copy for this exercise and one contribution branch. The choice of editor should improve how you understand and change the project. The repository and review process should still make the result understandable to everyone else.