Project instructions & context
Project instructions define stable requirements that should apply across related work inside a project.
Put durable rules here
Good project instructions include:
- required technology stack
- naming conventions
- architectural constraints
- preferred writing style
- release conventions
- organization-specific rules
- important product terminology
Keep temporary details out
Do not put one-time bugs, today’s deadline, temporary file names, or a single task’s acceptance criteria into durable project instructions unless they truly apply to future work too.
Instruction precedence
Project instructions are one context layer. They do not bypass platform safety, organization policy, tool permissions, or administrator configuration.
A task prompt can add narrower requirements, but it should not silently contradict stable project rules. When requirements conflict, Starfire should make the conflict visible rather than guessing which rule to ignore.
Context selection
Project OS can combine project instructions with relevant conversations, files, Knowledge, repositories, research, and artifacts. The runtime does not need to inject every project resource into every request.
Keep instructions maintainable
Review project instructions after major product changes. Remove stale framework versions, retired policies, or temporary migration rules that no longer apply.
If you keep copying the same paragraph into every conversation in a project, that paragraph probably belongs in project instructions or Knowledge.
