[Extension]: Add multi-repo

Read the extension catalog schema and existing extension entries, then check how submissions are validated. Add the proposed multi-repo entry using the supplied manifest details and verify it passes the catalog checks. Done when the catalog recognizes the extension and its download and repository URLs match the submission.

Extension ID

multi-repo

Extension Name

Multi-Repo Workspace Orchestration

Version

0.7.1

Description

Orchestrate spec-driven implementation across a workspace: a central specs repository dispatches implementation to member repositories

Author

Joao Victor

Repository URL

https://github.com/joaopaschuino/speckit-multirepo

Download URL

https://github.com/joaopaschuino/speckit-multirepo/archive/refs/tags/v0.7.1.zip

License

MIT

Homepage (optional)

https://github.com/joaopaschuino/speckit-multirepo

Documentation URL (optional)

https://github.com/joaopaschuino/speckit-multirepo/blob/main/README.md

Changelog URL (optional)

https://github.com/joaopaschuino/speckit-multirepo/blob/main/CHANGELOG.md

Required Spec Kit Version

=1.1.0

Required Tools (optional)

No response

Number of Commands

5

Number of Hooks (optional)

1

Tags

multi-repo,orchestration,workspace,specs,spec-driven-development,dependency-graph

Key Features

• Central/member topology — a central specs repository dispatches implementation to member repositories; all feature state lives in the central repo, member PRs are pure implementation diffs
• Dependency-wave dispatch — execution order computed from the depends_on graph in workspace.yml, with per-wave parallelism (max_concurrency)
• Objective verification — ## Verification commands run by exit code in the member repo (not the agent's self-report), with verify_retries and automatic feedback
• Cross-repo contract checks — verification-only members validate contracts between producers and consumers after the producers' wave
• Layered governance bundles — workspace, type, and local constitutions assembled into a bundle per dispatch; the most restrictive rule wins
• Resume & partial workspaces — workflow resume after failure, skip_completed skips finished members, missing: skip tolerates non-cloned members, ready: false holds members back
• Domain topology mapping — /speckit.multi-repo.domain infers domain/communicates_with by scanning member repos and generates a Mermaid diagram
• Workspace doctor — multi-repo-check dry-run reports each member's readiness without dispatching anything
• Timeouts & safety — dispatch_timeout with a watchdog that kills the agent's process tree; review gates keep a human in the loop
• Zero core changes — uses only stable Spec Kit extension surfaces (commands, hooks, custom step, workflows)

Testing Checklist

• Extension installs successfully via download URL
• All commands execute without errors
• Documentation is complete and accurate
• No security vulnerabilities identified
• Tested on at least one real project

Submission Requirements

• Valid extension.yml manifest included
• README.md with installation and usage instructions
• LICENSE file included
• GitHub release created with version tag
• All command files exist and are properly formatted
• Extension ID follows naming conventions (lowercase-with-hyphens)

Testing Details

Automated pytest suite in tests/ (5 files). Unit tests cover the step's dispatch logic, wave ordering, governance bundles, verification/retry, and config validation via a FakeIntegration stub. E2E tests exercise the real specify CLI (extension add, workflow step add, workflow run/resume) against a fake agent executable, covering install, dispatch, resume-after-failure, verification retries, timeout watchdog, and contract-check members. Run with uv sync --extra test && .venv/bin/python -m pytest tests/.

Example Usage

Setup — central specs repo + member repos (e.g. repo-s3, repo-lambda as siblings):

# in each member repo  
specify extension add multi-repo --from https://github.com/joaopaschuino/speckit-multirepo/archive/refs/tags/v0.7.1.zip  
  
# in the central repo (extension + step + workflows)  
specify extension add multi-repo --from https://github.com/joaopaschuino/speckit-multirepo/archive/refs/tags/v0.7.1.zip  

specify workflow step add multi-repo-implement --from https://github.com/joaopaschuino/speckit-multirepo/releases/download/v0.7.1/step-multi-repo-implement-v0.7.1.zip  

specify workflow add multi-repo --from https://raw.githubusercontent.com/joaopaschuino/speckit-multirepo/v0.7.1/workflow/multi-repo/workflow.yml  

specify workflow add multi-repo-check --from https://raw.githubusercontent.com/joaopaschuino/speckit-multirepo/v0.7.1/workflow/multi-repo-check/workflow.yml  

.specify/workspace.yml in the central repo — generate it with /speckit.multi-repo.workspace, which discovers the member repositories, or write it manually:

schema_version: "1.0"  
workspace:  
  id: my-platform  
members:  
  - id: s3  
    path: ../repo-s3  
  - id: lambda  
    path: ../repo-lambda  
    depends_on: [s3]  

Feature flow (in the central repo):

/speckit.specify <description>  
/speckit.plan <description>  
/speckit.tasks <description>  
/speckit.multi-repo.tasks        # splits tasks.md into tasks/s3.md, tasks/lambda.md  
  
specify workflow run multi-repo -i feature=specs/001-my-feature  
# → wave 1 dispatches s3, wave 2 dispatches lambda  
# → each member's ## Verification commands run by exit code  
# → review gate shows verification/report.md  
  
# a member failed? fix it, then:  
specify workflow resume <run-id>  

Dry-run / doctor (nothing dispatched):

specify workflow run multi-repo-check --json | jq '.step_results.check.output.members'  

Proposed Catalog Entry

{  
  "schema_version": "1.0",  
  "extensions": {  
    "multi-repo": {  
      "name": "Multi-Repo Workspace Orchestration",  
      "version": "0.7.1",  
      "download_url": "https://github.com/joaopaschuino/speckit-multirepo/archive/refs/tags/v0.7.1.zip",  
      "repository": "https://github.com/joaopaschuino/speckit-multirepo",  
      "description": "Orchestrate spec-driven implementation across a workspace: a central specs repository dispatches implementation to member repositories",  
      "author": "Joao Victor",  
      "license": "MIT",  
      "homepage": "https://github.com/joaopaschuino/speckit-multirepo",  
      "changelog": "https://github.com/joaopaschuino/speckit-multirepo/blob/main/CHANGELOG.md",  
      "requires": {  
        "speckit_version": ">=1.1.0"  
      },  
      "provides": {  
        "commands": 5,  
        "hooks": 1  
      },  
      "tags": [  
        "multi-repo",  
        "orchestration",  
        "workspace",  
        "specs",  
        "spec-driven-development",  
        "dependency-graph"  
      ],  
      "created_at": "2026-11-12T00:00:00Z",  
      "updated_at": "2026-11-12T00:00:00Z",  
      "releases": {  
        "0.7.1": {  
          "download_url": "https://github.com/joaopaschuino/speckit-multirepo/archive/refs/tags/v0.7.1.zip",  
          "released_at": "2026-11-12T00:00:00Z"  
        }  
      }  
    }  
  }  
}  

Additional Context

The extension installs from the tag source archive (contains extension.yml, commands/, scripts/, and hooks at the root). The step-multi-repo-implement-v0.7.1.zip release asset is a separate package used only by specify workflow step add --from, which expects step.yml at the archive root — both install paths are documented in the README.