How to Submit a PR from Figma Make Local Code: 2026 Designer Workflow

Figma Make local code is a beta workflow for working with an existing codebase. It is not a general-purpose promise that any account can open any project, and it is not a shortcut around engineering setup. Before you plan a design task, confirm both that the account can access the feature and that the Mac desktop app is available in the intended environment. Figma’s beta information describes a gradual rollout; access should be verified on the actual account rather than assumed from a team member’s access.

What account and Mac setup does the local-code workflow require? Check the account’s access to the beta, then confirm that the Mac version of the desktop app can be used. Also confirm access to the Git repository that contains the page you intend to edit. These are separate checks: beta access does not grant repository permissions, and repository access does not guarantee beta eligibility.

Keep the task narrow. This process fits an adjustment to an existing website interface—for example, changing a page section or refining a component. It is not a guide to building a new application, writing backend services, or operating deployment infrastructure. If the requested change depends on data models, authentication, APIs, or production configuration, agree on engineering ownership before opening the project.

Stop before setup if either gate fails. Ask the team administrator to verify beta access or repository permissions. Do not treat a missing feature or a failed clone as evidence that the design prompt is wrong.

The Git provider matters most when the work is ready to leave the designer’s machine. Figma’s setup information distinguishes the local-code workflow from the later PR process. For GitHub, Figma documents creating a PR from within the app; for GitLab and Bitbucket, the PR or merge request is handled on the provider’s own site. Check the current Figma setup instructions before beginning, then use the provider’s official instructions for GitLab merge requests or Bitbucket pull requests when applicable.

Do not read “Git support” as “identical PR support.” The repository may be available to Figma Make while the review request still needs to be created in a browser. Ask an engineer which branch naming rules, protected branches, checks, and reviewers the team expects. These policies are project-specific; a designer should not guess them from the app’s interface.

How do you connect an existing GitHub project? First check that the intended repository is the one your team uses for the page, and that your account has permission to access it. Then follow the connection or clone route shown in the current local-code setup guide. If the project needs a one-time configuration before it can run, have an engineer prepare or verify that configuration rather than improvising changes to project files.

There are two practical entry routes: connect a local repository already available in the Mac environment, or clone the remote repository the team has approved. In either case, record the repository and branch before making changes. That gives the reviewer a baseline and reduces the chance of editing a similarly named project or an outdated copy.

Once the project is open, start its preview using the project’s documented development workflow. The exact command and dependencies vary by repository, so use the team’s setup notes rather than copying commands from another project. Check that the page shown in the preview is the intended page and that it reflects the current project files. A preview that cannot start is a setup signal, not proof that a design edit has failed.

If the app cannot access the repository, verify the account permissions and the selected repository first. If dependencies fail or the development server does not start, compare the local environment with the project instructions and ask the engineer responsible for setup. Figma’s setup troubleshooting guide covers setup issues that can block the workflow. Keep the error message and the attempted setup steps for handoff.

Before editing, capture a simple baseline: note the page or component, the visible issue, and the expected outcome. That does not need to be a formal specification. A short note such as “tighten this card’s spacing without changing its content or mobile order” gives the reviewer a way to compare intent with the resulting code and preview.

Use the available controls—such as selecting an element, pointing to an area of the screen, or describing a change in natural language—to work on a clearly bounded part of the interface. Ask for one coherent adjustment at a time. Examples include refining a button’s spacing, revising a heading’s visual hierarchy, or aligning a card with an existing page pattern.

Avoid combining unrelated requests in one pass. A broad instruction that changes layout, copy, colors, and responsive behavior together makes it harder to tell which part caused a regression. It also makes the resulting PR more difficult to review. If the design change has several related details, write them down before editing and verify them individually in the preview.

Can Figma Make connect to an existing GitHub codebase? Figma’s local-code documentation describes working with a Git repository and the official setup process. The useful check is not simply whether a repository appears in the app: confirm that the selected project is the right one, that the preview runs, and that the change lands in the expected files. For a GitHub project, also confirm that the team’s branch and PR rules allow your account to push a proposed change.

Treat the preview and the code diff as two different checks. The preview helps you judge what the page looks like in the running project. The diff shows which files actually changed. A visually plausible result can still alter an unrelated component, omit an intended style, or conflict with the project’s design system. Compare the changed files with the task, then inspect the preview again after any correction.

Keep the reviewer’s question in view: can an engineer understand what changed, why it changed, and how to verify it without reconstructing the entire prompt history?

Figma’s workflow example can help explain how the product fits into a design-to-development process. It should not be taken as a guarantee that generated changes will match every team’s conventions or pass its checks automatically.

A branch is a separate line of proposed work. It lets the team review your change without putting it directly on the main working line. A commit records a snapshot of that change with a message that explains its purpose. Neither one certifies that the code is correct; they make the proposed work traceable and reviewable.

Before creating or pushing a branch, ask the engineering contact whether the project has a naming convention or a preferred base branch. Then inspect the changed files and remove unrelated edits if the workflow allows. A branch should represent the agreed design task, not incidental formatting or exploratory edits from another part of the project.

Use a commit message that describes the outcome, not just the tool used. For example, “Refine pricing card spacing” is more helpful to a reviewer than “Figma Make update.” Keep the description factual. If the change is incomplete or needs a follow-up, say so in the handoff rather than implying that it is ready to ship.

Run checks that fit the project and your role. These may include the project’s existing lint, build, or visual checks, but do not invent a command if the repository has no documented instruction for it. If a check is owned by engineering, note that it remains to be run. The purpose is to surface what has and has not been verified before the team reviews the proposal.

How do you turn a finished edit into a GitHub pull request? Review the diff, confirm the branch is based on the team-approved project state, and push the branch using the team’s workflow. If the app presents an in-app PR path for the connected GitHub repository, use it and verify the resulting request on GitHub. For other providers, go to the provider’s site and create the review request there. Figma’s provider-specific limits are documented in its local-code setup guide; do not assume the same in-app PR action exists for every host.

A useful PR description tells the reviewer what the design change is, where to look, and what still needs checking. Include the page or component changed, the intended visual result, and any known limitations. Link or describe the relevant design reference if the team’s process permits it. Keep the description short enough to scan, but specific enough that an engineer does not have to infer the acceptance criteria from a prompt.

Use this handoff checklist before sending the request:

• [ ] The branch comes from the intended repository and approved base.
• [ ] The changed files match the requested interface adjustment.
• [ ] The preview shows the intended page and the revised state.
• [ ] Relevant checks have been run, or remaining checks are clearly named.
• [ ] The PR description includes the goal, affected area, and any open questions.
• [ ] A team reviewer is assigned or the usual review process is followed.

For GitHub, the official PR review guide explains how reviewers inspect proposed changes. The engineer still decides whether the implementation is sound, whether it follows repository conventions, and whether it can be merged. The designer should respond to review comments, make requested changes through the agreed branch workflow, and avoid announcing a release until the team’s normal release owner confirms it.

What if the project uses GitLab or Bitbucket instead? Keep the code work and the review-request step distinct. Push the branch through the project’s approved workflow, then create the merge request or pull request in the provider’s web interface. Use the provider documentation linked above, and tell reviewers which branch contains the work. The feature’s ability to work with local code does not mean every provider has the same in-app PR controls.

A Windows computer cannot run the Mac desktop application required by this local-code workflow. If the task truly depends on that app, a remote Mac may be an option only when the Mac environment can run the required app, the account has beta access, and the repository can be reached from that environment. Remote access does not grant Figma eligibility, Git permissions, or team approval.

Use these decision branches before arranging an environment:

• If the account has beta access, the project is configured, and a Mac is already available: use that Mac, follow the team’s repository setup, and submit the change through the team’s provider workflow.
• If the account and repository are ready, but the Windows-first team lacks a Mac for a short task: evaluate a remote Mac only after confirming that the required Mac app can be installed and accessed in that environment. Test the connection and file handoff with a small, non-critical task before relying on it for a deadline.
• If beta access or repository permissions are missing: stop and resolve those with the relevant administrator or engineer. A different computer will not fix either issue.
• If the task involves backend behavior, production configuration, or an unreviewed release: hand it to engineering. Figma Make does not replace technical ownership or code review.

We do not have a representative, published MESHLAUNCH test record for this exact Figma Make local-code workflow, including beta-app availability, project setup, preview behavior, connection method, or file handoff. So we cannot claim that a remote Mac will work for every repository or provide a measured performance result. Confirm app compatibility and access before committing to a remote session; if the project depends on local peripherals or a team-managed Mac setup, use the environment approved by engineering.

A Windows-only process also has real tradeoffs: the local-code beta requires a Mac app, browser-based design work does not by itself provide the same local-repository workflow, and buying a Mac solely for an occasional review task may leave hardware underused. If a temporary Mac environment is appropriate, MESHLAUNCH offers a way to assess a hosted Mac instead of purchasing hardware up front. Review the available MESHLAUNCH Mac options and the MESHLAUNCH service overview, then verify the beta app, repository access, and connection requirements before starting. If the workflow is frequent and depends on local peripherals or a stable, dedicated workstation, owning or using a team-managed Mac may be the better fit.

The decision is straightforward: confirm beta access, repository permissions, and project readiness first. Then use Figma Make local code for a narrow, inspectable interface change, submit a PR through the supported provider route, and leave approval and release to the team’s review process. A remote Mac can address the Mac-app requirement for some Windows-based collaborators; it cannot bypass eligibility, repository setup, or engineering review.