cross-repo-change

Coordinate contract changes across the aweb OSS repo and the hosted ac repository.

82|9|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/awebai/aweb --skill cross-repo-change-awebai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cross-repo-change
Source: https://github.com/awebai/aweb/tree/main/.claude/skills/cross-repo-change
Command: npx skills add https://github.com/awebai/aweb --skill cross-repo-change-awebai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Changes that span the aweb open-source repo and the hosted ac SaaS repo can break deployed clients if released in the wrong order or with incompatible contract shapes. This Skill enforces a safe sequencing and compatibility discipline so cross-repo changes ship without breaking published clients. ## Core Features & Use Cases - Release sequencing: Enforces the OSS-first order — land on aweb main, release the package, pin exact versions in ac, then land the cloud change. - Contract shippability rules: Distinguishes the atomic aweb ↔ ac deploy boundary from published clients (CLI, channel plugin, self-hosted servers) that require additive-only, backward-compatible changes. - Schema mirror tracking: Ensures OSS migrations from both awid and server migration trees are mirrored into the cloud's own migration directories. - Use Case: When changing an API field accepted by the aweb server, use this Skill to determine whether you may narrow the contract, which repo lands first, and which migration mirrors are required before merge. ## Quick Start Ask the agent to plan a cross-repo change that modifies an aweb API contract and have it produce the ordered release steps and required migration mirrors.

Frequently Asked Questions about cross-repo-change

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

FAQPage Schema
How do I coordinate a change across two repositories that share a dependency?

Land the change in the upstream OSS repo first, release the package, then pin the exact published version in the downstream repo before landing its source change. Never land the downstream change before the upstream release is public, or CI will fail on import errors.

When can I make a breaking change to an API contract?

Only when you can name every consumer and show each deploys atomically with the change in the same image. For published clients like CLIs or self-hosted servers, you must stay additive-only and remove old shapes only after measuring that nothing sends them.

Why should I verify compatibility against published artifacts instead of source?

Your local source and the published client often disagree, and that disagreement is the deployment risk. Check the released tarball or tag to confirm what is actually deployed before merging a contract change.

How do I mirror database migrations between two repositories?

Copy each OSS migration as a one-statement ALTER or CREATE into the downstream repo's migration directory with a header comment naming the OSS source path. Grep all OSS migration trees touched in the bundle, since mirrors can come from multiple source directories.

Should I accept both old and new API formats during a transition?

Only when consumers deploy independently, such as published clients or self-hosted servers — then accept both and prefer the new. When both sides deploy atomically in one image, pick a single format instead.