Projects and onboarding

Cue turns a development project into a practical cockpit. Register the project once, connect its common launch points, and use the same entry point each time you work on it or prepare another machine.

Build the project cockpit

A project can expose one-click actions for its IDE, terminal, folders and URLs. The cockpit keeps these actions together, so developers do not need to remember a set of paths, bookmarks and commands before useful work begins.

Treat the cockpit as the stable front door to the project. Keep the actions focused on destinations the team actually uses, and make sure a new team member can understand what each one opens. The project remains part of Cue's Organization, Team and Project hierarchy, with memberships showing who belongs to the work.

Save launch profiles

Run and debug profiles preserve the way a project should start. A profile can launch an individual tool or orchestrate a multi-step execution when several components must come up in order. Cue can also attach to Visual Studio as part of the development flow.

Saved profiles reduce the gap between knowing that a project runs and knowing the exact sequence needed on a particular morning. They also give a new machine the same launch shape as an established one.

Check workspace readiness

Before starting, use workspace readiness to inspect dependencies on the current machine. The readiness view shows what is missing instead of allowing the first build or launch to reveal it later.

Readiness is specific to the machine running Cue. The project definition can sync, but each computer still needs its own tools and dependencies. Check readiness after registering a project, after changing its expected setup, and whenever a developer moves to a new machine.

Onboard a machine in one flow

Cue can start machine onboarding from the project itself. For a complete setup, the eight-step Create Local Environment wizard compiles activities such as getting the code, restoring it and configuring it into an executable run. The developer follows a guided sequence rather than translating a static checklist into local actions.

Use blueprints when the same project structure or setup procedure should be shared through the workspace. A blueprint provides a reusable starting point, while the executable run makes the setup concrete on the current computer.

Keep the path repeatable

After onboarding, verify readiness again and use the saved launch profile to start the project. If the setup needs a correction, update the shared project, blueprint or procedure so the next machine receives the improved path.

For the environment wizard and blueprint workflow, continue to the environment setup guide. For operational steps after launch, see the procedures and runbooks guide.