Project name: Reviewed CRM Update Assistant

Context:
- Team or function: [TEAM NAME / ROLE OR FUNCTION]
- CRM update moment to improve: [CRM UPDATE MOMENT, for example post-meeting opportunity cleanup or pre-forecast account hygiene]
- CRM system: [CRM SYSTEM, for example Salesforce, Dynamics 365, Dataverse, HubSpot, or another CRM]
- Integration path: [INTEGRATION PATH, for example approved CRM connector/app, custom app, MCP server, export/import workflow, or review-only prototype]
- Target CRM objects: [TARGET CRM OBJECTS, for example Account, Opportunity, Contact, Task]
- Target fields: [TARGET FIELDS]
- Sensitive or approval-required fields: [SENSITIVE OR APPROVAL-REQUIRED FIELDS, for example amount, stage, close date, forecast category, customer commitments]
- Approved source systems or inputs: [APPROVED SOURCE SYSTEMS, for example meeting notes, call transcripts, email threads, Slack or Teams threads, CRM records]
- Permission model: [PERMISSION MODEL, for example inherit the user's CRM permissions, restrict to read-only, use export/import, or require admin-approved service access]
- Traceability requirements: [TRACEABILITY REQUIREMENTS, for example CRM field history, change reports, app logs, compliance logs where available, reviewer notes]
- Reviewers and approvers: [REVIEWERS AND APPROVERS, for example account owner, sales manager, RevOps, CRM admin, IT, security/privacy, audit/compliance]
- Pilot scope: [PILOT SCOPE]
- Success signals: [SUCCESS SIGNALS]
- Measurement owner: [MEASUREMENT OWNER]

Default build decisions:
- Use Codex as the build workspace and planning partner.
- Create a reusable CRM update skill with narrow instructions, target fields, output format, integration assumptions, and guardrails.
- Start with a read/review-first workflow. The first version should propose CRM updates and produce a review log. Do not enable direct CRM writeback unless I explicitly confirm that the required approvals are complete.
- Use a simple Sites-hosted review hub if Sites is available in my workspace. Keep it private or restricted by default. The review hub should show proposed updates, evidence, confidence gaps, sensitive-field flags, approval status, traceability notes, and export or writeback status.
- If Sites is not available, create an equivalent review table or local prototype that my team can inspect before any CRM write action.
- Use synthetic examples unless I provide approved test records or approved customer/account context.

Goal:
Build a workflow that helps my team turn approved customer/account context into reviewed CRM updates. It should identify the relevant CRM record, propose field changes, show evidence or source notes, flag uncertainty, require explicit approval for sensitive fields, preserve a review trail, and create a clear path to update the CRM only after review.

What to build:
1. Workflow Design Spec
   - Trigger
   - Inputs
   - Integration/access path
   - AI task
   - Human review
   - CRM output
   - Team use
   - Feedback loop
   - Required versus optional steps

2. Workflow Requirements Doc
   - Business problem
   - Users and stakeholders
   - In-scope and out-of-scope fields
   - Source systems and data requirements
   - CRM integration options
   - Permission requirements
   - Security, privacy, retention, auditability, and log requirements
   - Review and approval model
   - First build requirements
   - Later upgrades
   - Risks and mitigations

3. CRM Update Skill Spec
   - Role: Act as a CRM update assistant for [TEAM NAME].
   - Task: Translate approved customer/account context into concise, accurate CRM update proposals.
   - Scope: Only use approved inputs and target fields.
   - Guardrails: Do not change or recommend changes to sensitive fields without explicit approval. Flag missing evidence, assumptions, and low-confidence recommendations.
   - Output: Proposed field updates, source/evidence notes, confidence gaps, approval requirements, traceability notes, and next-step recommendations.
   - Review: Make it easy for a human to accept, reject, revise, or request more evidence for each proposed update.

4. Field Map and Review Rules
   - Map each source input to the CRM fields it may update.
   - Mark each field as low-risk, review-required, or explicit-approval-required.
   - Define what evidence is needed before Codex can suggest a change.
   - Define what should happen when evidence is missing or confidence is low.
   - Define what must happen before any write action is allowed.

5. Integration and Access Plan
   - Identify whether the first build uses a CRM connector/app, custom integration, MCP server, export/import workflow, or review-only prototype.
   - Identify who owns configuration and approval for the integration.
   - Document whether permissions inherit from the user or rely on another approved access model.
   - Document which objects and fields are read-only, writeable, blocked, or approval-required.
   - Include a non-Salesforce path if my CRM is not Salesforce.

6. Review Hub or Review Table
   - Show proposed updates by account or opportunity.
   - Include current value, proposed value, evidence, confidence gap, approval requirement, reviewer, status, traceability note, and reviewer comments.
   - Include a clear status model: Draft, Needs context, Ready for review, Approved, Rejected, Written to CRM, Needs follow-up.
   - Keep access restricted by default.

7. Traceability and Audit Plan
   - Define what the team needs to inspect after the workflow runs.
   - Include CRM field history or change reports where available.
   - Include application, connector, or compliance logs where available.
   - Define who checks the first set of updates and how exceptions are handled.
   - If step-by-step logs are not available, document what evidence and reviewer notes will serve as the practical review trail.

8. Sample Inputs and Outputs
   - Create synthetic sample records and sample source context.
   - Create examples of good proposed updates and examples that should be blocked or escalated.
   - Include examples for low-risk fields, sensitive fields, missing evidence, conflicting evidence, and unsupported assumptions.

9. Adoption Plan
   - Define who tests the first version.
   - Define the first workflow moment.
   - Define how teammates will learn to use it.
   - Define what feedback to collect.
   - Define how repeated edits or rejected outputs become durable skill instructions.
   - Define how to decide whether to expand.

10. Measurement Plan
   - Track realistic early signals, not unsupported ROI claims.
   - Suggested signals: repeated use, fewer delayed updates, reviewer acceptance rate, fewer manual handoffs, clearer next steps, more consistent CRM summaries, fewer missing fields before forecast or account review, and fewer unsupported assumptions after skill hardening.

Governance and safe-use requirements:
- Do not use confidential customer data, personally identifiable information, regulated data, or internal-only strategy unless I confirm it is approved for this workflow.
- Do not imply that every workspace has the same connector, app, MCP, mobile, dictation, writeback, or compliance-log capabilities.
- Preserve human review for sensitive fields and business-critical changes.
- Keep CRM auditability in mind. Note what should be checked in CRM field history, change reports, app logs, connector logs, or other audit logs.
- Document all assumptions and approval gaps.
- If a required approval is missing, build the workflow in review-only mode and list what approval is needed before expanding.

How I want you to work:
- Start by producing a concise implementation plan.
- Ask clarifying questions only if they block a safe first version. Otherwise make reasonable default choices and clearly label assumptions.
- After the plan is approved, create the workflow artifacts and prototype.
- Keep the language understandable for non-technical teammates and reviewers.
- Clearly separate what is ready to use from what requires validation or approval.