菜单
Use when coordinating changes across multiple repositories — syncing skills, templates, agents, or harness policies between upstream and downstream repos, or designing portfolio-level agent orchestration
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Habitat-Thinking/ai-literacy-superpowers --skill cross-repo-orchestration命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Use when acting as the adversarial spec reviewer — raises steel-manned objections across six categories before plan approval, requires evidence per objection, and discloses what was not challenged
Use when designing, reviewing, or classifying an agent that guards the human — defines the sentinel category, the three-part signature (S1 read-only, S2 advisory-to-human, S3 explicit honesty rule), the near-miss gallery that explains why read-only-plus-advisory is not sufficient, the honesty-rule-before-detection-logic discipline, and the three anti-patterns that eject an agent from the category
This skill should be used when the user asks to "assess AI literacy", "run an assessment", "check literacy level", "evaluate our AI collaboration", "where are we on the framework", or wants to determine their team's AI literacy level using the ALCI instrument.
| name | cross-repo-orchestration |
| description | Use when coordinating changes across multiple repositories — syncing skills, templates, agents, or harness policies between upstream and downstream repos, or designing portfolio-level agent orchestration |
When a project spans multiple repositories, the practices that work within a single repo — specification-driven development, harness enforcement, compound learning — must extend across repo boundaries. This skill teaches two patterns for cross-repo coordination, each suited to a different maturity level.
This skill does not cover single-repo agent orchestration (see the orchestrator agent), CI/CD pipeline design, or monorepo tooling.
For worked examples and the sync workflow, consult
references/sync-patterns.md.
| Situation | Pattern |
|---|---|
| Syncing skills, templates, or hooks from a framework repo to a plugin repo | L4: Git-mediated |
| Propagating harness changes to downstream consumers | L4: Git-mediated |
| Rolling out a new convention across 2-5 related repos | L4: Git-mediated |
| Managing shared standards across 10+ repos in a portfolio | L5: Specification-mediated |
| Aggregating health snapshots across an organisation | L5: Specification-mediated |
| Designing platform-level harness policies | L5: Specification-mediated |
A single agent (or human) applies changes from an upstream repo to one or more downstream repos using git's standard workflow.
Not everything should flow downstream. Define clear boundaries:
| Sync | Don't sync |
|---|---|
| Skills (tool-agnostic knowledge) | HARNESS.md (project-specific constraints) |
| Agent definitions (pipeline patterns) | AGENTS.md (project-specific learnings) |
| Hook scripts and hooks.json | REFLECTION_LOG.md (project-specific reflections) |
| Templates (starting points) | Specs and plans (project-specific features) |
| CI workflow templates | Project source code |
Document what the upstream repo exports in its README or a dedicated manifest section. At minimum, state:
| Anti-pattern | Problem | Fix |
|---|---|---|
| Sync without contracts | Nobody knows what should flow where | Declare exports in README or manifest |
| Bidirectional sync | Changes flow both ways, causing conflicts | Pick one direction — upstream is authoritative |
| Sync everything | Downstream repos lose their identity | Only sync what's declared as exported |
| Manual ad-hoc copies | Drift accumulates silently | Use a documented sync command or workflow |
| Sync without CI | Broken changes propagate downstream | Every sync goes through a PR with CI checks |
At organisational scale, git-mediated sync becomes unwieldy. Repos declare their dependencies through specification manifests, and a platform orchestrator resolves and propagates changes.
Each repo declares what it exports and imports:
# .repo-manifest.yml (sketch — not yet a formal standard)
name: ai-literacy-superpowers
version: 0.1.0
exports:
skills:
- literate-programming
- cupid-code-review
- harness-engineering
- convention-extraction
- cross-repo-orchestration
agents:
- orchestrator
- code-reviewer
- integration-agent
hooks:
- constraint-gate
- drift-check
- snapshot-staleness
imports: [] # This is a root/platform repo — it imports nothing
A downstream repo declares what it consumes:
name: ai-literacy-exemplar
version: 0.1.0
exports:
agents:
- go-implementer # project-specific, not imported
imports:
- source: ai-literacy-superpowers
version: ">=0.1.0"
artefacts:
- skills/*
- hooks/*
When the platform repo changes a harness policy (e.g. raises the mutation testing threshold), downstream repos that import that policy inherit the change through their manifest contract. The platform orchestrator:
Health snapshots aggregate across the portfolio:
Portfolio Health — 2026-04-01
Repos: 12
At L3+: 9 (75%)
Below threshold: 3 (api-gateway, legacy-auth, billing-service)
Enforcement average: 84%
Mutation score average: 76%
Repos with stale snapshots: 1 (legacy-auth, 45 days)
This extends the single-repo harness observability pattern to organisational scale.
| Factor | Git-Mediated (L4) | Specification-Mediated (L5) |
|---|---|---|
| Number of repos | 2-5 | 10+ |
| Sync frequency | After specific changes | Continuous/automated |
| Coordination | Single agent or human | Platform orchestrator |
| Contract format | README documentation | Formal manifest files |
| Portfolio visibility | Per-repo snapshots | Aggregated dashboard |
| Team maturity needed | L4 (spec-first workflow) | L5 (platform engineering) |
Start with git-mediated. Graduate to specification-mediated when the portfolio grows beyond what a single agent can manage.