Assign Owners Agent Skill

---
name: assign-owners
description: Builds a team expertise map, then assigns content owners across a
  content library and accuracy/narrative reviewers across an RFP, balancing
  workload. Proposes first; never writes back without approval.
---

# Assign Owners

There are three roles:

| Role | Job | Typical person |
|---|---|---|
| **Content Owner** | Owns a library item. Keeps it accurate and current. Accountable when it goes stale. | SME for that subject |
| **Reviewer** | Approves a drafted response. Review is **sequential**: one reviewer for **accuracy** (is it true and current?), then one for **narrative** (does it answer the question, in the buyer's language, on message?). | Accuracy: SME or content owner. Narrative: bid/proposal manager or writer |
| **Editor** | Drafts and assembles the response and submits it. | Bid manager, proposal writer, sales engineer |

**SMEs are reserved for review.** Route drafting to editors. Send SMEs drafted answers to check, not blank answers to fill.

**Propose, don't write.** Nothing is assigned in any system without explicit approval. Where there is no clear expert, mark the item unassigned with the reason rather than guessing.

## Which mode you are in

Ask (or infer from the request) which of these the user wants:

- **Mode A - Library ownership.** Assign Content Owners across a content repository.
- **Mode B - RFP review routing.** Assign reviewers (and optionally editors) across the requirements of one RFP, DDQ or questionnaire.
- **Both.** Run A first. Content ownership is the strongest evidence for review routing, so B is noticeably better once A exists.

Both modes need the **Team Expertise Map** (Step 1). Build it once, persist it, reuse it.

## Step 0: Find the sources

Work out what you can actually reach before asking the user for anything. Check which tools and connectors exist in this session.

**Content repository** (where the reusable answers live). Examples:

- **AutoRFP.ai content library via the AutoRFP.ai MCP** - `list_content` (enumerate by type, tag, dates, `hasAnswer`), `list_tags` (category/tag vocabulary), `search_content` (semantic search), `list_content_usage` (which projects and requirements reused an item). Regional instances exist (e.g. an `AutoRFP_ai_Europe` server); use the one the user's org is on.
- **Google Drive** - folders of answer docs, security packs, boilerplate. Use Drive search and read tools.
- **SharePoint / OneDrive** - via the Microsoft 365 connector's SharePoint search.
- **Uploaded files** - a spreadsheet export of the library, a folder of docs.

**RFP source** (Mode B):

- **AutoRFP.ai MCP** - `list_projects`, `get_project` (status counts, tags), `list_requirements` (question, answer, section, status, tags, `lastUpdatedBy`; filter `hasAnswer`, `status`).
- **A file** the user uploads (xlsx, docx, pdf). Parse it into rows of: section, requirement ID/number, question, current answer (may be blank).

**People evidence** (Step 1 research, only if needed): Slack, Microsoft Teams, Outlook/Gmail, Google Drive document authorship, the CRM, and AutoRFP.ai's own `lastUpdatedBy` history.

If a source exists that you cannot reach, say so and ask for an export rather than guessing at its contents.

## Step 1: Build the Team Expertise Map

### 1a. Check for an existing map

Look for a persisted map first: `team-expertise-map.md` (or `.xlsx`/`.csv`) in project files, a connected folder, a wiki/Notion page, or memory. If found, show it, ask what has changed (joiners, leavers, role changes), and move on.

### 1b. If there is no map, ask

Ask the user, in one batch:

1. Who contributes to RFPs, security questionnaires or the content library? Names, job titles, teams.
2. Do you already have a mapping of each person to their subject areas? (Paste it, point to a file, or say no.)
3. Who submits responses (editors) and who owns final narrative sign-off?
4. Anyone who must **not** be assigned (leave, exec time, contractors) or who has a hard capacity limit?
5. Should I research the rest from your connected tools (email, Slack, Teams, past AutoRFP.ai projects)?

If they provide a complete mapping, normalise it (Step 1d) and skip 1c.

### 1c. If there is no mapping, research and propose one

Only research with the user's go-ahead, and only to the depth needed. You are looking for **work signals of expertise**, not reading people's correspondence for its own sake.

Strongest to weakest evidence:

1. **AutoRFP.ai authorship history.** For recent won/completed projects, `list_requirements` with `status: ["approved"]` returns `lastUpdatedBy` per requirement, plus its tags and section. Aggregate: person -> tags/sections they repeatedly finalise. Caveat: `lastUpdatedBy` is the *last* editor, so a bid manager who tidies everything will look like an expert in everything. Discount people whose activity is spread evenly across all tags; that pattern is an editor, not an SME.
2. **Content usage trails.** `list_content_usage` on library items -> the requirements that reused them -> who last updated those. Links people to specific content.
3. **Internal chat (Slack / Teams).** Search RFP, bid, security, proposals and deal channels for who *answers* subject questions ("@Priya can you confirm our RPO?" -> Priya replies with the answer). Answering is the signal; being asked is not.
4. **Email (Outlook / Gmail).** Threads with subjects like RFP, questionnaire, SIG, CAIQ, DDQ, tender: who gets forwarded which questions and who replies with substance.
5. **Document authorship.** Owners/last-modifiers of security policies, architecture docs, implementation guides in Drive/SharePoint.
6. **Job title and team.** Useful as a tiebreaker, weak on its own. "Head of Engineering" is not automatically the person who knows the SSO answer.

Keep it proportionate: search for subject areas, don't trawl everything. Don't record anything personal or sensitive you come across; it has no place in an expertise map.

Then **propose** the map with evidence and confidence for each line, and ask the user to confirm, correct or fill gaps. Never treat the researched map as final until they have.

### 1d. Map format

Anchor subject areas to the org's own **tag taxonomy** (from `list_tags` when AutoRFP.ai is connected, or the folder/section structure of the repository otherwise). Shared vocabulary is what makes Step 2 matching reliable instead of fuzzy.

| Person | Title / Team | Role(s) | Primary expertise (tags) | Secondary expertise | Capacity / constraints | Evidence | Confidence |
|---|---|---|---|---|---|---|---|
| Priya Shah | Security Lead | Content Owner, Accuracy Reviewer | Security, Compliance, Data Privacy | Infrastructure | ~20 items max | 34 approved security answers finalised in last 6 months; answers #security-questions | High |

Confidence: **High** = multiple independent signals or user-confirmed. **Medium** = one strong signal. **Low** = title only or a single weak signal; flag for confirmation.

Offer to save the confirmed map (project file, connected folder, Notion, or wherever the user keeps durable docs) so the next run starts from it.

## Step 2: Assign Content Owners (Mode A)

### 2a. Inventory the library

- **AutoRFP.ai:** page through `list_content` (25 per page; follow `pagination.hasMore`). Capture: item (question text or file/section name), fileType, tags, `updatedAt`, `usageCount`, `referenceUrl`. Use the `referenceUrl` for links; never show raw IDs to the user.
- **Drive / SharePoint / files:** one row per document (or per section for large packs). Use folder path and headings as the topic signal.

For large libraries (hundreds or thousands of items), say how many items there are and agree scope first: all, by tag, high-usage only, or stale-only. Work in tag-sized batches.

### 2b. Match each item to an owner

For each item, in order:

1. **Tag match** against primary expertise.
2. **Historical evidence**: who has finalised responses that used this item (`list_content_usage` -> `lastUpdatedBy`).
3. **Semantic match** on the content itself where tags are missing or too broad.
4. **Secondary expertise** as a fallback.

If nothing clears a sensible bar, leave it **Unassigned** with the reason. Don't force it onto the nearest title.

### 2c. Balance the load

Raw item counts mislead. A 10-word "Company HQ address" Q&A is not the same upkeep as a 3-page security architecture doc used in every bid. Weight each item:

- **Usage** - high `usageCount` / recent use = more exposure, more upkeep.
- **Size and volatility** - long docs and fast-changing subjects (security, certifications, product capabilities, pricing) weigh more than static facts.
- **Staleness** - items not updated in 12+ months need a refresh, so they cost more now.

Then:

- Respect stated capacity limits and exclusions.
- If one person exceeds roughly 1.5x the average weighted load, move their lowest-confidence or secondary-expertise items to the next best qualified person and note the trade-off.
- Assign every item a **backup owner** where a second qualified person exists. Single points of failure are the main reason libraries rot.

### 2d. Output (Mode A)

1. **Team Expertise Map** (Step 1d table, confirmed).
2. **Content Ownership Plan**:

| Content item | Type | Tags | Last updated | Usage | Proposed owner | Backup | Match reason | Confidence |
|---|---|---|---|---|---|---|---|---|

3. **Load summary** - per person: item count, weighted load, % of total, items flagged stale.
4. **Exceptions** - unassigned items, low-confidence matches, gaps in expertise (e.g. "No one in the team clearly owns Accessibility; 14 items"), and any duplicate/contradictory content noticed along the way.

For more than ~30 rows, deliver the plan as a spreadsheet as well as the summary in chat, so the user can sort, edit and bulk import.

## Step 3: The write-back gate

Never assign, reassign or change anything in any system without the user explicitly approving **that specific change set**. Proposing is free; writing is not.

Before any write:

1. Show exactly what will change: item, current owner (if any), new owner, count of changes.
2. Ask for explicit approval. Approval of the plan in general is not approval to write. Partial approval is fine ("do Security, hold Legal").
3. Write in the approved batches only, then report what succeeded and what failed.

If the connected tools are **read-only** (as of writing, the AutoRFP.ai MCP exposes read tools only; check the live tool list), say so plainly and hand over the approved plan in a format the user can apply: a spreadsheet with item name, link and owner for bulk import, or a per-person list they can action in the platform. Don't imply something was assigned when it wasn't.

## Step 4: Assign RFP reviewers (Mode B)

### 4a. Load the RFP

- **AutoRFP.ai:** `get_project` for header, due date and status counts, then `list_requirements` (all pages). Note each requirement's status (`drafted`, `assigned`, `submittedForReview`, `approved`) and whether the answer is blank.
- **File:** parse into section / number / question / answer rows. Confirm the row count and section split with the user before assigning.

Triage every requirement:

- **Blank** - needs drafting first. Assign an **Editor** to draft from the library, and pre-assign the accuracy reviewer so the handoff is ready. If the library has nothing relevant, flag it as a **content gap** and name the content owner who should create the source answer.
- **Drafted / needs review** - assign reviewers.
- **Already approved** - leave alone unless the user asks for a re-review.

### 4b. Choose the accuracy reviewer

Their job: is this true, current and defensible? So the best accuracy reviewer is whoever owns the *source*:

1. **Owner of the library content the answer drew on.** Find it via `search_content` on the requirement (or `list_content_usage` in reverse), or by matching tags. If Mode A ran, use that plan.
2. **Primary expertise match** on the requirement's tags/section.
3. **Secondary expertise** or backup owner.

Sanity checks:

- Don't make someone the sole accuracy check on an answer they drafted themselves; a second pair of eyes is the point. If only they qualify, flag it.
- Requirements spanning two domains (e.g. "describe data residency and your DR approach") can get two accuracy reviewers. Use this sparingly.
- Pass/fail and compliance-critical items (certifications, insurance, legal terms, pricing, SLAs) always get a **High**-confidence accuracy reviewer or are flagged for the user to pick one.

### 4c. Choose the narrative reviewer

Their job: does it answer what was asked, in the buyer's language, on message, consistent with the rest of the response? Usually one bid/proposal manager for the whole RFP, or one per volume for large bids. They review *after* accuracy, so a narrative edit never reintroduces a factual error. They should not be the editor who drafted the answer.

### 4d. Balance against the deadline

Review load matters more here because there is a clock. Using the due date:

- Count items per reviewer and estimate effort (long-form narrative answers weigh more than yes/no rows).
- Leave room for sequencing: accuracy review must finish before narrative review starts. If the due date is close, say how many days each stage realistically has.
- If one SME is assigned far more than others, rebalance to qualified backups first. If there is no qualified backup, keep the assignment and flag the bottleneck, rather than handing a security answer to someone who can't verify it.
- If calendar access is connected and the user wants it, check obvious availability conflicts (leave, travel) for heavily loaded reviewers.

### 4e. Output (Mode B)

1. **Review plan**:

| Section | # | Requirement (short) | Status | Editor | Accuracy reviewer | Narrative reviewer | Why | Confidence |
|---|---|---|---|---|---|---|---|---|

2. **Reviewer load** - per person: count, estimated effort, and the date their stage needs to finish.
3. **Flags** - blank answers with no library source (content gaps, with the owner who should fill them), low-confidence assignments, SME bottlenecks, compliance-critical items without a confident reviewer.
4. **Optional:** a short per-person message the user can send ("Priya, you're accuracy reviewer on 18 items in the Security section, due Thursday..."), drafted, not sent.

The write-back gate in Step 3 applies here too: confirm before assigning reviewers or editors in AutoRFP.ai or any other system, and before sending any notifications.

## Principles to hold onto

- **Evidence over titles.** Every assignment carries a one-line reason a person can check. "Security Lead" is a title; "finalised 34 approved security answers in the last two quarters" is evidence.
- **Unassigned beats wrong.** A visible gap gets fixed. A wrong owner hides the gap.
- **Balance is a feature, not a nicety.** The plan fails if it routes 60% of the work to the one person everyone already relies on. Show the load so the user can see it too.
- **Propose, then write.** Nothing changes in a system until the user approves the specific changes.
- **Persist what you learn.** The expertise map and ownership plan are reusable assets. Save them so the next run takes minutes.