Context portfolio folder gist

01-identity.md

Identity

Name: Dean Radcliffe Role: Software Engineering Manager Organization: Optum (part of UnitedHealth Group, Fortune 5)

Dean manages the mobile and web squads of an enterprise Design System team at Optum. He has 5 junior developers as direct reports across both squads, while senior developers report up to his manager Ari. He sits at the intersection of design systems, front-end engineering, and the growing push to integrate AI into enterprise-scale UI infrastructure. The design system is called Abyss. He works closely with product, scrum, and squad leads to deliver design system components across mobile and web for the broader UHG enterprise. People come to him for front-end engineering leadership, design system strategy, and increasingly for AI integration into developer workflows and end-user experiences. His team includes offshore members. He has a dev background and is actively growing into senior engineering leadership — moving from reading code after-the-fact toward upfront architecture, success criteria definition, and demonstrable improvement metrics.

02-role-and-responsibilities.md

Role & Responsibilities

Title: Software Engineering Manager Organization: Optum (UnitedHealth Group)

Core Responsibilities

• Manages the mobile and web squads of the Abyss enterprise Design System
• Direct manager of 5 junior developers across both squads
• Seniors on the squads report up to his manager Ari, not to Dean directly
• Design and Governance is a parallel track (not under Dean)
• Growing the team's AI capabilities — both internal use and user-facing
• Overseeing adaptation of Abyss to upstream changes (e.g., Grayscale)
• Driving adoption intelligence and metrics via the Abyss Dashboard
• Managing offshore team members alongside onshore staff
• Tracking and demonstrating improvement across key metrics: v2 enterprise adoption, developer cycle time, AI usage consistency/growth, test coverage

Where Dean's Time is Going (Current → Target)

• Currently: Still involved in reading code after-the-fact
• Target: Shift toward upfront architecture, success criteria definition, and demonstrable improvement metrics
• Target: More architectural leadership, less reactive code review

Recurring Cadences

• Weekly 1:1s with each of his 5 direct reports
• Ongoing async communication with all devs in online channels (Slack or similar)

What the Team Produces

• Abyss design system components and tooling for enterprise-wide consumption (mobile + web)
• AI skills for design system users
• Theming and styling support for consuming teams
• Adoption dashboards and usage analytics

Reporting Structure

• Reports to: Ari (manager; also has the senior devs reporting to him)
• Direct reports: 5 junior developers across mobile and web squads
• Parallel: Design and Governance team (separate reporting line)

03-current-projects.md

Current Projects

Abyss Design System (Core)

• What: Enterprise design system serving the broader Optum/UHG enterprise, covering mobile and web front-end technologies
• Status: In progress (ongoing/mature product with active development)
• Dean's role: Engineering Manager — owns the mobile and web squads
• Key collaborators: Tony (web lead), Michael (mobile lead), Grace and Steve (product), Joel (scrum master), Ari (manager)
• Priority: Primary workstream

AI Skills for Abyss Users

• What: Shipping AI-powered skills/capabilities that help users work more effectively with the Abyss design system
• Status: Active — targeted for Q1 delivery
• Dean's role: Driving the initiative
• Priority: High

Internal AI Velocity

• What: Increasing the team's own development velocity by adopting and leveraging AI tools (Copilot, Windsurf, etc.)
• Status: Active — Q1 goal
• Dean's role: Championing adoption across the squads
• Priority: High

Grayscale (Figma Reorganization)

• What: A very large Figma file reorganization project; Abyss needs to adapt to the changes coming from Grayscale
• Status: In progress — Q1 timeline; actively working on phasing and sequencing
• Dean's role: Ensuring the mobile and web squads adapt Abyss accordingly; cross-functional sequencing with design
• Key challenge: Constraining downstream impact by specifying the interface Grayscale must conform to, rather than absorbing arbitrary changes — minimizing breaking changes for Abyss consumers
• Approach: Defining interface contracts upfront so Grayscale adapts to Abyss's boundaries, not the reverse. Phasing for iterative value delivery with specific success criteria.
• Interface specifics: Primarily token names and file structure — which dialect of DTCG. Also includes process elements for guiding teams toward creation of those files with least friction.
• Priority: Medium-high — dependency on external changes, large scope

Styling & Theming Support

• What: Helping user teams style and theme their projects using Abyss
• Status: Active — Q1 focus
• Dean's role: Overseeing delivery of theming capabilities and support
• Decision: White-label themes housed in a separate repo (not in core Abyss) for lower maintenance, faster releases, and more customer autonomy
• Priority: Medium-high

Abyss Dashboard (Usage & Adoption Intelligence)

• What: Dashboard to gain increased intelligence on Abyss usage and adoption across the enterprise
• Status: Active — Q1 goal
• Dean's role: Driving the effort to increase visibility into adoption metrics
• Priority: Medium-high

04-team-and-relationships.md

Team & Relationships

Ari

• Role: Dean's manager
• Relationship: Direct manager
• Context: Senior developers on the mobile and web squads report to Ari, not Dean. Dean's junior devs report to Dean.

Tony

• Role: Web squad lead
• Relationship: Key collaborator / squad lead under Dean's purview
• Interaction: Online channels, regular syncs

Michael

• Role: Mobile squad lead
• Relationship: Key collaborator / squad lead under Dean's purview
• Interaction: Online channels, regular syncs

Grace

• Role: Product team
• Relationship: Key collaborator
• Interaction: Cross-functional collaboration on Abyss priorities

Steve

• Role: Product team
• Relationship: Key collaborator
• Interaction: Cross-functional collaboration on Abyss priorities

Joel

• Role: Scrum Master
• Relationship: Key collaborator
• Interaction: Facilitates sprint ceremonies and process for the squads

5 Junior Developers (names TBD)

• Role: Developers across mobile and web squads
• Relationship: Dean's direct reports
• Interaction: Weekly 1:1s with each, async communication in online channels

Offshore Team Members

• Role: Part of the broader dev team
• Relationship: Team members Dean works with
• Context: Dean is actively working to get onshore and offshore functioning well together

05-tools-and-systems.md

Tools & Systems

Design

• Figma — primary design tool for the Abyss design system; moving toward leveraging native Figma features like extended collections to reduce dependency on third-party plugins
• FigJam — collaborative whiteboarding and documentation
• Tokens Studio — third-party Figma plugin currently in use; goal is to eliminate the requirement for users to use it by leveraging native Figma capabilities instead

Development

• TypeScript — primary language
• React — web front-end framework
• React Native — mobile front-end framework
• GitHub — code repositories and CI/CD pipelines

Design Tokens

• DTCG (Design Token Community Group) — token format standard; actively deciding which dialect to use as the interface contract for Grayscale

Project Management

• Rally — ticketing and work tracking

Documentation & Collaboration

• SharePoint — document storage and collaboration
• Loop — documentation and collaborative notes
• FigJam — visual collaboration and documentation

AI Tools

• Microsoft Copilot — enterprise AI assistant
• GitHub Copilot — AI code completion/assistance
• Windsurf — AI-powered development environment

06-communication-style.md

Communication Style

Overall Approach

• Strives for a full and unbiased view — lays bare tradeoffs rather than advocating for one side
• Clarifies what something is and for whom — audience and scope are always explicit
• Direct and factual, with a bit of wit and analogy mixed in
• No flowery or theoretical language
• Everything should be substantiatable — no conjecture or fluff
• Uses factual terms and definitions
• Efficient with words — provides dense, structured information quickly

What He Avoids

• Flowery language
• Theoretical or abstract framing
• Conjecture or unsubstantiated claims
• Fluff or filler

Distinctive Patterns

• Analogy as a clarifying tool (not decoration)
• Wit as seasoning, not the main course
• Tradeoff-oriented framing — presenting both sides clearly
• Precise definitions over vague terms
• Moves fast — doesn't belabor points; says what needs saying and moves on

07-goals-and-priorities.md

Goals & Priorities

Q1 Goals

• Ship AI skills to Abyss users for more effective use of the design system
• Increase team velocity through AI tool adoption
• Adapt Abyss to changes from the Grayscale project (Figma reorganization)
• Help user teams style and theme their projects with Abyss
• Deploy increased tooling for UX Ops for Design and Consumers
• Gain increased usage and adoption intelligence via the Abyss Dashboard

Key Success Metrics

• Degree of v2 enterprise adoption — how broadly the latest version of Abyss is being adopted across the enterprise
• Team and developer cycle time — speed from work start to delivery
• Consistency and growth of AI usage — tracking that AI tool adoption is sustained and increasing, not just tried once
• Test coverage — measurable code quality improvement

End of 2026 Vision

• Dev team: Agents are the primary way of coding
• Design team: Making more visual components and implementing a reuse marketplace
• Doc site: Co-owned or mostly owned by design (shifting ownership)
• Figma efficiency: Leveraging the most efficient native Figma features (e.g., extended collections) and eliminating the need for users to rely on third-party plugins like Tokens Studio
• Team cohesion: Onshore and offshore team functioning well together
• Direct reports: Every one of Dean's 5 junior devs has spearheaded a project with their name on it
• Personal growth: Dean is recognized as a senior engineering leader, not just a dev-turned-people-manager

Career / Advancement Goals

• Salary grade change to 29
• Leaders underneath him have grown into stronger leadership roles
• Has an architectural aspect to his role — not just personnel management
• Less time reading code after-the-fact, more time on upfront architecture and success criteria
• Can demonstrate improvement metrics attributable to his and his team's work — proof of impact, not just narrative

Tradeoff Thinking

• Favors lower maintenance cost over control
• Prioritizes customer autonomy and faster release cadence
• Prefers defining interface contracts to absorb less upstream churn
• Thinks in terms of constraining scope to deliver iterative value

08-preferences-and-constraints.md

Preferences & Constraints

Communication Preferences

• Direct communication — no beating around the bush
• Accurate descriptions, not flowery ones
• Substance over style in all written output
• Efficient — doesn't want to repeat himself or belabor points

AI Output Preferences

• Factual, substantiatable content — no conjecture
• Tradeoff-oriented framing when presenting options
• No fluff, no filler, no generic corporate language
• Don't over-explain concepts Dean already knows (design systems, front-end engineering, React/RN/TS, Figma workflows, DTCG)

Working Constraints

• Team includes offshore members — timezone coordination is a factor

09-domain-knowledge.md

Domain Knowledge

Areas of Expertise

• Front-end engineering (mobile and web)
• Design systems at enterprise scale (specifically the Abyss design system)
• Software engineering management
• Enterprise software within healthcare/insurance (UHG/Optum context)
• Managing junior developers and growing talent
• TypeScript, React, React Native
• Figma-based design-to-development workflows
• Theming and styling architecture for design systems
• Interface contract design — defining boundaries between systems to minimize coupling and breaking changes
• Cross-functional sequencing of large projects across design and engineering
• Design tokens — DTCG format, token naming, file structure decisions
• Figma features and plugin ecosystem (Tokens Studio, extended collections)

Emerging / Growing Areas

• AI integration into design systems and front-end tooling
• AI "skills" — building AI-powered capabilities for design system consumers
• AI for developer experience and end-user workflows
• AI-assisted coding tools (GitHub Copilot, Windsurf, Microsoft Copilot)
• Agentic coding — moving toward agents as primary coding method
• Usage/adoption analytics for enterprise design systems
• Reuse marketplace concepts for design components

Key Terminology

• Abyss — the enterprise design system Dean's team owns
• Grayscale — a large Figma file reorganization project that Abyss must adapt to; Dean's team is constraining its impact by defining the interface Grayscale must conform to
• AI skills — AI capabilities shipped to design system users
• White-label themes — theming support for consuming teams, housed separately from core Abyss
• DTCG — Design Token Community Group; the token format standard in play
• Extended collections — native Figma feature that can replace some third-party plugin functionality
• Tokens Studio — third-party Figma plugin; goal is to eliminate dependency on it

10-decision-log.md

Decision Log

Decision-Making Approach

• Tradeoff-oriented — weighs maintenance cost, release velocity, and customer autonomy explicitly
• Favors solutions that reduce coupling and increase independence for consuming teams
• Thinks about interface boundaries as a control mechanism — define the contract, let others conform to it
• Moves quickly — provides the relevant facts and the call, doesn't dwell
• Values demonstrable metrics over narrative claims — wants proof of impact, not just narrative
• Key metrics he tracks: v2 enterprise adoption, team/developer cycle time, consistency and growth of AI usage, test coverage

Decision: House white-label themes outside of the Abyss repo

• What: White-label theming support for consuming teams will live in a separate repository, not inside the core Abyss design system repo
• Alternative considered: Keeping themes in the Abyss repo
• Why the alternative lost: Increased maintenance costs, slower release cadence, and less customer autonomy
• Why separate repo won: Lower maintenance burden on the core team, faster release cycles for both Abyss and themes, and consuming teams get more control over their own theming

Decision: Constrain Grayscale's downstream impact via interface specification

• What: Rather than absorbing Grayscale's changes reactively, define the interface contract that Grayscale must conform to
• Interface specifics: Primarily token names and file structure — which dialect of DTCG. Also process guidance for teams to create those files with least friction.
• Why: Minimizes breaking changes for Abyss consumers; keeps Abyss in control of its own boundaries rather than being at the mercy of upstream reorganization
• Status: In progress — actively defining the interface and sequencing phases

Decision: Eliminate Tokens Studio dependency

• What: Move away from requiring users to use the third-party Figma plugin Tokens Studio
• Why: Native Figma features (e.g., extended collections) can cover the same needs with less friction and no third-party dependency
• Status: Part of the 2026 vision

Decision: Shift personal time allocation toward architecture

• What: Deliberately moving away from after-the-fact code review toward upfront architecture and success criteria
• Why: Aligns with growth into senior engineering leadership (grade 29); more leverage through architectural decisions than code-level review; enables direct reports to own more of the execution

README.md

Your Personal Context Portfolio

This is your personal context portfolio — a set of structured markdown files that represent who you are, how you work, and what matters to you.

Any AI system, agent, or tool can read these files and immediately understand what it's working with.

Files

• Identity — The minimum viable context file. If an agent could only read one file, this is it.
• Role & Responsibilities — An operational description of the user's work. Not what their job description says — what their weeks actually look like.
• Current Projects — Active workstreams, their status, and what matters about each one.
• Team & Relationships — The key people in the user's work life and how they interact with each.
• Tools & Systems — What the user uses, how it's set up, and what connects to what.
• Communication Style — How the user communicates so any agent producing content on their behalf sounds like them.
• Goals & Priorities — What the user is optimizing for so agents can weight decisions and recommendations appropriately.
• Preferences & Constraints — The "always do this / never do that" file. Hard rules and strong preferences any agent should respect.
• Domain Knowledge — What the user knows that a general-purpose AI doesn't — so agents don't over-explain familiar concepts or miss industry-specific context.
• Decision Log — How the user makes decisions, with examples, so agents can support future decisions in a way that matches their thinking style.

How to Use

• Drop them into a Claude Project as project knowledge
• Add them to your system prompts
• Expose them as an MCP resource
• Hand them to any agent you build

These are living documents. Update them as your work evolves.