| name | methodology-explain-application |
| description | Load when answering questions about the current Pega application -- app stats, workflows, case types, data objects. Uses get-application as the primary source before any rule-level exploration. |
Use get-application as the single primary source for application understanding questions.
Trigger phrases
Treat these as application-state requests:
- current application, app overview, explain application, application summary
- application stats, app stats, current state, state of the app
- workflows present, case types in app, data objects in app, personas in app
When intent matches, do not start with search-rules or multiple get-rule calls.
Workflow
Step 1: Determine app context
| Situation | Action |
|---|
Both appName and appVersion known | Proceed to Step 2 |
| Neither known | Call get-application with no parameters (discovers default app) |
| Only one known | Ask for the missing value |
Step 2: Fetch application payload
Tool: get-application
Parameters: appName, appVersion (both optional), detail="summary" (default)
The summary includes: application label/description, case types, lifecycle structures
(stages/processes/steps), data objects, and personas.
Decision gate: If the payload answers the question, stop and respond. Only escalate
if a specific requested field is missing.
Step 3: Build response from payload
| Section | Source fields |
|---|
| Application definition | pyDADInfo.pyLabel, pyDADInfo.pyDescription |
| Stats | Counts of pyCandidateCaseTypes[], pyCandidateDataObjects[], pyCandidatePersonas[] |
| Workflows | Case types → pyDCDInfo → pyCandidateStages[] → pyCandidateStageProcesses[] → pyCandidateStageSteps[] |
| Data objects | pyCandidateDataObjects[] → pyCandidateFields[] with types and references |
Use resolved labels (persona/object names), not raw GUIDs.
Step 4: Offer deep dive
After the summary, ask whether the user wants:
- workflow-by-workflow walkthrough
- field-level data model details
- rule-level implementation drill-down
Call discipline
| Rule | Guidance |
|---|
| Minimum-call | Start with exactly one get-application call |
| Stop condition | If payload contains the answer, stop tool-calling |
| Escalation condition | Only when a required detail is absent — state missing field(s) first |
| No over-fetching | Never fetch flows/rules "just in case" |
Escalation path
Use rule-level exploration only if:
- User explicitly asks for implementation details, OR
get-application summary lacks a specific technical detail
Escalation sequence:
search-rules to locate artifactsget-rule detail="summary" firstget-rule detail="full" only when raw fields required
Server version discovery
To find the Pega platform version, search for Rule-RuleSet-Version rules named Pega-RULES.
The highest 08-XX-YY pattern maps to the Infinity release year: 08-24 = Infinity '24,
08-25 = Infinity '25. The patch (YY) indicates update level.
Output template
- Application overview (purpose)
- Current stats (case types/data objects/personas counts)
- Workflows present (case types + lifecycle highlights)
- Data objects present (object + key fields/references)
- Next options (ask for deep dive preference)
Anti-patterns
- Don't begin with many rule-level calls
- Don't provide only
appName or only appVersion — provide both or neither
- Don't run additional tools when the answer is already available
- Don't dump full raw payload by default
- Don't expose noisy internals (
pyGUID, pxObjClass) unless debugging
