generate-project-mixed

name	generate-project-mixed
description	Workspace project (IDE + collaborator + starter files). Use when the project is technical and benefits from collaborator support layered between coding tasks. Not for soft-skill conversation or role-play practice; use generate-project with scene_actor roles for those.
uses-phases	true
phases	brainstorming, project_info, blueprint, generation, milestone_design

generate-project-mixed

Authors workspace projects with collaborator support and starter files. The project is technical (IDE + collaborator + starter files), with milestone work broken into concrete coding microtasks.

RULE 0: Phase discipline

You MUST complete phases in order: brainstorming → project_info → blueprint → generation → milestone_design. Do NOT skip phases. Do NOT call tools from later phases until the current phase is complete.

Phase: brainstorming

Goal: Mirror the user's request and confirm the project scope.

Actions:

1. Reflect back what the user wants to build.
2. Mention that the project will be a workspace project (IDE + collaborator + starter files).
3. If the scope is clear, call choose_user with two real branches: proceed with the proposed scope, or let the planner revise/narrow the scope. The client auto-appends the only free-text Other card for custom input. Use 2-5 options when you are offering broader real scope branches.

Tools: choose_user for scope choices and confirmation choices. Do not create one-option user interrupts; make confirmation a two-branch choice.

Exit condition: User confirms.

Phase: project_info

Goal: Gather project metadata.

Actions:

1. Call update_title(new_title=...) with the confirmed short project title.
2. Call update_description(new_description=...) with 1-2 sentences describing what the user will build and practice.
3. Call set_project_tags(labels=["Full", "Shared-Sandbox"]) with exactly one label from each required tag group; workspace projects use Full runtime and the shared sandbox topology so collaborator actions affect the project workspace the user sees.
4. Call generate_cover(keyword=...).
5. Call finalize_project_info().

Tools: update_title, update_description, set_project_tags, generate_cover, finalize_project_info, get_project_info

Exit condition: Project metadata finalized.

Phase: blueprint

Goal: Author the single collaborator role and milestones.

Actions:

1. Call list_roles and identify the pre-seeded user and Instructor.
2. Call create_role exactly once to create the code collaborator. The saved role name is canonicalized to Collaborator; put project-specific flavor in description and system_prompt.
   • If a collaborator already exists, do NOT create another. Use the existing collaborator role and optionally refine it with update_role.
   • When assigning work, reference the saved role name or role ID (Collaborator, You, Instructor), never the lowercase role type string collaborator.
3. Draft 3-5 milestones. Each milestone:
   • runtime_mode: workspace
   • title: short, action-oriented
   • description: 2-3 sentences, what the user will build
   • success_criteria: 2-4 concrete checkpoints
4. Call create_milestone for each milestone in sequence.

Tools: list_roles, create_role, update_role, create_milestone

Exit condition: All milestones created.

Phase: generation

Goal: Generate starter files.

Actions:

1. Write IDE/code starter files with sandbox_write_file: source files, configs, tests, fixtures, assets, and a minimal starter-files/README.md explaining how to run the code.
2. If the project needs learner-facing notes, collection rubrics, experiment logs, drafts, or checklists, create them with publish_document(category="project", ...) instead of writing Markdown/text files into starter-files or workspace.
3. Keep starter files code-adjacent. Do not use IDE files as a substitute for the Document pane.

Tools: sandbox_write_file, sandbox_read_file, publish_document

Exit condition: Starter files generated.

Phase: milestone_design

Goal: Author microtasks for each milestone.

Actions: For each milestone in sequence:

1. Call create_microtask 3-5 times to break the milestone into concrete coding tasks.
2. Every microtask must be executable in the actual OpenMAIC workspace: workspace files/IDE for code, project documents for learner-facing docs, sandbox terminal, sandbox browser/Playwright, selected shared document provider tools, learner-submitted image evidence, or chat/status interaction. Notion/Feishu documents registered in the Document pane are read/fetch-only unless a loaded tool explicitly says it creates or edits provider docs. Do not assign collaborators to arbitrary desktop GUI work, private account flows, phone/device actions, purchases, real messaging/email, or third-party deployment without credentials.
3. For every collaborator-owned microtask, name the operating surface in the description or role prompt: "workspace code files", "project document", "sandbox terminal", "Playwright/local browser preview", "built-in markdown document", "project-scoped Notion/Feishu read", "attached image evidence", or "chat/status only". If you cannot name the surface, rewrite the task as a local prototype/script/test, project document, browser research pass, image-evidence review, or user-owned manual step with AI review. Tools: create_microtask

Exit condition: All milestones have microtasks.

Critical rules

1. Roles output: 1 user + 1 instructor + 1 collaborator. ZERO scene actors.
2. Milestones advance via microtask completion. Keep every milestone grounded in concrete tasks the learner can perform in the workspace.
3. Phase discipline: Do NOT call tools from later phases before the current phase is complete.
4. Capability fit: Microtasks must stay inside the client capability contract. The planner may design manual/user-owned steps for things outside the client, but collaborator-owned work must be something the local workspace can actually execute or inspect.
5. Documents vs IDE files: Learner-facing notes, drafts, logs, checklists, rubrics, and reports are project documents. Starter/workspace files are only for code/IDE artifacts and minimal run instructions.
6. Image evidence: For manual or visual inputs, ask the learner to submit photos/screenshots at meaningful checkpoints and design AI review around that evidence.