@rishildi/ldi-process-skills-test 0.0.19 → 0.0.20
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/build/skills/embedded.js +2 -2
- package/package.json +1 -1
package/build/skills/embedded.js
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
// AUTO-GENERATED by scripts/embed-skills.ts — do not edit
|
|
2
|
-
// Generated at: 2026-04-05T11:
|
|
2
|
+
// Generated at: 2026-04-05T11:40:29.950Z
|
|
3
3
|
export const EMBEDDED_SKILLS = [
|
|
4
4
|
{
|
|
5
5
|
name: "create-fabric-lakehouses",
|
|
@@ -183,7 +183,7 @@ export const EMBEDDED_SKILLS = [
|
|
|
183
183
|
files: [
|
|
184
184
|
{
|
|
185
185
|
relativePath: "SKILL.md",
|
|
186
|
-
content: "---\nname: fabric-process-discovery\ndescription: >\n Use this skill to conduct the initial environment discovery conversation for any\n Microsoft Fabric process workflow. Collects workload scope, workspace access,\n deployment approach, access control, capacity, data location, and environment\n promotion needs through a FATA-aligned, one-question-at-a-time adaptive\n conversation. Output is a structured environment profile used by the orchestrating\n agent to plan execution. Triggers as Sub-Agent 0 in any Fabric process workflow agent.\nlicense: MIT\ncompatibility: Works in any Claude context — no external tools required at this stage.\n---\n\n# Fabric Process Discovery\n\n> ⚠️ **GOVERNANCE**: This skill only gathers context — it never executes commands or\n> creates resources. All collected information feeds into the execution plan which the\n> operator reviews and confirms before anything runs.\n>\n> ⚠️ **PRIVACY**: Never ask for passwords, tokens, client secrets, or Object IDs\n> during discovery. If a Service Principal is needed, record that it is required and\n> the permissions needed — the operator enters credential values at runtime only.\n\n## Workflow\n\n1. Adopt a Fabric architect expert perspective before asking anything.\n2. Read process requirements — identify which domains are relevant.\n3. Ask Phase 1 (contextual + historical background) first.\n4. Work through relevant domains one question at a time, branching on each answer.\n5. Present a confirmation summary and wait for explicit approval.\n6. Write the environment profile and append to `CHANGE_LOG.md`.\n\n## References\n\n- `references/technical-constraints.md` — authentication separation, Object IDs,\n `notebookutils` Graph limitation, Service Principal requirements, capacity state\n- `references/fabric-architecture.md` — workload landscape, medallion architecture,\n environment promotion patterns, credential management\n\nLoad the relevant reference when a domain question requires deeper technical context\nor when the operator asks a technical follow-up.\n\n---\n\n## Core Principles\n\n**1. Expert perspective first.**\nBefore generating questions, reason as a senior Fabric architect. Ask: *what gaps,\nif left unfilled, would cause the plan to fail or need rework?* Surface things the\noperator may not know they need to tell you.\n\n**2. One question at a time — Yes/No or 3–4 labelled options.**\nNever present multiple questions in one turn. Each question must be answerable with\na yes/no or a single choice (A/B/C or A/B/C/D). Wait for the answer before\nbranching. In Fabric discovery, each answer materially changes which questions are\nworth asking next — this is why one-at-a-time is correct here even though FATA\ndefaults to single-turn efficiency.\n\n**3. Scaffold before asking.**\nOne sentence of context before each question explaining what it establishes and why\nit matters for the plan. Operators new to Fabric cannot anticipate what a Fabric\narchitect considers essential.\n\n**4. Cover all five FATA dimensions.**\n\n| Dimension | What to establish |\n|---|---|\n| **Contextual** | Project background, team, experience level |\n| **Constraint-based** | Permissions, tooling, licensing |\n| **Preference-oriented** | Deployment style, governance vs speed, reuse goals |\n| **Environmental** | Capacity, workloads, existing workspaces, data locations |\n| **Historical** | Previous runs, naming conventions, existing patterns |\n\n**5. Path decisions vs parameter values.**\nPath decisions (can you create workspaces? which workloads?) determine plan structure\n— always collect. Parameter values (exact names, IDs) — collect now if available,\notherwise flag as *required before running*.\n\n**6. Offer a way forward on every question.**\nInclude an \"I'm not sure / I'll find out\" option. For specific values the operator\nmay not have ready, offer the command to retrieve them.\n\n**7. Prevent over-questioning.**\nOnly cover domains the requirements actually need. Stop when all path decisions are\nresolved. Roughly: 4–6 questions for simple processes, up to 12 for full pipelines.\n\n---\n\n## Question Sequence\n\n### Phase 1 — Access baseline (always run first, one question only)\n\nBefore asking anything process-specific, confirm the operator has a working Fabric\ntenant. This is the only universal prerequisite — everything else follows from the\nrequirements.\n\nQuestion: Do you have access to a Microsoft Fabric tenant you can log into?\n- A) Yes — I can access the Fabric portal and have a workspace or capacity available\n- B) Yes — but I'm not sure what I have access to (I can check)\n- C) No — I need to get access first\n\nBranch:\n- A) → proceed to Phase 2\n- B) → ask them to open `app.fabric.microsoft.com` and describe what they see;\n use that to determine which domains apply before proceeding\n- C) → this process cannot proceed without tenant access; explain what is needed\n (a Microsoft 365 or Azure account with a Fabric capacity assigned) and stop\n\n**Do not ask about new vs existing setup, migration history, or naming conventions\nhere.** Those questions only arise if the requirements specifically call for it\n(e.g. \"use existing workspaces\" triggers a naming/convention question in Domain A).\n\n---\n\n### Phase 2 — Relevant Domains\n\nSelect domains based on requirements. Work through them in order, one question at a\ntime, completing each branch before moving to the next domain.\n\n| Process involves | Domains to cover |\n|---|---|\n| Creating workspaces | A, B, C, D, F |\n| Creating lakehouses | A, D, F + medallion question |\n| Ingesting files | D, E |\n| Full pipeline (multiple workloads) | Workload scope question first, then A–F |\n| Notebooks / scripts only | D, F |\n| Any of the above + multi-env mentioned in requirements | Add G |\n\n---\n\n#### Workload scope (ask first for full pipelines)\n\n*Only ask when requirements span more than one workload or mention end-to-end pipelines.*\n\nOne sentence of context: the answer determines which downstream skills are needed\nand what the workspace structure should look like.\n\nQuestion: Which Fabric workloads does this process involve? (Select all that apply)\n- A) Lakehouse / Spark (Delta tables, PySpark notebooks, file ingestion)\n- B) Data Warehouse (T-SQL analytics)\n- C) Pipelines (orchestration, data movement)\n- D) KQL / Eventhouse (real-time or time-series data)\n- E) Power BI / Semantic Model (reporting layer)\n\nLoad `references/fabric-architecture.md` → Workload Landscape for downstream skill mapping.\n\n---\n\n#### Domain A — Workspace access (Constraint-based + Environmental)\n\n**Establish:** Can the operator create workspaces, or must they use existing ones?\nWhat names?\n\nQuestion: Can you create new Fabric workspaces?\n- A) Yes — I can create workspaces\n- B) No — I need to use existing workspaces\n- C) I'm not sure — I need to check\n\nBranch:\n- A → ask for intended workspace names (or placeholder if not decided); if lakehouses\n involved, ask whether a medallion naming pattern is expected\n (load `references/fabric-architecture.md` → Medallion)\n- B → ask for the exact verbatim names of the existing workspaces to use; then ask:\n \"Are there existing naming conventions I should follow for lakehouses or other\n items?\" (Yes — describe them / No). If they need to look up exact names, suggest\n checking the Fabric portal or running `fab ls` after authenticating\n (`pip install ms-fabric-cli` → `fab auth login` → `fab ls`)\n- C → tell them to check in the Fabric portal: go to the workspace list and look for\n a **\"+ New workspace\"** button — if it's visible, they have create rights. If not,\n they'll need to use existing workspaces or request access from their admin\n\n---\n\n#### Domain B — Domain assignment (Constraint-based)\n\n**Establish:** Should workspaces be assigned to a Fabric domain?\n\nQuestion: Would you like to assign these workspaces to a Fabric domain?\n- A) Yes — assign to an existing domain\n- B) Yes — create a new domain for these workspaces\n- C) No — skip for now\n\nBranch:\n- A → ask for the domain name; then ask: \"Do you have Domain Contributor rights\n for that domain, or Fabric Admin rights?\" (Yes / No / Unsure)\n - No or Unsure → mark as manual gate; the workspace can be created but domain\n assignment will need to be done by a Domain Admin or Fabric Admin\n- B → ask if they have Fabric Administrator rights (Yes / No / Unsure)\n - No or Unsure → mark as manual gate, note intended domain name for documentation\n\n---\n\n#### Domain C — Access control (Environmental + Constraint-based)\n\n**Establish:** Who else needs workspace access? How will group identifiers be obtained?\n\nKey constraint: Fabric REST API requires Entra group **Object IDs** — display names\nare not accepted. Load `references/technical-constraints.md` → Entra Group Object IDs\nfor resolution methods.\n\nQuestion: Beyond yourself as Admin, does anyone else need workspace access?\n- A) No — just me for now\n- B) Yes — specific users (by email address)\n- C) Yes — Entra security groups\n- D) Yes — a mix of users and groups\n\nBranch (C or D):\n- Ask: Can you see these security groups in the Azure portal\n (Azure Active Directory → Groups)?\n - Yes → Ask: will you provide Object IDs directly, or should the agent generate\n Azure CLI lookup commands?\n - Either way: flag Object IDs as required before run; ask for group names and roles\n - No → mark group role assignment as manual gate; provide portal navigation instructions\n\nIf notebook deployment is chosen AND groups are involved: flag the `notebookutils`\nGraph limitation. Load `references/technical-constraints.md` → notebookutils and\nMicrosoft Graph. Ask whether a Service Principal is available or if the operator\nprefers to switch to PowerShell/terminal for role assignment.\n\n**Roles available:** Admin, Member, Contributor, Viewer\n\n---\n\n#### Domain D — Deployment approach (Preference-oriented)\n\n**Establish:** How does the operator prefer to run generated artefacts?\n\nKey context: all three approaches use the Fabric CLI (`fab`) internally — this is\nabout how the operator runs the generated artefacts, not whether they use the CLI.\nPowerShell and terminal approaches require **two separate logins**: `fab auth login`\n(Fabric) AND `az login` (Azure CLI, for group lookups). Load\n`references/technical-constraints.md` → Authentication for details.\n\nQuestion: How would you like to run the generated scripts or notebooks?\n- A) PySpark notebook — import into Fabric and run cell-by-cell in the Fabric UI\n- B) PowerShell script — review and run locally\n- C) Individual CLI commands — run step-by-step in the terminal\n\n---\n\n#### Domain E — Source data (Environmental)\n\n*Only ask if the process involves ingesting files.*\n\n**Establish:** Where are the source files?\n\nQuestion: Where are the source files you want to ingest?\n- A) On my local machine\n- B) Already in OneLake / Fabric (I have the path)\n- C) In cloud storage — SharePoint, Azure Blob, or similar\n\nBranch:\n- A → include upload step in plan\n- B → ask for OneLake path; skip upload\n- C → ask for source URL; include shortcut creation step\n\n---\n\n#### Domain F — Capacity (Environmental)\n\n*Ask whenever workspaces are being created.*\n\n**Establish:** What Fabric capacity will workspaces be assigned to?\n\nNote: capacity must be in Active state at creation time. Load\n`references/technical-constraints.md` → Capacity State Prerequisite if relevant.\n\nQuestion: Do you know the name of the Fabric capacity to use?\n- A) Yes — I know it (provide the name)\n- B) I can find it — I'll check via `fab ls` or the Fabric Admin portal\n- C) I'll provide it later — use a placeholder for now\n\n---\n\n#### Domain G — Environments (Constraint-based + Preference-oriented)\n\n*Only ask if the requirements explicitly mention multiple environments, production\ndeployment, CI/CD, or environment promotion. Do not ask by default.*\n\n**Establish:** How many environments need to be supported? This determines whether\nthe plan needs promotion logic and parameterised naming.\n\nLoad `references/fabric-architecture.md` → Environment Promotion for naming patterns.\n\nQuestion: Is this deployment for a single environment, or will it need to be\npromoted across environments?\n- A) Dev only — single environment, no promotion needed\n- B) Dev + prod — two environments, plan should parameterise workspace references\n- C) Dev + test + prod — three environments with a full promotion path\n- D) I'm not sure yet — build for single environment and we'll add promotion later\n\n---\n\n### Phase 3 — Credential management (ask if a Service Principal was flagged)\n\n*Only ask if Domain C or Domain D established that a Service Principal is needed.*\n\n**Establish:** How should SP credentials be managed in the generated artefacts?\n\nLoad `references/fabric-architecture.md` → Credential Management for options.\n\nQuestion: How would you like to handle the Service Principal credentials in the\ngenerated notebook or script?\n- A) Azure Key Vault reference — retrieve the secret at runtime from Key Vault\n- B) Runtime parameter entry — I'll paste in the values when running\n- C) Environment variable — set in my terminal session before running\n\n---\n\n### Phase 4 — Preference check\n\nAfter domains are resolved, ask one closing question if optional steps were\nidentified:\n\nQuestion: For optional steps (e.g. domain assignment, access control), would you\nprefer to include everything now or keep it minimal and add governance steps later?\n- A) Include everything — complete setup now\n- B) Keep it minimal — flag optional steps as manual for later\n- C) Decide step by step — confirm each optional item as we go\n\n---\n\n## Confirmation\n\nPresent a summary table before writing the profile. Include the FATA dimension for\neach item. Ask for explicit confirmation. If gaps remain, ask only the targeted\nfollow-up needed.\n\n```\n| # | Dimension | Question | Answer | What this means |\n|---|---------------|---------------------|-----------------------------|----------------------------------------------|\n| 0 | Contextual | Project context | New setup | No existing conventions to inherit |\n| A | Environmental | Workspace creation | Creating new | Agent creates workspaces |\n| B | Constraint | Domain assignment | New (manual gate) | Flagged manual — Fabric Admin rights needed |\n| C | Environmental | Access control | Groups — IDs direct | IDs required before run |\n| D | Preference | Deployment | PySpark notebook | .ipynb generated for Fabric import |\n| F | Environmental | Capacity | ldifabricdev | Embedded in notebook |\n| G | Constraint | Environments | Dev + prod | Plan parameterises all workspace references |\n```\n\n---\n\n## Output\n\nSave as `00-environment-discovery/environment-profile.md`. Include:\n- All path decisions (with FATA dimension)\n- Collected parameter values\n- Parameters flagged as required before execution (with retrieval instructions)\n- Manual gates with reason and operator instructions\n- Deployment prerequisites (auth steps, CLI installation)\n- Contextual/historical notes affecting naming or structure\n\nAppend to `CHANGE_LOG.md`:\n`[{DATETIME}] Sub-Agent 0 complete — environment-profile.md produced. [N] path decisions recorded. Manual gates: [list or none]. Parameters still needed: [list or none].`\n\n---\n\n## Gotchas\n\n- **Never frame deployment as CLI vs no-CLI** — all three approaches use `fab`\n- **`az login` and `fab auth login` are separate** — both required for PowerShell/terminal deployments that include group lookups\n- **Workspace names are case-sensitive** — confirm exact casing from `fab ls` output\n- **Entra group Object IDs required** — display names rejected by Fabric API; see `references/technical-constraints.md`\n- **`notebookutils` cannot query Microsoft Graph** — notebook + groups = SP or pre-resolved IDs required\n- **Domain creation = Fabric Admin rights** — not workspace-level; default to skip if uncertain\n- **Never collect credential values** — flag that they are needed; operator enters at runtime\n- **Stop when path decisions are resolved** — do not continue asking once the plan structure is clear\n",
|
|
186
|
+
content: "---\nname: fabric-process-discovery\ndescription: >\n Use this skill to conduct the initial environment discovery conversation for any\n Microsoft Fabric process workflow. Establishes the operator's tenant access, Fabric\n permissions, Entra group visibility, and deployment preference through a focused\n sequence of 6 questions asked one at a time. Output is a permissions and preferences\n profile used by the orchestrating agent to plan execution. Step-specific parameters\n (workspace names, group IDs, capacity, file paths) are collected contextually during\n execution — not upfront. Triggers as Sub-Agent 0 in any Fabric process workflow agent.\nlicense: MIT\ncompatibility: Works in any Claude context — no external tools required at this stage.\n---\n\n# Fabric Process Discovery\n\n> ⚠️ **GOVERNANCE**: This skill only gathers context — it never executes commands or\n> creates resources. All collected information feeds into the execution plan which the\n> operator reviews and confirms before anything runs.\n>\n> ⚠️ **PRIVACY**: Never ask for passwords, tokens, client secrets, Object IDs, or\n> credential values during discovery. Flag what will be needed; the operator provides\n> values at execution time.\n\n## Workflow\n\n1. Ask the 6 Phase 1 questions in order, one at a time, branching on each answer.\n2. Present a confirmation summary and wait for explicit approval.\n3. Write the environment profile and append to `CHANGE_LOG.md`.\n\n**Do not ask for workspace names, group names, capacity names, file paths, or any\nstep-specific parameters.** These are collected contextually during execution by the\nParameter Resolution Protocol — asking for them upfront is premature and confusing.\n\n## References\n\n- `references/technical-constraints.md` — authentication, Object IDs, notebookutils\n limitations, Service Principal requirements, capacity state\n- `references/fabric-architecture.md` — workload landscape, medallion architecture,\n environment promotion, credential management\n\n---\n\n## Core Principles\n\n**1. One question at a time — Yes/No or 3–4 labelled options.**\nEach question must be answerable with a yes/no or a single labelled choice. Wait for\nthe answer before asking the next question.\n\n**2. Scaffold before asking.**\nOne sentence before each question explaining what it establishes and why it matters.\nOperators new to Fabric cannot anticipate what a Fabric architect considers essential.\n\n**3. Always give a way to check.**\nFor every permission question, tell the operator exactly how to verify their access\nif they are unsure — which portal, which button to look for, which page to visit.\n\n**4. Permissions and preferences only.**\nPhase 1 establishes what the operator *can* do and *how* they prefer to do it.\nSpecific parameters (names, IDs, paths) belong to the execution phase, not here.\n\n---\n\n## Phase 1 — Permissions and Preferences\n\nAsk all 6 questions in sequence. Each one captures a universal constraint or\npreference that shapes the entire plan. Do not skip any of them.\n\n---\n\n### Q1 — Tenant and Fabric access\n\n*This confirms the process can proceed at all.*\n\n> \"First, let's confirm your Fabric environment. Can you access the Microsoft Fabric\n> portal and see at least one workspace?\"\n>\n> To check: go to [app.fabric.microsoft.com](https://app.fabric.microsoft.com).\n>\n> - A) Yes — I can log in and see workspaces\n> - B) I can log in but I'm not sure what I have access to\n> - C) No — I can't access Fabric yet\n\nBranch:\n- A → proceed to Q2\n- B → ask them to describe what they see; determine whether they have a Fabric\n capacity/SKU active (if the home page loads and they can see a workspace list,\n they have a working tenant — proceed to Q2)\n- C → stop; explain what is needed: a Microsoft 365 or Azure account with a Fabric\n capacity (F-SKU or P-SKU) assigned, or a Fabric trial activated at\n app.fabric.microsoft.com/home\n\n---\n\n### Q2 — Workspace creation\n\n*Determines whether the plan includes automated workspace creation or uses existing ones.*\n\n> \"Can you create new workspaces in Fabric?\"\n>\n> To check: in the Fabric portal, look for a **\"+ New workspace\"** button in the\n> left-hand workspace list. If it's visible, you have create rights.\n>\n> - A) Yes — I can create new workspaces\n> - B) No — I'll need to use existing workspaces\n> - C) I'm not sure — I'll check now\n\nBranch:\n- A → workspace creation steps will be automated in the plan\n- B → workspace creation steps will be marked manual (request from admin) or\n will use existing workspaces; note for plan\n- C → ask them to check the portal; wait for answer; branch as A or B\n\n---\n\n### Q3 — Fabric item creation\n\n*Determines whether lakehouses, notebooks, and other items can be created automatically.*\n\n> \"Within a workspace, can you create Fabric items like Lakehouses and Notebooks?\"\n>\n> To check: open any workspace, click **\"+ New item\"** and see if Lakehouse and\n> Notebook appear in the list.\n>\n> - A) Yes — I can create Lakehouses, Notebooks, and other items\n> - B) No — I can view items but not create them\n> - C) I'm not sure — I'll check now\n\nBranch:\n- A → item creation steps will be automated in the plan\n- B → item creation steps flagged as manual; plan will note admin involvement needed\n- C → ask them to check; wait; branch as A or B\n\n---\n\n### Q4 — Domain assignment rights\n\n*Determines whether workspace-to-domain assignment can be automated or needs an admin.*\n\n> \"Will these workspaces need to be assigned to a Fabric domain?\"\n>\n> - A) Yes — and I can do this myself (I'm a Domain Contributor or Fabric Admin)\n> - B) Yes — but I'll need an admin to do it\n> - C) No — skip domain assignment\n> - D) I'm not sure if I have the rights\n\nBranch:\n- A → domain assignment will be automated in the plan; domain name will be\n collected at the relevant execution step\n- B or D → domain assignment flagged as manual gate; the workspace creation\n proceeds automatically but domain assignment requires a Domain Admin or\n Fabric Admin.\n To check rights: in the Fabric Admin portal (app.fabric.microsoft.com/admin),\n look under Domains — if you can see and edit domains, you have admin rights.\n If you can assign workspaces within a domain but not manage the domain itself,\n you are a Domain Contributor.\n- C → no domain parameters needed; skip in plan\n\n---\n\n### Q5 — Entra group visibility\n\n*Determines how workspace role assignments will be handled if security groups are used.*\n\n> \"Can you see security groups in the Azure portal?\"\n>\n> To check: go to [portal.azure.com](https://portal.azure.com) → **Microsoft Entra ID**\n> (or Azure Active Directory) → **Groups**. If you can see a list of groups,\n> you have read access.\n>\n> - A) Yes — I can see security groups in the Entra portal\n> - B) No — I can't access that part of the portal\n> - C) We won't be using security groups for access control\n\nBranch:\n- A → group-based role assignment can be included in the plan; Object IDs will\n be collected or resolved at the relevant execution step (not now)\n- B → group role assignment flagged as manual or will use individual user emails\n instead; note for plan\n- C → role assignment will use individual users (email addresses) or be skipped;\n note for plan\n\nNote: Object IDs are **not** collected here — they are gathered at the role\nassignment execution step where the operator will have the context to look them up.\nLoad `references/technical-constraints.md` → Entra Group Object IDs if the operator\nasks why Object IDs are needed.\n\n---\n\n### Q6 — Deployment preference\n\n*Sets the default approach for all generated artefacts throughout the plan.*\n\n> \"How would you like to run the scripts and notebooks this process generates?\n> Here's what each option means:\"\n>\n> - **A) PySpark notebook** — Imported into your Fabric workspace and run\n> cell-by-cell in the browser. Authentication is automatic — no local software\n> needed. Each cell shows its output as it runs. Best if you prefer working\n> inside Fabric.\n>\n> - **B) PowerShell script** — A `.ps1` file you download and run locally in\n> PowerShell or VS Code. Requires the Fabric CLI installed locally\n> (`pip install ms-fabric-cli`). You can review the full script before running.\n> Best if you're comfortable with scripting locally.\n>\n> - **C) Terminal commands** — Individual `fab` commands run one at a time in\n> your terminal. Requires the Fabric CLI installed locally. Gives you full\n> visibility and control at each step. Best if you want to approve each action\n> before it runs.\n>\n> Note: some steps have constraints — local file uploads cannot be done in a\n> notebook, and large file batches are slow via script. Where a step requires a\n> different approach, you'll be told at that point and given the options.\n\nRecord the preference. This becomes the default for all execution steps, but can\nbe overridden step-by-step during execution.\n\n---\n\n## Confirmation\n\nPresent a summary before writing the profile:\n\n```\n| Q | What we established | Answer | Plan impact |\n|----|------------------------------|-------------------|------------------------------------------|\n| 1 | Tenant + Fabric access | Yes | Process can proceed |\n| 2 | Workspace creation | Yes | Workspace steps automated |\n| 3 | Item creation (lakehouses) | Yes | Lakehouse/notebook steps automated |\n| 4 | Domain assignment rights | Yes — contributor | Domain assignment automated |\n| 5 | Entra group visibility | Yes | Group role steps included; IDs at runtime|\n| 6 | Deployment preference | PySpark notebook | .ipynb generated for each step |\n```\n\nAsk: *\"Does this look correct? Confirm and I'll write the environment profile.\"*\nWait for explicit confirmation before writing.\n\n---\n\n## Output\n\nSave as `00-environment-discovery/environment-profile.md`. Include:\n\n- Permissions profile (workspace creation, item creation, domain rights, group visibility)\n- Deployment preference with any noted constraints\n- Manual gates identified (steps that will need admin or manual action)\n- Any prerequisites noted (CLI installation, tenant access requirements)\n\n**Do not include** workspace names, group names, capacity names, or any\nstep-specific parameters — these are collected at execution time.\n\nAppend to `CHANGE_LOG.md`:\n`[{DATETIME}] Sub-Agent 0 complete — environment-profile.md produced. Deployment preference: [preference]. Manual gates: [list or none].`\n\n---\n\n## Gotchas\n\n- **Never ask for step-specific parameters here** — workspace names, capacity,\n group IDs, file paths, domain names all belong to execution steps, not discovery\n- **Never frame deployment as CLI vs no-CLI** — all three approaches use `fab`\n- **`az login` and `fab auth login` are separate** — both required for\n PowerShell/terminal deployments that include group lookups; see\n `references/technical-constraints.md`\n- **Entra group Object IDs are not collected here** — flagged as needed, collected\n at the role assignment execution step with full context\n- **Domain creation requires Fabric Admin rights; assignment requires Domain\n Contributor** — both are distinct from workspace-level permissions\n- **`notebookutils` cannot query Microsoft Graph** — if notebook deployment +\n groups are used, Object IDs must be pre-provided; see references\n- **Never collect credential values** — flag what is needed; values entered at runtime\n",
|
|
187
187
|
},
|
|
188
188
|
{
|
|
189
189
|
relativePath: "references/fabric-architecture.md",
|
package/package.json
CHANGED