Connector context repository
Create one Git repository for content synchronized from Confluence, Slack, Linear, Notion, and other ctxpipe connectors.
ctxpipe is Git-native. Source connectors mirror approved content into a GitHub repository you control before ctxpipe indexes it. We recommend using one dedicated repository as the shared home for this connector-generated context.
For most organizations, name it ctxpipe-context and reuse it whenever you
add another connector.
Why use one repository?
- You grant the ctxpipe GitHub App access once.
- Connector content has one visible Git history and review surface.
- New connectors can reuse the repository instead of repeating setup.
- Generated content remains separate from application source code.
Each connector owns its own path, so their files do not overlap. For example:
ctxpipe-context/
├── confluence/
│ ├── config.yaml
│ └── ...
├── notion/
│ ├── config.yaml
│ ├── pages/
│ └── databases/
├── linear/
│ └── config.yaml
└── slack/
└── channels/Create the repository
Create ctxpipe-context
Create the recommended repository on GitHub. Choose the GitHub owner used by your ctxpipe organization and a visibility appropriate for the source material. Most teams should use a private repository.
Grant GitHub App access
Make sure the ctxpipe GitHub App installation can access the new repository.
If the installation is limited to selected repositories, add
ctxpipe-context to that selection.
Refresh and select it in ctxpipe
Return to connector setup and refresh the repository list. Select
ctxpipe-context, then continue with the connector's content scope.
Reuse it for later connectors
When the organization already has one active connector context repository, ctxpipe recommends and preselects it during subsequent connector setup; prefer that same repository for subsequent connectors unless access requirements differ.
Naming and access boundaries
ctxpipe-context is a recommendation, not a requirement. If one GitHub
organization contains several independent ctxpipe organizations or security
boundaries, use a qualified name such as ctxpipe-context-platform and keep
their repositories separate.
Use a separate repository when connector content has materially different access requirements — for example private Slack channels that should not live beside broadly shared Confluence docs. Repository access remains part of your security boundary; do not combine sources merely to avoid an extra setup step.
What ctxpipe writes
For curated systems such as Confluence, Notion, and Linear, connector setup
first proposes a configuration file (for example confluence/config.yaml,
notion/config.yaml, or linear/config.yaml) in a pull request. That file
records the approved source scope. After it is merged, ctxpipe synchronises the
selected content under the connector's directory and reindexes repository
changes.
Slack is different: there is no channel-scope config file. After you bind a
context repository, users capture specific threads by mentioning the bot in
Slack; ctxpipe commits those snapshots under slack/ and reindexes like any
other repository change. See the Slack connector.
Your team can inspect the generated Markdown, review configuration changes where they apply, and use Git history to understand when connector context changed.