Nogbase

View saved version →

---
name: client-shortlist
description: Turn a property buyer's brief (budget and currency, bedrooms, area, handover window, payment-plan limits such as maximum booking percentage or a post-handover plan) into filtered Nogbase inventory searches and a side-by-side comparison of three to five projects or units, using only facts Nogbase returns. Use when a broker asks to find, shortlist, match, or compare properties or off-plan projects for a client.
---

# Client shortlist

Turn a buyer's brief into Nogbase searches and compare the best three to five options in one table. Every fact in the table comes from a Nogbase tool result; anything Nogbase does not return is marked unknown, never estimated.

If the user's explicit instructions conflict with this skill, follow the user, except for the Rules at the end.

## 1. Map the brief to filters

`search_inventory_projects` takes these filters. Use only the ones the brief states; do not add your own preferences.

| Brief says | Filter |
| --- | --- |
| Area, community, or building | `search_inventory_locations` with `query` (English or Arabic, optional `country`), pick the result whose `breadcrumb` matches (ask when two places share a name), then `locationId` |
| Developer | `list_inventory_developers` with `query`, then `developerId` |
| Budget | `priceMin` / `priceMax` in major units with `currencyCode` (ISO 4217) |
| Bedrooms | `bedrooms` as a list of strings, for example `["1", "2"]` |
| Unit type | `unitType` |
| Size | `sizeMin` / `sizeMax` |
| Handover window | `handoverFrom` / `handoverTo` as `YYYY-MM-DD` (for example "by end of 2027" is `handoverTo: "2027-12-31"`) |
| Maximum booking or down payment | `maxBookingPercent` |
| Maximum paid before handover | `maxPreHandoverPercent` |
| Minimum paid after handover | `postHandoverPercent` |
| Wants (or refuses) a post-handover plan | `postHandoverOnly: true` (or `false`) |
| A plan split such as "60/40" (paid before handover / on or after handover) | `maxPreHandoverPercent` with the first number (`60`); when the brief says the second share is paid after handover ("60/40 post-handover"), also `postHandoverOnly: true` |
| Amenities | `amenities`: all must be offered; use the listed values (pool, gym, kids_play_area, bbq_area, parking, security, spa, garden, retail, restaurants, beach, jogging_track, pets_allowed, concierge, balcony, sports) or free text; at most 10 |
| Only units available now | `inventoryOnly: true` |
| Free-text project, developer, or area name | `query` |

Budget and currency:

- With `currencyCode` the band matches only units priced in that currency; Nogbase never converts it. If the buyer's budget is in a different currency from the market's listings (for example a USD budget for AED-priced units), do not convert it yourself. Ask the user for the budget in the listing currency, or search without a price band and report prices as Nogbase gives them.
- The payment-plan filters must all hold for one of the project's plans.

Ask a follow-up only when a missing detail would change the search materially (usually budget currency or area). Otherwise search with what you have and state the assumptions.

## 2. Search

1. Call `search_inventory_projects` with the filters. It pages by `offset`; when `meta.hasMore` is true and you have fewer than five good candidates, fetch the next page.
2. With any unit filter (unit type, bedrooms, price, size), each card carries `unitMatch`:
   - `"inventory"`: live units your company can read match. Get them with `search_inventory_units` (`projectId`, `bedrooms` as a single integer, `priceMin`/`priceMax` with `currencyCode`, `sort: "price_asc"`), which pages by `cursor` from `data.nextCursor`, or with `list_inventory_project_units` (`projectId`).
   - `"project"`: only the project's own unit mix and starting price match. Live availability is unconfirmed; the developer's sales contacts are in `get_inventory_project` (`developer.contacts`).
3. Locked projects arrive as shallow cards with 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: deal-check
description: Run Nogbase's investment evaluation for one off-plan unit (entry cost, the payment schedule, price against DLD sales, value scenarios with the sale at handover, break-even and, from a rent the user gives, yield and the after-handover cash flow) and present Nogbase's figures with their sources, warnings, disclaimer and attribution. Use when a broker or developer asks whether a unit is a good investment, what a buyer would make selling at handover, how its price compares with the market, or for a deal check, ROI, yield or IRR on a specific unit.
---

# Deal check

Run Nogbase's investment evaluation for one unit and present what it returns. Nogbase computes every figure. You never compute, round, convert or re-total one: you choose the inputs, call the evaluation, and arrange its answer.

If the user's explicit instructions conflict with this skill, follow the user, except for the Rules at the end, which protect their buyer and their licence to advertise.

## Inputs

- The unit: project name or id plus unit number; or a project plus a description of the unit (bedrooms, size in sq ft, floor, flat or villa, price and its currency).
- Optional: the payment plan, the purchase date, what-ifs (below), a currency to show amounts in, and the language (English by default; Arabic on request).
- Rent: Nogbase does not use DLD rent data yet. Rent, yield and the after-handover view need a gross annual rent from the user. If the user wants them, ask for the rent. Never suggest, estimate or look up a rent yourself. Without one, run the evaluation anyway and say those blocks need a rent.

Ask only for what blocks the next step. The evaluation needs nothing about the buyer; never ask for a buyer's name or contact details.

## 1. Find the unit

1. Resolve the project: `search_inventory_projects` with `query` (or `search_inventory_locations`, then `locationId`). A developer checking its own project can use `search_my_projects`.
2. Resolve the unit: `search_inventory_units` with `projectId` and `query` set to the unit number, or `list_inventory_project_units` (`list_my_project_units` for a developer's own project).
3. Stop when the project is locked or the unit is not found; say it is not readable by this workspace. Never try other ids. With no unit in Nogbase, the user can describe one instead (`unit` below).

## 2. Run the evaluation

Call `evaluate_unit`:

| Input | Value |
| --- | --- |
| `projectId` | the project id |
| `unitId` | the unit id, when the unit is in Nogbase |
| `unit` | without `unitId`, the described unit: `bedrooms` (0 for a studio), `sizeSqft`, `floor`, `propertyType` (`flat` or `villa`), `price` with `currencyCode` (in AED for a Dubai unit). With `unitId`, only the fields the user changes, for example a negotiated `price` |
| `paymentPlanId` | only when the user picks a plan: one of the returned `availablePaymentPlans`. Otherwise the project's default plan is used |
| `purchaseDate` | `YYYY-MM-DD`, only when the user gives one (default: today in Dubai) |
| `assumptions` | only the what-ifs the user states (table below) |
| `displayCurrency` | an ISO 4217 code, only when the user wants amounts shown in another currency |
| `locale` | `ar-AE` for Arabic server text; omit or `en` for English |

What-ifs. Money is in major units as a decimal string (`"110000"`), with `assumptions.currencyCode`. Percents are decimal strings in percent (`"5"` is 5%).

| User says | `assumptions` field |
| --- | --- |
| Value changes to test by handover | `scenarioChangesPct`, for example `["-5", "0", "5"]` (default -10, 0, 10) |
| One more value change | `customChangePct` |
| Expected annual rent | `annualRent` |
| Management fee share of rent | `managementPct` (default 5) |
| Vacant months a year | `vacancyMonths`, 0 to 11 (default 1) |
| A known admin or Oqood fee | `adminFee` |
| Buyer's agent fee | `agentFeePct`, percent of price including VAT (default 0) |
| A known seller transfer cost | `transferFee` |

If `

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: nogbase-actions
description: Change Nogbase data safely through the Nogbase connector, within the user's own permissions, asking before each change. Use when a broker or developer asks to update, create, hold, reserve, release, archive, approve, send, import, export, or otherwise act on Nogbase records (units and prices, leads and notes, holds, offerings, approvals, campaigns, workflows), or needs any Nogbase API operation the dedicated connector tools do not cover.
---

# Nogbase actions

Carry out changes and less common reads in Nogbase through the connector, one confirmed step at a time. Every call runs with the user's own Nogbase access in the connected workspace; Nogbase refuses what the user may not do, and every change is recorded as theirs.

If the user's explicit instructions conflict with this skill, follow the user, except for the Rules at the end, which protect their data and their clients.

## 1. Pick the tool

1. Prefer a dedicated Nogbase tool when one fits: the inventory, offer, file, brand and workspace tools for reads, and `create_record` / `update_record` for collection records.
2. Otherwise use the API tools, in this order:
   1. `search_api_operations` with a few words for the task (for example `unit price`, `lead notes`, `hold`), optionally with `method`.
   2. `describe_api_operation` with the chosen `operation` id. Read its path and query parameters, the request body, the scope it needs, whether it may answer `pending_approval`, and whether it honours an idempotency key.
   3. `call_api_read` for a GET operation, `call_api_write` for POST, PUT, PATCH or DELETE.
3. Never guess an operation id or a body field. When no operation fits, say so and point the user to the Nogbase app.

## 2. Read before you change

- Read the record first (with the dedicated tool or `call_api_read`) so you know its current values and its version.
- Pass that version as `ifMatch` on `call_api_write` (or as `expectedVersion` on `update_record`) whenever the operation changes an existing record.
- Show the user what will change in plain words: the record (by name or number, not only its id), each field's current and new value, and any side effect the operation describes (for example a hold that blocks the unit for others). For a new record, show the main fields.
- Wait for a clear yes before calling `call_api_write`, `create_record` or `update_record`. Ask again for each further change; one yes covers only the change you described.

## 3. Read the result

| Result | What to do |
| --- | --- |
| `status: ok` | Report what changed, using the values Nogbase returned. |
| `status: pending_approval` | The change is waiting for a person to approve it. Give the user the `approvalId`, say nothing has changed yet, and stop. Do not retry. |
| `status: version_conflict` | Someone changed the record since you read it, and nothing was changed. Read it again, show the user the new values, and ask whether to apply the change to them. |
| `status: download` | Give the user the link (`url`) with `fileName`, and say it expires at `expiresAt` (about 15 minutes) and that anyone holding the link can open the file until then. Do not repeat the link elsewhere or store it. Files over 10 MiB are refused; offer a smaller export (fewer rows or one project). |
| A list with `meta.truncated: true` | Only `meta.returnedCount` items fit. Follow `meta.truncationNote`: call again with the same parameters and `limit` set to that count, or advance the offset or cursor by it. Tell the user when a list is incomplete. |
| An error saying to reconnect Nogbase and allow changes | The connection can only read. Tell the user to reconnect Nogbase in Claude or ChatGPT and allow changes, then try again. |
| A refused call (403) | The user or this workspace may not do it. Say so; `get_my_workspaces` shows whether another of the user's workspaces can. Never try other ids or operations to get around it. |
| Any other error | Report its `code` and `message`. |

Retrie

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: nogbase-api
description: Read and change Nogbase data through the Nogbase v1 API from a terminal, with the user's own sign-in, using the nogbase CLI. Use when you can run shell commands (a coding agent with a terminal) and the task needs Nogbase records, schemas, the change feed, audit history, or anything the Nogbase connector tools do not cover. Not for chat apps without a terminal.
---

# Nogbase API from the terminal

The `nogbase` CLI calls the Nogbase v1 API with the user's own sign-in. You
never see or store a token or API key.

## 1. Check the CLI and the sign-in

1. Run `nogbase version`. If the command is missing, or the version is below
   0.3.0, ask the user to install or update it themselves by following
   https://github.com/nogbase/nogbase-cli#install (macOS, Linux and Windows).
   Don't run an installer yourself.
2. Run `nogbase status --json`. If it is not signed in, ask the user to run
   `nogbase login` themselves. It opens their browser; on a machine without
   one it prints a link and a code. Never ask for a password, token or API key,
   and never put one in a command.
3. `status` shows the workspace. If the task is for another workspace, ask the
   user to run `nogbase switch-entity <workspace>`. For another environment, ask
   them to switch profiles; `nogbase api` refuses `--api-url` and `NOGBASE_API_URL`.

## 2. Learn the API before calling it

Fetch `https://api.nogbase.ae/llms.txt` (a plain documentation fetch, not an API
call) once per session and follow it: v1 paths only, the response envelopes,
paging and the write rules. Use `nogbase api GET /v1/schemas` and
`nogbase api GET /v1/schemas/<collection>` to learn field names instead of
guessing.

## 3. Call it

```bash
nogbase api GET "/v1/collections/<collection>?limit=20"
nogbase api GET /v1/collections/<collection>/<id>
nogbase api POST /v1/collections/<collection> --data @record.json
nogbase api PUT /v1/collections/<collection>/<id> --data @record.json --if-match <_version>
```

- The body is printed exactly as the API returns it. Parse it as JSON.
- A non-2xx status, including a redirect (never followed), prints the body and
  exits with code 3. An error body looks like `{ "error": { "code", "message" } }`;
  read the code before deciding what to do.
- Collection lists: pass `meta.nextCursor` back as the `after` query parameter
  until `meta.hasMore` is false. Other endpoints page as `llms.txt` describes.
- URL-encode query values (`%20` for a space, `%2C` for a comma). The CLI sends
  the query exactly as you write it.
- Market scope: `--country AE` (or `--country all`) sets it, as in the data
  commands. Without `--country`, a login session uses the user's saved market
  (`nogbase market use <country>`). Don't send the `X-Nogbase-Market-Country`
  header; the CLI reserves it.

## 4. Write safely

- Before an update, read the record and send its `_version` with `--if-match`.
  A 412 conflict means someone else changed it: re-read, decide with the user if
  the change is not obviously still right, and send the corrected write without
  `--idempotency-key` (a new key). Reusing the old key replays the 412.
- Every write sends an `Idempotency-Key`. Reuse a printed key with
  `--idempotency-key` only to repeat the exact same request after an uncertain
  outcome (a timeout, a dropped connection). Not every endpoint supports
  idempotency, so check before repeating a write that creates something.
- With the user's `nogbase login` session, every change is recorded as theirs.
  Don't open a run and don't send a run id; the server ignores one. Only an agent
  API key opens runs, with `POST /v1/agent-runs`. Never invent a run id.
- If a response has `data.status` equal to `pending_approval`, a person must
  approve the change. Tell the user, give them the `approvalId`, and stop; don't
  retry. You can check it later with `nogbase api GET /v1/approvals/<approvalId>`.
- Ask before deleting anything, before changing more than a handful of records,

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: project-brief
description: Write a project brief for one Nogbase real-estate project (developer, location, handover, unit mix and starting prices, payment plans, amenities, brochures and documents, sales contacts) from Nogbase data, in English, Arabic, or both. Use when a broker or developer asks to describe, summarise, or present a project, or asks for a project brief, fact sheet, or project overview for a client.
---

# Project brief

Write a brief for one project from Nogbase data, in the conversation and in the format the user asks for. Every fact comes from a Nogbase tool result.

If the user's explicit instructions conflict with this skill, follow the user, except for the Rules at the end.

## Inputs

- The project: name or id, or enough detail to find it (area, developer).
- Optional: language (English by default; Arabic, or both side by side, on request), audience, length, and whether to put the company letterhead on it.

## 1. Find the project

- By name: `search_inventory_projects` with `query`.
- By area: `search_inventory_locations` with `query`, choose the result whose `breadcrumb` matches (ask when two places share a name), then `search_inventory_projects` with `locationId`.
- A developer's own project: `search_my_projects` with `query`.

## 2. Read the project

1. `get_inventory_project` with `projectId`. It returns, as the company may see it:
   - `project`: facts such as description, amenities, location, `handover` (the developer's estimated quarter and year), `completionDate`, `unitTypeSummary`, `priceSummary`, payment plans, gallery images, and `videos`;
   - `developer`: name, website, and sales `contacts`;
   - `brochures` and `documents`, each with a name and link;
   - `availability`: access state, `lockedReason`, and whether access can be requested.
   A developer reading its own project gets `project`, `properties`, and `unitSummary` instead of the developer and availability blocks.
2. `get_sales_offer_data` with `projectId`, `purpose: "project_brief"`, and no `unitId`. Add `locale: "ar-AE"` for Arabic. It returns the labels Nogbase's own brief uses: `project.handoverLabel`, `locationLabel`, `unitMixLabel`, `fromPriceLabel`, `serviceChargeLabel`, descriptions, `amenities`, `nearby`, image URLs, `unitTypes` (unit-type summary), `paymentPlans` (step percentages and due events; amounts need a unit price), and `sections`.
3. For a letterhead, `get_my_brand_context` (no input).

If the project is locked (a shallow card, or an `availability` block with `lockedReason`), write only what the card shows, say the rest needs access, and mention that access can be requested in the Nogbase app when `requestAccessAvailable` is true. If a call answers not found, the project is not readable by this workspace; do not retry with other ids.

## 3. Write the brief

Sections, in this order, each only when the data has it (leave out any section whose key is `false` in `sections`):

1. Overview: project name, developer, a short description.
2. Location: `locationLabel` or the project location, and `nearby` points.
3. Handover: write it as "Developer's published handover: Q2 2027" from `handover` or `handoverLabel`. It is the developer's estimate, not a guarantee. If `completionDate` differs, show both, labelled.
4. Unit mix and prices: unit types with sizes and "from" prices in their own currency (`unitTypes`, or `unitTypeSummary` with `startingPrice` and `currencyCode`; `priceSummary` for the range). Prices in other currencies (`otherCurrencies`) are noted, never converted.
5. Payment plans: each plan's steps as a table of percentage and due event.
6. Amenities.
7. Brochures, documents, and videos: list each by name with its link as Nogbase returns it.
8. Sales contacts: from `developer.contacts`.
9. Source line: "From Nogbase, `generatedOnLabel`. Prices, availability, and dates can change."

Language:

- Arabic: use the `ar-AE` labels from `get_sales_offer_data`, write right to left, and keep project, developer, a

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sales-offer
description: Prepare a branded real-estate sales offer for one Nogbase unit, with the quoted or list price, every payment-plan installment computed by Nogbase, offer terms and fees, and the company letterhead. Use when a broker or developer asks for a sales offer, price offer, quotation, or one-page offer for a specific unit or apartment in a Nogbase project, optionally at a quoted price, in another currency, in Arabic, or as a WhatsApp message.
---

# Sales offer

Build a sales offer for one unit from Nogbase data and write it in the conversation in the format the user asks for (a WhatsApp message, another message, table, document, or PDF when the host can produce one). Nogbase supplies every figure; you arrange and present them.

If the user's explicit instructions conflict with this skill, follow the user, except for the Rules at the end, which protect their data and their buyer.

## Inputs

- The unit: project name or id plus unit number, or enough detail to find it (area, type, bedrooms).
- Optional: the price quoted to the buyer, the currency to present the offer in, one-page or full offer, language (English by default; Arabic on request), and the buyer's name.

Ask only for what blocks the next step. Never ask for or invent buyer contact details: Nogbase returns none, and the buyer's name comes only from the user.

## 1. Find the unit

1. Resolve the project:
   - By name: `search_inventory_projects` with `query`.
   - By area: `search_inventory_locations` with `query` (English or Arabic), choose the result whose `breadcrumb` matches what the user meant (ask when two places share a name), then `search_inventory_projects` with that id as `locationId`.
   - A developer offering its own project: `search_my_projects` with `query`.
2. Resolve the unit within the project:
   - `search_inventory_units` with `projectId` and `query` set to the unit number (it matches unit name and number); or
   - `list_inventory_project_units` with `projectId` (broker), or `list_my_project_units` with `projectId` (developer, own project).
3. Stop and tell the user, without building an offer, when:
   - the project card is locked (a shallow card with access state and no units), or `list_inventory_project_units` returns an empty unit list with `lockedReason`: say it is locked for their workspace and, when `requestAccessAvailable` is true, that access can be requested in the Nogbase app;
   - the unit is not found, or `get_sales_offer_data` answers not found: the unit is not readable by this workspace. Do not retry with other ids;
   - the unit's `status` shows it is not available (for example sold or reserved): report the status and ask whether the user still wants a reference offer, labelled as such.

## 2. Get the offer data

Call `get_sales_offer_data` with:

| Input | Value |
| --- | --- |
| `projectId` | the project id |
| `unitId` | the unit id (required for a unit offer and for `offerPrice` or `currency`) |
| `offerPrice` | only when the user quotes a price: digits in major units of the **unit's own currency**, for example `"1850000"` |
| `currency` | only when the user wants the offer shown in another ISO 4217 currency, for example `"USD"` |
| `purpose` | `sales_offer_one_page` when the user asks for one page; otherwise omit (full `sales_offer`) |
| `locale` | `ar-AE` for Arabic labels; omit or `en` for English |

Price and currency handling:

- When the user quotes a price, always pass it as `offerPrice`. Nogbase then re-prices every payment-plan installment, the offer price label, and the fees from that price. Never recompute installments yourself.
- If the quoted price is in a different currency from the unit's (the unit's currency is in the search row's `currencyCode` or `priceMoney`), do not convert it. Ask for the price in the unit's currency, or offer to present the unit's price converted with `currency`.
- With `currency`, Nogbase converts at the company's own exchange rates and discloses it in `offer.convers

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.