Staff Design Engineer
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). Use - for any list of duties/requirements/benefits, and
for prose. Do NOT repeat the job title as a heading. Do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. Preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. IMPORTANT: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text (e.g. "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Prefer a few substantive sections over many thin ones.
We need to include sections only if content exists. The posting includes:
- About Scribe (company description) – could be a section? Not listed as required headings but we could include as "About Scribe" maybe not required but we can include as prose.
- About the role (heading) – yes.
- What you'll do (Responsibilities) – yes.
- Your first 90 days – could be a section (maybe "First 90 days").
- What we're looking for (Requirements/Qualifications) – yes.
- Nice to have (Skills) – maybe as "Nice to have" under Skills.
- Location – yes (Hybrid: Based in San Francisco. We work from the office 3 days per week.)
- Compensation – yes (Salary varies by location. All full-time employees receive equity in Scribe. Final offers depend on experience and scope. Also Compensation Range: $215K - $280K). So we have compensation details.
- Benefits – yes (list of benefits).
We should not include sections like Pay if not specific? Actually we have compensation details, so we can include a Pay section.
Schedule? Not given, so omit.
We need to use
for each section heading.
We need to use - for any list of duties/requirements/benefits.
We need to use
for prose.
We must not repeat job title as heading.
We must not include boilerplate like EEO etc. The posting includes a paragraph about celebrating differences and equal opportunity employer – that's boilerplate; we should remove it.
Also remove duplicated lines.
We need to preserve all substantive information.
Let's extract content:
About Scribe paragraph: "Scribe is where exceptional people come to do the best work of their careers. More than 94% of the Fortune 500 use Scribe to own their specialized intelligence: the unique way their teams work, decide, and get things done. Our Specialized Intelligence platform automatically captures how work happens and turns it into a living asset that helps people and AI agents do their best work. We're growing fast. Since our founding in 2019, we've grown to 7 million users across 600,000 businesses. Based in San Francisco, we've been named a LinkedIn Top Startup, are valued at over $1 billion, and are backed by leading investors. Join us in our mission to transform how people do work. We're builders who hold a high bar, move fast, and care deeply about each other and our customers."
We can put that as a
maybe under a heading "About Scribe"? Not required but we can include as a section heading "About Scribe". The instruction says use headings like About the role, Responsibilities, etc. It doesn't forbid other headings, but we should prefer few substantive sections. However About Scribe is substantive. Could be included as a
without heading? Probably better to include a heading "About Scribe" as
. It's not in the list but seems okay.
But the instruction: "use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." It gives examples but not exclusive. So we can use other headings as needed.
We'll produce sections:
About Scribe
...
About the role
... (the paragraph about role)
Responsibilities
- ... list items from "What you'll do" bullet points (the ones starting with Own Stylus., Build the hard components., Prototype in code..., Work with designers..., Keep design and code..., Make the system work for agents..., Share how you work.)
First 90 days
... maybe we can break into
for each phase? The content includes days 1-30, 31-60, 61-90 and by six months. Could be a with three items each containing subtext. We'll keep as with paragraphs? Better to use
- for each phase.
What we're looking for
- ... list items from bullet points: 8+ years experience..., Design ability..., You've worked on a design system..., You shape the work..., You already build with AI tools..., Accessibility..., etc.
Nice to have
- ... list items: Figma plugins..., Web components..., Desktop apps..., Agent-facing or generative UI work.
Location
Hybrid: Based in San Francisco. We work from the office 3 days per week.
Pay
Salary varies by location. All full-time employees receive equity in Scribe. Final offers depend on experience and scope. Compensation Range: $215K - $280K.
Benefits
- Health, dental, and vision insurance for you and your dependents
- Flexible paid time off and company holidays
- 401(k)
- Paid parental leave
- Daily catered lunch (SF office)
- Commuter benefits
- Home office stipend
We must ensure we don't include any boilerplate like EEO etc. Also remove duplicated lines (none). Ensure we preserve all substantive info.
Check that we didn't miss any details: The "About the role" paragraph includes: "We're hiring a Staff Design Engineer to own Stylus, our design system, and the quality of what we ship across the web app, desktop app, browser extension, and marketing site. As a Staff Design Engineer at Scribe, you sit at the intersection of design and frontend engineering. AI has made designs, code, and prototypes cheap to produce. What separates good product from great product now is judgment: knowing which interactions are worth building, and then building them well. We want someone who can look at a problem, decide what it should feel like, and ship it themselves. At its core, this role is anchored in Stylus ownership. From there you'll drive both design craft (product polish, prototyping, and interaction quality) and platform power (frontend tooling, DevEx, and the internal agents and skills)." We'll include that.
The "What you'll do" bullet list: we need to capture each bullet exactly as in text.
Let's extract bullet points from "What you'll do":
- Own Stylus. The roadmap, triage, and the call on what goes in, measured against numbers we actually track: component adoption, accessibility coverage, and documentation health, plus the design system survey we run every 6–12 months. You'll set direction while absorbing requests from engineers and designers.
- Build the hard components. The ones where aesthetics and performance fight each other. You'll decide what becomes a shared primitive and what stays a one-off, and build both.
- Prototype in code and validate with customers. Build interactive prototypes in React and TypeScript for the explorations that are faster in code than in Figma: animation, keyboard, touch. Then test them with real users.
- Work with designers without a handoff. A designer starts a direction, you iterate together in Figma or directly in code, and you're the person who can say what a given interaction will cost to build.
- Keep design and code from drifting apart. Tokens aligned with design, legacy components actively migrated onto the system instead of left alone, and Figma-to-code tooling that stays useful.
- Make the system work for agents as well as people. Explore emerging UX patterns and AI-ready design languages, and build the primitives we'll need as more of our UI gets assembled by models.
- Share how you work. Document the prompts, patterns, and workflows you use in Cursor and Claude Code and share them with designers and engineers. Mentor engineers on design principles.
We'll put each as - .
First 90 days: we have days 1-30, 31-60, 61-90, and by six months. We'll capture each as
- with the text.
Days 1–30 Ship, then map.Land your first Stylus change in the first week or two - small, real, in production. You'll learn more about our stack from one merged component fix than from a month of onboarding docs.Build the honest picture: where components have drifted, which surfaces are furthest from the system, and what our accessibility coverage actually is versus what we assume it is.Meet the people who file the requests - designers, product engineers, marketing - and watch customers use the product. Craft decisions get better when the person making them has watched someone struggle.
Days 31–60 Set the line.Publish the Stylus roadmap and the quality bar that goes with it, and start using both to say no. This is the point where a backlog becomes a plan with an owner.Pick the first hard component and build it - the one where aesthetics and performance fight each other, that nobody has had the time to do properly.Start the legacy migration where it pays off most, and make the path off legacy obvious enough that other engineers take it without being asked.
Days 61–90 Make it hold without you.Get adoption, accessibility, and documentation health reported automatically, so system health is a number we see rather than a question we ask.Make contributing to Stylus something engineers and designers actually do: a clear way in for requests, contributions, and exceptions, with you making the call on each.Ship the first AI workflows you'd want the rest of us using - the prompts, skills, and tooling that let designers and PMs build against the system safely. By six months: Stylus has a real roadmap instead of a backlog, the legacy-component migration is actively moving, and adoption is reported automatically rather than asked about.
We'll keep as is.
What we're looking for bullet list:
- 8+ years of experience in front-end development with a strong design sensibility and real depth in CSS, the DOM, and browser rendering. You have a view on when to use native platform elements versus a framework's version, and you can explain it.
- Design ability of your own. You can make the call on an interaction, and you know which ones aren't worth what they cost to build.
- You've worked on a design system at depth: components, primitives, tokens, versioning, adoption, and the governance to hold a line when a team wants an exception.
- You shape the work rather than take tickets.
for prose. Do NOT repeat the job title as a heading. Do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. Preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. IMPORTANT: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text (e.g. "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Prefer a few substantive sections over many thin ones. We need to include sections only if content exists. The posting includes: - About Scribe (company description) – could be a section? Not listed as required headings but we could include as "About Scribe" maybe not required but we can include as prose. - About the role (heading) – yes. - What you'll do (Responsibilities) – yes. - Your first 90 days – could be a section (maybe "First 90 days"). - What we're looking for (Requirements/Qualifications) – yes. - Nice to have (Skills) – maybe as "Nice to have" under Skills. - Location – yes (Hybrid: Based in San Francisco. We work from the office 3 days per week.) - Compensation – yes (Salary varies by location. All full-time employees receive equity in Scribe. Final offers depend on experience and scope. Also Compensation Range: $215K - $280K). So we have compensation details. - Benefits – yes (list of benefits). We should not include sections like Pay if not specific? Actually we have compensation details, so we can include a Pay section. Schedule? Not given, so omit. We need to use
for each section heading.
We need to use - for any list of duties/requirements/benefits.
We need to use
for prose.
We must not repeat job title as heading.
We must not include boilerplate like EEO etc. The posting includes a paragraph about celebrating differences and equal opportunity employer – that's boilerplate; we should remove it.
Also remove duplicated lines.
We need to preserve all substantive information.
Let's extract content:
About Scribe paragraph: "Scribe is where exceptional people come to do the best work of their careers. More than 94% of the Fortune 500 use Scribe to own their specialized intelligence: the unique way their teams work, decide, and get things done. Our Specialized Intelligence platform automatically captures how work happens and turns it into a living asset that helps people and AI agents do their best work. We're growing fast. Since our founding in 2019, we've grown to 7 million users across 600,000 businesses. Based in San Francisco, we've been named a LinkedIn Top Startup, are valued at over $1 billion, and are backed by leading investors. Join us in our mission to transform how people do work. We're builders who hold a high bar, move fast, and care deeply about each other and our customers."
We can put that as a
maybe under a heading "About Scribe"? Not required but we can include as a section heading "About Scribe". The instruction says use headings like About the role, Responsibilities, etc. It doesn't forbid other headings, but we should prefer few substantive sections. However About Scribe is substantive. Could be included as a
without heading? Probably better to include a heading "About Scribe" as
. It's not in the list but seems okay.
But the instruction: "use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." It gives examples but not exclusive. So we can use other headings as needed.
We'll produce sections:
About Scribe
...
About the role
... (the paragraph about role)
Responsibilities
- ... list items from "What you'll do" bullet points (the ones starting with Own Stylus., Build the hard components., Prototype in code..., Work with designers..., Keep design and code..., Make the system work for agents..., Share how you work.)
First 90 days
... maybe we can break into
for each phase? The content includes days 1-30, 31-60, 61-90 and by six months. Could be a with three items each containing subtext. We'll keep as with paragraphs? Better to use
- for each phase.
What we're looking for
- ... list items from bullet points: 8+ years experience..., Design ability..., You've worked on a design system..., You shape the work..., You already build with AI tools..., Accessibility..., etc.
Nice to have
- ... list items: Figma plugins..., Web components..., Desktop apps..., Agent-facing or generative UI work.
Location
Hybrid: Based in San Francisco. We work from the office 3 days per week.
Pay
Salary varies by location. All full-time employees receive equity in Scribe. Final offers depend on experience and scope. Compensation Range: $215K - $280K.
Benefits
- Health, dental, and vision insurance for you and your dependents
- Flexible paid time off and company holidays
- 401(k)
- Paid parental leave
- Daily catered lunch (SF office)
- Commuter benefits
- Home office stipend
We must ensure we don't include any boilerplate like EEO etc. Also remove duplicated lines (none). Ensure we preserve all substantive info.
Check that we didn't miss any details: The "About the role" paragraph includes: "We're hiring a Staff Design Engineer to own Stylus, our design system, and the quality of what we ship across the web app, desktop app, browser extension, and marketing site. As a Staff Design Engineer at Scribe, you sit at the intersection of design and frontend engineering. AI has made designs, code, and prototypes cheap to produce. What separates good product from great product now is judgment: knowing which interactions are worth building, and then building them well. We want someone who can look at a problem, decide what it should feel like, and ship it themselves. At its core, this role is anchored in Stylus ownership. From there you'll drive both design craft (product polish, prototyping, and interaction quality) and platform power (frontend tooling, DevEx, and the internal agents and skills)." We'll include that.
The "What you'll do" bullet list: we need to capture each bullet exactly as in text.
Let's extract bullet points from "What you'll do":
- Own Stylus. The roadmap, triage, and the call on what goes in, measured against numbers we actually track: component adoption, accessibility coverage, and documentation health, plus the design system survey we run every 6–12 months. You'll set direction while absorbing requests from engineers and designers.
- Build the hard components. The ones where aesthetics and performance fight each other. You'll decide what becomes a shared primitive and what stays a one-off, and build both.
- Prototype in code and validate with customers. Build interactive prototypes in React and TypeScript for the explorations that are faster in code than in Figma: animation, keyboard, touch. Then test them with real users.
- Work with designers without a handoff. A designer starts a direction, you iterate together in Figma or directly in code, and you're the person who can say what a given interaction will cost to build.
- Keep design and code from drifting apart. Tokens aligned with design, legacy components actively migrated onto the system instead of left alone, and Figma-to-code tooling that stays useful.
- Make the system work for agents as well as people. Explore emerging UX patterns and AI-ready design languages, and build the primitives we'll need as more of our UI gets assembled by models.
- Share how you work. Document the prompts, patterns, and workflows you use in Cursor and Claude Code and share them with designers and engineers. Mentor engineers on design principles.
We'll put each as - .
First 90 days: we have days 1-30, 31-60, 61-90, and by six months. We'll capture each as
- with the text.
Days 1–30 Ship, then map.Land your first Stylus change in the first week or two - small, real, in production. You'll learn more about our stack from one merged component fix than from a month of onboarding docs.Build the honest picture: where components have drifted, which surfaces are furthest from the system, and what our accessibility coverage actually is versus what we assume it is.Meet the people who file the requests - designers, product engineers, marketing - and watch customers use the product. Craft decisions get better when the person making them has watched someone struggle.
Days 31–60 Set the line.Publish the Stylus roadmap and the quality bar that goes with it, and start using both to say no. This is the point where a backlog becomes a plan with an owner.Pick the first hard component and build it - the one where aesthetics and performance fight each other, that nobody has had the time to do properly.Start the legacy migration where it pays off most, and make the path off legacy obvious enough that other engineers take it without being asked.
Days 61–90 Make it hold without you.Get adoption, accessibility, and documentation health reported automatically, so system health is a number we see rather than a question we ask.Make contributing to Stylus something engineers and designers actually do: a clear way in for requests, contributions, and exceptions, with you making the call on each.Ship the first AI workflows you'd want the rest of us using - the prompts, skills, and tooling that let designers and PMs build against the system safely. By six months: Stylus has a real roadmap instead of a backlog, the legacy-component migration is actively moving, and adoption is reported automatically rather than asked about.
We'll keep as is.
What we're looking for bullet list:
- 8+ years of experience in front-end development with a strong design sensibility and real depth in CSS, the DOM, and browser rendering. You have a view on when to use native platform elements versus a framework's version, and you can explain it.
- Design ability of your own. You can make the call on an interaction, and you know which ones aren't worth what they cost to build.
- You've worked on a design system at depth: components, primitives, tokens, versioning, adoption, and the governance to hold a line when a team wants an exception.
- You shape the work rather than take tickets.
for prose. We must not repeat job title as heading. We must not include boilerplate like EEO etc. The posting includes a paragraph about celebrating differences and equal opportunity employer – that's boilerplate; we should remove it. Also remove duplicated lines. We need to preserve all substantive information. Let's extract content: About Scribe paragraph: "Scribe is where exceptional people come to do the best work of their careers. More than 94% of the Fortune 500 use Scribe to own their specialized intelligence: the unique way their teams work, decide, and get things done. Our Specialized Intelligence platform automatically captures how work happens and turns it into a living asset that helps people and AI agents do their best work. We're growing fast. Since our founding in 2019, we've grown to 7 million users across 600,000 businesses. Based in San Francisco, we've been named a LinkedIn Top Startup, are valued at over $1 billion, and are backed by leading investors. Join us in our mission to transform how people do work. We're builders who hold a high bar, move fast, and care deeply about each other and our customers." We can put that as a
maybe under a heading "About Scribe"? Not required but we can include as a section heading "About Scribe". The instruction says use headings like About the role, Responsibilities, etc. It doesn't forbid other headings, but we should prefer few substantive sections. However About Scribe is substantive. Could be included as a
without heading? Probably better to include a heading "About Scribe" as
. It's not in the list but seems okay.
But the instruction: "use for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." It gives examples but not exclusive. So we can use other headings as needed.
We'll produce sections:
About Scribe
About Scribe
...
About the role
... (the paragraph about role)
Responsibilities
- ... list items from "What you'll do" bullet points (the ones starting with Own Stylus., Build the hard components., Prototype in code..., Work with designers..., Keep design and code..., Make the system work for agents..., Share how you work.)
First 90 days
... maybe we can break into
- for each phase? The content includes days 1-30, 31-60, 61-90 and by six months. Could be a
- for each phase.
What we're looking for
- ... list items from bullet points: 8+ years experience..., Design ability..., You've worked on a design system..., You shape the work..., You already build with AI tools..., Accessibility..., etc.
Nice to have
- ... list items: Figma plugins..., Web components..., Desktop apps..., Agent-facing or generative UI work.
Location
Hybrid: Based in San Francisco. We work from the office 3 days per week.
Pay
Salary varies by location. All full-time employees receive equity in Scribe. Final offers depend on experience and scope. Compensation Range: $215K - $280K.
Benefits
- Health, dental, and vision insurance for you and your dependents
- Flexible paid time off and company holidays
- 401(k)
- Paid parental leave
- Daily catered lunch (SF office)
- Commuter benefits
- Home office stipend
- . First 90 days: we have days 1-30, 31-60, 61-90, and by six months. We'll capture each as
- with the text. Days 1–30 Ship, then map.Land your first Stylus change in the first week or two - small, real, in production. You'll learn more about our stack from one merged component fix than from a month of onboarding docs.Build the honest picture: where components have drifted, which surfaces are furthest from the system, and what our accessibility coverage actually is versus what we assume it is.Meet the people who file the requests - designers, product engineers, marketing - and watch customers use the product. Craft decisions get better when the person making them has watched someone struggle. Days 31–60 Set the line.Publish the Stylus roadmap and the quality bar that goes with it, and start using both to say no. This is the point where a backlog becomes a plan with an owner.Pick the first hard component and build it - the one where aesthetics and performance fight each other, that nobody has had the time to do properly.Start the legacy migration where it pays off most, and make the path off legacy obvious enough that other engineers take it without being asked. Days 61–90 Make it hold without you.Get adoption, accessibility, and documentation health reported automatically, so system health is a number we see rather than a question we ask.Make contributing to Stylus something engineers and designers actually do: a clear way in for requests, contributions, and exceptions, with you making the call on each.Ship the first AI workflows you'd want the rest of us using - the prompts, skills, and tooling that let designers and PMs build against the system safely. By six months: Stylus has a real roadmap instead of a backlog, the legacy-component migration is actively moving, and adoption is reported automatically rather than asked about. We'll keep as is. What we're looking for bullet list: - 8+ years of experience in front-end development with a strong design sensibility and real depth in CSS, the DOM, and browser rendering. You have a view on when to use native platform elements versus a framework's version, and you can explain it. - Design ability of your own. You can make the call on an interaction, and you know which ones aren't worth what they cost to build. - You've worked on a design system at depth: components, primitives, tokens, versioning, adoption, and the governance to hold a line when a team wants an exception. - You shape the work rather than take tickets.
- with three items each containing subtext. We'll keep as
with paragraphs? Better to use