Product documentation
Updated September 27, 2026

Project Assistant: Create Projects, Endpoints, Tests and Workflows

Build a project from a conversation: ask the Project Assistant to create features, endpoints, tests, requirements, data sets, workflows or authentication, then review each proposal before it is created.

View as Markdown

Applies to: All editions (resource limits and edition features still apply) · Web app / Desktop app · Permission to create the item you ask for · Requires an AI provider configured under AI Settings

Overview

You can build a Shift-Left Studio project from a conversation. Ask the Project Assistant to create a project, add a feature or an endpoint, write a test, record a requirement, store a document, build a data set, assemble a workflow, or set up the project's authentication. Each request becomes a proposal card that you review and accept, exactly like the other assistant actions described in Project Assistant: Proposals You Approve.

The assistant creates each item through the same path as the screen that normally creates it, so the same checks, limits and audit entries apply. It also follows one firm rule: it writes only what you told it or what your files say. It never invents a request body, a response schema, a mock response or a workflow step to fill a gap. When something is missing, it asks, or it tells you exactly what is missing.

Key concepts

TermWhat it means
GroundedEvery field in the created item came from your words, an attached file, or an existing item. Nothing is guessed.
GapSomething the assistant could not create because the information does not exist yet, such as a workflow step with no test. Gaps are named, never filled with placeholders.
Use caseA requirement that records a sequence of calls in order. Studio can build a workflow from it.
Settings vs secretsFor authentication: settings (grant type, URLs, client ID, header name, username) can come from chat; secrets (passwords, keys, tokens, client secrets) never can.

Before you begin

  • You can open the assistant (see Project Assistant: Ask Questions About Your Project).
  • You have permission to create the kind of item you ask for.
  • Edition limits apply, for example the maximum number of endpoints or workflows in the Free edition.
  • Keep your specification or requirements document at hand if you want to attach it.

Step 1 — Create the project structure

A project. Ask "Create a project called Orders API". Accepting creates the project, and the conversation moves to it. A project with no endpoints cannot hold tests, so the card suggests importing a specification or adding endpoints next.

A feature. Ask "Add a feature called Payments". A new feature holds no endpoints until you add or import some. If the name already exists, the assistant says so.

An endpoint. Ask "Add an endpoint for POST /orders in the Orders feature".

  1. The assistant needs a method (GET, POST, PUT, PATCH or DELETE), a path and a feature. It asks for any that are missing.
  2. The card lists what will be written. Only parameters, request bodies and responses you described are included; everything else is left empty.
  3. Accept the card. The endpoint appears in the project tree.

Important: Leaving the schema empty is deliberate. A request body or response the assistant invented would become the shape every generated test is measured against. Describe the body, paste a fragment, or import the specification if you want a full schema.

Endpoints for SOAP, GraphQL, JSON-RPC and WebSocket-RPC cannot be created from a sentence. They need details only a specification has, such as a SOAPAction and envelope, or a GraphQL operation and type. The assistant refuses these by name and points you to importing the WSDL, schema, OpenRPC document or gateway descriptor instead.

Step 2 — Import a specification or store a document

Import a specification.

  1. Click the paperclip button (Attach a specification or a document) and choose a .json, .yaml, .yml, .wsdl, .xml, .graphql or .gql file, or drag it into the panel.
  2. Ask "Import this specification".
  3. Review the card and accept. The endpoints are created. Nothing is auto-approved.

An attached specification is held for about 15 minutes and only you can use it. If it expires, attach it again.

Store a requirements document.

  1. Attach a .pdf, .docx, .md, .txt, .csv or .xlsx file, or paste text and ask "Save this as a document".
  2. The document is stored in the project's documents with the usual duplicate checks and size limits. It is not read until you ask.
  3. Ask "Parse this document" to extract requirements. Reading a document takes minutes; the card follows it until it finishes. You can also ask it to parse several documents; they are queued and read one after another.

Step 3 — Write tests, requirements and data

A test. Ask, for example, "Create a test for POST /orders that sends quantity 0 and expects a 400".

  • The test passes the same quality checks as a generated test before it is offered. A check on a field the endpoint cannot return is dropped, and the card tells you why.
  • The status check comes from the test's intent (a positive test expects success, a negative test expects a rejection), never from a response.
  • WebSocket-RPC calls have no HTTP status, so those tests get no status check. A WebSocket-RPC test with nothing else to check is refused.
  • Creating a test runs nothing. Run it when you are ready.

A requirement. Ask "Record a requirement: an order must have at least one line item". It is recorded as yours and needs no approval.

A glossary term, business rule or traceability link. Ask "Define 'SKU' as the stock-keeping unit", "Add a rule to REQ-… that quantity is at most 100", or "Link this test to REQ-…". A new definition of an existing term replaces the old one; the card says so.

A data set. Ask "Create a data set called Users with columns email, role, INVALID_email and EXPECTED_STATUS" and give the rows.

Column namingMeaning
email, roleInput values sent in the request.
INVALID_emailA negative input for the email column. It must shadow a real column, or the assistant refuses it.
EXPECTED_STATUS, EXPECTED_data.idExpected results. They are checked, never sent.

Nothing uses a data set until a test is bound to it. Ask "Run the create-user test once per row of Users" to bind it.

A data source. The assistant records where data comes from (host, database, table). A password, token or connection string that contains one is refused; add it on the Data Sources screen.

Step 4 — Build a workflow

A workflow chains several test calls and carries values between them, for example the order ID from "Create order" into "Get order". There are three ways to ask for one.

From endpoints or tests

Ask "Build a workflow: create an order, then fetch it, then cancel it".

  1. The assistant finds the endpoints, orders the steps, and picks the existing test for each step.
  2. It wires the data: when a later step needs a value (such as orderId) that an earlier step returns, it adds the connector and the extraction on the earlier step that produces the value. A connector with no extraction would look right and carry nothing.
  3. The card previews the steps in order, the test each calls, and the values passed between them.
  4. If a step has no test, the card lists it under "One thing was left out" (or "N things were left out") with the endpoint named. It never adds a placeholder step.

From a sentence

Describe the journey in order. Each clause is matched to one endpoint, in the order you wrote them. A clause that matches nothing is reported as unmatched, never guessed, because a plausible wrong step is worse than a missing one: it would be run.

From a use-case requirement

If a requirement records ordered steps (a use case), ask for it by name: "Build the workflow for the Place Order use case".

  • If every step has a test, the card builds the workflow from the existing tests.
  • If a step is missing, the assistant says which kind of gap it is:
GapMeaningWhat to do
No testThe endpoint exists but has no test yet.Generate tests for it (see below).
No endpointThe requirement names a call your specification does not contain.Add the endpoint, import the specification, or correct the requirement.

One accept: generate the missing tests, then build the workflow. When the only gaps are steps with no test, and those endpoints are in the current project, the assistant offers both in one card. The card shows the generation dry run and the name of the workflow that will follow. Generation runs in the background; the workflow appears a few minutes later without you asking again. If a step still has no test when generation finishes, nothing is built and you are told why. If any step has no endpoint, the whole request stays a refusal until the specification is fixed.

A workflow built from a use case is never overwritten if you edited it by hand.

Across projects

Workflows can span projects. Name the other project, or use @ mentions, and the assistant reads and wires steps from every project you can open. Its first step's project becomes the workflow's home project.

Step 5 — Configure authentication

You can hand the assistant an authentication setup the way you would read it to a colleague. Every method Studio supports is available: OAuth 2.0 (all grant types), API key, Basic, Bearer, AWS Signature v4, OAuth 1.0a, Hawk, JWT, a fixed header or query parameter, a pasted cookie, a cookie login flow, mTLS, sign-in with steps, and no authentication.

  1. Paste the settings, for example a block of Grant type: Authorization Code, Auth URL: …, Access Token URL: …, Client ID: …, Scope: … lines, and name the environment.
  2. The card shows which method and settings it understood, which environment the profile will authenticate, and what is still needed.
  3. Accept. The profile is created and becomes the active profile for that environment; every run there now uses it.
  4. If a secret is still needed, the outcome reads "Still needed: … Paste it on the Authentication screen." Click Open Authentication settings. The profile opens in edit mode, with the missing field highlighted.

Why secrets are refused. Your message is stored as part of the conversation and re-read on later turns, so a secret typed into it would sit in the transcript. The assistant never stores a client secret, password, key value, token, passphrase or cookie from chat. It names the field it did not take and sends you to the encrypted Authentication screen instead. If you already pasted a secret, the card also recommends issuing a new one at your provider; not storing it protects the credential store, but it cannot un-send your message.

The callback (redirect) URL is this installation's. The card reports the redirect URI Studio uses. Register that value at your identity provider, not the one from another tool's notes, or the provider will reject the sign-in.

Signing in. For Authorization Code and Device Code grants, ask "Sign me in".

  1. Accept the sign-in card.
  2. Click Sign in now (or, for device code, note the code and click Open the sign-in page).
  3. Sign in at your identity provider. The card reads "Waiting for you to sign in…" and finishes on its own.

The token is stored and refreshed on the server. Neither you nor the assistant ever sees it. A public (PKCE) client needs no secret at all, so it can be set up and signed into entirely from chat. A confidential client needs its secret pasted on the Authentication screen first; the card tells you so before you go to sign in.

For sign in with steps, accepting runs the login steps up to the one-time code. You type the code on the Authentication screen, never in chat.

If you asked for more ("Set up OAuth and then run the smoke tests"), the assistant proposes the next step once the sign-in completes.

Activating an existing profile. Ask "Use the Partner Key profile on Staging". The card says which profile it replaces, since each environment has one active profile. A profile that cannot yet authenticate is not activated, because every run on that environment would then fail with authentication errors that look like an outage.

The assistant will not hand out an access token, sign your team out, edit a saved profile's credentials, or delete a profile. Do those on the Authentication screen.

Troubleshooting

SymptomWhy it happensWhat to do
"Which feature should it go in?"An endpoint needs a featureName one, or ask to create it first.
SOAP/GraphQL endpoint refusedThese need a specificationAttach and import the WSDL or schema.
Test created with fewer checks than askedA check targeted a field the endpoint cannot returnRead the reason on the card; correct the field or the endpoint's schema.
Workflow card lists gapsA step has no test, or no endpointGenerate the missing tests, or fix the specification or requirement.
Runs fail with 401 after setupThe profile is active but a secret is still missingClick Open Authentication settings and paste it.
Sign-in rejected before a password promptThe wrong redirect URI is registeredRegister the URI shown on the card.

Best practices

  • Import a specification instead of describing endpoints, whenever one exists.
  • Attach the document the requirement came from; the assistant can then cite where each requirement was found.
  • Build workflows after the steps have tests, or use the one-accept generate-then-build offer.
  • Paste authentication settings, then add secrets on the Authentication screen only.

FAQ

Does creating something from chat skip any checks? No. Every item goes through the same path as its screen, with the same validation, limits and audit log.

Will the assistant fill in a response schema for me? No. Describe it, paste it, or import the specification.

Next steps

Still stuck?

Tell us what you’re trying to accomplish and we’ll point you to the right setup—installation, auth, or CI/CD wiring.