Build the Instructions

I am now completing requirements discovery for a personal work AI assistant for [PRIMARY USER], who works as [ROLE OR FUNCTION]. This is Phase 3: Agent Instruction Design.

You have two authoritative inputs: Phase 1 Work Pattern Evidence Collection and Phase 2 Requirements Clarification. Convert them into the actual operating instructions for the assistant. Do not conduct a new discovery exercise or add generic best-practice behavior.

Requirement precedence: (1) confirmed requirement; (2) explicit new requirement; (3) combined evidence validated in Phase 2; (4) high-confidence Phase 1 evidence not contradicted in Phase 2; (5) unresolved, marked [DESIGN DECISION REQUIRED]. Do not encode any pattern classified as Legacy, Workaround, or Incorrect Observation unless Phase 2 explicitly requested it. Encode Contextual requirements with their stated conditions.

Write actual imperative instructions to the assistant, not commentary about what an assistant should do. Do not create a fictional persona. The assistant supports the user’s work; it does not replace their judgment or act in their name.

Use only the work domains established in Phase 1 and Phase 2. The assistant may support briefing, preparation, information compression, decision support, meeting preparation, history, commitments, and relevant work intelligence where the evidence supports those functions. Do not expand scope simply because a platform could support more functions.

Master Instruction Set Must Cover

Identity, primary user, mission, scope, and boundaries.

Core operating principles: evidence before assumption; current versus historical state; source grounding; uncertainty; conflicts; freshness; executive/work relevance; and information compression, but only where supported by the requirements.

Information retrieval rules: accessible sources only, known source priorities, when to combine sources, when to disclose uncertainty, and when to identify data gaps.

Role-specific intelligence: create default briefs and question behavior only for the work objects established by the evidence - for example a project, customer, vendor, system, initiative, contract, product, risk, or financial question.

Meeting preparation, decision support, challenge/pushback, commitments/follow-up, proactive intelligence, historical context, ownership, financial context, risk/issue context, and audience-aware communication where Phase 2 supports each behavior.

Trust, source, confidence, confidentiality, authority, failure handling, standard response patterns, and scope boundaries.

Required Outputs

A. Master Agent Instruction Set written as complete operating instructions.

B. Streamlined Production Instructions for a constrained platform instruction field. Preserve critical guardrails and identify logical modules that remain outside the core instructions if needed.

C. Required Knowledge and Data table: information domain; information required; why needed; observed/confirmed source; preferred source if established; freshness requirement; known gap.

D. Capability and Action Requirements table: capability; Read/Analyze/Draft/Monitor/Act; trigger; required data; required integration or capability; human approval; requirement source.

E. Design Decisions Still Required: genuinely unresolved decision; why it matters; evidence available; unknown; and impact.

F. Requirement Traceability table: instruction/behavior; Phase 1 evidence ID; Phase 2 requirement ID; confidence. Any invented behavior must be labeled [DESIGN DECISION REQUIRED].

Mandatory Guardrails

Never invent, assume, or silently fill missing work facts. Do not present stale or historical information as current.

Never claim to have searched or accessed a source unless the platform actually could.

Separate information retrieval, analysis, preparation, drafting, monitoring, and execution. Drafting does not grant permission to send or change anything.

Define action authority precisely. The assistant must not make decisions, send communications, assign work, alter records, or make external commitments without explicit approval where Phase 2 requires approval.

Respect user authorization and intended audience. Retrievable information is not automatically appropriate to disclose.

Fail visibly and usefully: identify what is known, missing, stale, conflicting, inaccessible, ambiguous, or insufficient for a recommendation.

Quality Check

Before returning the design, verify that each major behavior is Observed, Confirmed, Explicitly Requested, or labeled [DESIGN DECISION REQUIRED]. Confirm that no workaround has been mistaken for a desired future behavior, no unavailable source is treated as accessible, no authority was invented, and historical information is clearly separated from current state.