> ## Documentation Index
> Fetch the complete documentation index at: https://felix.so/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Descriptions
> A description is the plain-language instruction that tells Felix what a step should do.
Felix generates the code for each step entirely from its description. The more clearly you describe what you need, the more accurately the step will work.
## What a good description includes
A strong step description specifies:
* **What to work with** — the data, document, or service involved
* **What to do with it** — extract, classify, summarise, send, write
* **What the output should be** — format, structure, variable name
| Too vague | Specific |
| ----------------- | ------------------------------------------------------------------------------------------------------------------ |
| Get the contracts | Fetch all contracts uploaded to `@GoogleDrive` in the last 7 days |
| Summarise it | Summarise each document in one paragraph covering obligations, payment terms, and notice period |
| Send the results | Write results to `@GoogleSheets` — one row per contract, columns: party names, start date, end date, governing law |
## How Felix handles vague descriptions
If your description is missing details Felix needs to build the step, it will ask a follow-up question before generating code.
This means you don't need a perfect description to start. Write what you know — Felix will ask for the rest.
Felix asks follow-up questions to close gaps, not to test you. If you're unsure of a detail, describe what usually happens and Felix will work with that.
## Using `@mentions` in descriptions
Reference connectors directly in your descriptions using `@mentions`. Felix uses these to generate the correct API calls and authentication.
```
Extract the text from each PDF in @GoogleDrive and run it through
@Anthropic to identify any clauses that conflict with our standard
template.
```
## Referencing previous steps
Each step can reference outputs from earlier steps. Describe what data you need and Felix wires the connection automatically.
```
For each flagged clause from the previous step, generate a
one-sentence explanation of why it may be non-standard.
Output as a list.
```
## Describing edge cases
If your process has exceptions or conditions, describe them explicitly.
```
Extract key dates from each contract. If a contract is missing a
start date, flag it as incomplete and skip to the next document.
```
Felix generates conditional logic from plain-language conditions. You don't need to write if/else statements.
## Tips
* **Describe the output before the process** if you know what you need. Working backwards often produces cleaner steps.
* **Use domain language.** Felix understands legal, insurance, and finance terminology — use the terms you would use with a colleague.
* **Be explicit about filters.** "Recent contracts" is vague. "Contracts uploaded in the last 30 days" is not.
* **Describe one action per step.** If a description contains "and then", consider splitting it into two steps.
How steps chain together
How Felix generates code
Working with follow-up questions