sourceharbor

Build With SourceHarbor

SourceHarbor is the builder side of the same control tower.

It already exposes six real builder-facing layers:

  1. HTTP API contract for system integrations
  2. MCP surface for agent clients such as Codex, GitHub Copilot, Claude Code, and VS Code agent workflows
  3. Packaged public CLI for installable command discovery
  4. Repo-local CLI/help facade as the underlying direct substrate
  5. Public TypeScript SDK for typed HTTP reuse
  6. Public starter packs for reproducible Codex / GitHub Copilot / Claude Code / VS Code agent / SDK setup, plus a first-cut OpenClaw local pack

It now also exposes a seventh adoption layer:

The safest way to read this page is:

Product door Builder meaning Current truth
/subscriptions intake contract over one shared template catalog Web, API, and MCP now all point at the same strong-supported vs generalized intake split
/watchlists durable tracking-object substrate builders can treat watchlists as saved operator intent, not a temporary browser filter
/trends compounder front door repeated runs become merged stories and evidence surfaces instead of one-off search sessions
/briefings + /ask story-aware answer/change/evidence lane the same server-owned story payload now carries selected-story context into Ask
/mcp agent-facing reuse doorway assistants reuse the same jobs, retrieval, artifacts, and operator truth instead of a second business-logic stack

Skill Applicability Matrix

Use this before you describe SourceHarbor as a “skill” anything:

Surface Skill-repo criteria apply? Honest wording
Whole repository No multi-surface product repo with Web, API, MCP, runtime, CLI, SDK, and starter surfaces
starter-packs/** Yes, mostly public starter-pack and public-skill adoption layer
plugin-grade bundle directories Yes, strongly submission-ready or template-ready distribution artifacts
templates/public-skills/** Yes, partially copyable public prompt/template assets referenced by starter packs
internal .agents/skills/** No for public use internal operating surface, not a public export

If a newcomer only reads the builder docs, the safe takeaway should be:

Best-Fit Clients Today

Surface Best fit today Why
Codex Primary fit SourceHarbor already exposes a real MCP server plus operator-safe HTTP contracts
GitHub Copilot Primary fit It can reuse the same MCP and HTTP truth, and the repo now ships a real source-installable plugin bundle
Claude Code Primary fit Same MCP surface, same API-backed state, same retrieval and job evidence
VS Code agent workflows Primary fit They can reuse the same MCP and HTTP truth, and the repo now ships a real source-installable plugin bundle
Repo-local CLI users Primary fit ./bin/sourceharbor help gives one discoverable facade over the real bin/* entrypoints without duplicating business logic
Custom MCP clients Primary fit ./bin/dev-mcp starts a real FastMCP server over the current pipeline
Direct HTTP builders Primary fit The repo already carries a public OpenAPI contract and typed client helpers
OpenHands / OpenCode Secondary fit They are ecosystem-adjacent if you integrate through MCP or HTTP, but they are not the main front door today
OpenClaw First-cut local pack fit the repo now ships a local OpenClaw starter pack over the generic MCP / HTTP substrate, but it still is not a primary front-door label or marketplace claim

Builder Entry Points

1. HTTP API

Representative routes:

2. MCP

Representative tools:

3. Packaged Public CLI

If you want one installable command surface first:

npm install --global ./packages/sourceharbor-cli
cd /path/to/sourceharbor
sourceharbor help
sourceharbor mcp

Current truth:

4. Repo-Local CLI Substrate

These remain the direct command truth:

The packaged CLI above does not replace this substrate. It only makes it easier to discover and reuse.

5. Public TypeScript SDK

If you want a public, typed HTTP client first:

npm install ./packages/sourceharbor-sdk

Package path:

Current truth:

6. Public Starter Packs

If you want public templates instead of internal raw skills:

7. Plugin-Grade Bundles And Official-Surface Templates

If you need artifacts closer to public distribution than a starter README, open:

Current truth:

Container Truth For Builders

Do not treat every container surface as builder distribution:

Surface Purpose Builder-facing claim
infra/compose/core-services.compose.yml repo-local core runtime helpers local boot aid only
.devcontainer/devcontainer.json contributor workspace parity development environment only
ghcr.io/xiaojiou176-open/sourceharbor-api dedicated API image route product-facing API container lane; the product package now reads back as visibility: public, but it still stays a separate API-image builder surface rather than the default install story
ghcr.io/xiaojiou176-open/sourceharbor-ci-standard strict CI and devcontainer parity image infrastructure image, not newcomer-facing product container distribution

The actual newcomer-facing builder surfaces are MCP, HTTP API, packaged CLI, TypeScript SDK, starter packs, and plugin-grade bundles.

Distribution Rule

Keep the shipping language simple:

If you need the full shipping ledger, read docs/public-distribution.md.

What stays no-go this wave:

If you want the bucketed decision ledger instead of the packaging sequence, read docs/reference/ecosystem-and-big-bet-decisions.md.

Risk Boundaries

These are intentionally not opened in the current builder story:

If you need the public proof boundary before integrating, read docs/proof.md.

This site is open source. Improve this page.