Engineer

The MR arrives with requirements context, linked acceptance criteria, design references, and generated code. Start with the requirements — not the diff. Understand what was intended before evaluating whether the implementation achieves it.

The MR from a design repo sync contains: component files, Storybook stories, Playwright test files with test management case keys, and a description of what was validated before sync. What's intentionally missing: API integration (the component uses static mock data), error boundaries beyond the acceptance criteria, and feature flag wrapping. This is normal — the component is a validated shell that you complete with production logic.

You add: The judgment call about whether the approach is sound. Does the architecture make sense? Are there production considerations the requirements don't address?

Use the agent to load the relevant repo context — the requirements, the design context, the production patterns — before diving into implementation. The agent can summarize what's been specified and what the production codebase conventions expect.

"Summarize the requirements and acceptance criteria for [feature] from the repo."
"What production patterns from the codebase are relevant to implementing [feature]?"
"What edge cases in the requirements are likely to require engineering judgment?"
"Pull the context for [story key] and show me the existing API patterns in src/api/[area]"

The scaffolded component handles presentation. You add three categories of production-specific pieces that the design repo couldn't supply.

API Integration

The component arrives with static props. Connect it to your data layer using your team's established patterns. If the team uses React Query hooks, for example, the pattern looks like this — generalized from your codebase's conventions:

// The component from the design repo — static props
export const UserProfileCard: React.FC<UserProfileCardProps> = ({ name, avatarUrl, role }) => {
  // ... presentation code — validated in Storybook
};

// Your addition — connected to your data layer
import { useUserProfile } from '@/hooks/useUserProfile';

export const UserProfileCardContainer: React.FC<{ userId: string }> = ({ userId }) => {
  const { data: profile, isLoading, error } = useUserProfile(userId);

  if (isLoading) return <UserProfileCardSkeleton />;
  if (error) return <UserProfileCardError error={error} />;

  return <UserProfileCard {...profile} />;
};

Error Handling

Add error boundaries and fallback states that the design repo couldn't anticipate — states that depend on real API behavior, missing data, or network conditions. The design validated what the happy path looks like; you add the handling for everything else. An empty-state check, a null guard, an error boundary — these belong to you.

Feature Flag Wrapping

If the component is landing before the full feature is ready for all users, wrap it with your team's feature flag system:

import { useFeatureFlag } from '@/hooks/useFeatureFlag';

export const UserProfileCardGated: React.FC<UserProfileCardContainerProps> = (props) => {
  const isEnabled = useFeatureFlag('user-profile-card-v2');
  if (!isEnabled) return null;
  return <UserProfileCardContainer {...props} />;
};

You add: Production readiness. The generated code is shaped by the repo context, but your judgment about what "production-ready" means for this specific feature and codebase is irreplaceable.

The .spec.ts file from the design repo tests the component against Storybook. In production, you have three options — choose based on your team's setup and the role Storybook plays in your production pipeline.

Option A — Keep Storybook tests, add production tests separately. If your production repo also runs Storybook, the synced .spec.ts can continue to work as-is. Add a separate test file for the container component that tests the API integration path. The original tests validate presentation; the new tests validate behavior with real data patterns.

Option B — Adapt the base URL. Replace the Storybook URL in the test with your staging app URL. The test navigates to the actual feature in the application rather than the isolated Storybook story:

// Design repo version — navigates to Storybook story
await page.goto('http://localhost:6006/?path=/story/userprofilecard--default');

// Production version — navigates to the feature in the app
await page.goto(`${process.env.APP_URL}/settings/profile`);

Option C — Use the page object pattern. Abstract the navigation so the same test logic works in both environments. The page object handles "how to get to this component" and the test handles "what to verify." This is the most maintainable approach when the same tests need to run in CI against both Storybook and the production app.

The test case keys (PROJ-TC-XXX) in the test titles are preserved regardless of which option you choose. Results continue flowing to the same test management cases — the traceability chain from acceptance criteria through to production test results remains unbroken.

You add: Test architecture judgment. Which tests should be unit vs. integration vs. e2e? What coverage is actually meaningful here?

Run the full CI pipeline. If your org's technical standards are encoded in the repo, CI gates reflect those standards — lint, type-check, test coverage thresholds, security scans. Passing CI is not just a green check; it's verification that the implementation meets the org's encoded standards.

Deploy to staging and validate behavior against the acceptance criteria. This is the engineering equivalent of the designer's Storybook check — confirming that what was built in the implementation environment behaves correctly in the production-like environment, with real data and real dependencies.