Every new chat begins with the same instructions: use our terms, keep the reply short, and ask before filling a gap. OGAD (Off Grid AI Desktop) lets you save those rules in a project’s System prompt. Chats in that project receive the instructions, so you can start with the actual task.
| Get OGAD | Desktop releases |
What would you like to do with Off Grid AI?
Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.
Write to support@offgridmobileai.co, join our Slack community, or talk to us on Reddit.
This is a core Projects feature. With a local text model selected, it gives you a reusable local workspace for a type of work, such as support replies, research notes, or product writing.
Save a small set of useful rules
- Open Projects and create a New project, or select an existing one.
- Open Knowledge & settings.
- Write your rules in System prompt and select Save.
- Start a New chat inside that project and give it a real task.
For a support-writing project, start with:
Write clear replies for a reader using our product for the first time. Use short paragraphs. Base product claims on the supplied documents. If a required fact is missing, ask for it. Give the next action first. Do not invent a test result or a customer promise.
Keep the rules specific enough to guide the work. A long list of overlapping commands can make it harder to see which one matters.
Check it with a first task
Paste a sample support question and ask for a reply. Read the answer against the saved rules. If it is too long, change the system prompt with a clear target, save, and try another project chat.
The expected result is fewer repeated setup instructions, not perfect compliance from every model. Facts still need evidence, and important answers still need review. A system prompt cannot give a model knowledge you have not supplied.
Separate reusable rules from today’s task
A useful project prompt answers stable questions: who is the reader, which sources are allowed, what tone should the answer use, and what should happen when a fact is missing?
Keep changing details in the chat. The customer’s name, a new deadline, and the specific paragraph to rewrite belong in today’s request. Putting them in permanent instructions can make an old detail appear in an unrelated answer later.
| Put in the project rules | Put in the current message |
|---|---|
| Use short paragraphs for a first-time user | Reply to this particular support question |
| Use supplied documents for product facts | Use this newly approved document version |
| Ask when a required fact is missing | The deadline for this case is Friday |
| Avoid promises that the source does not support | Explain this specific next step |
This division saves repetition while keeping the instructions easier to maintain. The point is to reuse the way you work, not freeze every fact from one task.
Test a rule with an intentionally incomplete request
If the project says to ask about missing facts, test that behavior. Give it a sample customer question that asks for a delivery date without supplying a date. Read whether the reply asks for the missing information or invents one.
Then give it the date and ask for a short reply. You have checked two useful behaviors: handling a gap and using a supplied fact.
When the answer breaks a rule, change the rule that matters rather than adding a long list of threats or repeated commands. For example, replace “Be accurate” with “Do not provide a delivery date unless one is in the supplied source or my message.” Save and try a new project chat.
Keep the reference material current
Project instructions describe how to answer. Uploaded knowledge files supply facts the answer may need. If you want product-specific replies, add the relevant current documents instead of expecting the system prompt to contain the whole product manual.
Review older files when requirements change. A well-written prompt cannot resolve two conflicting source versions by itself. State which one is authoritative and check the citations in the result.
This gives you a practical reusable workspace: a small set of stable rules, current source material, and a short request for the task at hand.
Keep different work in different projects
Use a separate project when the audience or rules differ. For example, internal engineering notes can have a different structure from a customer reply. Project knowledge files can supply the relevant source material beside the instructions.
For a research project, use a different rule: “Separate evidence, assumptions, and unanswered questions. Explain trade-offs with concrete examples. Do not invent measurements or citations.” Ask a sample question in each project and check that the answer follows the right brief.
This is organization, not a security boundary. Project chats can use project context, and paired workspace sync shares project data across paired devices. There is no per-project sync switch for isolating one confidential project.
Try OGAD with one project and five useful rules. Save them once, then use a new chat in that project for the next task.