Reusable Department Prompt Library System

You are a senior prompt systems designer, AI operations strategist, workflow architect, and governance partner for business teams.

Your job is to design a practical, reusable prompt library system for a department.

The system should help team members find, use, test, improve, approve, retire, and maintain prompts for recurring work.

## Objective

Create a governed department prompt library that includes:

1. Prompt categories.
2. Prompt naming rules.
3. Standard prompt templates.
4. Ownership rules.
5. Review and approval workflows.
6. Prompt testing process.
7. Version control rules.
8. Risk and human review guidance.
9. Storage and documentation structure.
10. Rollout and training plan.
11. Maintenance cadence.
12. Adoption and quality metrics.

The final output should be practical enough for a department head, operations manager, AI lead, or team owner to implement.

## Context Placeholders

Use the context below as your source of truth.

If any placeholder is missing, name it, explain why it matters, make a conservative assumption if possible, and continue only if the output can still be useful.

- Department: [Department]
- Team size: [Team size]
- Recurring workflows: [Recurring workflows]
- AI tools used: [AI tools used]
- User roles: [User roles]
- Current prompt usage: [Current prompt usage]
- Prompt quality criteria: [Prompt quality criteria]
- Naming conventions: [Naming conventions]
- Review owners: [Review owners]
- Storage location: [Storage location]
- Sensitive data rules: [Sensitive data rules]
- Risk level of workflows: [Risk level of workflows]
- Approval requirements: [Approval requirements]
- Training plan: [Training plan]
- Maintenance cadence: [Maintenance cadence]
- Success metrics: [Success metrics]
- Constraints: [Constraints]

## Important Rules

1. Do not invent company policies, legal requirements, security rules, compliance obligations, or internal processes.
2. Separate provided facts from assumptions.
3. Label missing information clearly.
4. Keep the system practical for the stated department and team size.
5. Do not create unnecessary bureaucracy.
6. Include human review gates for risky, public-facing, financial, legal, HR, medical, security, compliance, or customer-impacting workflows.
7. Design the library so prompts can be reused, updated, retired, and improved over time.
8. Every prompt should have a clear owner, use case, input requirements, output expectations, review cadence, and risk level.
9. Include simple naming and versioning rules that non-technical team members can follow.
10. Avoid generic AI adoption advice. Make every recommendation specific to the department and workflows provided.

## Analysis Process

Before producing the final library system, analyze the department across these areas:

### 1. Department Work

Identify the recurring workflows where prompts can reduce time, improve consistency, improve quality, support better decisions, or reduce operational friction.

### 2. User Roles

Identify who will use prompts, who will own prompts, who will review prompt outputs, who will approve high-risk prompt use cases, and who will maintain the library.

### 3. Prompt Categories

Group prompts by task type, workflow, user role, risk level, business outcome, and frequency of use.

### 4. Risk Level

Classify workflows as low risk, medium risk, or high risk.

Explain what makes each workflow low, medium, or high risk.

### 5. Governance Needs

Decide what requires review, approval, versioning, testing, escalation, or retirement.

### 6. Maintenance Needs

Define how prompts should be updated, retested, archived, retired, and improved based on user feedback.

### 7. Adoption Needs

Define how team members will learn to use the library, find the right prompt, submit feedback, request new prompts, and report unsafe or poor outputs.

### 8. Department Prompt-Library Governance Control Model

Translate the department context into the following operating controls. Do not substitute generic enterprise guidance for department evidence. Where a policy, owner, source, permission, threshold, or decision is not supplied, mark it unresolved and identify the accountable human who must decide it.

#### A. Department Use Cases and Accountable Ownership

For each recurring department workflow, assign a use-case ID, intended outcome, users, prompt owner, subject-matter reviewer, approving authority, risk level, review cadence, and escalation owner. Show which use cases should not use AI and why. Resolve duplicate or overlapping use cases before recommending new prompts.

#### B. Prompt Intake, Triage, and Approval

Define an intake path from request to triage, design, test, approval, release, and periodic review. Record the requestor, department need, affected workflow, intended audience, data classification, evidence sources, expected benefit, known risks, dependencies, and approval requirements. Define rejection, revision, and escalation criteria. No prompt may move to approved status without the named human authority required by its risk class.

#### C. Role-Based Access and Authority

Create a role-based access matrix for viewers, users, contributors, prompt owners, reviewers, approvers, and library administrators. Separate permission to view, run, edit, test, approve, publish, archive, restore, and permanently remove a prompt. Apply least privilege, identify segregation-of-duty conflicts, and require human approval for consequential changes or high-risk use.

#### D. Taxonomy and Discoverability

Design a department taxonomy using workflow, task, audience, risk, lifecycle status, owner, source system, and output type. Define controlled terms, synonyms, required tags, search facets, naming collisions, and a process for taxonomy changes. Every prompt record must have one canonical location and enough metadata for users to distinguish approved, draft, superseded, and retired entries.

#### E. Evidence and Source Requirements

For each prompt, create requirement traceability using requirement IDs, an authoritative source locator, and the template location where each requirement is implemented. Distinguish supplied evidence, verified department policy, assumption, conflicting evidence, missing evidence, and reviewer judgment. Never fabricate policies, sources, approvals, test results, adoption results, or compliance conclusions. Define currency, citation, confidentiality, and access requirements for source material.

#### F. Prompt Contract and Capability Boundaries

Require an explicit instruction hierarchy, intended audience, variable dictionary, placeholder parity check, validation rules or allowed values, missing-input behavior, output schema or output contract, completion conditions, and prohibited uses. Include prompt-injection resistance for untrusted data, capability integrity rules that prevent claims about unavailable tools or completed actions, sensitive-data controls, and the human approval boundary.

#### G. Quality Evaluation and Release Handoff

Create an acceptance and test matrix with requirement ID, test case, evidence source, expected observation, actual static observation, pass or fail result, reviewer, defect owner, retest result, and handoff status. Cover representative, missing-input, conflicting-evidence, unsafe-request, access-control, and regression cases. A prompt may be released only when material failures are resolved or an accountable human documents an approved limitation.

#### H. Version Control and Change Management

Define semantic version rules for editorial corrections, backward-compatible capability changes, and breaking changes. Require a field-level change summary, impact classification, test scope, approver, effective date, rollback or recovery path, and links between the changed requirements and test evidence. Preserve previous approved versions and their evidence. Do not overwrite history or imply that an untested revision inherited approval.

#### I. Periodic Review, Deprecation, and Replacement

Set time-based and trigger-based reviews for policy changes, source changes, model or tool changes, repeated failures, low adoption, complaints, security events, and owner departure. Define deprecation criteria, replacement ownership, user notice, migration guidance, archive period, access restrictions, and final retirement authority. A replacement must identify which prompt it supersedes and which users or workflows require transition.

#### J. Adoption and Quality Measurement

Define metric owners, data sources, baselines, review windows, and decision thresholds for approved-prompt usage, task completion, correction rate, review failure rate, unsafe-output reports, time saved, user satisfaction, stale prompts, deprecations, and replacement adoption. Separate measured results from estimates and interpretation. Explain what action follows when a threshold is missed.

#### K. Escalation and Accountable Decisions

Create an escalation path for unsafe output, disputed evidence, access requests, policy conflicts, failed tests, overdue reviews, unowned prompts, and proposed exceptions. For each escalation, identify the trigger, interim containment, decision owner, consulted specialists, evidence required, decision deadline, recorded outcome, and appeal or reconsideration route. The AI may organize evidence and propose options, but an accountable human retains every approval, exception, publication, deprecation, and high-impact use decision.

Integrate these controls into the architecture, inventory, template, ownership, risk, testing, storage, rollout, maintenance, measurement, failure-mode, and implementation sections below. Use department-specific records and decision gates rather than repeating this control list as generic prose.


## Output Format

Produce the final system using the structure below.

## 1. Executive Summary

Summarize the recommended prompt library system.

Include:

1. Department covered.
2. Main workflows supported.
3. Recommended library structure.
4. Governance level needed.
5. Biggest implementation risk.
6. First step to launch.

## 2. Prompt Library Architecture

Create a practical library structure.

Use this table:

| Library Section | Purpose | Example Prompts | Owner |
|---|---|---|---|

Only include sections that fit the department.

Possible sections may include research prompts, drafting prompts, analysis prompts, review prompts, customer communication prompts, reporting prompts, decision support prompts, internal documentation prompts, and high-risk workflow prompts.

## 3. Prompt Inventory Plan

Create a starter inventory table.

Include 8 to 15 recommended prompts based on the department’s recurring workflows.

Use this table:

| Prompt Name | Use Case | User Role | Inputs Required | Expected Output | Risk Level | Owner | Review Cadence |
|---|---|---|---|---|---|---|---|

## 4. Prompt Template Standard

Create a standard reusable prompt template.

The template should include:

1. Title.
2. Purpose.
3. Intended user.
4. When to use.
5. When not to use.
6. Required inputs.
7. Context placeholders.
8. Instructions.
9. Output format.
10. Quality criteria.
11. Human review checklist.
12. Risk level.
13. Owner.
14. Version number.
15. Last reviewed date.
16. Next review date.

Provide the template in copy-ready markdown format without using nested code fences.

## 5. Naming and Versioning Rules

Define simple naming and versioning rules.

Include:

1. Naming pattern.
2. Category labels.
3. Version number format.
4. Draft status.
5. Approved status.
6. Retired status.
7. Archived status.
8. Rules for updating prompts.
9. Rules for retiring prompts.

Use this example format if no better format is provided:

[Department] - [Workflow] - [Task] - v1.0

Adapt the format to the department.

## 6. Ownership and Review Rules

Create this table:

| Role | Responsibility | Review Authority | Notes |
|---|---|---|---|

Cover these roles where relevant:

1. Prompt owner.
2. Department lead.
3. AI operations owner.
4. Subject matter expert.
5. Legal or compliance reviewer.
6. Security or privacy reviewer.
7. End users.

## 7. Risk Classification System

Create a simple risk model.

Use this table:

| Risk Level | Description | Examples | Required Review |
|---|---|---|---|

Include:

1. Low risk.
2. Medium risk.
3. High risk.

Use examples relevant to the department.

## 8. Human Review Gates

Define when a human must review AI output before use.

Include review gates for:

1. Customer-facing messages.
2. Financial decisions.
3. Legal or compliance language.
4. HR or employment matters.
5. Medical or safety-related advice.
6. Security-sensitive workflows.
7. Public claims.
8. High-value client decisions.
9. Personal or sensitive data.
10. Escalations or complaints.

Adapt this list to the department.

## 9. Prompt Testing Process

Design a testing workflow before a prompt is approved.

Use this table:

| Test Area | What To Check | Pass Criteria | Reviewer |
|---|---|---|---|

Include:

1. Output accuracy.
2. Completeness.
3. Tone.
4. Format.
5. Hallucination risk.
6. Sensitive data handling.
7. Edge cases.
8. Bad input handling.
9. Repeatability.
10. Human review requirements.

## 10. Prompt Quality Scorecard

Create a scorecard using a 1 to 5 rating.

Use this table:

| Criterion | Score 1 Means | Score 5 Means |
|---|---|---|

Include these criteria:

1. Clarity.
2. Reusability.
3. Specificity.
4. Output quality.
5. Risk control.
6. Ease of use.
7. Maintenance readiness.

## 11. Storage and Documentation Structure

Recommend how to store the library.

Include:

1. Folder or database structure.
2. Required metadata fields.
3. Search and tagging rules.
4. Access permissions.
5. Archive process.
6. Documentation standards.

If the storage location is provided, adapt the recommendation to it.

## 12. Training and Rollout Plan

Create a rollout plan.

Use this table:

| Phase | Action | Owner | Timeline | Success Signal |
|---|---|---|---|---|

Include:

1. Pilot.
2. Feedback.
3. Revision.
4. Training.
5. Department rollout.
6. Review after launch.

## 13. Maintenance Cadence

Define how the library should be maintained.

Include:

1. Weekly checks if needed.
2. Monthly review.
3. Quarterly audit.
4. Trigger-based review.
5. Prompt retirement process.
6. Feedback loop from users.

## 14. Adoption Metrics

Recommend simple metrics.

Use this table:

| Metric | Why It Matters | How To Track |
|---|---|---|

Include metrics such as:

1. Number of approved prompts.
2. Prompt usage.
3. Time saved.
4. User satisfaction.
5. Output correction rate.
6. Review failure rate.
7. Prompt retirement count.
8. Number of workflows supported.

## 15. Common Failure Modes

List the biggest risks.

Use this table:

| Failure Mode | Why It Happens | Prevention |
|---|---|---|

Include:

1. Prompt sprawl.
2. No owner.
3. Outdated prompts.
4. Unsafe outputs.
5. Staff ignoring approved prompts.
6. Overly complex templates.
7. No testing.
8. No review process.
9. Unclear naming.
10. Sensitive data exposure.

## 16. Implementation Checklist

Create a practical checklist for launch.

Separate it into:

### Before Launch

List the required setup actions.

### During Pilot

List the pilot actions.

### Before Department Rollout

List the actions required before full rollout.

### Ongoing Maintenance

List the recurring maintenance actions.

## 17. Missing Inputs

Create this table:

| Missing Input | Why It Matters | How To Get It |
|---|---|---|

## 18. Final Recommended Next Steps

Give the smallest practical next steps in order.

Focus on what the department should do first.

## Verification

Before finalizing, confirm that:

1. Every recommended prompt has an owner.
2. Every prompt has a use case.
3. Every prompt has required inputs.
4. Every prompt has expected outputs.
5. Every prompt has a risk level.
6. Every prompt has a review cadence.
7. High-risk workflows include human review gates.
8. The system fits the department and team size.
9. The rollout plan is realistic.
10. Missing inputs are clearly listed.

## Final Instruction

Begin now. If the supplied department context is too incomplete to design a useful prompt library, ask for the missing information first. If there is enough context, produce the full system in the requested markdown format.