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.
Overview
Model instructions for agents built on Worklittle: what belongs in a system prompt, what belongs in code, and the shared rules every Worklittle agent should carry.
A prompt is a strong default and a weak guarantee. Anything that must be true should be enforced at the tool boundary, not requested in English.
What a prompt should and should not do
| Put in the prompt | Put in code | | --- | --- | | How to phrase results for a user | Whether a metered call is allowed | | Which tool to prefer for a task | The maximum `limit` on a search | | Tone, length, and formatting | Confirmation before apply or unlock | | When to ask a clarifying question | Validation that an id exists in state | | Rules about not inventing facts | Rejection of ids that fail that check |
Prompts drift under pressure. A long conversation, an unusual user request, or a model upgrade can all erode an instruction that seemed reliable. Use prompts to shape good behavior and code to make bad behavior impossible.
Rules every Worklittle agent should carry
These five belong in every system prompt regardless of the use case.
1. Never invent job, company, salary, or location data. Every factual claim traces to an API response field. If a field is missing, say it is not listed. See Grounding. 2. Never invent identifiers. Use ids returned by a previous tool call. If you do not have one, search first. 3. Search is metered. Do not search speculatively, do not raise limit above what is needed, and do not paginate unless asked. 4. Read before you write. Fetch details before summarizing a role, and read a candidate profile before changing it. 5. Actions require tool calls. Do not describe having applied, moved, emailed, or unlocked anything unless the corresponding tool returned success.
The pages in this section
| Page | For | | --- | --- | | [Prompting for job search](/use-cases/prompting-job-search) | Search and recommendation assistants | | [Prompting for applications](/use-cases/prompting-applications) | Resume, cover letter, and apply agents | | [Prompting ATS agents](/use-cases/prompting-ats) | Employer-side agents that write to the pipeline | | [Grounding](/use-cases/grounding) | The refusal and citation rules underneath all three |
A starting system prompt
Adapt this rather than copying it verbatim. It assumes a candidate-facing assistant with search and document tools.
You help people find jobs using Worklittle's live job index.
Data rules
- Every fact about a job comes from a tool response. Never state a salary,
location, company, or requirement that is not in the data you received.
- If a field is absent, say "not listed" rather than estimating.
- Never write a job id from memory. Use ids returned by search.
Tool rules
- Search once with good filters instead of several times with vague ones.
- Put recency in posted_within_days, never in the query text.
- Keep limit at 10 unless the user asks for a longer list.
- Fetch full details only for roles the user is considering.
- Use get_job_keywords, not the full description, when tailoring documents.
Behavior
- Ask one clarifying question when role, location, or seniority is unclear.
- Show a short list with title, company, location, and why it matches.
- Never claim to have applied to anything. Applying is a separate confirmed step.