Support for a new type of agent—skills instead of topics

[lukoplt]

Problem or Use Case

Currently, the skill supports the creation of topics (the original agent type) instead of skills (the new agent type).

Proposed Solution

Ideally, the best solution would be to separate the plugins for creating the new and original agent types, since they have different structures.

Alternatives Considered

No response

Area

Skills

Additional Context

No response

[lukoplt]

I have now validated the workspace differences against a live Copilot Studio environment.

Verified environment:

• Copilot Studio VS Code extension: 1.6.68
• New agent template: cliagent-1.0.0
• authoringShape: 2

The important difference is not only UI terminology. The persisted workspace structure is different:

Capability	Legacy agent	New agent experience
Instructions	agent.mcs.yml	settings.mcs.yml under configuration.agentSettings.instructions.segments
Agent skills	Topics / dialogs	behaviors/*.mcs.yml with kind: InlineAgentSkill
Tools	actions/	capabilities/tools/
Knowledge	knowledge/	capabilities/knowledge/

I also confirmed that LSP validation alone is not sufficient for the new shape. Unknown values under configuration.agentSettings can pass validation but be silently dropped during push. I verified persistence using:

1. push the modified agent;
2. clone the agent into a fresh scratch workspace;
3. compare the expected YAML content.

Proposed implementation

Rather than maintaining two mostly duplicated plugins, I propose keeping one plugin and detecting the agent layout from the cloned workspace.

The first PR would:

1. add deterministic legacy/new-layout detection;
2. add an add-agent-skill authoring skill that creates behaviors/<name>.mcs.yml with kind: InlineAgentSkill;
3. make instruction editing layout-aware;
4. preserve the existing legacy topic workflow;
5. fail safely when the layout cannot be identified;
6. add legacy and new-layout fixtures and scenario evals;
7. document the required round-trip persistence verification.

Tools, knowledge sources, connections, and variables could follow in separate PRs after the core approach is reviewed.

I have a locally verified reference skill documenting the exact persisted YAML shapes and the failure modes encountered during testing.

Would this single-plugin, layout-aware approach be acceptable, or would the maintainers prefer a separate plugin for the new agent experience?

[deldos]

Adding another independently observed requirement for the new agent experience.

We have also validated the new workspace shape where attached agent Skills are represented under behaviors/ using kind: InlineAgentSkill.

The important requirement for us is not only authoring an InlineAgentSkill, but making the complete Skill lifecycle deterministic enough for source control and CI/CD.

Pulling an already attached Skill gives useful source-level representation. The remaining problem is reliable write-back. In testing, isolated changes within Skill content/reference files have not always behaved like ordinary tracked agent changes: some changes can persist, while other isolated changes are not detected/applied deterministically. That makes it unsafe for automation to assume that a successful general agent push also proves that a Skill-only change was deployed.

We would therefore suggest treating first-class Skill lifecycle support as part of this enhancement.

A useful target would be:

local Skill package -> attach/create -> change detection -> update/replace -> pull-back verification

with the Skill operation working independently of unrelated agent-setting changes.

Suggested acceptance criteria:

• attach/create an agent Skill from a local Skill folder or supported package containing root SKILL.md;
• detect changes to SKILL.md and referenced Skill files;
• push a Skill-only modification deterministically;
• explicitly replace or remove a Skill;
• freshly pull/clone the agent and reproduce the deployed Skill content;
• provide a clear error when a Skill component or file type isn’t supported by the synchronization surface;
• work headlessly from CLI/automation without requiring portal Replace/Upload;
• document which on-disk representation is a supported authoring contract versus generated/internal representation.

This would make the new agent experience genuinely agent-as-code + Skills-as-code, rather than agent-as-code with a remaining manual Skill deployment checkpoint.

This also complements the broader automatic push discussion in #42, but the requirement here is specifically deterministic InlineAgentSkill lifecycle support.