npm - @rishildi/ldi-process-skills-test - Versions diffs - 0.0.18 → 0.0.20 - Mend

@rishildi/ldi-process-skills-test 0.0.18 → 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.

Files changed (2) hide show

package/build/skills/embedded.js +4 -4
package/package.json +1 -1

package/build/skills/embedded.js CHANGED Viewed

@@ -1,5 +1,5 @@
 // AUTO-GENERATED by scripts/embed-skills.ts — do not edit
-// Generated at: 2026-04-04T23:26:58.038Z
+// Generated at: 2026-04-05T11:40:29.950Z
 export const EMBEDDED_SKILLS = [
     {
         name: "create-fabric-lakehouses",
@@ -71,11 +71,11 @@ export const EMBEDDED_SKILLS = [
         files: [
             {
                 relativePath: "SKILL.md",
-                content: "---\nname: create-fabric-process-workflow-agent\ndescription: >\n  Use this skill to create an orchestration agent definition (agent.md) for any\n  Microsoft Fabric technical process. The user describes what they want to automate;\n  the skill produces a self-contained agent.md. When run, the agent maps the process\n  to available Fabric process skills, automatically creates any missing skills using\n  create-fabric-process-skill, logs all changes to an audit trail, and orchestrates\n  the full process end-to-end. The process skills library grows with every run.\n  Triggers on: \"create a process workflow agent\", \"build an orchestration agent\n  for [process]\", \"create an agent that automates [process]\", \"orchestrate\n  [process] into an agent\". Does NOT trigger for creating individual process\n  skills, running an agent, writing code, or one-off analysis.\nlicense: MIT\ncompatibility: Python 3.8+ required for scripts/\n---\n\n# Create Fabric Process Workflow Agent\n\nCreates a concise, self-contained `agent.md` that defines an orchestration agent\nfor a Microsoft Fabric technical process. No process skills need to exist upfront.\nWhen run, the agent maps requirements to available skills, creates any that are\nmissing, and builds up the process skills library over time.\n\n## Core Governance Rules\n\nThese rules are non-negotiable. They must be embedded verbatim in every generated\n`agent.md` so they are active at runtime.\n\n- **RULE 1 — Never execute autonomously.** Never run terminal commands, API calls,\n  or scripts directly. Present every command in a fenced code block with the\n  insert-into-terminal icon. The user runs it and reports back before proceeding.\n- **RULE 2 — Pre-empt; don't react.** Before any step, ask pointed questions about\n  permissions, tooling, and dependencies. Do not collect parameters and then\n  discover blockers mid-execution.\n- **RULE 3 — No silent approach changes.** If a blocker is found with the chosen\n  approach, surface it and present alternatives. Let the user decide. Never switch\n  silently.\n- **RULE 4 — No inference from context.** Collect all parameters from the user or\n  the current prompt. Do not pre-populate from prior chat history, previous runs,\n  or attached files not explicitly part of the current request.\n- **RULE 5 — Respect the user's skill level and environment.** Do not steer toward\n  an approach the agent finds easier to generate. Match the user's comfort level,\n  installed tooling, and stated preferences.\n- **RULE 6 — Stay within skill boundaries.** Generate only what skill definitions\n  describe. On any failure: explain the cause from the error, offer the simplest\n  manual or UI fallback, ask whether to skip.\n- **RULE 7 — Append to CHANGE_LOG.md after every step.** Include: step number,\n  what was done, outcome (success/failure/skipped), and any notable decisions.\n\n## Inputs\n\n| Parameter | Description | Example |\n|-----------|-------------|---------|\n| `PROCESS_NAME` | Short name for the process (lowercase, hyphens) | `monthly-budget-consolidation` |\n| `REQUIREMENTS` | Full description of the process and each of its steps | `\"1) Collect data from five Excel files... 2) Summarise by category...\"` |\n| `SECTIONS` | Sub-agent sections to include (default: all four) | `impl-plan, biz-process, architecture, governance` |\n| `USERNAME` | Used in output folder naming | `rishi` |\n\n## Workflow\n\n- [ ] **Collect** — If `PROCESS_NAME`, `REQUIREMENTS`, or `USERNAME` are missing, ask for them.\n\n- [ ] **Analyse discovery questions** — Read the requirements and identify the\n  environment-specific questions that determine which approaches are viable. For each question:\n  - Name the specific activity that needs the permission or tool\n  - Offer concrete options (not yes/no)\n  - State what the agent does differently based on the answer\n  Group questions by domain (permissions, tooling, execution preferences, data access,\n  existing infrastructure). Ask only about domains the requirements actually need.\n  Embed the questionnaire as **Sub-Agent 0: Environment Discovery** in the generated agent.md.\n\n- [ ] **Confirm sections** — Present the four standard sections with descriptions\n  (see `references/section-descriptions.md`). Ask which to include. Default: all four.\n  Wait for explicit confirmation before drafting.\n\n- [ ] **Draft agent.md** — Use `assets/agent-template.md` as the base.\n  - Substitute `{PROCESS_NAME}` and a ≤3-sentence `{REQUIREMENTS_SUMMARY}`.\n  - Remove excluded sections. Keep each sub-agent block ≤25 lines.\n  - Do not name any specific process skill or technology — all resolved at runtime.\n  - Do not hardcode company names, specific values, or environment paths.\n\n- [ ] **Validate** — Present the draft. Ask: *\"Does this accurately reflect the process? Anything unclear?\"*\n  Refine until the user confirms.\n\n- [ ] **Scaffold** — Run `python scripts/scaffold_output.py --process-name $PROCESS_NAME --username $USERNAME --sections $SECTIONS`.\n  Write the confirmed agent.md to the returned `agent_md_path`.\n\n- [ ] **Confirm** — Report the output root path and list all created subfolders.\n\n## Output Format\n\n```\noutputs/\n└── {process-name}_{YYYY-MM-DD_HH-MM}_{username}/\n    ├── agent.md                        ← self-contained orchestration agent definition\n    ├── CHANGE_LOG.md                   ← audit trail; updated as agent runs\n    ├── 01-implementation-plan/         ← empty; populated when agent runs\n    ├── 02-business-process/            ← empty; populated when agent runs\n    ├── 03-solution-architecture/       ← empty; populated when agent runs\n    ├── 04-governance/                  ← empty; populated when agent runs\n    └── NN-step-name/                   ← additional subfolders for execution steps\n        ├── generate_thing.py           ← intermediate (generator script)\n        └── thing.ipynb                 ← final deliverable (generated notebook)\n```\n\n`CHANGE_LOG.md` is initialised empty and updated by the agent each time it runs.\n\n### Intermediate vs. final artefacts\n\n| Classification | Description | Examples |\n|----------------|-------------|----------|\n| **Final** | The deliverable the user runs or deploys | `.ipynb` notebooks, `.sql` scripts, `.md` documentation |\n| **Intermediate** | Scripts that generate the final artefacts | `generate_*.py`, `generate_*.ps1` |\n\n- Intermediate artefacts live alongside their final outputs (same subfolder).\n- Label both types clearly when presenting outputs to the user.\n- Intermediate scripts must be deterministic and re-runnable.\n\n### Sub-agents in the generated agent.md\n\n| # | Section | Output document |\n|---|---------|-----------------|\n| 0 | Environment Discovery | `00-environment-discovery/environment-profile.md` |\n| 1 | Implementation Plan | `01-implementation-plan/implementation-plan.md` |\n| 2 | Business Process Mapping | `02-business-process/sop.md` |\n| 3 | Solution Architecture | `03-solution-architecture/specification.md` |\n| 4 | Security, Testing & Governance | `04-governance/governance-plan.md` |\n\n## Gotchas\n\n- **Do not check for or create process skills during skill execution.** All skill\n  discovery, creation of missing skills, and audit logging happen inside Sub-Agent 2\n  when the generated agent.md is run.\n- **Do not execute sub-agents** during skill execution — `agent.md` is a definition only.\n- Do not name specific tools, technologies, or process skills in the generated agent.md.\n- **Environment discovery must be contextual, not generic.** Derive questions from the\n  requirements. If the process doesn't involve workspaces, don't ask about workspace\n  creation permissions. The questionnaire should read like a knowledgeable consultant\n  scoping a project, not a bureaucratic form.\n- Confirm sections **before** drafting, not after.\n- Keep each sub-agent block ≤25 lines to avoid context overload when the agent runs.\n\n## Available Scripts\n\n- **`scripts/scaffold_output.py`** — Creates the dated output folder structure including\n  an empty `CHANGE_LOG.md`. Run: `python scripts/scaffold_output.py --help`\n",
+                content: "---\nname: create-fabric-process-workflow-agent\ndescription: >\n  Use this skill to create an orchestration agent definition (agent.md) for any\n  Microsoft Fabric technical process. The user describes what they want to automate;\n  the skill produces a self-contained agent.md. When run, the agent maps the process\n  to available Fabric process skills, automatically creates any missing skills using\n  create-fabric-process-skill, logs all changes to an audit trail, and orchestrates\n  the full process end-to-end. The process skills library grows with every run.\n  Triggers on: \"create a process workflow agent\", \"build an orchestration agent\n  for [process]\", \"create an agent that automates [process]\", \"orchestrate\n  [process] into an agent\". Does NOT trigger for creating individual process\n  skills, running an agent, writing code, or one-off analysis.\nlicense: MIT\ncompatibility: Python 3.8+ required for scripts/\n---\n\n# Create Fabric Process Workflow Agent\n\nCreates a concise, self-contained `agent.md` that defines an orchestration agent\nfor a Microsoft Fabric technical process. No process skills need to exist upfront.\nWhen run, the agent maps requirements to available skills, creates any that are\nmissing, and builds up the process skills library over time.\n\n## Core Governance Rules\n\nThese rules are non-negotiable. They must be embedded verbatim in every generated\n`agent.md` so they are active at runtime.\n\n- **RULE 1 — Never execute autonomously.** Never run terminal commands, API calls,\n  or scripts directly. Present every command in a fenced code block with the\n  insert-into-terminal icon. The user runs it and reports back before proceeding.\n- **RULE 2 — Parameter gate before every execution step.** Before generating any\n  artefact for a step, verify every required parameter is resolved. Any parameter\n  deferred during discovery (marked `[TBC]`) must be asked for explicitly before\n  proceeding. Never silently skip a parameter or substitute an empty value.\n- **RULE 3 — No silent approach changes.** If a blocker is found with the chosen\n  approach, surface it and present alternatives. Let the user decide. Never switch\n  silently. Approach constraints by step type:\n  - Local file upload (CSV/PDF from operator's machine): **notebook not possible** —\n    options are script, CLI commands, or manual. For 50+ files, note that script/CLI\n    is sequential and slow; suggest manual upload via Fabric Files UI instead.\n  - Schema creation: notebook (Spark SQL) or CLI; no native Fabric UI for lakehouses.\n  - Shortcuts: CLI (`fab ln`) or script; notebook cannot run `fab ln` natively.\n- **RULE 4 — No inference from context.** Collect all parameters from the user or\n  the current prompt. Do not pre-populate from prior chat history, previous runs,\n  or attached files not explicitly part of the current request.\n- **RULE 5 — Respect the user's skill level and environment.** Do not steer toward\n  an approach the agent finds easier to generate. Match the user's comfort level,\n  installed tooling, and stated preferences.\n- **RULE 6 — Stay within skill boundaries.** Generate only what skill definitions\n  describe. On any failure: explain the cause from the error, offer the simplest\n  manual or UI fallback, ask whether to skip.\n- **RULE 7 — Append to CHANGE_LOG.md after every step.** Include: step number,\n  what was done, outcome (success/failure/skipped), and any notable decisions.\n- **RULE 8 — Two-question post-step pattern.** After each execution step: (Q1) ask\n  whether the previous artefact ran correctly — if not, get the error and resolve it\n  before proceeding; (Q2) propose the next step by name, state the planned approach\n  and any implications, offer Yes (generate it) or No (choose a different approach\n  or manual). Update the SOP and CHANGE_LOG to reflect any runtime decisions.\n\n## Inputs\n\n| Parameter | Description | Example |\n|-----------|-------------|---------|\n| `PROCESS_NAME` | Short name for the process (lowercase, hyphens) | `monthly-budget-consolidation` |\n| `REQUIREMENTS` | Full description of the process and each of its steps | `\"1) Collect data from five Excel files... 2) Summarise by category...\"` |\n| `SECTIONS` | Sub-agent sections to include (default: all four) | `impl-plan, biz-process, architecture, governance` |\n| `USERNAME` | Used in output folder naming | `rishi` |\n\n## Workflow\n\n- [ ] **Collect** — If `PROCESS_NAME`, `REQUIREMENTS`, or `USERNAME` are missing, ask for them.\n\n- [ ] **Analyse discovery questions** — Read the requirements and identify the\n  environment-specific questions that determine which approaches are viable. For each question:\n  - Name the specific activity that needs the permission or tool\n  - Offer concrete options (not yes/no)\n  - State what the agent does differently based on the answer\n  Group questions by domain (permissions, tooling, execution preferences, data access,\n  existing infrastructure). Ask only about domains the requirements actually need.\n  Embed the questionnaire as **Sub-Agent 0: Environment Discovery** in the generated agent.md.\n\n- [ ] **Confirm sections** — Present the four standard sections with descriptions\n  (see `references/section-descriptions.md`). Ask which to include. Default: all four.\n  Wait for explicit confirmation before drafting.\n\n- [ ] **Draft agent.md** — Use `assets/agent-template.md` as the base.\n  - Substitute `{PROCESS_NAME}` and a ≤3-sentence `{REQUIREMENTS_SUMMARY}`.\n  - Remove excluded sections. Keep each sub-agent block ≤25 lines.\n  - Do not name any specific process skill or technology — all resolved at runtime.\n  - Do not hardcode company names, specific values, or environment paths.\n\n- [ ] **Validate** — Present the draft. Ask: *\"Does this accurately reflect the process? Anything unclear?\"*\n  Refine until the user confirms.\n\n- [ ] **Scaffold** — Run `python scripts/scaffold_output.py --process-name $PROCESS_NAME --username $USERNAME --sections $SECTIONS`.\n  Write the confirmed agent.md to the returned `agent_md_path`.\n\n- [ ] **Confirm** — Report the output root path and list all created subfolders.\n\n## Output Format\n\n```\noutputs/\n└── {process-name}_{YYYY-MM-DD_HH-MM}_{username}/\n    ├── agent.md                        ← self-contained orchestration agent definition\n    ├── CHANGE_LOG.md                   ← audit trail; updated as agent runs\n    ├── 01-implementation-plan/         ← empty; populated when agent runs\n    ├── 02-business-process/            ← empty; populated when agent runs\n    ├── 03-solution-architecture/       ← empty; populated when agent runs\n    ├── 04-governance/                  ← empty; populated when agent runs\n    ├── 05-step-name/                   ← execution step 1 (numbered from 05)\n    │   └── thing.ipynb                 ← deliverable only (.ipynb / .ps1 / cli-commands.md)\n    └── 06-step-name/                   ← execution step 2\n        └── thing.ps1\n```\n\n`CHANGE_LOG.md` is initialised empty and updated by the agent each time it runs.\n\n### Intermediate vs. final artefacts\n\n| Classification | Description | Examples |\n|----------------|-------------|----------|\n| **Final** | The deliverable the user runs or deploys | `.ipynb` notebooks, `.sql` scripts, `.md` documentation |\n| **Intermediate** | Scripts that generate the final artefacts | `generate_*.py`, `generate_*.ps1` |\n\n- Intermediate artefacts live alongside their final outputs (same subfolder).\n- Label both types clearly when presenting outputs to the user.\n- Intermediate scripts must be deterministic and re-runnable.\n\n### Sub-agents in the generated agent.md\n\n| # | Section | Output document |\n|---|---------|-----------------|\n| 0 | Environment Discovery | `00-environment-discovery/environment-profile.md` |\n| 1 | Implementation Plan | `01-implementation-plan/implementation-plan.md` |\n| 2 | Business Process Mapping | `02-business-process/sop.md` |\n| 3 | Solution Architecture | `03-solution-architecture/specification.md` |\n| 4 | Security, Testing & Governance | `04-governance/governance-plan.md` |\n| — | **Execution Phase** | `05-[step]/`, `06-[step]/` ... + `COMPLETION_SUMMARY.md` |\n\nThe execution phase runs after all planning sub-agents are reviewed and confirmed.\nEach SOP step becomes a numbered execution subfolder. The SOP is updated in place\nthroughout execution to reflect runtime decisions (approach changes, errors, manual\nselections). CHANGE_LOG.md is updated after every step.\n\n## Gotchas\n\n- **Do not check for or create process skills during skill execution.** All skill\n  discovery, creation of missing skills, and audit logging happen inside Sub-Agent 2\n  when the generated agent.md is run.\n- **Do not execute sub-agents** during skill execution — `agent.md` is a definition only.\n- Do not name specific tools, technologies, or process skills in the generated agent.md.\n- **Environment discovery must be contextual, not generic.** Derive questions from the\n  requirements. If the process doesn't involve workspaces, don't ask about workspace\n  creation permissions. The questionnaire should read like a knowledgeable consultant\n  scoping a project, not a bureaucratic form.\n- Confirm sections **before** drafting, not after.\n- Keep each sub-agent block ≤25 lines to avoid context overload when the agent runs.\n\n## Available Scripts\n\n- **`scripts/scaffold_output.py`** — Creates the dated output folder structure including\n  an empty `CHANGE_LOG.md`. Run: `python scripts/scaffold_output.py --help`\n",
             },
             {
                 relativePath: "assets/agent-template.md",
-                content: "# Orchestration Agent: {PROCESS_NAME}\r\n\r\n## Context\r\n\r\n**Process**: {PROCESS_NAME}\r\n**Requirements**: {REQUIREMENTS_SUMMARY}\r\n\r\n---\r\n\r\n## How to Run This Agent\r\n\r\n**Start with Sub-Agent 0 (Environment Discovery).** This gathers the user's\r\npermissions, tooling, and preferences so that every subsequent sub-agent produces\r\nplans tailored to their actual environment. Do not skip this step.\r\n\r\nThen execute each remaining sub-agent in sequence:\r\n\r\n1. Use only the inputs and instructions provided in this file.\r\n2. Produce the specified output document in the designated subfolder.\r\n3. Present the output to the user; ask clarifying questions if anything is unclear.\r\n4. Refine until the user explicitly confirms the output.\r\n5. Append a timestamped entry to `CHANGE_LOG.md` recording what was produced or decided.\r\n6. Pass the confirmed output as the primary input to the next sub-agent.\r\n   **Every sub-agent must also read `00-environment-discovery/environment-profile.md`**\r\n   and respect the path decisions recorded there.\r\n\r\n> 🛑 **HARD STOP RULE — applies to every sub-agent and every execution step:**\r\n> After producing any output, you MUST stop and wait. Do not proceed to the next\r\n> step until the user responds with explicit confirmation (e.g. \"confirmed\",\r\n> \"looks good\", \"proceed\"). A lack of objection is NOT confirmation. Never\r\n> self-confirm or assume approval. Never run two steps in the same turn.\r\n\r\n**Do not produce code, scripts, or data artefacts not described in each sub-agent below.**\r\n\r\n### Parameter Resolution Protocol\r\n\r\nWhen invoking any skill, **always resolve parameters from existing documents before\r\nasking the user**. Check in this order:\r\n\r\n1. `00-environment-discovery/environment-profile.md` — provides: deployment approach,\r\n   capacity name, workspace names, access control method, Object ID resolution approach,\r\n   environment (dev/prod), credential management approach, available tooling\r\n2. The confirmed SOP (`02-business-process/sop.md`) — provides: lakehouse names,\r\n   schema names, shared parameters, step inputs and outputs\r\n3. The implementation plan (`01-implementation-plan/implementation-plan.md`) — provides:\r\n   naming conventions, task-level decisions\r\n\r\n**Only ask the user for parameters not found in any of these documents.** Summarise\r\nwhat was resolved automatically before asking for what remains. Never ask for a\r\nparameter that was explicitly captured during environment discovery or planning.\r\n\r\n### Notebook Documentation Standard\r\n\r\nEvery Fabric notebook produced by any skill **must** include a numbered markdown cell\r\nimmediately above each code cell. Each markdown cell must:\r\n\r\n1. State the cell number and a short title (e.g. `## Cell 1 — Install dependencies`).\r\n2. Explain **what** the code cell does in 1–2 sentences.\r\n3. Explain **how to use it**: variables to change, flags to toggle, prerequisites.\r\n\r\nAll transformation logic and design rationale must be **embedded as markdown cells inside\r\nthe notebook** — not maintained as separate documentation files. The notebook is the single\r\nsource of truth. A reader must be able to understand what each cell does, why the logic was\r\nchosen, and how to run it without opening any other file.\r\n\r\n### Output Conventions\r\n\r\n- Each sub-agent writes to its own **numbered subfolder** (`01-implementation-plan/`,\r\n  `02-business-process/`, etc.). Execution steps continue the numbering (e.g.,\r\n  `05-execution/`, `06-gold-layer/`).\r\n- Within each subfolder, only present **final deliverables** to the user: notebooks,\r\n  SQL scripts, and documentation they run or deploy. Generator scripts (e.g.\r\n  `generate_notebook.py`) are internal tools the skill runs to produce deliverables —\r\n  **never present generator scripts as outputs and never generate notebook or script\r\n  content directly**. Run the generator script via Bash; present what it produces.\r\n- All transformation logic and design rationale must be **embedded as markdown cells\r\n  inside notebooks** — not maintained as separate documentation files. The notebook\r\n  is the single source of truth.\r\n\r\n---\r\n\r\n## Sub-Agent 0: Environment Discovery\r\n\r\n**Input**: Requirements above\r\n**Output**: `00-environment-discovery/environment-profile.md`\r\n\r\nThis sub-agent runs **before anything is planned or built**. Its sole purpose is to\r\nunderstand the operator's environment, permissions, and preferences so that every\r\nsubsequent sub-agent produces plans tailored to what is actually possible and practical.\r\n\r\n**Invoke the `fabric-process-discovery` skill to run this step.**\r\n\r\nThe skill defines the full adaptive questioning tree — which questions to ask, in what\r\norder, and how to branch based on answers. Key principles:\r\n\r\n- **Read the requirements first.** Only ask about domains the process actually needs.\r\n  A CSV ingestion job does not need workspace creation questions. A full pipeline\r\n  needs all domains.\r\n- **Present all questions in a single turn**, grouped by domain. Never ask one question\r\n  at a time. Target **5–7 questions** for most processes; simpler ones may need 3–4.\r\n- **Branch adaptively.** The skill defines conditional follow-ups — apply them after\r\n  the first-turn answers before presenting the confirmation summary.\r\n- **Confirm before proceeding.** After processing answers, present the path table and\r\n  ask: *\"Is this accurate, or anything to correct before I proceed to planning?\"*\r\n  Wait for explicit confirmation.\r\n\r\nThe skill covers these domains (use only those relevant to the requirements):\r\n\r\n| Domain | When to include |\r\n|--------|----------------|\r\n| **A — Workspace access** | Any step creates or uses workspaces |\r\n| **A — Domain assignment** | Requirements mention domain governance (only if creating workspaces) |\r\n| **A — Access control / groups** | Process assigns roles to users or groups |\r\n| **B — Deployment approach** | Any step generates notebooks, scripts, or CLI commands |\r\n| **C — Source data location** | Process ingests files (CSV, PDF, etc.) |\r\n| **D — Capacity / SKU** | Process involves compute-intensive operations |\r\n\r\n**Critical framing rules from the skill — do not deviate:**\r\n\r\n1. **Deployment approach is NOT a CLI vs no-CLI question.** All three options (PySpark\r\n   notebook, PowerShell script, CLI commands) use the Fabric CLI internally. The\r\n   question is only about *how* the operator runs it. Present it as:\r\n   - **A) PySpark notebook** — imported into Fabric, run cell-by-cell in the Fabric UI\r\n   - **B) PowerShell script** — generated `.ps1` reviewed and run locally\r\n   - **C) CLI commands** — individual `fab` commands run interactively in the terminal\r\n\r\n2. **Workspace creation must branch correctly.** If the operator cannot create\r\n   workspaces, immediately ask for the exact names of existing hub and spoke\r\n   workspaces — do not ask about domain assignment or access control (they only\r\n   apply when creating).\r\n\r\n3. **Entra group Object IDs are a known technical constraint.** When groups are\r\n   involved, always surface this: *\"The Fabric API requires Object IDs — display\r\n   names are not accepted programmatically.\"* Then offer the resolution options\r\n   (have IDs / Azure CLI / PowerShell Graph / UI manual).\r\n\r\n4. **Never leave the user blocked.** If a step requires permissions they don't have,\r\n   offer: (a) skip and mark as manual, (b) produce a spec for their admin, or\r\n   (c) substitute a UI-based workaround.\r\n\r\nOnce the environment profile is confirmed, save it as\r\n`00-environment-discovery/environment-profile.md` and append to `CHANGE_LOG.md`:\r\n`[{DATETIME}] Sub-Agent 0 complete — environment-profile.md produced. [N] path decisions recorded. Manual gates: [list or none].`\r\n\r\n🛑 **STOP — present the environment profile and ask: \"Does this look correct? Please confirm before I move to the implementation plan.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 1: Implementation Plan\r\n\r\n**Input**: Requirements above\r\n**Output**: `01-implementation-plan/implementation-plan.md`\r\n\r\nProduce a phased implementation plan using the structure below. Keep ≤50 lines.\r\nUpdate the RAID log whenever a later sub-agent raises a new risk or dependency.\r\n\r\n```markdown\r\n---\r\ngoal: {PROCESS_NAME} — Implementation Plan\r\nstatus: Planned\r\ndate_created: {DATE}\r\n---\r\n\r\n# Implementation Plan: {PROCESS_NAME}\r\n\r\n## Requirements & Constraints\r\n- REQ-001: [Requirement drawn from the context above]\r\n- CON-001: [Key constraint]\r\n\r\n## Phases\r\n\r\n### Phase 1: [Phase name]\r\n| Task     | Description | Status  |\r\n|----------|-------------|---------|\r\n| TASK-001 | [Task]      | Planned |\r\n| TASK-002 | [Task]      | Planned |\r\n\r\n### Phase 2: [Phase name]\r\n| Task     | Description | Status  |\r\n|----------|-------------|---------|\r\n| TASK-003 | [Task]      | Planned |\r\n\r\n## RAID Log\r\n| Type       | ID    | Description  | Mitigation / Action | Status |\r\n|------------|-------|--------------|---------------------|--------|\r\n| Risk       | R-001 | [Risk]       | [Mitigation]        | Open   |\r\n| Assumption | A-001 | [Assumption] | [Validation]        | Open   |\r\n| Issue      | I-001 | [Issue]      | [Resolution]        | Open   |\r\n| Dependency | D-001 | [Dependency] | [Owner]             | Open   |\r\n```\r\n\r\nRules:\r\n- Use REQ-, CON-, TASK-, R-, A-, I-, D- prefixes consistently.\r\n- Task status values: Planned / In Progress / Done.\r\n- Do not include implementation code or scripts.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 1 complete — implementation-plan.md produced.`\r\n- 🛑 **STOP — present the implementation plan and ask: \"Does this look correct? Please confirm before I move to the business process mapping.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 2: Business Process Mapping\r\n\r\n**Input**: Confirmed output of Sub-Agent 1 + Requirements above\r\n**Output**: `02-business-process/sop.md`\r\n\r\nThis sub-agent maps requirements to process skills, creates any that are missing,\r\nand produces a Standard Operating Procedure. Work through the three steps below.\r\n\r\n### Step 1 — Decompose requirements into process steps\r\n\r\nRead the requirements and break them into discrete, ordered steps. For each step,\r\nwrite a one-line description of what it needs to do and what its output is.\r\n\r\n### Step 2 — Map each step to a process skill\r\n\r\nFor each step, search the skills directory for a matching process skill\r\n(a skill whose description covers the same action and output).\r\n\r\nFor every step, one of three outcomes applies:\r\n\r\n**A — Skill found**: Read the skill's `SKILL.md`. Note its inputs, outputs, and\r\nany parameters it needs from earlier steps. Mark the step as covered.\r\n\r\n**B — Skill not found**: Determine the deterministic logic needed to automate\r\nthis step (the specific inputs, the repeatable actions, and the expected output).\r\nInvoke `create-fabric-process-skill` to create a new skill definition for this step.\r\nOnce created, read its `SKILL.md` and mark the step as covered.\r\nAppend to `CHANGE_LOG.md`:\r\n`[{DATETIME}] New skill created: [skill-name] — [one-line description of what it does].`\r\nAdd the new skill as a dependency in the RAID log from Sub-Agent 1.\r\n\r\n**C — Step must be manual**: If the step cannot be automated (e.g. requires human\r\njudgement or a physical action), document it as a manual step with exact operator\r\ninstructions and mark it accordingly.\r\n\r\nRepeat until every step is either covered by a skill or accepted as manual.\r\n\r\n🛑 **STOP — present the skill list and ask: \"Does this mapping look correct? Please confirm before I produce the SOP.\"** Do not proceed to Step 3 until the user confirms.\r\n\r\n### Step 3 — Produce the SOP\r\n\r\n```markdown\r\n# SOP: {PROCESS_NAME}\r\n\r\n## Step Sequence\r\n| Step | Skill / Action      | Input Parameters (resolved values where known) | Output            | Manual? |\r\n|------|---------------------|------------------------------------------------|-------------------|---------|\r\n| 1    | [skill-name]        | capacity=ldifabricdev, deployment=notebook     | [output artefact] | No      |\r\n| 2    | [skill-name]        | workspace=[from step 1], lakehouse=[name]      | [output artefact] | No      |\r\n| 3    | [Manual: action]    | —                                              | —                 | Yes     |\r\n\r\nPopulate parameter values from `00-environment-discovery/environment-profile.md` where\r\nalready known. Use `[TBC]` only for parameters not yet resolved.\r\n\r\n## Shared Parameters\r\n| Parameter | Value / Source                  | Passed to steps |\r\n|-----------|---------------------------------|-----------------|\r\n| [param]   | [actual value or \"user input\"]  | 1, 3            |\r\n\r\n## Newly Created Skills\r\n| Skill name   | Step | Description                        |\r\n|--------------|------|------------------------------------|\r\n| [skill-name] | 2    | [What it does — one line]          |\r\n\r\n## Manual Steps\r\n- MANUAL-001: [Step] — [Reason] — [Exact operator instructions]\r\n```\r\n\r\nRules:\r\n- If requirements are unclear for any step, ask a targeted question and update\r\n  requirements before continuing.\r\n- New skills created in this sub-agent are a permanent addition to the skills\r\n  library and will be available for future agents.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 2 complete — sop.md produced. [N] new skills created.`\r\n- 🛑 **STOP — present the SOP and ask: \"Does this look correct? Please confirm before I move to the solution architecture.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 3: Solution Architecture\r\n\r\n**Input**: Confirmed output of Sub-Agent 2\r\n**Output**: `03-solution-architecture/specification.md`\r\n\r\nProduce a plain-language specification. Keep total length ≤50 lines.\r\nWrite for a non-technical reader — no code, no implementation detail.\r\n\r\n```markdown\r\n---\r\ntitle: {PROCESS_NAME} — Solution Specification\r\nstatus: Draft\r\ndate_created: {DATE}\r\n---\r\n\r\n# Specification: {PROCESS_NAME}\r\n\r\n## Purpose\r\n[One paragraph: what this solution does and what problem it solves.]\r\n\r\n## Scope\r\n[What is included and what is explicitly excluded.]\r\n\r\n## How It Works\r\n| Step | What happens                  | Automated? | Notes           |\r\n|------|-------------------------------|------------|-----------------|\r\n| 1    | [Plain-language description]  | Yes        |                 |\r\n| 2    | [Plain-language description]  | No         | See MANUAL-001  |\r\n\r\n## Manual Steps\r\n- MANUAL-001: [Step] — [Reason] — [Exact operator instructions]\r\n\r\n## Acceptance Criteria\r\n- AC-001: Given [context], when [action], then [expected outcome].\r\n\r\n## Dependencies\r\n- DEP-001: [External system, file, or service] — [Purpose]\r\n```\r\n\r\nRules:\r\n- Write for a non-technical reader. No jargon without explanation.\r\n- Every manual step must include exact operator instructions.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 3 complete — specification.md produced.`\r\n- 🛑 **STOP — present the specification and ask: \"Does this look correct? Please confirm before I move to the governance plan.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 4: Security, Testing and Governance\r\n\r\n**Input**: Confirmed output of Sub-Agent 3\r\n**Output**: `04-governance/governance-plan.md`\r\n\r\nProduce a governance and deployment plan. Keep total length ≤45 lines.\r\n\r\n```markdown\r\n---\r\ntitle: {PROCESS_NAME} — Governance Plan\r\ndate_created: {DATE}\r\n---\r\n\r\n# Governance Plan: {PROCESS_NAME}\r\n\r\n## Agent Boundaries\r\n| Boundary                | Rule                                       |\r\n|-------------------------|--------------------------------------------|\r\n| Allowed actions         | [Permitted operations]                     |\r\n| Blocked actions         | [Prohibited operations]                    |\r\n| Requires human approval | [Steps needing explicit sign-off]          |\r\n\r\n## Testing Checklist\r\n- [ ] Validate each sub-agent output before passing it to the next\r\n- [ ] Test all manual steps with a real operator before production use\r\n- [ ] Run against a minimal test dataset before using real data\r\n- [ ] Review CHANGE_LOG.md to confirm all new skills are correct\r\n- [ ] Verify the output folder structure after scaffolding\r\n\r\n## Microsoft Responsible AI Alignment\r\n| Principle      | How Applied                                            |\r\n|----------------|--------------------------------------------------------|\r\n| Fairness       | [How bias is avoided in outputs and decisions]         |\r\n| Reliability    | [Validation steps, error handling, new skill review]   |\r\n| Privacy        | [Data handling — no PII retained in output files]      |\r\n| Inclusiveness  | [Plain language; no domain assumptions made]           |\r\n| Transparency   | [User validates every sub-agent output; CHANGE_LOG]    |\r\n| Accountability | [Human sign-off required before production execution]  |\r\n\r\n## Deployment Guidance\r\n- Review `CHANGE_LOG.md` to verify all newly created skills before first run.\r\n- Store `agent.md`, all outputs, and new skills in version control.\r\n- Review the RAID log from Sub-Agent 1 before each new run.\r\n- Human sign-off required before running against production systems.\r\n```\r\n\r\nRules:\r\n- Every RAI principle row must be completed — state explicitly if not applicable and why.\r\n- Human approval must be required for any step that modifies production systems.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 4 complete — governance-plan.md produced. Agent definition finalised.`\r\n- 🛑 **STOP — present the governance plan and ask:**\r\n  > \"Planning is complete. Here's a summary of what we've produced:\r\n  > - `00-environment-discovery/environment-profile.md`\r\n  > - `01-implementation-plan/implementation-plan.md`\r\n  > - `02-business-process/sop.md`\r\n  > - `03-solution-architecture/specification.md`\r\n  > - `04-governance/governance-plan.md`\r\n  >\r\n  > Please review these documents. When you're ready to proceed with execution, say **'ready to execute'**.\"\r\n  Do not begin the Execution Phase until the user says they are ready.\r\n\r\n---\r\n\r\n## Execution Phase\r\n\r\n**Input**: Confirmed outputs of Sub-Agents 0–4 (environment profile, SOP, governance plan)\r\n**Trigger**: User explicitly confirms they are ready to execute after reviewing Sub-Agent 4\r\n\r\n🛑 **Do not begin execution until the user explicitly says they are ready** (e.g. \"ready\r\nto execute\", \"let's go\", \"proceed\"). When they confirm, read the SOP from\r\n`02-business-process/sop.md` and execute steps one at a time.\r\n\r\n**One step per turn.** After completing each step and presenting the output, stop and\r\nask: *\"Step [N] complete — [filename] is in `0N-[step-slug]/`. Ready for step [N+1]?\"*\r\nDo not proceed until the user confirms.\r\n\r\n### How execution steps work\r\n\r\nFor each step in the SOP:\r\n\r\n1. **Announce the step.** State the step number, name, and which skill will handle it.\r\n   Show what parameters will be used (resolved from environment profile and SOP).\r\n   Ask for any parameters not yet resolved — keeping the Parameter Resolution Protocol.\r\n\r\n2. **Invoke the skill.** Run the skill using the resolved parameters. Follow the skill's\r\n   instructions exactly — run generator scripts via Bash, do not generate artefact content\r\n   directly.\r\n\r\n3. **Write output to its subfolder.** Each step writes to a numbered subfolder continuing\r\n   from `04-governance/`. Step 1 of the SOP → `05-[step-slug]/`, step 2 → `06-[step-slug]/`,\r\n   etc. The slug is a short lowercase hyphenated name derived from the SOP step name\r\n   (e.g. `05-create-workspaces/`, `06-create-lakehouses/`).\r\n\r\n4. **Only the deliverable goes in the folder.** One of:\r\n   - **PySpark notebook**: the `.ipynb` file only\r\n   - **PowerShell script**: the `.ps1` file only\r\n   - **CLI commands**: a `cli-commands.md` recording each `!fab` command run and its output\r\n   - **Other**: the specific file type described by the skill (e.g. workspace definition `.md`)\r\n   No intermediate files, generator scripts, or working notes.\r\n\r\n5. **Present the output and confirm.** Show the user what was produced. Wait for explicit\r\n   confirmation before moving to the next step.\r\n\r\n6. **Log the step.** Append to `CHANGE_LOG.md`:\r\n   `[{DATETIME}] Execution step [N] complete — [step-name] — [filename] produced.`\r\n\r\n7. **Proceed to the next step.** Repeat until all non-manual SOP steps are complete.\r\n\r\n### Manual steps\r\n\r\nFor any step marked Manual in the SOP, do not invoke a skill. Instead:\r\n- Display the exact operator instructions from the SOP\r\n- Wait for the user to confirm they have completed the manual step\r\n- Log it: `[{DATETIME}] Manual step [N] confirmed by operator — [step-name].`\r\n\r\n### CLI command log format\r\n\r\nWhen deployment approach is terminal (interactive CLI), produce a `cli-commands.md`\r\nin the step subfolder with this structure:\r\n\r\n```markdown\r\n# CLI Commands: [Step Name]\r\n_Executed: {DATETIME}_\r\n\r\n## Commands Run\r\n\r\n### [Command description]\r\n```bash\r\n[exact command]\r\n```\r\n**Output:**\r\n```\r\n[output or \"No output / success\"]\r\n```\r\n\r\n## Result\r\n[One-sentence summary of what was created or confirmed]\r\n```\r\n\r\n### After all steps complete\r\n\r\nOnce all SOP steps are confirmed, produce `outputs/COMPLETION_SUMMARY.md`:\r\n\r\n```markdown\r\n# Completion Summary: {PROCESS_NAME}\r\n_Completed: {DATETIME}_\r\n\r\n## Steps Executed\r\n| Step | Folder | Deliverable | Status |\r\n|------|--------|-------------|--------|\r\n| [N]  | [folder] | [filename] | ✅ Complete |\r\n\r\n## Manual Steps\r\n| Step | Description | Confirmed by operator |\r\n|------|-------------|----------------------|\r\n| [N]  | [description] | ✅ Yes |\r\n\r\n## Next Steps\r\n[Any post-execution actions: verify in Fabric UI, share workspace, run first notebook, etc.]\r\n```\r\n\r\nAppend to `CHANGE_LOG.md`:\r\n`[{DATETIME}] Execution phase complete — all [N] steps done. See COMPLETION_SUMMARY.md.`\r\n",
+                content: "# Orchestration Agent: {PROCESS_NAME}\r\n\r\n## Context\r\n\r\n**Process**: {PROCESS_NAME}\r\n**Requirements**: {REQUIREMENTS_SUMMARY}\r\n\r\n---\r\n\r\n## How to Run This Agent\r\n\r\n**Start with Sub-Agent 0 (Environment Discovery).** This gathers the user's\r\npermissions, tooling, and preferences so that every subsequent sub-agent produces\r\nplans tailored to their actual environment. Do not skip this step.\r\n\r\nThen execute each remaining sub-agent in sequence:\r\n\r\n1. Use only the inputs and instructions provided in this file.\r\n2. Produce the specified output document in the designated subfolder.\r\n3. Present the output to the user; ask clarifying questions if anything is unclear.\r\n4. Refine until the user explicitly confirms the output.\r\n5. Append a timestamped entry to `CHANGE_LOG.md` recording what was produced or decided.\r\n6. Pass the confirmed output as the primary input to the next sub-agent.\r\n   **Every sub-agent must also read `00-environment-discovery/environment-profile.md`**\r\n   and respect the path decisions recorded there.\r\n\r\n> 🛑 **HARD STOP RULE — applies to every sub-agent and every execution step:**\r\n> After producing any output, you MUST stop and wait. Do not proceed to the next\r\n> step until the user responds with explicit confirmation (e.g. \"confirmed\",\r\n> \"looks good\", \"proceed\"). A lack of objection is NOT confirmation. Never\r\n> self-confirm or assume approval. Never run two steps in the same turn.\r\n\r\n**Do not produce code, scripts, or data artefacts not described in each sub-agent below.**\r\n\r\n### Parameter Resolution Protocol\r\n\r\nWhen invoking any skill, **always resolve parameters from existing documents before\r\nasking the user**. Check in this order:\r\n\r\n1. `00-environment-discovery/environment-profile.md` — provides: deployment approach,\r\n   capacity name, workspace names, access control method, Object ID resolution approach,\r\n   environment (dev/prod), credential management approach, available tooling\r\n2. The confirmed SOP (`02-business-process/sop.md`) — provides: lakehouse names,\r\n   schema names, shared parameters, step inputs and outputs\r\n3. The implementation plan (`01-implementation-plan/implementation-plan.md`) — provides:\r\n   naming conventions, task-level decisions\r\n\r\n**Only ask the user for parameters not found in any of these documents.** Summarise\r\nwhat was resolved automatically before asking for what remains. Never ask for a\r\nparameter that was explicitly captured during environment discovery or planning.\r\n\r\n### Notebook Documentation Standard\r\n\r\nEvery Fabric notebook produced by any skill **must** include a numbered markdown cell\r\nimmediately above each code cell. Each markdown cell must:\r\n\r\n1. State the cell number and a short title (e.g. `## Cell 1 — Install dependencies`).\r\n2. Explain **what** the code cell does in 1–2 sentences.\r\n3. Explain **how to use it**: variables to change, flags to toggle, prerequisites.\r\n\r\nAll transformation logic and design rationale must be **embedded as markdown cells inside\r\nthe notebook** — not maintained as separate documentation files. The notebook is the single\r\nsource of truth. A reader must be able to understand what each cell does, why the logic was\r\nchosen, and how to run it without opening any other file.\r\n\r\n### Output Conventions\r\n\r\n- Each sub-agent writes to its own **numbered subfolder** (`01-implementation-plan/`,\r\n  `02-business-process/`, etc.). Execution steps continue the numbering (e.g.,\r\n  `05-execution/`, `06-gold-layer/`).\r\n- Within each subfolder, only present **final deliverables** to the user: notebooks,\r\n  SQL scripts, and documentation they run or deploy. Generator scripts (e.g.\r\n  `generate_notebook.py`) are internal tools the skill runs to produce deliverables —\r\n  **never present generator scripts as outputs and never generate notebook or script\r\n  content directly**. Run the generator script via Bash; present what it produces.\r\n- All transformation logic and design rationale must be **embedded as markdown cells\r\n  inside notebooks** — not maintained as separate documentation files. The notebook\r\n  is the single source of truth.\r\n\r\n---\r\n\r\n## Sub-Agent 0: Environment Discovery\r\n\r\n**Input**: Requirements above\r\n**Output**: `00-environment-discovery/environment-profile.md`\r\n\r\nThis sub-agent runs **before anything is planned or built**. Its sole purpose is to\r\nunderstand the operator's environment, permissions, and preferences so that every\r\nsubsequent sub-agent produces plans tailored to what is actually possible and practical.\r\n\r\n**Invoke the `fabric-process-discovery` skill to run this step.**\r\n\r\nThe skill defines the full adaptive questioning tree — which questions to ask, in what\r\norder, and how to branch based on answers. Key principles:\r\n\r\n- **Read the requirements first.** Only ask about domains the process actually needs.\r\n  A CSV ingestion job does not need workspace creation questions. A full pipeline\r\n  needs all domains.\r\n- **Present all questions in a single turn**, grouped by domain. Never ask one question\r\n  at a time. Target **5–7 questions** for most processes; simpler ones may need 3–4.\r\n- **Branch adaptively.** The skill defines conditional follow-ups — apply them after\r\n  the first-turn answers before presenting the confirmation summary.\r\n- **Confirm before proceeding.** After processing answers, present the path table and\r\n  ask: *\"Is this accurate, or anything to correct before I proceed to planning?\"*\r\n  Wait for explicit confirmation.\r\n\r\nThe skill covers these domains (use only those relevant to the requirements):\r\n\r\n| Domain | When to include |\r\n|--------|----------------|\r\n| **A — Workspace access** | Any step creates or uses workspaces |\r\n| **A — Domain assignment** | Requirements mention domain governance (only if creating workspaces) |\r\n| **A — Access control / groups** | Process assigns roles to users or groups |\r\n| **B — Deployment approach** | Any step generates notebooks, scripts, or CLI commands |\r\n| **C — Source data location** | Process ingests files (CSV, PDF, etc.) |\r\n| **D — Capacity / SKU** | Process involves compute-intensive operations |\r\n\r\n**Critical framing rules from the skill — do not deviate:**\r\n\r\n1. **Deployment approach is NOT a CLI vs no-CLI question.** All three options (PySpark\r\n   notebook, PowerShell script, CLI commands) use the Fabric CLI internally. The\r\n   question is only about *how* the operator runs it. Present it as:\r\n   - **A) PySpark notebook** — imported into Fabric, run cell-by-cell in the Fabric UI\r\n   - **B) PowerShell script** — generated `.ps1` reviewed and run locally\r\n   - **C) CLI commands** — individual `fab` commands run interactively in the terminal\r\n\r\n2. **Workspace creation must branch correctly.** If the operator cannot create\r\n   workspaces, immediately ask for the exact names of existing hub and spoke\r\n   workspaces — do not ask about domain assignment or access control (they only\r\n   apply when creating).\r\n\r\n3. **Entra group Object IDs are a known technical constraint.** When groups are\r\n   involved, always surface this: *\"The Fabric API requires Object IDs — display\r\n   names are not accepted programmatically.\"* Then offer the resolution options\r\n   (have IDs / Azure CLI / PowerShell Graph / UI manual).\r\n\r\n4. **Never leave the user blocked.** If a step requires permissions they don't have,\r\n   offer: (a) skip and mark as manual, (b) produce a spec for their admin, or\r\n   (c) substitute a UI-based workaround.\r\n\r\nOnce the environment profile is confirmed, save it as\r\n`00-environment-discovery/environment-profile.md` and append to `CHANGE_LOG.md`:\r\n`[{DATETIME}] Sub-Agent 0 complete — environment-profile.md produced. [N] path decisions recorded. Manual gates: [list or none].`\r\n\r\n🛑 **STOP — present the environment profile and ask: \"Does this look correct? Please confirm before I move to the implementation plan.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 1: Implementation Plan\r\n\r\n**Input**: Requirements above\r\n**Output**: `01-implementation-plan/implementation-plan.md`\r\n\r\nProduce a phased implementation plan using the structure below. Keep ≤50 lines.\r\nUpdate the RAID log whenever a later sub-agent raises a new risk or dependency.\r\n\r\n```markdown\r\n---\r\ngoal: {PROCESS_NAME} — Implementation Plan\r\nstatus: Planned\r\ndate_created: {DATE}\r\n---\r\n\r\n# Implementation Plan: {PROCESS_NAME}\r\n\r\n## Requirements & Constraints\r\n- REQ-001: [Requirement drawn from the context above]\r\n- CON-001: [Key constraint]\r\n\r\n## Phases\r\n\r\n### Phase 1: [Phase name]\r\n| Task     | Description | Status  |\r\n|----------|-------------|---------|\r\n| TASK-001 | [Task]      | Planned |\r\n| TASK-002 | [Task]      | Planned |\r\n\r\n### Phase 2: [Phase name]\r\n| Task     | Description | Status  |\r\n|----------|-------------|---------|\r\n| TASK-003 | [Task]      | Planned |\r\n\r\n## RAID Log\r\n| Type       | ID    | Description  | Mitigation / Action | Status |\r\n|------------|-------|--------------|---------------------|--------|\r\n| Risk       | R-001 | [Risk]       | [Mitigation]        | Open   |\r\n| Assumption | A-001 | [Assumption] | [Validation]        | Open   |\r\n| Issue      | I-001 | [Issue]      | [Resolution]        | Open   |\r\n| Dependency | D-001 | [Dependency] | [Owner]             | Open   |\r\n```\r\n\r\nRules:\r\n- Use REQ-, CON-, TASK-, R-, A-, I-, D- prefixes consistently.\r\n- Task status values: Planned / In Progress / Done.\r\n- Do not include implementation code or scripts.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 1 complete — implementation-plan.md produced.`\r\n- 🛑 **STOP — present the implementation plan and ask: \"Does this look correct? Please confirm before I move to the business process mapping.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 2: Business Process Mapping\r\n\r\n**Input**: Confirmed output of Sub-Agent 1 + Requirements above\r\n**Output**: `02-business-process/sop.md`\r\n\r\nThis sub-agent maps requirements to process skills, creates any that are missing,\r\nand produces a Standard Operating Procedure. Work through the three steps below.\r\n\r\n### Step 1 — Decompose requirements into process steps\r\n\r\nRead the requirements and break them into discrete, ordered steps. For each step,\r\nwrite a one-line description of what it needs to do and what its output is.\r\n\r\n### Step 2 — Map each step to a process skill\r\n\r\nFor each step, search the skills directory for a matching process skill\r\n(a skill whose description covers the same action and output).\r\n\r\nFor every step, one of three outcomes applies:\r\n\r\n**A — Skill found**: Read the skill's `SKILL.md`. Note its inputs, outputs, and\r\nany parameters it needs from earlier steps. Mark the step as covered.\r\n\r\n**B — Skill not found**: Determine the deterministic logic needed to automate\r\nthis step (the specific inputs, the repeatable actions, and the expected output).\r\nInvoke `create-fabric-process-skill` to create a new skill definition for this step.\r\nOnce created, read its `SKILL.md` and mark the step as covered.\r\nAppend to `CHANGE_LOG.md`:\r\n`[{DATETIME}] New skill created: [skill-name] — [one-line description of what it does].`\r\nAdd the new skill as a dependency in the RAID log from Sub-Agent 1.\r\n\r\n**C — Step must be manual**: If the step cannot be automated (e.g. requires human\r\njudgement or a physical action), document it as a manual step with exact operator\r\ninstructions and mark it accordingly.\r\n\r\nRepeat until every step is either covered by a skill or accepted as manual.\r\n\r\n🛑 **STOP — present the skill list and ask: \"Does this mapping look correct? Please confirm before I produce the SOP.\"** Do not proceed to Step 3 until the user confirms.\r\n\r\n### Step 3 — Produce the SOP\r\n\r\n```markdown\r\n# SOP: {PROCESS_NAME}\r\n\r\n## Step Sequence\r\n| Step | Skill / Action      | Input Parameters (resolved values where known) | Output            | Manual? |\r\n|------|---------------------|------------------------------------------------|-------------------|---------|\r\n| 1    | [skill-name]        | capacity=ldifabricdev, deployment=notebook     | [output artefact] | No      |\r\n| 2    | [skill-name]        | workspace=[from step 1], lakehouse=[name]      | [output artefact] | No      |\r\n| 3    | [Manual: action]    | —                                              | —                 | Yes     |\r\n\r\nPopulate parameter values from `00-environment-discovery/environment-profile.md` where\r\nalready known. Use `[TBC]` only for parameters not yet resolved.\r\n\r\n## Shared Parameters\r\n| Parameter | Value / Source                  | Passed to steps |\r\n|-----------|---------------------------------|-----------------|\r\n| [param]   | [actual value or \"user input\"]  | 1, 3            |\r\n\r\n## Newly Created Skills\r\n| Skill name   | Step | Description                        |\r\n|--------------|------|------------------------------------|\r\n| [skill-name] | 2    | [What it does — one line]          |\r\n\r\n## Manual Steps\r\n- MANUAL-001: [Step] — [Reason] — [Exact operator instructions]\r\n```\r\n\r\nRules:\r\n- If requirements are unclear for any step, ask a targeted question and update\r\n  requirements before continuing.\r\n- New skills created in this sub-agent are a permanent addition to the skills\r\n  library and will be available for future agents.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 2 complete — sop.md produced. [N] new skills created.`\r\n- 🛑 **STOP — present the SOP and ask: \"Does this look correct? Please confirm before I move to the solution architecture.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 3: Solution Architecture\r\n\r\n**Input**: Confirmed output of Sub-Agent 2\r\n**Output**: `03-solution-architecture/specification.md`\r\n\r\nProduce a plain-language specification. Keep total length ≤50 lines.\r\nWrite for a non-technical reader — no code, no implementation detail.\r\n\r\n```markdown\r\n---\r\ntitle: {PROCESS_NAME} — Solution Specification\r\nstatus: Draft\r\ndate_created: {DATE}\r\n---\r\n\r\n# Specification: {PROCESS_NAME}\r\n\r\n## Purpose\r\n[One paragraph: what this solution does and what problem it solves.]\r\n\r\n## Scope\r\n[What is included and what is explicitly excluded.]\r\n\r\n## How It Works\r\n| Step | What happens                  | Automated? | Notes           |\r\n|------|-------------------------------|------------|-----------------|\r\n| 1    | [Plain-language description]  | Yes        |                 |\r\n| 2    | [Plain-language description]  | No         | See MANUAL-001  |\r\n\r\n## Manual Steps\r\n- MANUAL-001: [Step] — [Reason] — [Exact operator instructions]\r\n\r\n## Acceptance Criteria\r\n- AC-001: Given [context], when [action], then [expected outcome].\r\n\r\n## Dependencies\r\n- DEP-001: [External system, file, or service] — [Purpose]\r\n```\r\n\r\nRules:\r\n- Write for a non-technical reader. No jargon without explanation.\r\n- Every manual step must include exact operator instructions.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 3 complete — specification.md produced.`\r\n- 🛑 **STOP — present the specification and ask: \"Does this look correct? Please confirm before I move to the governance plan.\"** Do not proceed until the user confirms.\r\n\r\n---\r\n\r\n## Sub-Agent 4: Security, Testing and Governance\r\n\r\n**Input**: Confirmed output of Sub-Agent 3\r\n**Output**: `04-governance/governance-plan.md`\r\n\r\nProduce a governance and deployment plan. Keep total length ≤45 lines.\r\n\r\n```markdown\r\n---\r\ntitle: {PROCESS_NAME} — Governance Plan\r\ndate_created: {DATE}\r\n---\r\n\r\n# Governance Plan: {PROCESS_NAME}\r\n\r\n## Agent Boundaries\r\n| Boundary                | Rule                                       |\r\n|-------------------------|--------------------------------------------|\r\n| Allowed actions         | [Permitted operations]                     |\r\n| Blocked actions         | [Prohibited operations]                    |\r\n| Requires human approval | [Steps needing explicit sign-off]          |\r\n\r\n## Testing Checklist\r\n- [ ] Validate each sub-agent output before passing it to the next\r\n- [ ] Test all manual steps with a real operator before production use\r\n- [ ] Run against a minimal test dataset before using real data\r\n- [ ] Review CHANGE_LOG.md to confirm all new skills are correct\r\n- [ ] Verify the output folder structure after scaffolding\r\n\r\n## Microsoft Responsible AI Alignment\r\n| Principle      | How Applied                                            |\r\n|----------------|--------------------------------------------------------|\r\n| Fairness       | [How bias is avoided in outputs and decisions]         |\r\n| Reliability    | [Validation steps, error handling, new skill review]   |\r\n| Privacy        | [Data handling — no PII retained in output files]      |\r\n| Inclusiveness  | [Plain language; no domain assumptions made]           |\r\n| Transparency   | [User validates every sub-agent output; CHANGE_LOG]    |\r\n| Accountability | [Human sign-off required before production execution]  |\r\n\r\n## Deployment Guidance\r\n- Review `CHANGE_LOG.md` to verify all newly created skills before first run.\r\n- Store `agent.md`, all outputs, and new skills in version control.\r\n- Review the RAID log from Sub-Agent 1 before each new run.\r\n- Human sign-off required before running against production systems.\r\n```\r\n\r\nRules:\r\n- Every RAI principle row must be completed — state explicitly if not applicable and why.\r\n- Human approval must be required for any step that modifies production systems.\r\n- Append to `CHANGE_LOG.md`: `[{DATETIME}] Sub-Agent 4 complete — governance-plan.md produced. Agent definition finalised.`\r\n- 🛑 **STOP — present the governance plan and ask:**\r\n  > \"Planning is complete. Here's a summary of what we've produced:\r\n  > - `00-environment-discovery/environment-profile.md`\r\n  > - `01-implementation-plan/implementation-plan.md`\r\n  > - `02-business-process/sop.md`\r\n  > - `03-solution-architecture/specification.md`\r\n  > - `04-governance/governance-plan.md`\r\n  >\r\n  > Please review these documents. When you're ready to proceed with execution, say **'ready to execute'**.\"\r\n  Do not begin the Execution Phase until the user says they are ready.\r\n\r\n---\r\n\r\n## Execution Phase\r\n\r\n**Input**: Confirmed outputs of Sub-Agents 0–4 (environment profile, SOP, governance plan)\r\n**Trigger**: User explicitly confirms they are ready to execute after reviewing Sub-Agent 4\r\n\r\n🛑 **Do not begin execution until the user explicitly says they are ready** (e.g. \"ready\r\nto execute\", \"let's go\", \"proceed\"). When they confirm, read the SOP from\r\n`02-business-process/sop.md` and execute steps one at a time.\r\n\r\n**One step per turn.** After completing each step and presenting the output, stop and\r\nask: *\"Step [N] complete — [filename] is in `0N-[step-slug]/`. Ready for step [N+1]?\"*\r\nDo not proceed until the user confirms.\r\n\r\n### Per-step execution pattern\r\n\r\nEvery step follows this exact sequence. Do not skip any part of it.\r\n\r\n---\r\n\r\n#### A — Parameter check (before generating anything)\r\n\r\nBefore invoking the skill, verify every required parameter is resolved. Cross-check\r\nagainst `environment-profile.md` and the SOP shared parameters table. For any\r\nparameter that was deferred during discovery or planning (marked `[TBC]` or\r\n\"provide at runtime\"), ask now:\r\n\r\n> *\"Before I generate step [N], I need a few values that weren't available earlier:*\r\n> *— [param 1]: [brief explanation of what it is and where to find it]*\r\n> *— [param 2]: ...*\r\n> *Please provide these and I'll proceed.\"*\r\n\r\nDo not generate the artefact until all required parameters are confirmed. Never\r\nsilently skip a parameter or substitute an empty value.\r\n\r\n---\r\n\r\n#### B — Generate the artefact\r\n\r\nInvoke the skill using the resolved parameters. Follow the skill's instructions\r\nexactly — run generator scripts via Bash, do not generate artefact content directly.\r\n\r\nWrite the deliverable to a numbered subfolder continuing from `04-governance/`:\r\n- Step 1 → `05-[step-slug]/`, step 2 → `06-[step-slug]/`, etc.\r\n- Slug = short lowercase hyphenated step name (e.g. `05-create-workspaces/`)\r\n- Only the deliverable goes in the folder: `.ipynb`, `.ps1`, `cli-commands.md`,\r\n  or the specific file type described by the skill. No generator scripts, no notes.\r\n\r\n---\r\n\r\n#### C — Q1: Did the previous step run correctly?\r\n\r\nPresent the generated artefact. Then ask (for all steps after step 1):\r\n\r\n> *\"Before we move on — did step [N-1] ([step name]) run correctly?*\r\n> *— A) Yes, all looks good*\r\n> *— B) No — I hit an error\"*\r\n\r\nIf B: ask the user to paste the error message and note where it occurred. Diagnose\r\nthe issue, suggest a fix or workaround, update the SOP to note the error, and log:\r\n`[{DATETIME}] Error in step [N-1] — [error summary] — [resolution or status].`\r\nOnly proceed once the error is resolved or the user accepts the workaround.\r\n\r\n---\r\n\r\n#### D — Q2: Proceed to next step with approach confirmation\r\n\r\nAfter Q1 is resolved, propose the next step:\r\n\r\n> *\"I've updated the change log. Next is **step [N+1]: [step name]** — [one sentence\r\n> of what it does].*\r\n>\r\n> *[Approach note — see rules below]*\r\n>\r\n> *Shall I continue?*\r\n> *— A) Yes — generate the [notebook / PowerShell script / CLI commands]*\r\n> *— B) No — I want to take a different approach for this step\"*\r\n\r\nIf B: present the available alternatives for this step type (see Approach Rules\r\nbelow), including implications of each. If the user selects manual, generate\r\ndetailed UI instructions (see Manual Instructions below).\r\n\r\nUpdate the SOP step to reflect the chosen approach and log:\r\n`[{DATETIME}] Step [N+1] approach confirmed: [approach] — [reason if changed].`\r\n\r\n---\r\n\r\n### Approach rules and implications\r\n\r\nWhen proposing step [N+1] in Q2, include a one-line approach note. Use the rules\r\nbelow to determine what to say and what options to offer if the user says no.\r\n\r\n**Workspace / lakehouse creation, role assignment:**\r\n- All three approaches work: notebook, PowerShell script, CLI commands\r\n- Default to the approach chosen in the environment profile\r\n- If manual selected: walk through the Fabric portal UI step by step\r\n\r\n**Local file upload (CSV, PDF, any file from the operator's machine):**\r\n- ⚠️ **Notebook approach is not possible** — notebooks run inside Fabric and cannot\r\n  access the operator's local file system\r\n- Available options: PowerShell script, CLI terminal commands, manual upload via UI\r\n- For **large file volumes (50+ files)**, note: script and CLI upload is sequential\r\n  and slow for large batches. For 100+ files, manual drag-and-drop via the Fabric\r\n  Files section (or OneDrive sync) is significantly faster\r\n- If manual selected: provide instructions for uploading via the Fabric Files UI\r\n\r\n**Schema creation:**\r\n- Notebook (Spark SQL cell) or CLI commands work; PowerShell script works via\r\n  shell-invoked CLI\r\n- Manual: Fabric doesn't have a direct UI for schema creation in lakehouses —\r\n  recommend using a notebook with a single Spark SQL cell as the simplest option\r\n\r\n**Shortcuts (cross-lakehouse):**\r\n- CLI commands (`fab ln`) or PowerShell script work; notebook cannot run `fab ln`\r\n  natively\r\n- Manual: Fabric portal has a shortcut creation UI (Lakehouse → New shortcut)\r\n\r\n**Notebook / script execution (running something already generated):**\r\n- This step is always manual — the operator runs the artefact themselves\r\n- Provide instructions for importing and running it in Fabric\r\n\r\n---\r\n\r\n### Manual step instructions\r\n\r\nWhen a step is manual (either flagged in the SOP or chosen at runtime), do not just\r\nsay \"do this manually.\" Generate step-by-step UI instructions specific to the action:\r\n\r\n- State the exact URL or navigation path in the Fabric portal\r\n- List each click, field, and value required\r\n- Include what success looks like (what the user should see when done)\r\n- Note any common mistakes or things to watch for\r\n\r\nLog: `[{DATETIME}] Step [N] — manual approach selected — UI instructions provided.`\r\nUpdate the SOP step to mark it as Manual with reason.\r\n\r\n### CLI command log format\r\n\r\nWhen deployment approach is terminal (interactive CLI), produce a `cli-commands.md`\r\nin the step subfolder with this structure:\r\n\r\n```markdown\r\n# CLI Commands: [Step Name]\r\n_Executed: {DATETIME}_\r\n\r\n## Commands Run\r\n\r\n### [Command description]\r\n```bash\r\n[exact command]\r\n```\r\n**Output:**\r\n```\r\n[output or \"No output / success\"]\r\n```\r\n\r\n## Result\r\n[One-sentence summary of what was created or confirmed]\r\n```\r\n\r\n### SOP and CHANGE_LOG updates at runtime\r\n\r\nThe SOP is a living document during execution. Update `02-business-process/sop.md`\r\nwhenever a runtime decision changes the plan:\r\n\r\n- Approach changed for a step → update the Skill / Action column and add a note\r\n- Error encountered and resolved → add an error note and resolution to the step row\r\n- Parameter provided at runtime → fill in the `[TBC]` value in the Shared Parameters table\r\n- Step marked manual at runtime → update Manual? column to Yes, add reason\r\n\r\nEvery update to the SOP must also be logged in `CHANGE_LOG.md` with a timestamp.\r\n\r\n---\r\n\r\n### After all steps complete\r\n\r\nOnce all SOP steps are confirmed, produce `outputs/COMPLETION_SUMMARY.md`:\r\n\r\n```markdown\r\n# Completion Summary: {PROCESS_NAME}\r\n_Completed: {DATETIME}_\r\n\r\n## Steps Executed\r\n| Step | Folder | Deliverable | Approach | Status |\r\n|------|--------|-------------|----------|--------|\r\n| [N]  | [folder] | [filename] | [notebook/script/CLI/manual] | ✅ Complete |\r\n\r\n## Runtime Decisions\r\n| Step | Decision | Reason |\r\n|------|----------|--------|\r\n| [N]  | Changed from notebook to manual upload | 150 files — script too slow |\r\n\r\n## Manual Steps\r\n| Step | Description | Confirmed by operator |\r\n|------|-------------|----------------------|\r\n| [N]  | [description] | ✅ Yes |\r\n\r\n## Next Steps\r\n[Any post-execution actions: verify in Fabric UI, share workspace, run first notebook, etc.]\r\n```\r\n\r\nAppend to `CHANGE_LOG.md`:\r\n`[{DATETIME}] Execution phase complete — all [N] steps done. See COMPLETION_SUMMARY.md.`\r\n",
             },
             {
                 relativePath: "references/section-descriptions.md",
@@ -183,7 +183,7 @@ export const EMBEDDED_SKILLS = [
         files: [
             {
                 relativePath: "SKILL.md",
-                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",
+                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",
             },
             {
                 relativePath: "references/fabric-architecture.md",

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@rishildi/ldi-process-skills-test",
-  "version": "0.0.18",
+  "version": "0.0.20",
   "description": "LDI Process Skills MCP Server — TEST channel. Mirrors the development branch for pre-production validation.",
   "type": "module",
   "bin": {