Athlentic maintains separate Git repositories for iOS, Android, and Web. That separation makes releases and history clear, but creates a problem for AI agents: an agent opened inside the iOS repository cannot see a policy already implemented on Android, product copy from the website, or the plan for the next release.
Our solution is deliberately simple. Instead of merging repositories, we place a product-level workspace above them.
Start one level above the repositories
Create an Athlentic directory at the root and place both shared documents and platform repositories inside it.
Each platform directory still owns its own .git. The parent workspace tracks product-level documents and rules, while code is committed and released independently within each platform repository.
Keep platform code out of the parent Git repository
We also initialize Git in the parent Athlentic directory, then ignore the platform folders. This preserves the history of plans without accidentally tracking nested repositories.
If the parent repository must pin exact platform commits, submodules are a better fit. Our goal is simply to expose local context while keeping repositories independent, so ignored sibling repositories are enough.
Open only the root folder for the AI agent
Set the AI agent's workspace to the Athlentic root instead of an individual repository. The agent can then inspect the shared plan and all three implementations before it starts.
- It can translate a feature already implemented on Android into native iOS patterns.
- It can find inconsistencies between website copy and in-app language.
- It can assess how a shared model change affects every platform.
- It can break down a product-level plan into repository-specific work.
A request such as “plan workout export and implement iOS first” can now lead the agent to write a plan under docs/plans, inspect Android's existing model and the website's privacy copy, then make scoped changes in the iOS repository.
Plans become the agent's long-term memory
Co-location alone is not enough. Product context needs to be written down so the agent does not repeat the same reasoning in every session.
AGENTS.md,CLAUDE.mddefines build commands, conventions, and repository boundaries.docs/plansrecords goals, scope, and completion criteria.docs/architectureexplains shared concepts and data flows.docs/decisionscaptures why a decision was made, not only what was chosen.
These files survive a new conversation. Context that once lived only in chat becomes a reviewable asset: onboarding material for people and long-term memory for AI.
The benefit—and the boundary
The biggest benefit is that the agent starts thinking in terms of the product, not a single file. It checks other platforms before duplicating an implementation and reads the plan before changing code.
A broad workspace still needs a narrow change boundary. Seeing every repository does not mean the agent should edit every repository. State the target repository and completion criteria, and require separate Git status checks for each repository.
“Read context from the whole product; make changes only in the requested repository.” It preserves the advantage of a broad workspace while reducing surprises.
Closing thought
Working effectively with AI agents turned out to be less about writing longer prompts and more about designing a workspace where the right information is discoverable. Persisting plans and decisions as files made an even larger difference.
If one product spans several platforms, try creating a lightweight product workspace above the repositories before merging them. It gives both people and AI a map of the whole product.