[FEATURE] Add to fabric-cli-core skill Fabric workspace initiation best practises

Use Case / Problem

Comprehensive approach is a UI-first, Git-backed, deployment-pipeline promoted model across DEV, TEST and PROD

High-level thoughts:

Build and initialize the DEV workspace in the Fabric UI. Once the item topology looks right, connect that workspace to Git from Workspace settings > Git integration, and the SKILL will inform Fabric write the native item definitions to the repo.

From there, use deployment pipelines to promote DEV -> TEST -> PROD. That keeps the UI as the primary design surface for initiation in DEV, while Git becomes the history, rollback, and review layer. Microsoft’s current guidance is aligned to this pattern: Git integration for source control, deployment pipelines for promotion, and separate workspaces per environment. See Get started with Git integration, CI/CD for pipelines in Data Factory, and the ALM tutorial.

Skill should also include YAML to capture run-time variables such as:

to runtime-operational parameters only, for example:

fabric_environment
timezone
source_system
semantic_refresh_enabled
landing_retention_days....etc.

Overall:

DEV is the only workspace where people make UI changes.
After UI changes, commit from the Fabric Source control pane.
TEST and PROD are deployment targets, not design workspaces.
If someone changes repo files directly, pull them back with Update from Git into DEV, validate in UI, then promote.

Tie this Skill to https://learn.microsoft.com/en-us/rest/api/fabric/core/git/initialize-connection

Proposed Solution

Create a best practise skill so the fabric-cli-core is not solely a toolset of silo'd function. It enables a process flow for best practise workspace initialisation.

Alternatives Considered

No response

Impact Assessment

• This would help me personally
• This would help my team/organization
• This would help the broader fabric-cli community
• This aligns with Microsoft Fabric roadmap items

Implementation Attestation

• I understand this feature should maintain backward compatibility with existing commands
• I confirm this feature request does not introduce performance regressions for existing workflows
• I acknowledge that new features must follow fabric-cli's established patterns and conventions

Implementation Notes

No response