Jan Benjamin Yap

Procter & Gamble · Internship · 2026

A proof of concept for agentic development at SK‑II, built on a cross‑repo context pipeline

Every feature touched four codebases, so the workflow itself was the bottleneck. I built a cross-repo context pipeline to coordinate those changes, and shipping a feature went from a week to a day.

Role
SK-II Software Engineering Intern
Stack
BMAD, Context engineering, Cross-repo architecture, Azure DevOps, Full SDLC

One feature through the context pipeline

FeatureTouches all 4 repos

Ordering stepPicks which repo changes first

  1. Story 01 · Code + testsMicroservice

    Context docMicroservice

  2. Story 02 · Code + testsCommon

    Context docCommon

  3. Story 03 · Code + testsParent

    Context docParent

  4. Integration check · Azure DevOpsMock environmentApplication and all 3 repos together

ShippedOnce it all worked together

Each story file runs with its repo’s context doc loaded and ships with its own tests, so the agent works in one codebase at a time and follows the patterns already in it. The microservice goes first, and everything is deployed together to the mock environment through Azure DevOps.
7×
faster shipping
1 day
per feature, from 1 week
4
codebases

During my three-month internship at P&G, I built the proof of concept for agentic development on SK-II's Super-Powered Assistant. I architected a cross-repo context pipeline on my own, used it to build two core features across the full SDLC, and shipped a feature the team usually estimated at a week in one day.

The brief was open: deliver a proof of concept for agentic development with BMAD, either by building an app from scratch or by working in the existing codebase. The harness I was given had no vision, so I had to describe every layout to the agent in text, which made building UI slow. Starting from scratch wasn't an option for what the business needed, so I worked in the existing codebase.

Four repos for every change

The features I worked on lived in one microservice, but a change to it never stayed there. It also needed changes in the application, a parent repository and a common repository, and each of them had to accept those changes in the right order.

Everything was locked into everything else. You couldn't make an easy UI change without connecting all four repos together, and even mocking data meant changes in all four. Running it locally wasn't possible with how tightly it was coupled, so the only place to see everything work together was the mock environment I was given. On top of that, the repos were all Java but ran different framework versions, so the agent couldn't carry what worked in one repo into the next.

Writing the code was never the slow part. Moving a change through four repos was.

Building the context pipeline

The proof of concept was new work, so there was no existing setup to follow and no one telling me how to build one. I designed the pipeline myself and built it with BMAD in three parts. First, a context doc for each repo that captured the design patterns and conventions it actually used. Second, an ordering step that worked out which repository had to accept a feature's changes first and sequenced the rest from there. Third, story files that broke the feature into changes per repo, in that order, so the agent worked through one repo at a time with the right context loaded.

For my features, that order started in the microservice, then went to the common repository and then the parent, and every repo got new tests along the way. Last, I deployed the changes through Azure DevOps to the mock environment and checked that everything, the application included, worked together.

With the pipeline in place, I built two core features end to end, and a feature the team usually estimated at a week shipped in a day.