Essential Guidelines

Instructing Opulent Effectively

How to achieve optimal results.

The most important thing to remember when instructing Opulent is to be as specific as possible. Just as you would provide a detailed spec when asking a coworker to do something, you should do the same with Opulent — whether the work is engineering, diligence, finance, GTM, research, or operations. This guide will help you structure your instructions/prompts to effectively use Opulent. For broader strategies, also check out our best-practices guide.

How to Write Effective Prompts

Here is an example prompt that demonstrates effective instruction:

Note

In the platform repo, I want you to build a tool that monitors the RAM and CPU usage of the remote machines that Opulent runs on. To do that, please perform the following tasks:

  • Create a background task that launches automatically when the service entrypoint starts.
  • The task should open a connection to all forked remote machines used in this Opulent session and monitor their RAM and CPU usage.
  • If usage exceeds 80% of the available resource, emit a new type of event to signal this (check how we use Kafka).
  • Architect this in a smart way that doesn't block other operations. You should understand how all the containers for the parallel child sessions interact with each other.

Why This Works Well

Provides Helpful Context
  • Detail: Specifies the repo and the broader purpose (monitoring resource usage).
    • Benefit: Opulent knows the scope and domain clearly.
Gives Step-by-Step Instructions
  • Detail: Tasks like "create a background task" and "emit an event at 80% usage."
    • Benefit: Breaks down the work into logical parts.
Defines Clear Success Criteria
  • Detail: Defines "success" as emitting a specific event upon 80% usage.
    • Benefit: Opulent knows exactly what to achieve.
References Existing Patterns and Code
  • Detail: Mentions Kafka and container interactions.
    • Benefit: Encourages reuse of established code or design approaches.

The same principles apply to non-engineering work. A diligence, finance, or GTM prompt is strongest when it names the source of record, the exact output you want, and how you'll check it — for example, "reconcile Q3 vendor spend against the /finance/q3 Drive folder and flag any line item that differs from the ledger by more than 2%."

Best Practices: Do's and Don'ts

Be Opinionated and Specific

Do: Provide Clear Directives

* **Why:** Opulent can get stuck without a clear path or when faced with too many interpretations.
* **How:**
  * Make important decisions and judgment calls for Opulent.
  * Offer specific design choices and implementation strategies.
  * Define clear scope, boundaries, and success criteria.
* **Example:** "Optimize the getOrderDetails query in orderService.js by adding a composite index on the order\_id and product\_id columns in the order\_items table. Refactor the query to replace the existing correlated subquery with a JOIN to the products table for fetching product details."


Don't: Leave Decisions Open-Ended


    

  • Why: Vague instructions can lead Opulent to implement solutions that don't align with your actual needs.
    • 

  • How:
      

    • Avoid statements that require Opulent to make significant design or implementation decisions without guidance. This can lead to unexpected results.
      • 

    

    • 

  • Example: Don't: "Improve our database's performance." Don't: "Look into this account and tell me if it's healthy."
Leverage Opulent

Do: Pick tasks that Opulent is good at

* **Why:**
  * **Maximize Results:** By assigning tasks that align with Opulent's capabilities, you get the best results for the least amount of effort.
* **How:**
  * Read this guide: [When to use Opulent](when-to-use-opulent)
  * Provide examples, modules, resources, and templates that Opulent can follow.
    * Share direct links to docs sites so Opulent can read about details like API request bodies and features it might not know about.
    * Share specific filenames, records, or Drive folders that you want Opulent to look at and learn from.
  * Connect [connectors](/work-with-opulent/connector-marketplace) to give Opulent access to Figma designs, databases, monitoring tools, CRMs, and more.
  * **Example:** Do: "Refactor state management in the Header component to use React's useReducer hook for better scalability and maintainability. Ensure that all existing functionality is preserved and add unit tests to cover the new state logic."
  * **Example:** Do: "Use authTemplate.rs as a reference to maintain consistency in error handling."
  * **Example:** Do: "Check out the official Sequelize docs at [https://sequelize.org/docs/v6/getting-started/](https://sequelize.org/docs/v6/getting-started/) for migration steps."


Don't: Skip Providing Context for Complex Tasks


    

  • Why: Even though Opulent can handle complex work, it performs best when you provide context and clear direction.
    • 

  • How:
      

    • For tasks requiring domain knowledge, provide relevant docs, examples, or references.
      • 

    • For visual tasks, provide Figma files via the Figma connector, reference designs, or detailed specs — Opulent can build from these but won't invent aesthetics on its own.
      • 

    • For mobile apps, Opulent can build and test in its sandbox where an emulator is available; otherwise provide clear testing criteria.
      • 

    

    • 

  • Example: Don't: "Make the app look better" — instead, provide specific design specs or a Figma file.
    • 

  • Example: Don't: "Improve our database's performance" — instead, specify which queries to optimize and what metrics to target.
Use Feedback Loops

Do: Establish Clear and Frequent Checks

* **Why:** Frequent feedback (both from you and from tests/checks/linters) ensures Opulent corrects mistakes effectively.
* **How:**
  * Use tests (unit/integration) to confirm correctness.
  * Maintain build validations, lint checks, and static analysis for code quality.
  * Enable [Opulent Review](/work-with-opulent/opulent-review) with [Auto-Fix](/work-with-opulent/opulent-review#auto-fix) so Opulent automatically responds to review comments and CI failures — creating a closed loop where PRs iterate toward merge-ready quality without you in the loop.
* **Example:** Do: "Run npm test after each iteration."
* **Example:** Do: "Ensure the pipeline on CircleCI doesn't fail."
* **Example:** Do: "Pass ESLint/Prettier checks before pushing any commits."


Don't: Neglect Providing Feedback


    

  • Why: Without feedback, Opulent won't know if its solutions meet your standards.
    • 

  • How:
      

    • Avoid assigning tasks without defining how you'll evaluate them.
Set Checkpoints

Do: Set Clear Checkpoints and Sub-Tasks

* **Why:** Breaking down complex tasks into smaller checkpoints helps Opulent stay focused and reduces errors.
* **How:**
  * Split tasks into verifiable sub-tasks, and start one Opulent session for each sub-task.
  * Define what success looks like for each sub-task and optionally set checkpoints within each sub-task.
  * Ask Opulent to report back after completing each checkpoint or sub-task.


Examples:


    

  • Example: Do: "When working with the dataset, verify that it has at least 500 rows and contains columns X, Y, Z."
    • 

  • Example: Do: "When modifying the API, confirm the endpoint returns status 200 and includes all required fields."
    • 

  • Example: Do: "When drafting the memo, confirm every figure cites its source and totals reconcile to the ledger."
    • 



Don't: Skip Specific Validation Requirements


    

  • Why: Without defined validation steps, Opulent cannot confidently complete tasks.
    • 

  • How:
      

    • Avoid vague success criteria.
      • 

    • Don't leave verification steps implicit or undefined.
      • 

    

    • 

  • Example: Don't: "Make sure it works."
Let Opulent Verify Its Own Work

Opulent has a full sandbox environment — shell, editor, and browser in its Workbench. Tell Opulent to verify its own work before delivering:

* **Spin up the app:** "Run `npm run dev` and verify the new page renders at `/settings`."
* **Browser testing:** "Open the browser, navigate to the login page, and confirm the OAuth flow completes successfully."
* **Visual verification:** "Take screenshots at desktop (1440px) and mobile (375px) widths and confirm the layout matches the design."
* **Cross-check the numbers:** "Recompute the report totals from the raw data and confirm they match before sharing."


This lets Opulent QA its work the same way you would — before you ever need to look at it.

Use Playbooks and Knowledge

For repetitive or complex tasks, we suggest using and iterating on Playbooks. Learn more about using playbooks effectively. Playbooks are reusable and shareable prompts that streamline task delegation. For example, if you want Opulent to address ongoing CI build failures — or produce a weekly revenue summary — create a playbook that includes the general steps Opulent should follow each time.

For persistent context that Opulent should remember across all sessions — such as coding standards, common bugs and fixes, deployment workflows, client context, or how to use internal tools — use [Knowledge](/product-guides/knowledge). Knowledge items are automatically recalled when relevant, so you don't need to repeat the same instructions in every prompt. You can pin Knowledge to specific workspaces or apply it globally.


<Tip>Playbooks vs. Knowledge: Use Playbooks for step-by-step procedures tied to specific tasks. Use Knowledge for general tips, conventions, and context that apply broadly across sessions.</Tip>