# Component Requests: From a Figma Component to a GitHub Issue in One Click Every design-system team has a component that fell through the cracks. A designer draws a new alert banner for the billing flow. It gets variants, it gets reviewed, it goes into the library. Then someone has to tell engineering, and that part lives in a Slack thread, a comment on a Figma frame, or a line in a planning doc. A month later a product engineer builds a one-off banner because nobody told them the design system had one on the way. [Scry Link](https://www.figma.com/community/plugin/1602918953997015259) already connects Figma layers to Storybook stories: select a layer, find its story, link it, and anyone in the file can jump to the live code. The question it couldn't answer was what to do when there is no story yet. Component requests are that answer, and they are live in Scry Link today. The designer asks from the place they already are, engineering gets an issue in the place they already work, and the component itself remembers that it was asked for. ## How it works It takes three steps, all inside Figma.  **1. Select the component.** In Scry Link, select a component or component set that has no story linked. Under the story search, a card reads "No story for this yet?" with the target repository and a **Request this component** button. Variants and instances work too: the request goes to the component set or the instance's main component, so you don't end up with four issues for four variants of the same thing. **2. Check the details.** The form is filled in for you. There is a 2x preview of the component, a title (`Build component: AlertBanner`), and the variants and properties Scry read from Figma, shown as chips. You add notes if engineering needs context, such as where the component is used, what it replaces, or which states matter first. If you're not signed in, the plugin asks you to sign in and then returns to the same form. If the project has no repository yet, it links straight to the settings page where an admin connects one. **3. Create the issue.** Press **Create issue**. A few seconds later you see "Issue #9 created" and a link to open it on GitHub. From then on the component shows **Requested · #9 open** to everyone who opens the file, with who asked and when. The request is stored on the node itself, so a collaborator sees it even without an account. If you request the same component twice, you get the existing request back instead of a duplicate issue. ## What engineering receives The issue is opened by the Scry GitHub App, not by the designer, so designers don't need GitHub accounts or seats. It contains everything needed to start work without going back to Figma: - the component preview, - a link to the exact Figma node, - a link to the request in the Scrymore dashboard, - a table of variants, properties and size, - the designer's notes, - "Requested by via Scry Link".  It carries two labels, `design-request` and `scry`, so it fits into whatever triage you already run: filter a board by label, route it to the design-system team, or pick it up in a sprint like any other issue. Notes are treated as untrusted text: `@mentions` and `#123` references are neutralised, so a note can't page half the organisation or cross-link unrelated issues. ## Tracking requests in the dashboard Requests also show up in the Scrymore dashboard, under **Design Sync → Requests**, next to the screens you have already linked. Each row shows the preview, who asked, when, the issue number and a status. Filters split them into Open, Fulfilled, Closed and Failed.  **View** opens a detail dialog with a large preview, the variants grouped by property, the notes, the GitHub state and a timeline from "Requested" through "Issue opened" to "Story linked" and "Fulfilled". The "request details" link in the issue opens the same dialog, so an engineer can go from GitHub to the design context in one click.  Sometimes GitHub says no. The App might have lost access to the repository, or the installation might be suspended. When that happens the request is saved anyway and marked Failed, and **Retry** in the plugin or the dashboard repeats only the GitHub step. Nobody has to export or retype anything. ## Permissions and privacy We kept the GitHub side as small as it can be. The Scry GitHub App asks for two permissions: **Issues (read and write)** and **Metadata (read)**, on the repositories you choose. It cannot read or write your code, pull requests or settings. A project admin connects the repository once, from the project's new **Repository** tab, and Scry checks that the GitHub installation actually belongs to the person connecting it before saving anything.  A few other choices are worth knowing about: - **Requests are signed-in only**, and viewers can't file them. Every issue is tied to a real project member. - **The requester's name comes from their Scrymore account**, never from the plugin, and never as a full email address. - **The preview image is hosted by Scrymore** behind an unguessable signed link, so it renders in private repositories without Scry needing write access to your code. Nothing is committed to your repository. - **The Figma file stores only what the badge needs**: the issue number and link, the title, the requester's name and the date. No tokens. ## Try it Component requests are available now in [Scry Link](https://www.figma.com/community/plugin/1602918953997015259) (version 7 and later; update the plugin if Figma hasn't already). A project admin connects the repository once from the **Repository** tab in the Scrymore dashboard, and from then on any signed-in project member except viewers can request components. The [docs](https://docs.scrymore.com/guide/component-requests) cover setup step by step. ## What's next **Fulfilment.** The request is only half of the loop. When an engineer builds the component and a designer links its new story to the Figma node, which is the normal Scry Link flow, the request should mark itself fulfilled and comment on the issue with the story link. The plugin already says "Linking a story fulfils the request", and the timeline already has the steps, but the automatic part isn't built yet. Until then, close the issue when the component ships. If your team keeps a spreadsheet of "components we still need to build", we'd like to hear how you run it. Tell us on the [feedback form](https://docs.scrymore.com/feedback) or email feedback@scrymore.com.