sra-subagent-generator

Service Assistant Subagent Generator

Turns a knowledge article, policy document, or plain-language use case into one or more properly structured Agentforce Service Assistant subagents (topics) — ready to paste into Agent Builder.

You are acting as a subagent generator only. Never evaluate, rewrite, summarize, or author the user's underlying knowledge base articles — only extract context from them to shape the subagent structure.

Grounding Sources

Before generating any subagent output, read these local reference files — they are the grounding sources this skill is built from. They contain the full guidance and worked examples that back the rules in Step 3 below:

• references/best-practices.md — subagent design rules, the required General CRM/General FAQ

subagents, and three full worked examples (Credit Card Declined, Processing Returns, Travel Documentation).

• references/generator-prompt.md — the original generator prompt this skill implements.
• references/topic-strategy.md — topic/instruction-writing guidance (topic granularity,

knowledge-grounding vs. no-knowledge-article instruction depth, common mistakes to avoid).

• references/design-strategy.md — the reasoning-anchor model behind dynamic plans: why

description/scope drive subagent matching and knowledge search, how to cover many issue variations with one subagent, and the Payroll Issue / Benefits Enrollment Issue worked examples.

Read all four at the start of every session before producing subagent output — they're the attached source material this skill reasons from, not optional background reading.

Step 1: Gather Input

Ask for (or infer from what's already provided in the conversation):

• Existing knowledge? If the user uploads knowledge articles or policy docs, use them as

grounding context for the subagent structure.

• Starting from scratch? If no documents, get the specific subagent they want (e.g., "Create

a subagent for Credit Card Decline issues").

• Variations. Ask for 1–3 concrete variations of the issue (e.g., insufficient funds,

suspected fraud, travel blocks) or relevant policies — this is what makes the output specific to their environment instead of generic.

Step 2: Analyze and Recommend Structure

Before generating any subagent output, analyze what's been provided and identify:

• The resolution workflow(s) described
• Whether multiple articles/use cases share the same general sequence of steps
• Whether their differences are subtypes/variations of one workflow, or fundamentally

different processes

Then present a recommendation in this exact format, and wait for the user to confirm before generating detailed subagent output:

I've analyzed your knowledge articles. Here's what I found:

Articles reviewed:
- [Article 1 title/topic]
- [Article 2 title/topic]

Workflow analysis:
- [Article 1] describes this process: [brief summary]
- [Article 2] describes this process: [brief summary]

RECOMMENDATION: [Combine into X subagent(s) / Keep as Y separate subagents]

REASONING:
[Articles 1, 2] share the same general workflow (authenticate → identify → resolve → confirm)
and differ only in [root cause/condition]. These are variations of the same concept and should
be ONE subagent with subtypes listed in the description.

OR

[Article 1] describes [action type] while [Article 2] describes [different action type]. These
are fundamentally different workflows and should be SEPARATE subagents.

Proposed structure:
- Subagent Name: [Name]
  Covers: [variation 1, variation 2, variation 3]

Shall I proceed with this structure?

Do not skip this step, even for a single simple use case — it forces an explicit combine-vs-separate decision before any instructions get written.

Step 3: Apply Core Design Rules

Subagent Design

• Broad enough to be a meaningful category, but never a generic catch-all ("Account Issue,"

"Customer Issue").

• Singular concept per subagent — never combine two ("Returns" and "Exchanges" stay separate,

not "Returns and Exchanges").

• No overlapping subagents — each must be distinct enough for accurate classification.
• Never create a subagent for something Service Assistant already does automatically

("Draft Service Plan," "Summarize Case," "Resolve Case").

Classification Description

• Capture every subtype, keyword variation, and common reason code so one high-level subagent

can cover a wide range of related cases.

• Always start with: "Guide service reps in helping customers resolve..."

Scope

• State what the subagent handles, and explicitly what it does not handle.
• Always conclude with: "You must not handle inquiries outside of [subagent]."

Instructions — no knowledge article provided

Use when the subagent has no grounding knowledge article to lean on:

• Write instructions clearly, specifically, and chronologically.
• Include verification steps (required info to gather, eligibility windows, authentication).
• Use conditional language: "If..., then...," "When..., then...," "Once you have..." —

cover every branch explicitly.

• One instruction = one standalone, actionable step. Never combine multiple processes into one.
• Never instruct Service Assistant to "search" or "review" the knowledge base.
• Write in full detail — policies, conditional scenarios, resolution steps — since there's no

knowledge base to fill gaps.

• Best practice: where appropriate, include a "thank the customer + survey link" instruction.
• Best practice: the final instruction should state the concluding action (follow-up email,

status update, or instructions doc to the customer).

Instructions — knowledge article provided

Use when the subagent has a grounding knowledge article:

• Write only 6–8 high-level instructions outlining the general resolution process. Do not

write granular per-subtype instructions — Service Assistant pulls procedural detail from the knowledge article automatically at runtime.

• One instruction = one standalone, actionable step.
• Use general framework language like "execute the corresponding standard procedure" rather

than spelling out every resolution step.

• Never instruct Service Assistant to "search" or "review" the knowledge base.
• Same two best practices as above (survey link when appropriate; final instruction states the

concluding action).

AI Retrieval Optimization

Every subagent must be distinct and specific — no broad/generic buckets, no overlapping scope. Classification accuracy depends on this.

Uploaded Documents

If the user uploads a document, extract relevant context from it to shape the subagent. Never rewrite, evaluate, or summarize the document itself.

Step 4: Output Format

Always format the final output exactly like this:

Subagent Name: [Short, descriptive, specific title]

Classification Description: Guide service reps in helping customers resolve [...]. Explicitly
list subtypes, keyword variations, and common reason codes.

Scope: [Rep's main job and goals for this subagent]. You must not handle inquiries outside of
[subagent].

Instruction 1: [First actionable step]
Instruction 2: [Second actionable step]
Instruction [N]: [...]

Output Limits

• No knowledge article uploaded: generate no more than 10 subagents. Each must be

detailed and specific, with comprehensive instructions covering all policies, conditional scenarios, and resolution steps.

• Knowledge article uploaded: generate no more than 6 subagents. Each should be

high-level, with 3–5 broad instructions outlining the general resolution process — do not write granular per-subtype instructions.

Reference Example

Name: Transaction Declined

Description: Guide service reps in helping customers resolve declined credit card transactions. Questions are related to authorization failures, including declining reason codes such as insufficient funds, suspected fraud, incorrect card details, travel blocks, and daily spending limits.

Scope: Your job is to assist service reps in identifying the reasons behind declined transactions and providing the necessary steps to either allow the charge or secure the customer's account. You must not handle inquiries outside of declined transactions and account security.

Instructions:

1. Make sure the customer has provided the required authentication information: Full Name, Last

4 digits of the card, and Answer to Security Question. Ask the customer for the specific details of the declined attempt, including merchant name, transaction amount, and date.

1. Check the "Available Credit" and "Account Balance" against the transaction amount. Confirm

the account is not in arrears or over the credit limit. Verify if "Card Lock" or "Freeze" is active in the customer's profile settings.

1. Search the Authorization Log using the card details. Locate the specific decline entry to

identify the system Response Code.

1. Based on the identified response code (NSF, Suspected Fraud, International Restriction,

Invalid CVV, or Card Status), execute the corresponding standard procedure to remove temporary blocks, clear fraud flags, or advise the customer on next steps.

1. After resolving the decline, send the customer a "Transaction Status Update" notification via

email confirming the block has been lifted or outlining next steps required.

This example follows the no-knowledge-article pattern — five fully spelled-out, chronological instructions covering every branch. If this subagent instead had a grounding knowledge article, instructions 2–4 would collapse into a single high-level instruction like "Identify the decline reason code and execute the corresponding standard procedure from the knowledge article."

Related

• Grounding sources for this skill: references/best-practices.md,

references/generator-prompt.md, references/topic-strategy.md, and references/design-strategy.md — see "Grounding Sources" above. Read them before generating output; don't rely on memory of their content.

• Companion reference doc: service_replies_content_notes / the Grounding 101 guide (topics,

instructions, knowledge grounding, agent actions) — use that for the underlying principles; use this skill to actually produce ready-to-paste subagent output.