Architects are expected to make sound decisions faster than ever, but speed without structured discovery can lead to overlooked requirements and costly rework. It’s widely accepted by now that AI can dramatically accelerate discovery when it’s guided effectively.

Skills are a good way to get consistent analysis with AI. A skill is a reusable set of instructions that tells AI what to analyze, how to reason through a problem, and how to present the results. 

This post focuses on how to write effective AI skills so you can consistently produce relevant, actionable insights across every discovery session. It revisits the four discovery domains from Part one of this two-part series, applying a five-dimension framework to each one. Learning to write skills will allow you to expand and adapt them to your own engagements.

Use these best practices to write skills that produce consistent results

Careful consideration of the following five dimensions creates a repeatable framework for writing skills that produce consistent, actionable, and relevant results across four discovery domains: custom objects, automation, integration, and antipatterns.

• Scope: Define exactly what AI should analyze and what it should ignore. A clear scope keeps AI focused on the problem you’re trying to solve, improving the relevance of the results.
• Question: State the specific question you want AI to answer. Well-defined questions guide AI toward meaningful analysis instead of broad summaries, resulting in findings that directly support your discovery objectives.
• Output format: Specify how the results should be presented, such as a table, prioritized list, executive summary, or set of recommendations. Defining the format produces standardized output that can be reviewed, shared, and compared across discovery sessions.
• Constraints: Establish the rules AI should follow, such as using only trusted sources, avoiding assumptions, limiting recommendations to supported evidence, or considering organizational policies. Constraints improve the quality and trustworthiness of the output by keeping AI aligned with your objectives.
• Structure: Organize the skill into logical phases that guide AI through the analysis. Each phase should have a directed output, with the next phase using the output of the previous phase. This allows each phase to be run independently, helping to keep the AI agent on task without bloating the context window and making it easier for the agent to apply the right scoring logic for each phase. This is especially helpful if the agent fails to render a response or times out. 

Use utility scripts to reduce token cost on repetitive tasks

Not every discovery task needs a conversation. For deterministic, repeatable work like iterating through object lists, extracting field metadata, or flagging naming inconsistencies, a script runs faster than a prompt and consumes no tokens. When your AI agent generates SOQL queries or metadata extraction logic as part of a discovery pass, that output can be reused in a script. Scripts can be stored with the skill and referenced as part of the instructions. Each time the skill is executed, the script runs identically, providing you with a consistent base for the remaining instructions.

Apply a framework for custom object analysis

Part one of this series discussed how undocumented custom objects often lead to legacy triggers or abandoned objects being left in place because no one fully understands their downstream dependencies. The framework described in this section directly addresses that problem. It is designed to determine whether each object is still doing its original job, how much logic has accumulated around it, and how embedded it is in the systems that depend on it.

Here’s how you can use the five dimensions to create a skill for custom object analysis to understand the schema footprint, per-object health, and dependency radius of custom objects in a mature org. 

• Scope: Start with an org-wide inventory before drilling into individual objects. Starting narrow may miss high-risk areas like functional overlap or low-variance structures. For larger, more mature environments, partitioning this initial phase into sections can help avoid processing bottlenecks.
• Question: Focus each phase of the skill on one analytical dimension. Mixing multiple dimensions in a single prompt produces output that is too broad and can lead to context bloat. 
• Output format: Request structured output at each phase. A schema footprint table feeds the per-object drill-down. A per-object health table feeds the dependency radius assessment. Each phase output should be immediately actionable and usable as input to the next phase without manual reformatting.
• Constraints: Managed packages account for a significant portion of custom object metadata in many orgs and can’t be modified. Exclude them from remediation recommendations to keep the focus on custom code you can act on.
• Structure: Build the skill as a three-phase execution. Each phase should answer a specific question before passing its findings to the next phase. Define explicit phase boundaries and state what each phase consumes as input and produces as output. 

Follow this approach to assess custom object health

The three phases below are suggested instructions for your custom object analysis skill. Add them directly to your skill file and adjust them to your needs. They move the skill from a broad schema survey to a targeted health assessment to a full dependency map of the objects that need attention.

Note: If Phase 1 surfaces more flagged objects than Phase 2 can process in a single run, raise the risk threshold and start with high-risk objects only. If your org has fewer than fifty custom objects, Phases 1 and 2 can run together. 

Phase 1 queries the org-level schema footprint: total custom object count, objects with a single record type, and objects with names suggesting functional overlap (Contact2__c, Legacy_Contact__c, etc.). Flag any object with naming patterns that suggest duplication of standard objects. Score each flagged object as high or medium risk before passing results to Phase 2.

Phase 2 takes the high and medium risk objects from Phase 1 and runs a per-object health assessment: record count, frequency of record creation, field count, deprecated or unused field count, validation rule count and complexity, trigger count, active flow count, and cross-object formula field depth. Flag any object showing signs of field overloading or cross-object hacks (for example, formula field traversal depth greater than three levels, roll-up summaries with no clear parent-child relationship, fields named with Cache, Denorm, Copy, or From_Parent suffixes). Include these flags in the Phase 2 output.

Phase 3 maps the dependency radius for each flagged object: Apex class references, lookup and master-detail relationship count, report volume and execution frequency, and inbound and outbound integration touchpoints. Output each phase as a structured table. Exclude managed package objects from remediation recommendations but include them in total counts.

Apply a framework for automation discovery

Part one highlighted that automation failures typically surface at runtime, not before you deploy. A field change that looks safe in isolation can break a validation rule, trigger a recursive loop, or cause a record-triggered flow to re-fire triggers in a way no one anticipated. The four phases below are built around that risk profile.

Here’s how you can use the five dimensions to create a skill for automation discovery to understand what automations exist, what order they fire, where they conflict, and what is safe to change. 

• Scope: Map the full automation footprint across all objects before analyzing any single object in depth. In a mature org, hundreds of active components can be distributed across dozens of objects. Narrowing too early risks missing concentration patterns and cross-object conflicts that only show up at scale. 
• Question: Focus each phase of the skill on one risk signal. Combining multiple risk signals in a single unstructured prompt produces overly broad output. 
• Output format: Request structured output at each phase. A ranked table by automation count feeds Phase 2 scoping. A field-write conflict list feeds the Phase 3, where conflict candidates are identified. A conflict candidate list feeds the Phase 4 safe-to-change assessment. Each phase output should be immediately actionable. 
• Constraints: Managed packages like CPQ, Billing, and Field Service can account for dozens of triggers in a single org, can’t be modified, and represent vendor decisions. If you decide to include them, consider addressing them in a separate pass.
• Structure: Build the skill as a sequential four-phase execution with explicit phase boundaries. Each phase should state what it consumes as input, what it produces as output, and what format that output takes. Design pause points between phases so you can review the output before the next phase runs. Human-readable output lets the architect review and redirect. Machine-readable output makes the next phase’s input reliable. Both formats should be included in the phase definition, not left to the model to decide.

Follow this approach to audit automation execution risks

The four phases below are the suggested instructions for your automation analysis skill. Adding these enriches the skill beyond a full automation inventory to a conflict and complexity analysis to a remediation priority ranking based on risk and change frequency.

Note: Part one identified trigger stacking as a coordination problem. Multiple teams writing automation independently, across release cycles, without a shared handler framework, can lead to multiple active automation types per object with no clear owner. That context shapes how you read Phase 1 output. On a smaller org, that pattern may not exist. On a large org with multiple development teams, it’s more likely. Adjust the Phase 1 scope accordingly: a smaller org may need only a single pass, a larger org may need filtering by business process or release cycle before Phase 2 output is actionable.

Phase 1 queries all active automation types using the Tooling API: before-save flows, record-triggered flows including trigger type and order, scheduled flows, autolaunched flows, Apex triggers including bulk safety and event contexts, Process Builder processes, and workflow rules. Validation rules are queried separately through the Tooling API using SOQL against the ValidationRule object. Results are organized by object with a count for each automation type. Flag any object with three or more active automation types, multiple triggers with overlapping event contexts, or active Process Builder processes alongside flows. Also flag non-bulk-safe triggers (for example, UsageIsBulk = false, SOQL or DML inside loops) and any trigger written without bulk operation context. Include these flags in the Phase 1 output.

Phase 2 takes the flagged objects from the output of Phase 1 and maps each to the Salesforce save order. Identify which automations fire in the before-save context, which fire in the after-save context, and where Process Builder processes or workflow rules introduce a secondary save that re-fires triggers.

Phase 3 uses the execution order map from Phase 2 to identify conflict candidates: fields written by more than one automation type, automations sharing a triggering condition on the same object, and triggers without recursion guards where flows could cause re-execution.

Phase 4 produces a safe-to-change assessment for each flagged object, answering whether the object requires a stabilization plan before sandbox testing can begin, or is ready to proceed to sandbox testing with bulk data. Output each phase as a structured table. 

Apply a framework for integration discovery

Part one established that high-velocity integrations, whether batch or high-frequency API bursts, act as risk amplifiers. Concurrency issues, record locking errors, and governor limit problems from these integrations rarely surface in a sandbox. That risk profile influences the dimensions below: the scope, constraints, and structure are all calibrated around identifying which integrations are under stress before recommending anything that touches them.

Here’s how you can use the five dimensions to create a skill for integration discovery to gain deep insight into integration points and their systemic impact on your org’s business logic and stability. 

• Scope: Start by establishing the full inventory of connection points before analyzing behavior or volume. This baseline guides all subsequent dependency and volume analysis.
• Question: Move through each phase sequentially. Each phase answers a different question, and combining all three in a single prompt makes it challenging to differentiate existence from impact.
• Output format: Start with a list of all integration points, then use it to map where these connections touch your business logic. List areas with multiple touchpoints, as well as ones with no touchpoints. Once these are mapped, evaluate each one by frequency and volume, separating high-frequency integrations that carry concurrency and system limit risks from safer low-frequency processes.
• Constraints: You are observing only the Salesforce side of the integration and you will need to instruct the agent to flag any touchpoints where Salesforce metadata alone provides an incomplete dependency map. Highlighting where external documentation is essential ensures that findings remain grounded and helps prevent overconfident recommendations that lack a full architectural perspective.
• Structure: Build the skill as a three-phase execution: inventory, dependency mapping, and velocity and volume analysis. The depth of the third phase is dependent on your Salesforce add-ons. If Event Monitoring or Salesforce Shield are available, the skill utilizes precise frequency data, but if they are missing, it must explicitly note the limitation and show what’s available through audit trails and custom logging.

Follow this approach to discover integration touchpoints

Part one of this series drew an important distinction that informs how you choose to adapt these phases. On a smaller org with a handful of named credentials and predictable batch jobs, Phase 3 quantification may be straightforward. However, on a larger org with high-frequency API interactions across multiple connected systems, Phase 3 requires additional consideration. Start Phase 1 with the full inventory, but calibrate how deep you go in Phase 3 based on what the inventory reveals. If you don’t have Event Monitoring or Shield, flag that gap explicitly in the skill so the output reflects what the analysis could and couldn’t see.

The three phases below are the suggested instructions for your integration analysis skill. These phases map the existing connections, establish where they intersect with business logic, and quantify how much load each touchpoint carries, flagging those with concurrency and governor limit risk.

Phase 1 establishes the connection inventory: named credentials, connected apps, external client apps, remote site settings, external data sources, platform events, API Catalog entries, outbound messages, Streaming API subscriptions, Change Data Capture configurations, and Apex callout metadata. Organize results by connection type with a count per type and flag any connection type with more than five active entries for Phase 2 analysis. For larger, more mature environments, this initial phase could be split into inbound and outbound sections to avoid processing failures. 

Phase 2 maps the Phase 1 inventory to business logic intersections: Apex classes referencing named credentials, making callouts, or annotated with @RestResource; flows invoking external actions or platform events; and record-triggered automations on high-integration-perimeter objects. It identifies dependent business processes and flags connections where Salesforce-side analysis requires external documentation.

Phase 3 quantifies velocity and volume: when the add-ons discussed earlier are available, the skill queries API usage logs to identify high-frequency connection patterns and flag integrations with concurrency or governor limit risk. If these add-ons are not active, it executes the fallback protocol to extract insights through audit trail duration and any custom logging metadata. Output each phase as a structured table, and flag any integration touchpoint where analysis is limited to the Salesforce side only.

Apply a framework for recognizing inherited antipatterns

Part one introduced the principle that antipatterns compound. A single cross-object hack is a workaround. Multiple cross-object hacks in the same domain usually indicate the org has consistently been working around a gap in the data model. When all four pattern types appear together, Part one mentioned that the org has likely been operated without a consistent architectural function.

Here’s how you can use the five dimensions to create a skill for reading antipatterns to move from raw metadata observations to architectural conclusions and recommendations. 

• Scope: Build the pattern reading skill on top of existing discovery output. Pattern reading builds on the inventory work already done in earlier discovery phases. Feeding the custom object, automation, and integration analysis outputs directly into the pattern skill, including the pattern flags each prior skill emits, avoids redundant detection work and produces a more reliable signal to interpret. 
• Question: Ask the skill to name the architectural signal behind each pattern. A skill that returns “this field has too many values” is less useful than one that returns “this field is doing the work of three separate state machines.” Structure each prompt phase around the interpretive question rather than the retrieval task. 
• Output format: Request findings organized by pattern type, with a section that identifies where multiple patterns appear in the same domain. 
• Constraints: Distinguish between patterns in custom code and managed packages. Consider flagging patterns found in managed package components separately, distinguishing those tied to packages in active use from those being evaluated for replacement.
• Structure: Build the skill to move from observation to signal to decision for each pattern. Each finding should answer three questions: 
  • What does the metadata show? 
  • What does it signal about the org’s history?
  • What should the architect do with that signal before designing? 

Follow this approach to turn discovery data into insights

Part one pointed out that identifying a pattern isn’t the same as being ready to act on it. Before modifying any affected functionality, trace the related dependencies first. When multiple patterns appear together in the same domain, run the skill a second time with the dependency trace as explicit input, asking it to map what each affected component connects to (for example the triggers, flows, validation rules, integrations, and so on that reference it). That map tells you which changes carry downstream risk, which can be addressed independently, and which require a coordinated release before anything is touched.

The phases below are suggested instructions for your antipattern analysis skill. They move the skill from surfacing raw pattern signals across all four discovery domains to interpreting what each pattern reveals architecturally to producing a prioritized list of findings.

Phase 1 reads the flagged pattern signals from the prior discovery outputs (for example, field overloading and cross-object hacks from the object analysis, and non-bulk-safe flags from the automation discovery) and compiles them into a unified pattern inventory organized by type and domain. Where prior outputs did not include pattern flags, the skill performs a targeted scan to fill the gap.

Phase 2 interprets each pattern found in Phase 1 as an architectural signal: what it reveals about how the org was built and what governance gap it represents.

Phase 3 identifies domains where more than one pattern is present and produces a compound reading: what the combination of patterns signals about the org’s governance history and whether remediation requires technical work alone or a governance model alongside it.

Start with one skill, one domain, one org section

Architectural discovery scales as your needs grow, but its foundation relies on moving from basic prompt engineering to building structured agentic skills. While a good prompt shows you what an agent can do, a structured skill is what makes that capability repeatable. It transforms one-off answers into a portable, consistent framework that ensures your analysis remains reliable month after month.

You won’t complete your full set of skills overnight. Rather than trying to cram your entire workflow into a single, massive “mega-skill” file, look at your immediate roadmap and ask yourself one question: “What is the biggest risk I have today?”

It might be a data transformation, a specific API integration, a formatting rule, or something that you are uncertain about. Work side-by-side with your agent to architect a skill for just that one piece, run the analysis, and validate the output. The results give you the data you need to make your next move with greater confidence.

Ultimately, every skill you refine is a permanent asset in your architect toolbox, ready to scale, reuse, and share across your entire organization.