How to use Project Lane

Before you start

A Project Lane run is easiest to guide when the relevant codebases and agent execution settings are ready before the request starts.

• Your source-control connection is active.
• The repositories you expect to change are enabled in Factory.
• Your agent configuration has a connected provider, model, reasoning level, and compute profile.
• You know the outcome, important constraints, and what must be true before the change can ship.

Start the lane

1. 1
   Open Sessions

   Select New to create a new durable work session.

2. 2
   Select Build

   Use Build when you want agents to make repository changes. Use Plan first when you only want to shape the work.

3. 3
   Add repository hints

   Select the likely repositories. These guide discovery but do not force scope before agents inspect the system.

4. 4
   Choose Full lane

   Select Full lane in the Build controls. You can also type /full-lane at the start of the request.

5. 5
   Describe the outcome

   Include requirements, constraints, and what done looks like. Attach supporting files when they provide useful context.

6. 6
   Submit

   Prinevo saves the request, starts the session, and hands the work to the first eligible agent.

Write a useful request

Describe the business outcome and the boundaries that matter. Avoid prescribing file-level implementation unless that choice is already a firm engineering decision.

Build role-based access control for workspace settings.

Requirements
- Owners can invite and remove members.
- Members can view settings but cannot change access.
- Record an audit event for every access change.
- Update the API, web app, tests, and rollout notes.

Done means the change is reviewed, sandbox-verified, and ready to ship.

What happens next

Specialist agents move the request through one visible sequence. The session remains the shared place for progress, artifacts, decisions, and evidence.

ProductClarifies scope and acceptance criteria.

ArchitectDefines system boundaries and the high-level design.

LeadTurns the design into an implementation and test plan.

ImplementBuilds the change in the selected cloud workspace.

Code ReviewReviews the change against repository and design expectations.

VerifyRuns the required checks and captures evidence.

Deploy PlanPackages rollout and release guidance when needed.

LearningRecords approved decisions and reusable improvements.

The exact path can pause at a decision gate. A pause is not a failed run. It means the next stage needs accountable input before work continues.

Skills used in Project Lane

Each stage starts with the specialist's platform skills and can load additional task-specific skills when the work requires them. Approved project skills add your engineering standards and playbooks without replacing the platform baseline.

Product

Requirements, scope, user journeys, acceptance criteria, and edge cases.

Architect

System design, architecture tradeoffs, contracts, data boundaries, and rollout risk.

Lead

Implementation planning, task decomposition, ownership, and test planning.

Implement

Code navigation, language and framework practices, migrations, and focused tests.

Code Review

Correctness, security, compatibility, maintainability, and deployment safety.

Verify

Test selection, local runtime checks, browser flows, and evidence capture.

Deploy Plan

Release sequencing, migrations, monitoring, rollback, and operator checks.

Learning

Decision capture, memory review, recurring gaps, and workflow improvements.

Skills are selected from the task, risk, technology, and verification surface. Project Lane does not force every available skill into every run.

Guide the run

Open the active session to see the current stage, agent activity, artifacts, decisions, and verification. When Prinevo needs judgment, use the decision panel to approve, request changes, or give specific feedback. Your feedback remains part of the session rather than becoming a separate untracked conversation.

Review before approving

• Open the current PRD, architecture, plan, diff, or verification artifact.
• Check that affected repositories and contracts match the intended scope.
• Give concrete feedback when the direction is wrong.
• Approve only when the artifact is good enough for the next stage.

When to use another lane