MCP Writeback Governance Prompt

The Prompt

You are a systems governance assistant. Create a safe writeback protocol for MCP-enabled execution after research and synthesis, with explicit separation between read access, draft generation, approval, and final writes.

PREFERRED LLM / FAMILY:
{{preferred_llm}}

PROCESS TYPE:
{{process_type}}

INPUT SOURCES:
{{input_sources}}

WRITE TARGETS:
{{write_targets}}

APPROVAL RULES:
{{approval_rules}}

ROLLBACK PLAN:
{{rollback_plan}}

COMPLIANCE REQUIREMENTS:
{{compliance_requirements}}

Return exactly these sections:

1) Write Action Matrix
- Proposed writes: system, action type, scope, required source evidence, post-write verification step.
- Classification: low / medium / high risk.
- Mark each row as read-only, draft-only, or write-after-approval.

2) Human-in-the-Loop Design
- Required approver for each risk class.
- Required artifacts for approval.
- Conditions that force escalation to manual handling.

3) MCP Execution Protocol
- Step order: preflight checks, dry-run, approval, execution, post-write validation.
- Idempotency method per action type.
- Logging requirements per step.

4) Draft Payload Set
- For each target system, provide a JSON-ready payload template marked as DRAFT.
- Include fields the human reviewer must confirm before execution.

5) Verification and Audit
- Evidence requirements
- What to log for traceability
- Recovery steps and rollback trigger conditions

6) Policy Checks
- Actions blocked by policy
- Required escalation path for violations
- Connector or MCP capability assumptions that must be re-verified before rollout

Rules:
- Never generate raw credentials or secrets.
- Do not emit commands that execute outside user policy.
- Include "requires_human_approval: true" in all non-read proposed writes.
- If a capability depends on workspace plan, tenant configuration, or admin enablement, flag that dependency explicitly.

When to Use

Use this when a workflow includes recommendations that must be written back to knowledge systems, issue trackers, chat systems, or operational boards. It is designed for the newer generation of MCP-enabled agents where the model can both retrieve context and propose system changes, but the team still needs a strict approval boundary.

Variables

Variable	Description	Example
`preferred_llm`	Preferred model for policy-sensitive synthesis	`gpt`, `claude-sonnet`
`process_type`	Workflow being governed	”incident response”, “monthly briefing”, “financial close review”
`input_sources`	Source systems and trusted evidence inputs	”Jira API, Confluence pages, Slack thread IDs”
`write_targets`	Destination systems where proposals will be drafted	”Notion, Atlassian Rovo, Slack”
`approval_rules`	Role + threshold rules	”Manager approve for low risk, director for critical”
`rollback_plan`	Recovery approach if action is wrong	”revert page revision, reopen prior status, notify channel”
`compliance_requirements`	Required legal or policy boundaries	”No customer identifiers in public logs”

Tips & Variations

Ask for dual-pass validation: one model drafts, a second reviewer model critiques every proposed write.
Add a “plan capability matrix” when some MCP targets are read-only and others can write.
Add a “no action taken” branch when confidence is below threshold.
For critical systems, require at least two independent evidence links before proposing changes.
Request periodic cleanup: clear out stale proposed actions after N days.
Require a reviewer-friendly changelog line for each approved write so later audits can reconstruct intent quickly.

Example Output

Draft matrix includes ticket updates and decision log rows, each marked proposed.
Execution protocol separates read, draft, approve, write, and verify phases.
Audit section tracks approver, rationale, timestamp, rollback target, and post-write confirmation for each action.

The Prompt

When to Use

Variables

Tips & Variations

Example Output

Related site references