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.

## 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.