This describes the target ABCD self-service flow. Today, repo provisioning and Vercel wiring still go through the AI Ops team — submit a request to the AI Operations Service Desk to get started. See the future plan for what we’re building toward.
Prerequisites
An AI coding assistant
Either Claude Code (already installed for most colleagues — see Tools › Development) or OpenAI Codex CLI (npm i -g @openai/codex, then run codex in your project folder).
GitLab group membership
Membership of gitlab.com/docebo/internal-citizen-developers. No GitLab account? See the non-engineering path — AI Ops can set up access for you.
RequiredGitLab local authentication
You need glab, the GitLab CLI, installed and authenticated before you can clone or push. Install it with brew install glab on Mac (or download from the GitLab CLI releases page), then run glab auth login, select gitlab.com as the host, and sign in through your browser using Docebo SSO. Once done, glab configures your local git credentials automatically.
Vercel team membership
You need to be on the Docebo Vercel team (Pro plan with SSO) so the project is created under the right account. Request access through the standard IT app access form.
Request via CorpITLocal Node.js + Git
A current Node.js (LTS) and Git installed locally. The AI assistant runs commands on your behalf, but they still need a working local environment. Not sure whether you have it or how to install? Ask your LLM assistant, or follow this guide for Git installation.
StandardFrom idea to live URL
This is a sequential process: each step builds on the previous one. The AI assistant can run almost every command for you — when you see a snippet, you can paste it as-is or just describe the goal and let the tool execute.
Scope the app — run the intake checklist
Before any code, run the docebo-app-checklist Claude Code skill. It walks you through a 7-question scoping interview (audience, business criticality, data sensitivity, storage, read/write integrations, AI/LLM usage), produces a DOCEBO_APP_CHECKLIST-<name>.md spec in your project folder, computes a risk tier, and submits a service desk ticket to the AI Ops team for review.
How to invoke: in Claude Code, type “scope my app” or “/docebo-app-checklist”.
What happens next: AI Ops reviews the ticket and, once approved, provisions two things on your behalf: a GitLab repository from the standard citizen-developer template, and a Vercel project linked to that repo with CATO protection pre-applied and a CI/CD pipeline that automatically deploys the latest code whenever main is updated. You will receive the repo URL and Vercel project access via the ticket before you can continue to Step 2.
Codex CLI? Skills are a Claude Code feature. If you’re on Codex, you can still import the folder into your parent folder and direct the agent to use the skill, as it is a standard format.
Skill not available? AI Ops manages skill distribution — submit a ticket to the AI Operations Service Desk if you don’t see it in Claude Code.
Already started building? No problem — the skill’s project-scan phase reads existing code and pre-fills its answers. You can run it on an existing project to retrofit a checklist and trigger the approval ticket.
Clone your AI Ops-provisioned repo
Once AI Ops shares your repo URL, clone it to your local machine. The repo comes pre-configured with the standard folder structure, a .gitignore, branch protection on main, and the required security checks. How you start depends on where your project currently lives.
Greenfield — you have no existing code yet
Clone the repo, open it in your AI assistant, and start building from scratch.
git clone <url-from-ai-ops>
cd <repo-name>Then open Claude Code in that folder and describe what you want to build. The assistant will scaffold the project inside the existing repo structure.
Brownfield — you already have code locally
If you built something locally before going through the intake process, you cannot simply point your existing repo at the new remote — the AI Ops template contains governed files that need to be preserved. The safest approach is to clone the AI Ops repo and let the assistant bring your code into it.
Before you do that, it helps to understand what’s in the template and what to do when the same filename exists in both places. There are three categories:
Files AI Ops owns — keep the template version, do not overwrite
These contain pipeline configuration and governance instructions that apply to every citizen-developer project. If your existing project has a file with the same name, the template version takes precedence.
| File | What it does |
|---|---|
.gitlab-ci.yml and anything in .gitlab/ | Defines the Wiz security scan, AI code review, and the auto-deploy pipeline to Vercel |
agents.md / cloud.md | Governance instructions for AI coding assistants — tells the assistant how to behave inside this repo |
Files that need combining — both versions have something useful
These files exist in both your project and the template, and both versions matter. The assistant can merge them for you.
| File | How to combine |
|---|---|
.gitignore | Keep all entries from both — the template has the governed baseline, yours may have project-specific additions |
.env.example / sample.env | Start from the template version; add any extra variable names your project defines |
README.md | Keep the template structure; replace the placeholder app description with your own |
Everything else is yours
Your source code, components, framework config, package.json, and any other project files come across as-is. The assistant will copy them in without touching the governed files above.
How to do the merge
Clone the AI Ops repo into a new folder, then open Claude Code in that folder and paste this prompt — substituting the path to your existing project:
I have an existing project at <path-to-your-project> that I need to bring
into this repo. The repo was provisioned by our AI Ops team and contains
governed files for security scanning and deployment — preserve those exactly
as they are. For any files that exist in both places, use your judgement to
combine them sensibly. Copy everything else from my project across, and ask
me before overwriting anything you're unsure about.The assistant will compare the two folders, flag any ambiguous cases, and complete the merge without touching the governed files.
Lovable project — you built in Lovable and want to deploy it
Extracting a Lovable project into the governed GitLab repo is a separate process handled in coordination with AI Ops. Submit a request to the AI Operations Service Desk and reference your intake ticket — the team will guide you through connecting the Lovable project to the designated repo.
Secrets stay out of code and out of chat. API keys, tokens, passwords, connection strings — anything sensitive — must live in a local .env file that you fill in by hand, and .env is already listed in the repo’s .gitignore so it can never be pushed to GitLab. Don’t paste secret values to the assistant either: refer to them by the env-var name (e.g. process.env.STRIPE_API_KEY) so the assistant writes the wiring without ever seeing the actual value. Anything that lands in the repo or in the chat context is effectively leaked.
Develop locally with the AI assistant
Iterate inside the cloned repo. Run the dev server, ask the assistant for changes, and smoke-test in the browser at localhost. Do not test new features against a live Vercel deployment — cloud deploys are for governed releases, not iteration.
The assistant will keep your work on a feature branch — never commit directly to main, which is branch-protected.
Commit and push to a feature branch
When your changes are ready, ask the assistant to create a branch, commit, and push.
Example prompt:
Create a feature branch called feat/<short-name>, commit what we changed
with a short message, and push it to GitLab.What the agent will run for you
git checkout -b feat/<short-name>
git add .
git commit -m "<message>"
git push -u origin feat/<short-name>Open a Merge Request to main
When you push a new branch, GitLab prints a direct link in the terminal output to open a Merge Request — click it, add a short description of what changed, and submit.
remote: To create a merge request for feat/<short-name>, visit:
remote: https://gitlab.com/docebo/internal-citizen-developers/<repo>/-/merge_requests/new?...Once the MR is open, the pipeline kicks off automatically: Wiz security scan, AI code review, dependency checks. See workflow step 4 for the full picture and the review SLA (4–14 days depending on data sensitivity).
While the MR is under review, complete Step 6 — your environment variables must be in place before the MR is merged, as merging to main triggers an automatic deployment.
Add your environment variables to Vercel
AI Ops created and owns the Vercel project — you do not need to set up or configure the deployment itself. Your only task here is to add your app’s secret values so they are available when the first deployment runs.
Open the Vercel project (linked in your intake ticket), go to Settings → Environment Variables, and add each variable your app needs. Start by checking the .env.example file in the root of your repo — it lists every expected variable name as a placeholder. The names there are exactly what you need to add in Vercel; you supply the values.
Where to find secret values:
- Credentials your team owns (internal API keys, service tokens) — ask the service owner or team lead. If access needs to be requested, use the IT service desk.
- Third-party service credentials — generate them in the provider’s dashboard, the same place you would normally source a local
.envvalue. - Not sure what your app needs? Ask the AI assistant: “What environment variables does this app require?” — it will read the code and list them.
Never paste secret values into the repo, the assistant chat, or any shared document. Use the Vercel project settings UI as the sole entry point for production secrets.
Confirm CATO protection is active
CATO network protection is applied automatically to all citizen-developer apps in the Docebo Vercel team — you do not need to configure Trusted IPs yourself. What you do need to do is confirm it is working correctly after your first deployment.
Test it in both directions: open the production URL while connected to the corporate network via CATO (the app should load), then open it again from a personal hotspot or off-network connection (you should see a Vercel access challenge). If both behave as expected, the protection is active.
If the app loads off-network, contact the AI Ops team — the Trusted IPs configuration may need to be applied to your project manually.
Verify the deployment
With CATO confirmed, do a final smoke test from the corporate network: walk through the core flows of the app, check that all environment variables resolved correctly (no missing-key errors), and confirm the UI looks as expected. If everything checks out, you’re done.
For any issues after deployment, the Vercel project dashboard shows build logs and runtime logs per deployment.
What’s next
- The big picture: Citizen developer infrastructure — why this framework exists and how the pieces connect.
- Start with intake: Project intake skill — the conversational scoping session that produces the assessment doc.
- Approved tools: AI tools › Development — what you can use during build time.
- Network access: Default network access — behind CATO — how CATO Trusted IPs work and what the three IP ranges are.