FlightBrief
Brief your AI before it flies in your org.
FlightBrief writes a brief of your Salesforce org for the AI assistants and people who build in it: your objects and how they relate, the conventions your code really follows, your automation, and your own standards. 100% native and free.
An AI assistant knows Salesforce. It does not know your org.
Ask an assistant to add a field, a trigger or a Flow and it writes good, general Salesforce code. Then it puts logic in a trigger your team keeps one line long, queries outside the selector classes everyone else uses, misses the validation rule that will reject the save, and invents a field name close to the real one. FlightBrief gives it the facts first, in one file it reads at the start of every task.
Conventions measured, not assumed
Each rule in a brief comes from your code and says how often it holds: "Declare every class with sharing (48 of 48)". Where the code is mixed, the brief says so and tells the assistant to ask.
Your standards come first
An administrator enters the company's own standards once. Every brief starts with them and tells the assistant they win wherever the code does otherwise.
Metadata only, and nothing leaves
FlightBrief reads your org's configuration and code, never its records, and only what the person running it can see. The brief is saved as a file in your org; FlightBrief sends nothing anywhere.
What a brief looks like
Part 1 is the rules for building in the org; Part 2 is the reference the assistant looks things up in. This is an excerpt from Part 1 of a brief of a small sample org.
# Part 1: Building in this org ## Company standards Your company's own standards, as an administrator entered them in FlightBrief. Where they and the ground rules measured from the code below disagree, follow these standards; the ground rules show how far the code follows them today. - New automation is a record-triggered Flow unless it needs Apex. - Never hard-code ids or addresses; read them from Integration_Settings__c. ## Ground rules 1. Declare every non-test class `with sharing` (8 of 8). 2. Use API version 68.0 for new classes (9 of 9). Observations (too few cases for a rule): - Put no logic in triggers: each trigger is one line that calls a handler class (2 of 2). - Write SOQL only in selector classes named `<Object>Selector` (2 of 2). - Log through `LogUtil`, not `System.debug` (2 of 2). ## Answers from your team - **Which objects are written by integrations or data loads, and by which ones?** Project__c, nightly from the billing system. Do not add required fields. ## Open questions Your team has not answered these yet. When your task touches one, ask the person before you proceed, and do not assume an answer. - When you add a field, which page layouts or Lightning record pages must it also be added to? ## Where new code goes | Change | Where | | --------------------------------------- | ------------------------------------- | | Logic when a record of Project__c saves | A new override in its trigger handler | | A configurable value | A field on `Trigger_Setting__mdt` |
What a brief covers
- The data model: objects, fields and how they relate, with each field's description or help text, and how to query them.
- Apex conventions: sharing, trigger structure, where queries and business logic live, logging and testing, each with how often your code follows it.
- Automation: triggers and Flows by object, platform events and who subscribes to them.
- Configuration: custom metadata types and custom settings with their records by name. Their values are never read.
- Security and naming: the permission sets and sharing defaults in use, and how things are named.
- What it could not see: a brief says what it leaves out, and raises those things as questions for your team.
A Surface brief works as soon as FlightBrief is installed. A Deep brief, after a one-time setup by an administrator, adds validation rules with their conditions, the fields each class and Flow uses, what each Flow does, and your Lightning web components. Email addresses and record ids in rule conditions are replaced before anything is written.
Built for a team, not just one developer
Publish one brief for everyone
An administrator reviews a brief and publishes it as the team's. Readers open, copy and download it without generating their own.
Answers to what code cannot tell
Each brief asks what the scan cannot settle, such as which objects integrations write to. Your team answers once, and later briefs carry the answers.
Fresh on a schedule
Have a brief generated daily or weekly and published when it completes. The page says how many classes, triggers and Flows changed since your latest brief.
Ready for your AI tool
Download a brief as AGENTS.md, CLAUDE.md, a Cursor rule or an Agentforce Vibes rule: the files those tools already read from your project folder.
Simple to roll out
- Install from the AppExchange for administrators only.
- Assign the permission sets: FlightBrief User to those who generate briefs, FlightBrief Admin to the administrators who set standards and publish, and FlightBrief Reader to everyone who only needs the team's brief.
- Open the FlightBrief app from the App Launcher, choose Surface and press Generate brief. A large org takes a minute or two.
The deep scan setup, company standards, questions, publishing and schedules are in the Administrator GuideAdministrator Guide. Prefer to watch? The setup in a short video (2:52).
Questions
Does FlightBrief send my org to an AI service?
No. FlightBrief makes no calls outside Salesforce. It writes the brief as a file in your org, and you decide whether to give it to an AI assistant, and which one.
Does it read my records?
No. It reads configuration and code only. A brief never holds record data.
Can a brief show more than the person running it can see?
No. A brief covers only what the person who generated it can see. A brief published for the team is read by people who may see less, so it can name objects or fields they cannot open, but still no records.
Which AI assistants does it work with?
Any assistant that reads a file or pasted text. FlightBrief also saves a brief under the file names Claude Code, Cursor, Agentforce Vibes and tools that read AGENTS.md look for.
My org is large. Will the brief fit?
A brief is sized to fit an assistant's working memory, keeping the rules and the most important objects. When it has to shorten long lists, FlightBrief also saves a full reference with every object, field, rule, Flow and class, for tasks that need it.
How current is a brief?
It describes the org as it was when it was generated, and says when that was. Generate a new one at any time, or schedule one daily or weekly.
What does it change in my org?
It keeps its own records of each brief, the brief files, and what your administrators enter. The optional deep scan asks an administrator to create a sign-in for it in Setup; those settings belong to your org and can be removed like any others.
What does it cost?
Nothing. FlightBrief is free, with every feature included.
Support
FlightBrief is free, and support is by email on a best-effort basis: support@adeptapps.net. When writing, say which version is installed. Please do not send us a brief unless we ask for a specific part of one.
Use of FlightBrief is governed by the Terms of UseTerms of Use. What we receive when you install it is described in the Privacy PolicyPrivacy Policy: the app itself sends us nothing. How we build, test and support our apps, and how to report a security issue, is on our SecuritySecurity page.