multi-repo-workflow

Coordinate cross-repo changes and deployments across microservice repositories.

4|1|Updated Mar 15, 2026
One-click install
npx skills add https://github.com/FaysilAlshareef/dotnet-ai-kit --skill multi-repo-workflow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: multi-repo-workflow
Source: https://github.com/FaysilAlshareef/dotnet-ai-kit/tree/main/skills/workflow/multi-repo-workflow
Command: npx skills add https://github.com/FaysilAlshareef/dotnet-ai-kit --skill multi-repo-workflow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Coordinating feature work, contract changes, and deployments across multiple microservice repositories can lead to broken contracts, inconsistent branches, and deployment order failures; this Skill provides patterns and rules to synchronize cross-repo changes and deployments.

Core Features & Use Cases

  • Shared contract coordination: Update and propagate proto files and event types from a centralized shared-contracts repo before implementing service changes.
  • Dependency-ordered implementation: Follow a prescribed repo-by-repo order (shared-contracts → command → query → processor → gateway → controlpanel) to avoid runtime mismatches.
  • Coordinated branches and PRs: Enforce consistent feature branch names across repos, generate idempotent feature briefs for secondary repos, and auto-commit briefs when safe.
  • Deployment guidance & checks: Provide rollout order examples and repository readiness checks to reduce deployment-related regressions.

Quick Start

Use this skill to create a coordinated feature brief, branch plan, and deployment checklist to implement a new cross-repo feature that touches shared-contracts, command, query, and gateway repositories.

Frequently Asked Questions about multi-repo-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I coordinate proto contract updates across multiple microservice repositories?

To coordinate proto contract updates across multiple microservice repositories, propagate changes from a centralized shared-contracts repo first, then implement service changes in a dependency-ordered sequence to avoid runtime mismatches.

What is the correct deployment sequence for cross-repo microservice features?

The correct deployment sequence for cross-repo microservice features follows a dependency-ordered rollout: shared-contracts first, then command, query, processor, gateway, and controlpanel to prevent deployment failures and broken contracts.

How do I enforce consistent branch naming for coordinated PRs across separate microservice repos?

Enforce consistent branch naming for coordinated PRs across separate microservice repos by applying standardized feature branch names and generating idempotent feature briefs for secondary repositories before auto-committing when safe.

Can I automate feature brief projection for secondary repos during cross-repo changes?

Yes, you can automate feature brief projection for secondary repos during cross-repo changes by performing repository readiness checks first, then auto-committing idempotent briefs only when those repositories are verified as safe.

How do I avoid merge chaos when shipping features that touch shared-contracts, command, and gateway repositories?

Avoid merge chaos when shipping features across shared-contracts, command, and gateway repositories by synchronizing shared contracts first, enforcing consistent branch names, and following the prescribed dependency-ordered implementation and deployment sequence.

What are the limitations of dependency-ordered deployments for multi-repo microservices?

Dependency-ordered deployments for multi-repo microservices require strict sequencing from shared-contracts through controlpanel; bypassing this order or failing repository readiness checks risks broken contracts, inconsistent branches, and deployment-related regressions.