Reduce user interaction; Remove App version instructions

[Steven J (tonystevenj)]

Reduce unnecessary questions during app creation by inferring sensible defaults from the user’s prompt; Remove App version instructions

• Generate the app and folder names automatically.
• Plan all requested capabilities and ask for approval once.
• Infer UI, data, and connector choices when possible.
• Scaffold in the current folder when empty; otherwise use an inferred subfolder.
• Skip optional CLI upgrade prompts during creation.
• Update related documentation and bump the plugin version to 2.0.3.
• Removed instructions related to app version

Compared public and updated plugin flows using the same prompt:

• Public 2.0.2: 7 questions
• Updated 2.0.3: 1 expected plan approval question

The agent will now infer as much as possible and generate a detailed plan for the user to review. Once the user approves it, the agent will execute the plan. My north star for this change was to make the flow as simple as possible:

User provides one prompt => Agent generates a detailed plan => User approves => App is generated

Ideally, the user only needs to take one action: approve the plan. Someone who just wants to try the plugin can generate an app in two clicks. More experienced users can work with the agent to refine the plan before approving it. I think this creates a good experience for both groups.

[Anshul Jain (Anshulmsft)]

Could we validate this behavior with a few intent-based prompts before merging? The goal is to confirm that the generated app uses the appropriate connector rather than silently falling back to mock data when the user clearly expects real organizational data.

Suggested prompts and expected behavior:

• Create an app that shows my meetings for the next 7 days. → Office 365 Outlook
• Create an app that helps me prepare for my meetings over the next 7 days and uses Work IQ to generate a summary. → Office 365 Outlook + Work IQ
• Create an app that shows my org chart, manager, and direct reports. → Office 365 Users (discovered through the generic connector flow)
• Create an app that shows my unread emails from this week. → Office 365 Outlook
• Create a simple personal habit tracker. → local/sample data is reasonable

The current phrase “only when the prompt explicitly requests external or organizational data” may be interpreted too narrowly because users usually express intent (my meetings, my emails, our org chart) rather than explicitly asking for organizational data or naming a connector.

Suggested wording:

Infer data needs from user intent. Add the appropriate connector whenever the requested experience clearly depends on user, organizational, shared, persistent, or external data, even if the user does not mention a connector. Treat phrases such as “my meetings,” “my emails,” and “our org chart” as organizational-data intent. Use local sample data only when the experience is genuinely self-contained or the data intent is unclear. Ask one focused question only when choosing incorrectly would materially change the app.

[Anshul Jain (Anshulmsft)]

Could we validate this rule with a few intent-based prompts before merging, to confirm the generated app selects real connectors rather than mock data when organizational-data intent is clear?

• Show my meetings for the next 7 days. → Office 365 Outlook
• Help me prepare for my meetings over the next 7 days and use Work IQ to generate a summary. → Office 365 Outlook + Work IQ
• Show my org chart, manager, and direct reports. → Office 365 Users via the generic connector flow
• Show my unread emails from this week. → Office 365 Outlook
• Create a personal habit tracker. → local/sample data is reasonable

“Only when the prompt explicitly requests external or organizational data” may be too narrow: users normally express intent such as “my meetings” or “our org chart,” rather than naming a connector or explicitly saying “organizational data.” Suggested wording:

Infer data needs from user intent. Add the appropriate connector whenever the requested experience clearly depends on user, organizational, shared, persistent, or external data, even if the user does not mention a connector. Use local sample data only when the experience is genuinely self-contained or the data intent is unclear. Ask one focused question only when choosing incorrectly would materially change the app.

[Anshul Jain (Anshulmsft)]

This conflicts with the shared planning policy, which requires app_generated_plan.md under <PROJECT_ROOT> before ExitPlanMode. If the current directory starts empty, writing that file first makes ms app create . fail because the CLI requires the target to be completely empty.

Since ms app create also initializes the Git repository, the plan should become part of that repository. I think the intended order should be:

1. Generate and approve the plan in plan mode.
2. Run ms app create while the target is still empty.
3. Set PROJECT_ROOT.
4. Immediately write the approved plan to <PROJECT_ROOT>/app_generated_plan.md before implementing the app.

Could we update both this workflow and shared/planning-policy.md to state that the plan dump is deferred until immediately after scaffolding for new apps? It will then be tracked with the rest of the generated app instead of preventing creation.

[Anshul Jain (Anshulmsft)]

Could we test this specifically when /create-app is invoked from the root of an existing Microsoft App?

The current rule selects a child folder whenever the current directory is non-empty. PR bic/PowerPlatform-Managed-Host#1214 allows that path and initializes Git there, so this scenario would create a nested Git repository inside the existing app. That also conflicts with Step 1, which says a clearly different app should be created as a sibling project.

The likely intended behavior seems to be:

• Existing Microsoft App root → create the new app beside it, under the current project's parent directory.
• Generic non-empty workspace/folder → create the app in the inferred child folder as described here.
• Empty folder → create directly in ..

Please verify those three scenarios against the updated CLI and clarify the folder-selection rule accordingly. At minimum, we should avoid silently creating a nested app repository inside another app repository.