Instrumentl

View saved version →

---
name: award-budget-review
description: Use when the user asks about spending on an awarded grant — budget versus actuals, remaining balance by category, or whether spenddown is on track for the grant period.
---

# Award budget review

Report on how an awarded grant's budget is tracking. This skill is read-only.

## Ground rules

- **No internal identifiers in output.** Never show an ID, cursor, or API field name.
- **Never invent grant data.** If a fact isn't in the record, say the record doesn't cover it.
- **Out of scope** — say so plainly and point to the Instrumentl app: creating or configuring projects, writing or storing proposal narrative, building or restructuring budget categories, recording actual expenses.

## Money formats — read this before reporting any figure

The two sources use **different representations** and mixing them produces wrong numbers by a factor of 100:

- **Budget figures** (`amount_cents`, `actual_cents`, `planned_cents`, `remaining_cents`) are **integer cents**. Divide by 100. `2500000` is $25,000.00.
- **Expense amounts** are **decimal dollar strings** — `"700.00"` is $700.00. Use as-is. **Do not divide an expense amount by 100.**

## Category totals roll up — do not sum them

Expense categories are a **tree**. A parent category's actual, planned, and remaining figures already include everything in its children — summing every category in the list double-counts spending. Report the parent, or its children, never both added together. The **budgeted** amount is the exception: it is each category's own line and does not roll up children, so a parent's budgeted figure can be smaller than its children's combined. Nesting can run three levels deep.

## Workflow

1. **Identify the grant.** `list_budgets` accepts a grant name or project title and returns the grant name and project title on each budget, so no separate name resolution is needed here. If the grant is unclear, list the awarded grants that have budgets and ask. Only awarded grants with expense categories set up appear — a submitted or in-progress grant won't, and neither will an awarded grant with no categories yet.

2. **Report by category**: budgeted, actual, planned, and remaining. Present as dollars.

3. **Flag the exceptions:**
   - Any category where remaining is **negative** — over budget.
   - Any category nearly exhausted.
   - Any category **underspent relative to how far into the grant period they are**, using the budget phase's start and end dates. **Sanity-check the phase range first.** If it is implausible for the phase's name — a phase called "Year 1" spanning eight years, or a range ending before it starts — say so and skip the pace calculation rather than reporting a figure built on it. A wrong range makes everything look dramatically underspent, and the award period dates on the tracker record cannot be read back to cross-check it.
   - An **"Uncategorized"** category with spending against a zero budget means expenses landed without a category assignment. Report it as unassigned spending needing attention in the app, not as an overspent line item.
   - A **negative actual** is a refund or correction. Report it as recorded; don't treat it as an error.

4. **If the user asks for expense detail**, call `list_expenses` — it requires at least one filter, so scope it by saved grant, grant name, or project name. Expenses carry only a category ID, so map them back to category names using the budget you already pulled.

5. **Offer the follow-on action** — adding a planned expense — and hand off to the planned expense skill. Do not create anything here.

## Guardrails

- This skill does not write. Hand off rather than acting.
- If the user asks to log what was **actually** spent, decline and explain that actuals belong in their accounting system, which is the source of truth, and that Instrumentl reads actuals from there.
- Never delete or ignore an expense from this skill. Expenses can carry an ignored marker; report it, never set it here — if the user asks to remove or ignore one, hand off to the planned expense skill.
- Don't restructure a budget or create categories — that's done in the Instrumentl app.

View saved version →

---
name: grant-deadline-review
description: Use when the user asks what grant work is due, what's overdue, or who owns what across the tasks and deadlines on the grants in their tracker.
---

# Grant deadline review

Answer questions about upcoming and overdue grant work. This skill is read-only.

## Ground rules

- **"My grants" is ambiguous.** Saved grants are already in the tracker; matches are new recommendations. Ask one short clarifying question rather than guessing.
- **No internal identifiers in output.** Never show an ID, cursor, or API field name.
- **Never invent grant data.** If a fact isn't in the record, say the record doesn't cover it.
- **Out of scope** — say so plainly and point to the Instrumentl app: creating or configuring projects, writing or storing proposal narrative, building or restructuring budgets, recording actual expenses.

## Resolving names before you present anything

Task records contain **only IDs** — no person name, no grant name. A readable answer needs three hops:

1. `list_tasks` returns `assignee_id`, `nominator_id`, and `saved_grant_id`.
2. Resolve people with `list_users`.
3. Resolve the grant by taking the task's saved grant through `list_saved_grants` to get its `grant_id`, then a single `list_grants` call for the name and funder.

If a lookup fails, say that row couldn't be loaded rather than inferring.

## Workflow

1. **For "what's due"**: pull open tasks in the requested window plus anything past due, sorted by date. **Call out overdue items first.**

2. **Disambiguate person references before filtering.** "Sarah's tasks" could mean assigned to, created by, completed by, or nominated (handed off) by her — these are four separate filters that compose with AND, so the wrong one returns wrong results. Ask: "Do you mean tasks assigned to Sarah, ones she created, ones she completed, or ones she handed off?"

3. **Filter by task kind with care.** Kinds are full proposal, report, general, letter of inquiry, and cultivation — but **older tasks may have no kind recorded at all**. If the user asks for a specific kind, say plainly that tasks without a recorded kind won't appear, and offer to show the unclassified ones too.

4. **Report unowned work** when relevant — tasks with no assignee are a common gap in a deadline review.

5. **Offer the follow-on action** — create, assign, reschedule, or complete a task — and hand off to the task management skill. Do not perform the write here.

## Guardrails

- This skill does not write. If the user asks to create, assign, or complete anything, hand off rather than acting.
- Never mark a task complete or assign work as a side effect of a status question.
- A task with a deadline earlier than its creation date is a data artifact, not necessarily overdue work — report it as recorded and don't editorialize.

View saved version →

---
name: grant-match-triage
description: Use when the user wants to review, filter, or act on the grant opportunities Instrumentl has matched to their projects — deciding which are worth pursuing, saving strong fits to their tracker, and hiding ones that don't fit.
---

# Grant match triage

Help the user work through Instrumentl's recommended matches for a project and decide what to pursue.

## Ground rules

- **"My grants" is ambiguous.** Saved grants are already in the tracker; matches are new recommendations. Ask one short clarifying question rather than guessing.
- **Confirm before any write.** Restate exactly what will change and wait for a yes.
- **No internal identifiers in output.** Never show an ID, cursor, slug, or API field name.
- **Never invent grant data.** If a fact isn't in the record, say the record doesn't cover it.
- **Money formats differ by source.** Budget figures are integer cents (divide by 100). Expense amounts are decimal dollar strings (use as-is).
- **Out of scope** — say so plainly and point to the Instrumentl app: creating or configuring projects, writing or storing proposal narrative, building or restructuring budgets, recording actual expenses.

## Workflow

1. **Resolve the project.** Call `list_projects`. If the user has more than one and hasn't named one, ask which. A project with `wants_matches` off will have no recommendations — say so rather than reporting an empty list as "no good fits."

2. **Confirm matches vs. tracker.** If the phrasing could mean either, ask: "Do you mean new recommendations Instrumentl surfaced, or grants already saved in your tracker?" Use `list_project_matches` only after they confirm they want recommendations; otherwise hand off to the pipeline review skill.

3. **Pull matches** with the user's filters applied — deadline window via the deadline range, recency via newly surfaced matches.

4. **Present a short ranked list.** For each: funder, opportunity name, and next deadline.
   - Use the grant's **next deadline** only. Each record also carries historical funding cycles with deadlines that have already expired — never present one of those as upcoming.
   - **There is no award-amount field on a match.** Do not state a dollar figure unless the opportunity's overview text explicitly names one, and if you quote it, attribute it ("the overview says grants range from $50,001–$175,000"). Never estimate or infer an amount.
   - The overview arrives as HTML. Summarize it in a sentence; never paste markup.
   - Ground the one-line "why it fits" in the record's own categories — field of work, location of field work, applicant type, funding uses. Do not assert eligibility the record doesn't state.

5. **Apply judgment the tools can't filter on.** If the user gives criteria beyond the available filters (programs they've flagged as underfunded, a pasted strategic plan), apply it on top of the retrieved set and say plainly that's what you did.

6. **Optional funder enrichment.** If the user asks about a specific funder while reviewing — who they are, whether the organization has a relationship there — call `list_funders` and `list_funder_contacts` and report only what's on file. Surface whether contacts exist and who they are, nothing more. Do not assemble a funder profile, giving history, or research brief; if the record is thin, say so and move on. Everything about a funder comes from Instrumentl's records — never fill gaps with general knowledge about a foundation.

7. **On a save or hide instruction**, restate exactly which opportunities will be saved to which project and which will be hidden for that project. Get a yes, then call `save_match` (pass `hide: true` to hide instead).

8. **Confirm what changed** and note that a hidden match can be restored in the Instrumentl app.

## Guardrails

- Never save or hide without explicit confirmation.
- Saving is not idempotent — saving an opportunity that is already in the tracker creates a duplicate entry. If it may already be saved, check the tracker first and tell the user instead of saving again.
- Don't assess eligibility beyond what the record states.
- Don't present a match as vetted for this organization beyond what Instrumentl's matching already says.
- To remove something already in the tracker, that's a different action — hand off to the tracker update skill.

View saved version →

---
name: grant-pipeline-review
description: Use when the user asks where their grant pipeline stands — a status rollup, what's stalled, totals requested or awarded, or prep for a board or leadership update.
---

# Grant pipeline review

Report on the state of the user's tracked grants. This skill is read-only.

## Ground rules

- **"My grants" is ambiguous.** Saved grants are already in the tracker; matches are new recommendations. Ask one short clarifying question rather than guessing.
- **No internal identifiers in output.** Never show an ID, cursor, or API field name.
- **Never invent grant data.** If a fact isn't in the record, say the record doesn't cover it.
- **Money formats differ by source.** Budget figures are integer cents (divide by 100). Expense amounts are decimal dollar strings (use as-is).
- **Out of scope** — say so plainly and point to the Instrumentl app: creating or configuring projects, writing or storing proposal narrative, building or restructuring budgets, recording actual expenses.

## Resolving names before you present anything

Saved-grant records contain **only IDs** — no grant name, no funder, no deadline. You must resolve them or the output is unusable:

1. Call `list_saved_grants` with the user's scope.
2. Collect the `grant_id` values from the results.
3. Resolve them in a **single** `list_grants` call passing all of them at once, which returns each grant's name, funder, and next deadline.
4. Resolve owner and assignee references through `list_users`.

If a row fails to resolve, say that row couldn't be loaded. Never infer a grant's name or deadline from surrounding context.

## Workflow

1. **Pull saved grants**, scoped to a project or fiscal year if the user named one.

2. **Group by pipeline status** — researching, planned, started, LOI in progress, submitted, LOI submitted, awarded, closed, declined, abandoned. Report counts and dollar totals (requested, awarded) per group. Amounts on a saved grant are already in dollars; do not convert them.

3. **Surface what's stuck**: grants sitting in researching or started well past the grant's next deadline, and grants with no owner. The deadline comes from the resolved grant record, not the saved grant.

4. **If they're prepping for a meeting**, lead with the three things that changed or need a decision, not the full table.

5. **Offer the follow-on action** — update a status, assign an owner, add a task — and hand off to the tracker update or task management skill. Do not perform the write here.

## Guardrails

- Say explicitly that totals are calculated live from their records in this conversation, not pulled from a saved Instrumentl report.
- This skill does not write. If the user asks to change something, hand off rather than acting.
- A saved grant with a null requested or awarded amount is unknown, not zero. Exclude it from totals and note how many rows were excluded.

View saved version →

---
name: grant-task-management
description: Use when the user wants to create, assign, reschedule, or complete tasks and deadlines on the grants in their tracker, or wants a prep checklist built out from a grant deadline.
---

# Grant task management

Create and change task records on the user's tracked grants.

## Ground rules

- **"My grants" is ambiguous.** Saved grants are already in the tracker; matches are new recommendations. Ask one short clarifying question rather than guessing.
- **Confirm before any write.** Restate exactly what will change and wait for a yes.
- **No internal identifiers in output.** Never show an ID, cursor, or API field name.
- **Never invent grant data.** If a fact isn't in the record, say the record doesn't cover it.
- **Out of scope** — say so plainly and point to the Instrumentl app: creating or configuring projects, writing or storing proposal narrative, building or restructuring budgets, recording actual expenses.

## Workflow

1. **Identify the saved grant** the task belongs to. Every task attaches to a saved grant — there is no free-floating task. Find it by grant name or project name through `list_saved_grants`, and resolve the display name through `list_grants` so your confirmation names the grant in plain language.

2. **Resolve any named teammate to a user record** via `list_users` before assigning. Search matches first name, last name, or email. Do not try to find people through the task people-filters — those only surface users already on a task, not everyone on the account. If a name matches more than one person, ask which.

3. **Pick the task kind**: full proposal, report, general, letter of inquiry, or cultivation. If the user's intent doesn't clearly map to one, ask rather than defaulting.

4. **Set the deadline** as a date and time. Never invent a date the user didn't state — ask.

5. **For a prep checklist from a deadline**, propose the full list of tasks with their dates first, get **one** confirmation, then create them in a **single batch**.

6. **Report what actually happened.** Rows are processed independently and a failed row does not roll back the others, so the response may be partially successful. Always report failures explicitly and in plain language:
   - the saved grant wasn't found or belongs to another account
   - an assignee isn't a member of this account
   - the caller lacks permission for that row
   - the row failed validation

## Tasks cannot be deleted

There is no delete operation. A task can only be created, updated, or marked complete. If the user asks to delete or remove a task, say plainly that deletion happens in the Instrumentl app.

**Do not mark a task complete as a substitute and describe it as removed.** A completed task still exists, and because completed tasks are hidden from the default tracker view, the user can easily believe it's gone when it isn't. If marking it done is what they actually want, confirm that first and say clearly that the task remains on the grant.

## Guardrails

- **Never assign work to a teammate without confirming** — restate who is getting what, by when.
- **Never mark a task complete on the user's behalf unless they explicitly said so.** Completing is a write like any other; reopening a completed task is also a write and needs the same confirmation.
- Never reschedule or reassign in bulk without listing every affected task first.
- If the user has a calendar connected in ChatGPT, you may offer to suggest blocking prep time. Frame it as available only when their other tools are connected — don't promise it, and don't imply Instrumentl writes to their calendar.

View saved version →

---
name: grant-tracker-update
description: Use when the user reports an outcome or change on a grant they're tracking — a submission, an award, a decline, a new amount, a change of owner, or award period dates — and it needs to be recorded in Instrumentl.
---

# Grant tracker update

Record changes to a saved grant in the user's tracker.

## Ground rules

- **"My grants" is ambiguous.** Saved grants are already in the tracker; matches are new recommendations. Ask one short clarifying question rather than guessing.
- **Confirm before any write.** Restate exactly what will change and wait for a yes.
- **No internal identifiers in output.** Never show an ID, cursor, or API field name.
- **Never invent grant data.** Never guess a dollar amount or a date the user didn't state.
- **Out of scope** — say so plainly and point to the Instrumentl app: creating or configuring projects, writing or storing proposal narrative, building or restructuring budgets, recording actual expenses.

## Money format

Amounts on a saved grant — requested and awarded — are **dollars**, not cents. Send `25000` for $25,000. This differs from budget and expense figures elsewhere in Instrumentl; don't carry a cents conversion over from those.

## Workflow

1. **Find the saved grant.** Search by grant name or project name through `list_saved_grants`. Because a saved-grant record carries only IDs, resolve the grant's display name through `list_grants` before you restate anything back to the user. If the same grant is tracked across more than one project, **ask which project's record** they mean — they are separate records and updating the wrong one is silent.

2. **Map what the user said to the right fields**: pipeline status, amount requested, amount awarded, owner, award notification date, award period start and end, notes, or fiscal year. Resolve a named owner to a user record via `list_users` first.

3. **Restate what will change and get confirmation.** Only the fields you pass are touched; everything else is left alone.
   - **Status, amount requested, and amount awarded are readable beforehand** — state the before-and-after for these.
   - **Notes, owner, fiscal year, notification date, and award period dates are not readable beforehand.** Do not assert a current value for them. Say what the new value will be, and if the prior value matters, ask the user rather than guessing.
   - A null amount means unknown, not zero. Don't describe filling one in as "changing it from $0."

4. **Warn before setting status to researching.** That clears the requested amount and submission goals, matching the app's behavior. Say so explicitly and get a second confirmation before proceeding.

   **The awarded amount only persists on an awarded grant.** If the status is not awarded (active or closed), a saved awarded amount is silently cleared — so when recording an award, set the status and the amount in the same update, and warn that moving a grant out of an awarded status drops its awarded amount.

5. **Award period dates must be consistent** — the start date has to fall on or before the end date. If the user gives dates that don't, ask rather than reordering them.

6. **Apply and confirm.** The update response comes back with the grant name, funder, project, and owner already filled in — use those to confirm in plain language. No follow-up lookup is needed after a write.

7. **Offer the natural next step** — for example a report deadline task on a newly awarded grant. Hand off to the task management skill rather than creating it here.

## Guardrails

- **"Remove this grant" means hide, not delete.** Hiding marks the grant as no longer saved. Explain that everything attached to it — submission goals, tasks, expenses — is preserved and that it can be restored from the Instrumentl app (not from here). Confirm before hiding.
- Never guess a dollar amount or a date the user didn't state.
- Moving a grant to a different project is a real change with downstream effects on reporting — confirm it explicitly rather than treating it as a minor edit.
- If the user wants to record an outcome on an opportunity that isn't in the tracker yet, that's a save, not an update — hand off to the match triage skill.

View saved version →

---
name: planned-expense-entry
description: Use when the user wants to add planned or forecasted costs to an awarded grant's budget — a single planned expense, or a recurring cost spread across the remaining grant period.
---

# Planned expense entry

Add **planned** (not-yet-incurred) expenses to a grant budget.

## The rule that governs this entire skill

**Only ever create planned expenses.** The create call treats an expense as an **actual** unless you explicitly mark it planned — the planned flag defaults to off, so omitting it silently records real spend. **Always set it explicitly on every row, every time.**

If the user asks to log what was **actually** spent, decline and explain that actuals belong in their accounting system, which is the source of truth, and that Instrumentl reads actuals from there.

## Ground rules

- **Confirm before any write.** Restate exactly what will change and wait for a yes.
- **No internal identifiers in output.** Never show an ID, cursor, or API field name.
- **Never invent grant data.** Never guess an amount, a date, or a category the user didn't state.
- **Out of scope** — say so plainly and point to the Instrumentl app: creating or configuring projects, writing or storing proposal narrative, building or restructuring budget categories, recording actual expenses.

## Money formats — three different representations, do not mix them

1. **Budget figures** come back as **integer cents** — divide by 100 to present. `2500000` is $25,000.00.
2. **When creating an expense**, the amount must be **sent** as integer cents — $1,500.00 is `150000`.
3. **When reading an expense back**, the amount comes back as a **decimal dollar string** — the expense you just created as `150000` reads back as `"1500.00"`. **Do not divide it.**

The dry-run preview reports in cents; the expense list reports in dollars. Always restate dollars to the user, never a cents value.

## Workflow

1. **Find the budget and category.** Call `list_budgets` first — it accepts a grant name or project title and returns the grant name and project title, so you can confirm the target in plain language. Match the expense to a category by name.
   - Categories are a **tree** and a parent's totals already include its children. Place the expense on the most specific matching category.
   - Prefer a category whose remaining balance can cover the amount. If none can, say so rather than picking arbitrarily.
   - If no category clearly matches, **ask** — do not fall back to an uncategorized bucket, and do not create a category (that's done in the app).

2. **Always dry run first.** Preview the impact before creating anything. The preview reports, per category, the projected remaining balance, whether it would be overspent, and any expenses that already exist in that category.

3. **Show the user the preview**: projected remaining, whether it would overspend, and any existing expense that looks like a possible duplicate — they may want to update that one instead of adding another.

4. **For recurring costs** ("$1,500 a month for the rest of the grant year"), lay out the individual dated expenses in full before creating them. Get one confirmation for the set, then create in a single batch.

5. **Only create after explicit confirmation.**

6. **Report what actually happened.** Rows are created independently, so the result may be partially successful. Report any failures in plain language: the grant or category wasn't found or belongs to another account, the caller lacks permission, or the row failed validation.

## Guardrails

- Only planned expenses. Never record actual spend.
- Don't restructure a budget or create categories.
- Never place an expense in a category the user didn't approve.

## Removing or ignoring existing expenses

These are separate operations from creating, and both are available. Treat them as higher-risk than a create:

- **Ignoring** an expense excludes it from budget totals but keeps the record. It is reversible. Use it when the user wants a charge to stop counting against a category.
- **Deleting** an expense removes it permanently. There is no undo. Expenses linked to a connected external system (QuickBooks, Sage Intacct, Financial Edge NXT, or any other integration) cannot be deleted here and will be refused — those must be removed in the source system first.

Rules for both:

1. Never delete or ignore anything unless the user explicitly asked for it. Do not infer it from a duplicate you noticed.
2. **List every affected expense by description, amount, and date, and get a yes before acting.** Never act on a filter or a description alone — resolve to specific records and show them first.
3. Prefer ignoring over deleting when either would satisfy the request, and say why: ignoring is reversible.
4. Report exactly what changed, including any rows that were refused.