# Fabric Workspace Create

> Provision a New Fabric Workspace

- Skill: `rbutinar/fabric-workspace-create` (Agent Skill)
- Install (CLI): `npx skillmds add rbutinar/fabric-workspace-create`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rbutinar/fabric-workspace-create/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: rbutinar (https://skillmd.com/u/rbutinar)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/rbutinar/fabric-workspace-create

---


# /fabric-workspace-create — Provision a New Fabric Workspace

> **Status**: preview. F2 Fabric workspace lifecycle suite, 2026-05-28.
> Source pattern from `distributions/demo-claude/.../local/_run_migration_dev.py`
> + `_rerun_migration_clean.py` (workspace provision step of DDF demo).

## What it does

Creates a new Microsoft Fabric workspace, optionally bound to a specific
capacity. Returns the new workspace id and assigns the configured identity
as an Admin role on it.

This is the "I need a workspace I don't have yet" skill. For existing
workspaces, use the overlay configuration in `overlays/{env}.yaml`.

## When to use

- Bootstrapping a new environment (DEV / CERT / PROD) on Fabric
- Setting up a sandbox workspace for testing
- The reference distribution onboarding flow (each operator may need their
  own dev workspace to avoid stepping on others)

## When NOT to use

- The workspace already exists — use the existing `workspace_id` in your
  overlay; no need to re-create
- You don't yet have a Fabric Capacity id — run `/fabric-capacity-list`
  first (without a capacity the workspace lands on Trial which has limits)

## Prerequisites

- `FabricConnector` credentials configured (`config/credentials.yaml`)
- `az login` or service principal credentials in scope
- The identity must have **Capacity Admin** or equivalent on the target
  capacity (to bind the new workspace to it)
- Decide name in advance — Fabric does not let you trivially rename
  workspaces afterwards via API

## Usage

```
/fabric-workspace-create --name "AcmeSales_DEV"
/fabric-workspace-create --name "AcmeSales_DEV" --capacity-id <id>
/fabric-workspace-create --name "AcmeSales_DEV" --capacity-id <id> --description "Dev workspace for AcmeSales medallion"
/fabric-workspace-create --name "AcmeSales_DEV" --dry-run   # preview only, no API call
```

## Safety

- **Confirmation required**: before issuing `POST /workspaces` the skill
  echoes the resolved name + capacity + description and asks
  "Proceed? (y/N)". A `y` is mandatory unless `--yes` is passed.
- **Name collision check**: pre-flight calls `find_workspace_by_name(name)`;
  if a workspace with that name already exists, the skill refuses to create
  a duplicate and surfaces the existing id instead.
- **Capacity state check**: if `--capacity-id` is provided, pre-flight
  verifies the capacity is `Active`. A `Paused`/`Suspended` capacity is
  refused with a clear error.

## Pipeline summary

1. Load project + credentials
2. Build `FabricConnector`
3. Pre-flight:
   - `find_workspace_by_name(name)` → refuse if exists
   - if `--capacity-id`: `list_capacities()` + verify state `Active`
4. Echo plan + confirm (skip with `--yes`)
5. Call `connector.client.create_workspace(name, description=..., capacity_id=...)`
6. New workspace id returned
7. Suggest next step: update overlay `overlays/{env}.yaml` with the new
   `workspace_id` so subsequent operations target it
8. ops.log: `WORKSPACE-CREATE | <env or -> | fabric: name=<name> id=<new_id> | ok`

## Preview tracking — known unknowns

1. **Default role assignments**: the API creates the workspace with the
   caller as Admin. Adding other principals as Member / Contributor / Viewer
   is a separate step (see `client.add_role_assignment()` — not wrapped in
   this skill yet).
2. **Region selection**: workspace inherits the region of the assigned
   capacity. Without `--capacity-id`, Trial picks an arbitrary region.
3. **Rate limits**: Fabric throttles workspace creation per tenant. The
   skill does not currently retry on 429 — caller waits and re-invokes.
4. **`--dry-run` semantics**: V1 just prints the plan without issuing the
   POST. Does not validate name uniqueness against the live tenant in
   dry-run mode (would require a real API call).

## Status — promotion to `stable`

1. 3+ workspaces successfully created across distinct identities + capacities
2. At least 1 case where the name-collision pre-flight prevented a duplicate
3. At least 1 case where the capacity state pre-flight caught a bad capacity
4. No silent failures on 403 (Insufficient permissions surfaced clearly)
5. ops.log entries reviewed and confirmed to capture the right fields for audit

ARGUMENTS: $ARGUMENTS