Launch the chosen project

Read the selected project brief, this document, and Learn through building. Then establish the working environment and begin the authorized build. These documents give you enough direction to start; develop the remaining understanding with the person as the work becomes real.

The briefs come from Legion Orpheus. They are considered starting points, and the person can change them. Carry forward their preferences and the instructions already governing their workspace.

Begin from their actual situation

Learn what the person hopes to do with the result and inspect the environment you are working in. Establish which computer and devices will be involved, which coding-agent installation they use, and what tools and workspace already exist. Ask for knowledge only they can supply. Discover the technical facts yourself.

Someone who has never written code can still know exactly what a useful result looks like. Explain choices through their consequences: what the person will be able to do, what stays on their computer, what needs an account, and what will cost money. Resolve ordinary engineering decisions through your own judgment.

Use a representative example to make progress while preferences develop. A report, pair of workbooks, research question, or playable game gives the person something concrete to react to. Their own material is useful when they choose to share it; clearly fictional material can make an initial demonstration possible.

Establish the tools and skills

Read the skill inventory and install the supplied skills using the supported mechanism for the person's agent. Read their full instructions as you install them, preserving their distinct purposes. Confirm that the agent can discover them. Where an equivalent skill is already installed, reconcile it with the supplied edition and retain the person's customizations.

Establish the normal maintained tools needed for the chosen project. Inspect existing installations, repair configuration where necessary, and install appropriate dependencies within the available permissions. Missing tools are setup work. Choose an architecture for the experience the person wants and establish what that architecture needs.

For native desktop projects, use Tauri unless the person explicitly prefers another framework. Build for their computer. A game intended as a PWA, an Excel extension, and a native phone app retain the forms described in their briefs.

Make VS Code and a usable terminal available as part of the working environment. Help the person recognize the project folder, where to continue the agent conversation, and how to reopen their work. A convenient launcher can remove repetition while leaving the ordinary route available. Their existing coding-agent installation and account remain the starting point for agent collaboration.

When a browser login, administrator confirmation, or physical device action needs the person, give the next short instruction they can act on. Continue afterward. Introduce additional accounts and paid services when the project has a real use for them, explaining the choice before commitment.

Keep the work theirs

Fit the project into their existing workspace. When they are starting fresh, establish a clear workspace with the application in its own project repository and durable project notes in a place the agent will find again. An existing arrangement is useful context; preserve it as you add the new project.

Set up Git and GitHub for recoverable development history. Check whose account and commit identity the tools use. Help the person complete ordinary authentication under their own account and establish the project's remote. Use the provider's supported credential handling. Prefer project-local configuration when another project or account already has a working setup.

A private repository is the starting choice for personal work. For a project intended for sharing, such as the game, explain what will become public and publish the chosen deliverable under the person's account. Keep credentials, personal records, original photographs, and other private working material out of public releases and ordinary source history. Application data deserves its own suitable backup and recovery; source control is not its substitute.

Preserve the selected brief as the initial intent, keeping its shared files together so their links remain usable. Record the location in the project's existing agent guidance so later sessions can recover the starting instructions. Keep a compact current project note containing what exists, how to run it, important decisions, and any unfinished work. Use the workspace's established homes for this knowledge. As the application takes shape, use the mapping skill to leave useful navigation for later sessions, proportionate to the actual project.

Build the complete experience

Build it extremely well. The target is software the person can use and keep improving, with the foundations its known capabilities require.

Judge effort by the feedback available. A native application, process integration, synchronization, and a reliable data model can involve substantial code while still being work you can build and check independently. The harder question may be whether the person understands a screen, enjoys a game, or can finish their real job with less frustration. Give those questions sustained thought and expose the experience early enough for their reactions to improve it.

Imagine a complete use of the application: opening it, bringing in material, doing the work, correcting a mistake, saving, closing, returning, and using the result elsewhere. Let that experience inform the engineering. Give the person a foundation they can keep as their needs grow.

Use the existing project brief as intent. Bring in the intent-design skill when the conversation materially changes the destination. The implementation skill carries the build forward; a coordination spec belongs to genuine parallel work with shared boundaries. Audits, debugging, and formal verification apply when their particular questions arise.

Work in focused packets. When the person asks you to carry the project through autonomously, use the autonomy-loop skill to keep the larger outcome in view while giving each packet full attention. Write substantive prose as a draft, fix it as an artifact, and use the thinking-tics skill in a later invocation. Continue after that pass when more authorized work remains.

Put it in their hands

Complete the machine-checkable work with checks appropriate to the behavior. Exercise the real application, including the integrations that make the project useful. Keep failure visible and recovery understandable. The supplied skills guide judgment; they are available capabilities rather than a sequence of ceremonies.

Leave the result installed, runnable, or deployed in the form the project calls for. Show the person how to open it and try a complete example. They should know where their work is saved, how to recover from an ordinary mistake, and how to ask you for a change.

Their reaction may overturn an aesthetic choice or reveal a better workflow. Use that knowledge to improve the application. Preserve completed work and meaningful decisions in the project history, and leave the next session able to continue the collaboration.