Quick Start · 7 steps · ~60 min

From zero to repository configured

Q: How long does the quick start take?

Less than 60 minutes from scratch to the first ruled deploy: set up the repository, write the first specification and have Devin running in your Salesforce context.

Q: What do I need before I start?

Access to org Salesforce, Git repository and Devin and Flosum credentials. Quick start covers the initial configuration and the first example spec.

Q: Is the result safe for production?

The flow is already governed: the deploy passes through Flosum's treadmill with approvals and validation. The quick start has established this trail since the first delivery, avoiding the untraceable manual deploy.

A Guide imperative and sequential — tells you exactly what to do in that order, No deviations. At the end, your repository will be cloned, configured and with Devin running a Spec Real.

Scope of this guide

This guide assumes that you have access to Devin (Cognition), Flosum installed on your org and permission to create sandboxes. If you don't, complete the prerequisites below before you begin.

Your progress

of completed

Click on each step to mark it as it advances in the guide.

I never used Devin.

Complete all steps in order. No, no, no. Skip Step 4.

I know Devin.

You can jump right into the Step 5 after Step 2.

Tech Lead

In Step 2, declare a domain per team. In Step 4, create a Shared Blueprint with the quad.

Before you start

Prerequisites

Mark each item before moving forward. Jumping a prerequisite here will lock you in the middle of the guide.

Access checklist and tools

of confirmed prerequisites

All set.

You confirmed the seven prerequisites. Advance to Step 1 →

Step 1 · ~5 min

Take the template

Objective: To have the local repository with the structure ready

1. Do the fork

Official template

Github. with/issei/sf-repo

Click Fork in the upper right corner.

Open in GitHub

2. Clone your fork

git clone https://github.com/<seu-org>/sf-repo.git
cd sf-repo

3. Check out the structure

sf-repo/
├── knowledge-base/   ← você vai editar isso no Passo 2
├── specs/            ← você vai criar aqui no Passo 5
├── playbooks/        ← não mexa ainda
└── scripts/          ← vai rodar no Passo 7

Warning: do not rename folders. Devin references these paths in the playbooks.

Step 2 · ~10 min

Tell Devin where he is.

Objective: fill the knowledge-base with real org and team data

This is the stage most important and more ignored. Devin without context is a dev without onboarding — will guess conventions, step on methadata from other teams and generate rework. Three files, ten minutes, huge difference.

Open knowledge-base/metadata-ownership.yaml and replace for its real context:

domains:
  - name: CommercePricing          # nome do seu domínio
    team: pricing-squad            # nome do seu time
    objects: [Order, Product2]     # objetos que seu time é dono
    classes_prefix: CP_            # prefixo de naming das suas classes
  - name: CustomerService
    team: cs-squad
    objects: [Case, Contact]
    classes_prefix: CS_

Single team? State one domain. What matters is that it exists and that the prefix is real.

Open knowledge-base/org-inventory.md and list your orgs real:

## Orgs disponíveis
| Alias       | Tipo     | Uso                         |
|-------------|----------|-----------------------------|
| dev-<nome>  | Sandbox  | Desenvolvimento individual  |
| qa          | Sandbox  | Validação pré-merge         |
| preprod     | Sandbox  | Homologação                 |
| prod        | Produção | Deploy final via Flosum     |

Open knowledge-base/flosum-pipeline-map.md and confirm pipeline:

## Pipeline de promoção
dev → qa → preprod → prod
Responsável pelo deploy: Flosum (nunca o Devin diretamente)

Step 3 · ~5 min

Connect orgs

Objective: To authenticate orgs individually with Web Login

Web login by alias

# Execute para cada org que vai usar
sf org login web --alias dev-<seu-nome>
sf org login web --alias qa
sf org login web --alias preprod

Why Web Login and Not JWT

In sandboxes Salesforce each dev log in individually. Individual JWT by dev is unviable operationally, and centralizing a systemic user of IC/CD would eliminate the traceability of changes by author — critical information for Audit and Smart Merge. The Web Login preserves identity without compromising the pipeline.

Verification

sf org list

Confirm the aliases appear on the list before moving forward.

Step 4 · ~10 min

Prepare Devin

Objective: to create Blueprint and configure Agents.md for Devin to understand the environment from the first session

4 ed

Blueprint

In Devin's panel, create a Blueprint pointing to the root of the cloned repository. Ensure that the environment has:

● Python 3.9+
● Node.js 18+
● Salesforce CLI (sf)
● Access to root directory of sf-repo

Official documentation

docs.devin.ai/onboard-devin/environment/blueprints

Agents. md

The file already exists in the template. Edit only these two lines:

# Contexto do agente
Repositório: sf-repo — domínio: <seu-domínio>
Org principal de validação: <alias-da-sua-sandbox>

Verification — test prompt

Leia knowledge-base/org-inventory.md e me diga
quais orgs estão disponíveis.

If Devin replies with the orgs you registered in Step 2, the environment is set Right.

Tech Lead

Create a shared Blueprint and distribute already filled Agents.md to the square. Every dev does only Step 3 web login individually.

Step 5 · ~10 min

Write your first Spec

Objective: to create a real Spec of a demand of your context

Use a demand real of your backlog — not an invented example. A Spec does not need to be perfect; needs to be honest About what you know Now. Devin will lock where Spec is vacant, and that's useful -- that's the signal to refine before he asks. Code.

Spec Full Template

# SPEC: [<TICKET>] <título da demanda>

## 1. Contexto
<Por que essa demanda existe? Qual dor de negócio resolve?>

## 2. Requisitos funcionais
- <comportamento observável 1>
- <comportamento observável 2>

## 3. Regras técnicas
- Padrão: conforme /playbooks/02_apex.md
- Cobertura mínima: 85%
- Prefixo de naming: <prefixo do seu domínio>_

## 4. Limites (out-of-scope)
- NÃO modificar Profiles ou Permission Sets
- NÃO tocar em metadata fora de <seu-domínio>

## 5. Critérios de aceite
- [ ] <critério testável e mensurável 1>
- [ ] check-metadata-ownership.py aprovado

## 6. Guardrails
- Auth: sf org login web apenas
- Deploy: --check-only em sandbox; promoção via Flosum
- Sem destructiveChanges. Sem JWT.

Saving

Save as specs/<TICKET>.md inside the repository.

Tip

If you lock in Context, start with the Acceptance Criteria. The question "how should I know Who's ready?" Answers why alone.

You want to understand why Spec has six sections? → Spec anatomy in the guide complete

Step 6 · ~10 min

Run with Devin

Objective: first real execution with Spec created in the previous step

Exact prompt to copy

Leia specs/<TICKET>.md e playbooks/02_apex.md.
Implemente apenas em force-app/main/default/.
Rode scripts/validation/check-metadata-ownership.py antes de finalizar.
Pare e me informe se qualquer guardrail falhar.

What to follow (not checklist Conclusion)

If something fails — a decision flow

Ownership error

Symptoms

check-metadata-ownership.py failure

Action

Review metadata-ownership.yaml (Step 2a) and re-execution.

Coverage error

Symptoms

Tests below the minimum defined in Spec.

Action

Refine the Spec section 3 (Rules — do not ask for more code.

Loop without progress

Symptoms

Devin tries to fix the same error 2× or more.

Action

Stop. Refine Spec. Re-execut with the start prompt of this step.

Golden rule: Never itere in the dark. If something fails twice in a row, the problem is Spec - not Devin.

Step 7 · ~5 min

Validate and deliver to Flosum

Objective: to validate locally and trigger Flosum to promote

Block 1 — Local validation

python scripts/validation/check-metadata-ownership.py
python scripts/validation/check-destructive-changes.py
sf project deploy start --check-only --target-org qa
bash scripts/salesforce/run-tests.sh

Block 2 — Promotion via Flosum (PR approved and merge on main)

npx @flosum/cli branch sync --branch devin/<ticket>-<slug>
npx @flosum/cli package deploy \
  --manifest manifest/package-deploy.xml

Critical warning

Devin doesn't run this stage. Flosum is the only official deployer for shared environments. Never ask Devin to rotate the flosum cli in QA, PreProd or Prod.

You finished the Quick Start

What to do Now

Individual Dev

Repeat cycle Spec → Devin → Flosum with your next real demand. Every iteration gets faster.

Tech Lead

Fork repository for each team. Adapt metadata-ownership.yaml by domain. Distribute the Blueprint configured.

All

Read the section of Governance in the complete guide to understand ownership in scale with multiple teams.

In-depth links

Go back to the full guide to understand why each piece.

Spec-Driven Development

You want to understand why Spec has six sections?

Spec anatomy

Architecture

You want to understand the multi-repo model?

Federated Architecture

Costs

You want to reduce cost of ACUs?

Cost optimization

In short

From zero to first deploy ruled in <60 min

A guided way out of zero to the configured repository, with the first written specification and Devin running in your Salesforce context in less than an hour — already within a governed treadmill.

Repository configured — Salesforce metadata in Git.
Written Spec — the first behavior described as the source of truth.
Devin running — agent operating in its context against spec.
Deploy ruled — promotion with Flosum governance from day one.

Practical starting point for Agent DevOps.

Frequently Asked Questions

How long does the quick start take?

Less than 60 minutes from scratch to the first ruled deploy: set up the repository, write the first specification and have Devin running in your Salesforce context.

What do I need before I start?

Access to org Salesforce, Git repository and Devin and Flosum credentials. Quick start covers the initial configuration and the first example spec.

Is the result safe for production?

The flow is already governed: the deploy passes through Flosum's treadmill with approvals and validation. The quick start establishes this trail since the first delivery, avoiding the manual "deploy without trace".