# Doable Connect > Connect the current private mono-repo or multi-repo workspace through the configured Doable MCP connection. Use when the user says “Doable setup,” asks to connect a workspace, or a Doable context request cannot be resolved because `.doable/workspace-private.json` is missing or stale. Build only a routing-level workspace map, keep real repository identities and source provenance local, and sync a sanitized profile after approval. - Skill: `getdoable/doable-connect` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add getdoable/doable-connect` - Raw SKILL.md: https://api.skillmd.com/api/skills/getdoable/doable-connect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: getdoable (https://skillmd.com/u/getdoable) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/getdoable/doable-connect --- # Connect Doable Workspace Set up the local-to-remote privacy boundary needed by Doable code-context requests. Setup is demand-driven; do not scan a workspace merely because this Skill is installed. The bundled helper is an implementation detail, not a user-facing CLI: ```bash node /scripts/doable-code-context.mjs ... ``` ## Workflow 1. Before using workspace state to prepare a profile or scanning repositories, call the configured Doable MCP tool `get_code_context_connection`. When `.doable/workspace-private.json` already exists, read only its `workspace.clientRef` and pass that as `local_workspace_id`; when setup came from a Round copy prompt, also pass that original code as `round_code`. This lets an unbound new Round recover the existing workspace and its latest server revision instead of inventing a new binding. If the tool is unavailable or disconnected, returns `401`, or resolves a different organization than the copy prompt, follow [the connection recovery workflow](references/authentication.md), retry this exact call, and resume the original setup without asking the user to repeat it. Save a successful MCP response to a private temporary JSON file for the helper; do not reinterpret the organization binding. 2. Look for `.doable/workspace-private.json` at the workspace root. - If it is valid and bound to the current organization, reuse it. - If paths moved but repositories are the same, refresh the local paths while preserving `workspaceId` and `repoRef` values. - If it is absent or cannot be recovered, rebuild the routing map and reuse an unambiguous remote `repoRef` whose sanitized role, surfaces, user-facing flag, and description still match. Never pretend lost exact provenance was recovered. 3. Reuse existing `.doable/features/*/doable-intake.json` records or a customer-supplied ownership map as local orientation hints when present; verify current repository roots and routing roles rather than regenerating their feature context. Then identify every independent Git repository under the user-selected workspace boundary. Do not treat a common parent directory as a synthetic repository. For each repository, establish only: - its local identity and path; - its product role and user-facing surfaces; - whether it contributes user-visible behavior; - a short, safely shareable product-level description. Describe stable, broad product responsibilities that remain useful across later feature requests. Do not turn the feature that triggered setup into the repository's entire role or surface list unless the repository is genuinely dedicated to that feature. Existing feature intakes are orientation hints, not an exhaustive workspace map. When the user has explicitly supplied PRDs, screenshots, Figma exports, or runtime captures outside Git, record only the narrow directory containing those supplied files as a private `artifactRoot`. Do not infer broad roots such as a home, Downloads, Documents, or workspace-parent directory, and do not scan adjacent files. 4. Do not inventory every feature, symbol, endpoint, package, database, or deployment component. Setup exists to route later questions to likely owners. A feature missing from the map is not evidence that it is missing from the product; later requests still search the current workspace from the base feature query. 5. Write `.doable/workspace-candidate.json` using the contract in [references/workspace-contract.md](references/workspace-contract.md), then run `prepare-workspace` with the saved MCP handshake response. It is private, ignored, and must never be uploaded. When setup was entered from a round copy prompt, pass its code with `--round-code`; this lets Doable recover the already-selected workspace even if local state was deleted. The helper assigns stable opaque repository references, records local Git provenance, writes `.doable/workspace-private.json` with private permissions, and validates the safe profile locally. It performs no network request. 6. Show the user only the organization, product roles, surfaces, and safe descriptions that would be shared. Ask once before the first profile upload or any material role/surface/description change. A revision-only refresh needs no new approval. 7. After approval, run `build-workspace-profile --approved --output `. If the helper says approval is not required, omit `--approved`. Read only the generated `profile` and `workspace_ref`, then call Doable MCP `sync_code_context_workspace` with those exact values. Save the MCP response privately and run `record-workspace-sync --payload --response `. Do not author or modify the safe payload between validation and the MCP call. Repeated calls are idempotent. 8. If setup was entered from a Doable request, return immediately to `doable-answer-questions` and pull that exact request. Do not make the user repeat the copy prompt. ## Privacy boundary Keep these only in `.doable/workspace-private.json` and local request ledgers: - real repository names and paths; - explicitly supplied artifact roots and artifact file identities; - branches, commits, dirty state, diffs, symbols, and line locators; - secrets, environment values, private URLs, raw logs, source snippets, and customer data. The remote profile may contain only opaque `repoRef` values, product roles, surfaces, user-facing flags, sanitized descriptions, and opaque fingerprints. Do not upload a repo map produced by another tool without passing it through the bundled helper. ## Completion Report that the workspace is connected, name the shared product surfaces, and continue the pending Doable request when one exists. Do not claim that a TRD or test case was created.