Coding agent documentation index Fetch the complete documentation index at: https://docs.worklittle.com/docs-agent-manifest.json Use this file to discover all available pages before exploring further.

Grounding

The rule underneath every Worklittle agent: never invent salary, company, location, or requirements. Cite the API field, and refuse cleanly when the data is not there.

Job data has real consequences. A hallucinated salary changes whether someone applies, negotiates, or quits a job they already have.

Why this matters more here than elsewhere

A wrong answer about a framework's syntax costs a developer a few minutes. A wrong answer about a job costs someone a decision they cannot easily undo.

An invented salary range anchors a negotiation or triggers a resignation. An invented location sends someone into an application for a role they cannot take. An invented requirement talks a qualified candidate out of applying. An invented company detail shows up in a cover letter and reads as carelessness to a hiring manager. * An invented candidate fact in an ATS note becomes part of a hiring record.

None of these produce an error the user can see. They just look like answers.

The rules

1. Every factual claim maps to a response field. If you cannot point at the field it came from, do not say it. 2. Absent means absent. When salary, location, or a requirement is not in the payload, the answer is "not listed", not a range, not a typical figure, not an inference from the title. 3. Do not average from memory. A model's prior about what a senior engineer earns in Denver is not data. If the user wants a market figure, call /jobs/salary-average and report it with its sample size. 4. Snippets are not descriptions. Do not describe responsibilities from a list row. Fetch details. 5. Flags over inference. Eligibility, closure, and board features are fields. Never derive them from URLs, source names, or vibes. 6. Refuse cleanly. "The posting does not list a salary" is a complete, useful answer. Hedged invention is not.

Cite the field

Requiring the model to name its source is a cheap and effective constraint, because a claim with no field to point at becomes visibly unsupported.

Grounding
- For every concrete claim about a job, you must have received the value in
  a tool response. If asked, you should be able to name the field.
- Missing values are reported as "not listed in the posting".
- Never estimate salary. If the user wants market context, use the salary
  average tool and report the sample size along with the figure.
- Never infer whether a job can be applied to automatically. Read
  can_apply.
- Never infer whether a job is still open. Read closed_at.

In user-facing copy this does not need to be verbose. "Salary is not listed" and "Listed at $150k to $180k" are both short. The difference is that only one of them is a guess.

Good and bad answers

| User asks | Bad | Good |
| --- | --- | --- |
| "What does this pay?" | "Probably around $160k for this level" | "The posting does not list compensation" |
| "Is it remote?" | "It says Senior Engineer, so likely hybrid" | "`workplace_type` is remote" |
| "What are the requirements?" (from a list row) | Invents five bullets | "Let me pull the full posting first" |
| "Can you auto-apply?" | "The careers URL looks automatable, so yes" | "`can_apply` is false for this role" |
| "How many remote PM jobs exist?" | Counts three pages of search | Calls the free market overview |
| "Did you move Alex to onsite?" | "Yes, done" | Reports the tool result, or that it failed |

Refusing without being useless

A refusal should still move the user forward. Pair the missing fact with the next best action.

No salary listed, so offer the market average for that title and location and label it as a market figure rather than this employer's. Thin description, so say so and offer to search for similar roles at the same company. Not eligible for automated apply, so surface the employer apply_url and offer to generate a tailored resume for a manual application. Job closed, so say it closed and offer a fresh search with the same filters.

The goal is not caution for its own sake. It is that the user can always tell which statements are data and which are help.