Prompts that produce a finished document from your org's real components. Each one comes in two forms: a short version you can type in a few seconds, and a fuller version for when you want more control over what comes back.
Two conventions in the prompts below:
‹Opportunity›means replace this with your own object, flow, field or requirement«option A | option B»means pick one
Assess an org
Health score by domain
Type this:
Score this org's health out of 100 by domain and write it up for a client.
For more control over the domains and the evidence behind each score:
Score this org's health for a client-facing assessment report. Give an overall score out of 100 with a letter grade, plus a score out of 100 for each of these domains: ‹Code Quality, Security, Technical Debt, Automation, Data Model, Documentation, Knowledge Management, Licensing, Reporting, Governance›. For each domain give the score, the specific metadata evidence behind it including counts, and the single change that would most improve it. State the criteria you used for each score. Flag any number that should be confirmed with a direct query, and give me the query.
Leaving the domains open lets the Assistant score what it can evidence in your org. Naming them gives you a consistent scorecard across several orgs, which is what you want when the report is a deliverable.
Technical debt register
Find the technical debt on our ‹Opportunity and Account› objects and write it up as a document.
The fuller version names the patterns to look for, which is what surfaces the specific offenders rather than general advice:
Produce a technical debt register for ‹the Opportunity and Account objects› in this org. Include duplicate or near-duplicate automation doing the same job, components with test or placeholder names still active in production, items that appear superseded by newer versions, and anything with a hardcoded ID or profile reference. For each give the component name, why it's debt, the risk of leaving it, and the effort to remove it. Rank by «risk × effort | quick wins first | blast radius».
Critical findings, in client-report format
Produce the Critical Findings section of a client-facing org assessment report for this org. Cover findings with active operational, compliance or delivery risk. Present each with an ID, a severity, a 'Business Impact of Fixing' paragraph, a 'Risk of Not Fixing' paragraph naming the components and counts you found, and a recommendation. Order by business risk. Flag any number that should be confirmed with a direct query before a client sees it, and give me the query.
Security and access review
I'm doing an audit of all permission sets and profiles in this org. Produce an assessment and recommendations to ensure governance and compliance, listing the profiles, permission sets and permission set groups by name. Flag which profiles and permission sets grant risky permissions, and note where permission set groups could replace profile sprawl. Rank the findings by risk. Make it an HTML file so it's presentable to review.
Asking it to list components by name is the clause that matters here. Without it the request pulls toward the risky items and away from a full inventory.
Legacy automation review
Produce a legacy automation migration review document for this org. Inventory the workflow rules, Process Builders, and flows, including inactive, obsolete and draft ones. For each legacy automation, state what it does and what migrating it to Flow would involve. Rank by migration risk and recommend a migration sequence.
Naming the automation types explicitly is what returns all of them. A general request for "automation" can miss the legacy types.
Naming and documentation hygiene
Produce a naming and documentation hygiene report for ‹the Opportunity object› in this org. Cover components whose API name doesn't match their label or purpose, misspelled API names, auto-generated opaque names, missing descriptions on flows and fields, and inconsistent conventions between similar components. Report the names exactly as they are, and do not correct them silently. Recommend a naming standard based on what the org already does well.
Useful ahead of an Agentforce rollout, which leans on field descriptions.
Design and plan work
Scope a discovery call
Ask the question first, then turn it into the document. This is the pattern to use live on a call:
We just did a discovery call about ‹deal approvals›. The client wants ‹approval routing above a dollar threshold, locked fields once a deal is in approval, and win rate by discount band›. Which of those already exist in this org?
Then:
Write that up as a statement of work.
Or ask for both in one message, with the requirements attached:
Create a statement of work based on the requirements from this call, and compare it against what the client already has built in this org. For each requirement say whether it exists today, partially exists, or needs building, naming the components involved. Flag the requirements you cannot assess from metadata alone.
Solution design
Produce a solution design document for ‹the requirement›. Search this org and name the existing components the design should reuse. Cover the objects and fields involved, the automation, the security model, and the decisions someone needs to make before this is built.
Impact analysis before a change
Produce an impact analysis document for this change: ‹adding a new stage to the Opportunity sales process›. Cover everything downstream that could break: automations, fields, reports, dashboards, integrations. Separate what you can prove from the metadata from what a human needs to check. Present it as a prioritized risk table and a recommended sequence for making the change safely.
Migration plan
Produce a migration plan for moving ‹from Profiles to Permission Sets› in this org. Cover the current state with real component names and counts, the target state, the order of migration and why, what can be automated versus what needs manual review, the rollback position at each step, and the risks specific to this org's configuration. Flag any number that should be confirmed with a direct query, and give me the query. Note where the plan depends on information Swantide can't see, such as user assignments.
Profiles to permission sets, in full
Produce a Profiles to Permission Sets migration blueprint for this org, as an HTML file. Work through it in this order, and cover every profile in the org rather than a sample:
1. Inventory: list the profiles, permission sets and permission set groups by name, with the licence each profile uses and what it appears to exist for. Say how many of each there are.
2. For each profile, the risky system permissions it grants.
3. Overlap: which profiles grant substantially the same access and could therefore share one permission set. Name the profiles in each cluster and say what they have in common.
4. Residue: what cannot move out of a profile at all and has to stay there.
5. Target architecture: one shared baseline permission set, reusable capability permission sets, persona permission set groups built from those capabilities, and the risky permissions isolated into their own separately-assigned sets. Name every set you propose and say which profiles it replaces.
6. Rollout: a sequence that is additive and reversible at each step, with the rollback position for each.
Rank the work by risk, then by effort. Where something depends on user assignments or licence counts, put it in a separate 'needs a human to check' list with the SOQL that answers it.
Document and hand over
Onboarding guide for a new admin
Write an onboarding guide for a new admin joining this org.
The fuller version, which produces the "five things that will surprise you" section people tend to quote back:
Write an onboarding guide for an administrator new to this org. Cover the business the org supports, the objects carrying the core process, the automation they'll encounter, the org's naming and configuration conventions, and the five things most likely to surprise someone coming from a standard Salesforce build. Ground every point in this org's real components.
Swap the audience to change the document: "for a consultant starting on this client org tomorrow, who has never seen it" produces the briefing version.
Handover runbook
Produce an administrator handover runbook for this org, focused on ‹the sales process›. Cover the automations that run on a schedule or in the background and what they do, the integrations and packages in play, the components most likely to need attention, and the known fragile spots. Note anything a new admin should not touch without checking, and why.
Business process documentation
Write a process document covering the entire lifecycle from ‹lead creation through opportunity closing and account management› in this org, based on the current metadata. Be specific about the objects, fields, automations and validation rules involved at each stage, and name them.
Naming the start and end points keeps it on the process you mean.
ERD or object map
Draw me an ERD of ‹Opportunity, Account, Contact and OpportunityContactRole› as an HTML file, with the diagram drawn as inline SVG, no wider than 900 pixels.
The width instruction is worth keeping. It is what keeps the diagram inside the panel.
The fuller version adds a relationship table under the picture:
Produce an entity relationship diagram for ‹the Opportunity, Account, Contact and OpportunityContactRole objects› in this org, as an HTML file. Draw the diagram as inline SVG in the HTML, with boxes for each object listing their key fields, lines between them for the real lookup and master-detail relationships, and cardinality labels on each line. Use the actual relationship fields in this org, and name them on the lines. Keep the diagram no wider than 900 pixels. Below the diagram, list each relationship as a row: child object, parent object, the relationship field's API name, and whether it is a lookup or master-detail.
For a non-technical audience, ask for plain business language on the boxes instead of API names.
Enablement and QA
Test plan from your real validation rules
Produce a test plan for ‹the Opportunity stage progression process› in this org. Derive the test cases from the actual validation rules, required fields and automation on the object. Reference each by name, state which rule each test exercises, and cover every active validation rule on the object. Include the negative cases and the expected error message the user should see. Format as «a numbered test script | a table with expected and actual columns | Provar-ready steps».
End-user quick reference
Write a one-page quick reference for ‹sales reps› working with ‹Opportunities› in this org. Cover what they need to fill in and when, what the validation rules will stop them doing and why, and what happens automatically. Plain language, no API names.
Executive summary
Write a one-page executive summary of ‹this org's technical health› for a ‹VP of Sales Operations› who is not technical. Lead with what's working. Explain the risks in business terms, such as deal cycle time, reporting accuracy and audit exposure, rather than in Salesforce terms. Give three recommendations with the business outcome of each. Include only the numbers you are confident in.
Data extracts
Inventory as a spreadsheet
Create a CSV file of ‹the Opportunity record types› in this org, with columns: «label, developer name, active | name, active, error message | name, object, last modified».
Opens straight into Excel.
Configuration workbook
Create a configuration workbook for ‹the Opportunity object› in this org as a CSV, with one section per component type: fields, validation rules, record types, and active automation. For each, give the API name, the label, and what it does.
Reshaping a document you already have
Type these into the same conversation. Each one updates the document in place.
Re-aim it at a different reader
Rewrite this for ‹a non-technical executive›. Keep the findings, change the language and the level of detail.
Add a section
Add a section on ‹rollback and how to reverse each change›.
Change the format
Convert this to an HTML file, styled so it's presentable to a client.
Tighten it
Cut this to one page. Keep the ranked findings and the recommendations, drop the background.
Narrow it
Which three of these should we fix first, and why?
Say add or underneath to keep what is already there. Say turn this into and it rewrites, replacing the earlier version.
Getting the best out of it
Say who will read it. This shapes depth and tone more than any other instruction you can add.
Ask it to rank. Ranked output puts the useful part at the top and keeps the document focused.
Ask it to flag numbers worth confirming. Adding "flag any number that should be confirmed with a direct query, and give me the query" is the single most useful sentence you can add. You get the figure and the SOQL to confirm it.
Give it the values it can't see. If a document depends on a picklist's real values, a licence count or a governor limit, paste them into the prompt. Anything Swantide cannot read from metadata is worth supplying.