@salesforce/afv-skills 1.7.2 → 1.7.4

package/skills/developing-agentforce/assets/patterns/bidirectional-routing.agent

@@ -1,34 +1,34 @@
 # Bidirectional Routing Pattern
-# Navigate to a specialist topic and return with results
+# Navigate to a specialist subagent and return with results
 #
 # ★ When To Use This Pattern:
-#   - Main topic needs specialized processing then returns
+#   - Main subagent needs specialized processing then returns
 #   - "Consult a specialist" pattern (like asking an expert)
 #   - Complex workflows where you leave, do work, then come back
-#   - Alternative to cramming everything into one topic
+#   - Alternative to cramming everything into one subagent
 #
 # ★ Key Insight:
 #   Standard transitions (@utils.transition) are one-way.
 #   For round-trip routing, store the "return address" in a variable.
-#   The specialist topic transitions back when done.
+#   The specialist subagent transitions back when done.
 #
 # ★ Architecture Decision:
 #   Use this when you want separation of concerns:
-#   - Main topic: Orchestration and user interaction
-#   - Specialist topic: Focused, complex processing
+#   - Main subagent: Orchestration and user interaction
+#   - Specialist subagent: Focused, complex processing
 #
 # This is a PARTIAL template - integrate into a complete agent file
 
 variables:
 	# ... standard linked variables ...
-	return_topic: mutable string = ""
-		description: "Topic to return to after specialist consultation"
+	return_subagent: mutable string = ""
+		description: "Subagent to return to after specialist consultation"
 	specialist_result: mutable string = ""
-		description: "Result from specialist topic"
+		description: "Result from specialist subagent"
 	consultation_status: mutable string = ""
 		description: "Status of specialist consultation"
 
-# Main orchestration topic
+# Main orchestration subagent
 start_agent main_hub:
 	label: "Main Hub"
 	description: "Central hub that routes to specialists and handles results"
@@ -46,17 +46,17 @@ start_agent main_hub:
 			| Consultation status: {!@variables.consultation_status}
 		actions:
 			# Route to pricing specialist (store return address first)
-			consult_pricing: @utils.transition to @topic.pricing_specialist
+			consult_pricing: @utils.transition to @subagent.pricing_specialist
 				available when @variables.consultation_status != "in_progress"
 
 			# Route to technical specialist
-			consult_technical: @utils.transition to @topic.technical_specialist
+			consult_technical: @utils.transition to @subagent.technical_specialist
 				available when @variables.consultation_status != "in_progress"
 
-			end_conversation: @utils.transition to @topic.farewell
+			end_conversation: @utils.transition to @subagent.farewell
 
-# Pricing specialist topic
-topic pricing_specialist:
+# Pricing specialist subagent
+subagent pricing_specialist:
 	label: "Pricing Specialist"
 	description: "Handles complex pricing calculations and returns results"
 
@@ -78,7 +78,7 @@ topic pricing_specialist:
 	# Mark consultation as in progress when entering
 	before_reasoning:
 		set @variables.consultation_status = "in_progress"
-		set @variables.return_topic = "main_hub"
+		set @variables.return_subagent = "main_hub"
 
 	reasoning:
 		instructions: ->
@@ -93,14 +93,14 @@ topic pricing_specialist:
 				set @variables.specialist_result = @outputs.final_price
 
 			# Return to main hub with results
-			return_with_results: @utils.transition to @topic.main_hub
+			return_with_results: @utils.transition to @subagent.main_hub
 
 	# Mark consultation complete when leaving
 	after_reasoning:
 		set @variables.consultation_status = "completed"
 
-# Technical specialist topic
-topic technical_specialist:
+# Technical specialist subagent
+subagent technical_specialist:
 	label: "Technical Specialist"
 	description: "Handles technical troubleshooting and returns results"
 
@@ -119,7 +119,7 @@ topic technical_specialist:
 
 	before_reasoning:
 		set @variables.consultation_status = "in_progress"
-		set @variables.return_topic = "main_hub"
+		set @variables.return_subagent = "main_hub"
 
 	reasoning:
 		instructions: ->
@@ -132,12 +132,12 @@ topic technical_specialist:
 				with symptoms=...
 				set @variables.specialist_result = @outputs.diagnosis
 
-			return_with_results: @utils.transition to @topic.main_hub
+			return_with_results: @utils.transition to @subagent.main_hub
 
 	after_reasoning:
 		set @variables.consultation_status = "completed"
 
-topic farewell:
+subagent farewell:
 	label: "Farewell"
 	description: "Ends the conversation"
 
@@ -148,9 +148,9 @@ topic farewell:
 # ★ Alternative: Simple one-way transitions (when you don't need to return)
 #
 # If the specialist doesn't need to return results to a coordinator,
-# use simple transitions without the return_topic pattern:
+# use simple transitions without the return_subagent pattern:
 #
-# go_orders: @utils.transition to @topic.orders
-# go_billing: @utils.transition to @topic.billing
+# go_orders: @utils.transition to @subagent.orders
+# go_billing: @utils.transition to @subagent.billing
 #
 # The bidirectional pattern adds complexity - only use when needed.

package/skills/developing-agentforce/assets/patterns/critical-input-collection.agent

@@ -23,7 +23,7 @@
 #   - Workflows that REQUIRE a specific ID (account, order, case, etc.)
 #   - When slot filling has been unreliable
 #   - When invalid input causes downstream failures
-#   - Multi-topic agents where input must persist across transitions
+#   - Multi-subagent agents where input must persist across transitions
 #
 # This is a COMPLETE template - customize for your use case
 
@@ -74,8 +74,8 @@ language:
 	additional_locales: ""
 	all_additional_locales: False
 
-# ★ ENTRY POINT: Input Collection Topic
-# This topic's ONLY job is to collect and validate the critical input
+# ★ ENTRY POINT: Input Collection Subagent
+# This subagent's ONLY job is to collect and validate the critical input
 start_agent input_collector:
 	label: "Input Collector"
 	description: "Collects and validates the account ID before allowing research"
@@ -127,7 +127,7 @@ start_agent input_collector:
 				| ✅ Account ID validated: {!@variables.account_id}
 				| Account Name: {!@variables.account_name}
 				|
-				| Transition to research topic to begin analysis.
+				| Transition to research subagent to begin analysis.
 
 			if @variables.collection_attempts > 2 and @variables.account_id_validated == False:
 				| ❌ Multiple validation failures.
@@ -148,11 +148,11 @@ start_agent input_collector:
 
 			# ★ PATTERN 4: Null Guard Pattern
 			# Transition ONLY available when input is validated
-			go_research: @utils.transition to @topic.research
+			go_research: @utils.transition to @subagent.research
 				available when @variables.account_id_validated == True
 
-# ★ RESEARCH TOPIC: Only accessible after input is validated
-topic research:
+# ★ RESEARCH SUBAGENT: Only accessible after input is validated
+subagent research:
 	label: "Account Research"
 	description: "Performs research on the validated account"
 
@@ -194,7 +194,7 @@ topic research:
 				available when @variables.research_summary == ""
 
 			# Return to collector for new account
-			new_account: @utils.transition to @topic.input_collector
+			new_account: @utils.transition to @subagent.input_collector
 				available when @variables.research_summary != ""
 
 # ═══════════════════════════════════════════════════════════════════════════

package/skills/developing-agentforce/assets/patterns/delegation-routing.agent

@@ -1,21 +1,21 @@
-# Topic Delegation vs Transition Pattern
+# Subagent Delegation vs Transition Pattern
 # Understanding the difference between delegation and permanent handoffs
 #
 # ★ KEY CONCEPTS:
 #
-#   DELEGATION (@topic.* syntax):
-#   - Syntax: action_name: @topic.topic_name
-#   - Control CAN return to the calling topic
+#   DELEGATION (@subagent.* syntax):
+#   - Syntax: action_name: @subagent.subagent_name
+#   - Control CAN return to the calling subagent
 #   - Use for: consulting specialists, sub-tasks, getting help
 #
 #   TRANSITION (@utils.transition syntax):
-#   - Syntax: action_name: @utils.transition to @topic.topic_name
+#   - Syntax: action_name: @utils.transition to @subagent.subagent_name
 #   - PERMANENT handoff - control does NOT return
 #   - Use for: menu navigation, workflow stages, permanent routing
 #
 # ★ When To Use Each:
 #   DELEGATION: "Consult an expert then continue here"
-#   TRANSITION: "Go to this topic and stay there"
+#   TRANSITION: "Go to this subagent and stay there"
 #
 # ★ Implementation Note:
 #   If delegation syntax doesn't work in your deployment method,
@@ -25,20 +25,20 @@
 # This is a PARTIAL template - integrate into a complete agent file
 
 # ═══════════════════════════════════════════════════════════════
-# PATTERN 1: Topic Delegation (can return)
+# PATTERN 1: Subagent Delegation (can return)
 # ═══════════════════════════════════════════════════════════════
 
 # Delegation syntax in reasoning.actions:
 #
 # reasoning:
 #    actions:
-#       # Delegation - specialist CAN return control to this topic
-#       consult_expert: @topic.specialist_topic
+#       # Delegation - specialist CAN return control to this subagent
+#       consult_expert: @subagent.specialist_subagent
 #          description: "Consult specialist for complex questions"
 #          available when @variables.needs_expert_help == True
 #
-# The specialist topic processes the request and control returns
-# to the original topic when done.
+# The specialist subagent processes the request and control returns
+# to the original subagent when done.
 
 # ═══════════════════════════════════════════════════════════════
 # PATTERN 2: Transition (permanent handoff)
@@ -48,11 +48,11 @@
 #
 # reasoning:
 #    actions:
-#       # Transition - permanent move to orders topic
-#       go_orders: @utils.transition to @topic.orders
+#       # Transition - permanent move to orders subagent
+#       go_orders: @utils.transition to @subagent.orders
 #
-# Control moves to orders topic and STAYS there.
-# User continues in that topic until another transition occurs.
+# Control moves to orders subagent and STAYS there.
+# User continues in that subagent until another transition occurs.
 
 # ═══════════════════════════════════════════════════════════════
 # PATTERN 3: Manual Bidirectional (fallback pattern)
@@ -62,17 +62,17 @@
 # See: bidirectional-routing.agent for full implementation
 
 variables:
-	return_topic: mutable string = ""
-		description: "Topic to return to after specialist"
+	return_subagent: mutable string = ""
+		description: "Subagent to return to after specialist"
 	specialist_result: mutable string = ""
 		description: "Result from specialist consultation"
 
 # Before going to specialist, store return address:
-# set @variables.return_topic = "main_hub"
-# go_specialist: @utils.transition to @topic.specialist
+# set @variables.return_subagent = "main_hub"
+# go_specialist: @utils.transition to @subagent.specialist
 
 # In specialist, transition back when done:
-# return_home: @utils.transition to @topic.main_hub
+# return_home: @utils.transition to @subagent.main_hub
 
 # ═══════════════════════════════════════════════════════════════
 # COMPARISON TABLE
@@ -80,7 +80,7 @@ variables:
 #
 # | Feature              | Delegation        | Transition              |
 # |----------------------|-------------------|-------------------------|
-# | Syntax               | @topic.name       | @utils.transition to    |
+# | Syntax               | @subagent.name       | @utils.transition to    |
 # | Returns to caller?   | YES               | NO                      |
 # | Use in actions:      | YES               | YES                     |
 # | Use in lifecycle:    | NO                | YES (bare syntax)       |

package/skills/developing-agentforce/assets/patterns/lifecycle-events.agent

@@ -15,7 +15,7 @@
 # ★ CRITICAL SYNTAX RULES for Lifecycle Blocks:
 #   1. Use "transition to" NOT "@utils.transition to" for transitions
 #   2. The pipe (|) command is NOT supported in lifecycle blocks
-#   3. after_reasoning may NOT run if a transition occurs mid-topic
+#   3. after_reasoning may NOT run if a transition occurs mid-subagent
 #   4. `run` has inconsistent runtime behavior in lifecycle blocks —
 #      reliable primitives are `set`, `if`/`else`, `transition to`
 #
@@ -40,9 +40,9 @@ variables:
 	current_context: mutable string = ""
 		description: "Refreshed context for current turn"
 
-topic conversation:
+subagent conversation:
 	label: "Conversation"
-	description: "Main conversation topic with lifecycle tracking"
+	description: "Main conversation subagent with lifecycle tracking"
 
 	actions:
 		get_timestamp:
@@ -67,8 +67,8 @@ topic conversation:
 			inputs:
 				turn_number: number
 					description: "Which turn this is"
-				topic_name: string
-					description: "Current topic"
+				subagent_name: string
+					description: "Current subagent"
 			outputs:
 				logged: boolean
 					description: "Whether log succeeded"
@@ -87,7 +87,7 @@ topic conversation:
 		# ★ CORRECT: Use "transition to" (not @utils.transition to) in lifecycle blocks
 		# Example: Route away if session expired
 		# if @variables.session_expired == True:
-		#    transition to @topic.session_expired
+		#    transition to @subagent.session_expired
 
 		# Refresh context before every turn
 		run @actions.refresh_context
@@ -105,14 +105,14 @@ topic conversation:
 			|
 			| Respond helpfully using the refreshed context above.
 		actions:
-			end_conversation: @utils.transition to @topic.farewell
+			end_conversation: @utils.transition to @subagent.farewell
 
 	# ★ after_reasoning: Runs AFTER each reasoning step
 	after_reasoning:
 		# Log analytics for each turn
 		run @actions.log_turn
 			with turn_number=@variables.turn_count
-			with topic_name="conversation"
+			with subagent_name="conversation"
 
 		# Update last activity timestamp
 		run @actions.get_timestamp

package/skills/developing-agentforce/assets/patterns/llm-controlled-actions.agent

@@ -27,7 +27,7 @@ variables:
 	action_taken: mutable string
 		description: "Last action taken by agent"
 
-topic order_assistance:
+subagent order_assistance:
 	label: "Order Assistance"
 	description: "Helps customers with order-related questions"
 
@@ -122,9 +122,9 @@ topic order_assistance:
 				available when @variables.has_order_id == True
 				available when @variables.order_status != "shipped"
 
-			# Topic transitions
-			go_help: @utils.transition to @topic.general_help
-			go_escalation: @utils.transition to @topic.escalation
+			# Subagent transitions
+			go_help: @utils.transition to @subagent.general_help
+			go_escalation: @utils.transition to @subagent.escalation
 				available when @variables.needs_human == True
 
 # ★ Insight: When to Use Each Method
@@ -150,7 +150,7 @@ topic order_assistance:
 # ★ Example: Action Callback Pattern (Deterministic Chaining)
 # Use "run" for guaranteed follow-up actions after a primary action
 
-topic checkout:
+subagent checkout:
 	label: "Checkout"
 	description: "Handles order checkout"
 

package/skills/developing-agentforce/assets/patterns/multi-step-workflow.agent

@@ -22,10 +22,10 @@
 # This is a COMPLETE template - customize for your use case
 #
 # ★ Step Guard Pattern (Feb 2026 Community Best Practice):
-#   - The topic selector re-evaluates on EVERY user utterance
+#   - The subagent router re-evaluates on EVERY user utterance
 #   - Without a step guard, follow-up messages ("my email is X") get re-routed
 #   - The `if @variables.current_step > 1:` guard in start_agent forces
-#     re-entry to the current workflow, bypassing LLM topic selection
+#     re-entry to the current workflow, bypassing LLM subagent selection
 #   - Reset current_step to 1 when the workflow completes
 
 system:
@@ -168,7 +168,7 @@ start_agent onboarding:
 	reasoning:
 		instructions: ->
 			# ★ STEP GUARD — Force re-entry if workflow in progress
-			# This prevents the topic selector from re-routing the user
+			# This prevents the subagent router from re-routing the user
 			# mid-workflow when they provide follow-up information
 			if @variables.current_step > 1:
 				| Continuing your account setup...