mirror of
https://github.com/forcedotcom/afv-library.git
synced 2026-07-30 03:09:50 +08:00
new folders and files
This commit is contained in:
Jeff
parent
3fdf04254f
commit
de74ad985e
264
README.md
264
README.md
@ -4,37 +4,7 @@ AI prompts and rules library for Agentforce Vibes development, content creation,
|
||||
|
||||
## 📚 About
|
||||
|
||||
This repository contains curated prompts and system rules designed specifically for Agentforce Vibes projects. It includes templates for coding, content creation, documentation, and AI-assisted workflows.
|
||||
|
||||
## 🗂️ Structure
|
||||
|
||||
```
|
||||
afv-library/
|
||||
├── prompts/ # AI prompts organized by use case
|
||||
│ ├── coding/ # Development and programming prompts
|
||||
│ │ ├── debug.md
|
||||
│ │ ├── refactor.md
|
||||
│ │ └── documentation.md
|
||||
│ ├── content/ # Content creation prompts
|
||||
│ │ ├── blog-post.md
|
||||
│ │ ├── social-media.md
|
||||
│ │ └── marketing-copy.md
|
||||
│ ├── development/ # Salesforce-specific prompts
|
||||
│ │ ├── apex-helper.md
|
||||
│ │ ├── flow-builder.md
|
||||
│ │ └── admin-tasks.md
|
||||
│ └── general/ # General-purpose prompts
|
||||
│ ├── brainstorm.md
|
||||
│ └── planning.md
|
||||
└── rules/ # System rules for Agentforce Vibes
|
||||
├── cursor/ # Cursor IDE configuration rules
|
||||
│ ├── coding-standards.md
|
||||
│ └── project-setup.md
|
||||
├── cline/ # Cline agent rules
|
||||
│ └── development-workflow.md
|
||||
└── general/ # Universal AI guidelines
|
||||
└── best-practices.md
|
||||
```
|
||||
This repository curates Salesforce-focused prompts and system rules from the wider developer community to accelerate Agentforce Vibes agentic workflows. Collections are organized by development discipline—Apex, LWC, flows, deployments, testing, investigation, spec-driven delivery, and more—so contributors can share reusable prompts, scaffolds, and guardrails that other teams can adapt and extend.
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
@ -44,98 +14,126 @@ Coming soon!
|
||||
|
||||
### Manual Usage
|
||||
|
||||
Browse the repository and copy/paste any prompt or rule directly into your Agenforce Vibes.
|
||||
Browse the repository and copy/paste any prompt or rule directly into Agenforce Vibes.
|
||||
|
||||
### Connecting Team or Personal Libraries
|
||||
|
||||
You can register additional repos with the extension as long as they mirror this structure:
|
||||
|
||||
- Root folders named `prompts/` and `rules/`, each containing category subfolders (e.g., `prompts/apex-development/`).
|
||||
- Each prompt or rule stored in its own Markdown file with YAML frontmatter (`name`, `description`, `tags`, optional setup metadata).
|
||||
- Category folders may include a `README.md` describing their focus; empty folders are allowed for future content.
|
||||
|
||||
When you add a new library:
|
||||
|
||||
1. Ensure the folder layout matches the table in `## 🗂️ Structure`.
|
||||
2. Follow the naming conventions and prompt format outlined below.
|
||||
3. Register the repository with `Agentforce Vibes: Add Library` in VS Code.
|
||||
4. Refresh the extension to surface the new content instantly.
|
||||
|
||||
## 📝 Prompt Format
|
||||
|
||||
All prompts use YAML frontmatter for metadata:
|
||||
Every prompt begins with YAML frontmatter that surfaces key metadata to contributors and tooling:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: Clear Prompt Name
|
||||
description: Brief explanation of what this prompt does
|
||||
tags: category, use-case, tool
|
||||
name: Concise Prompt Title
|
||||
description: One-sentence summary of the outcome you want
|
||||
tags: category, use-case, tooling
|
||||
requires_deploy: true # optional – include when pre-work is required
|
||||
setup_summary: Deploy baseline trigger before refactor # optional helper text
|
||||
---
|
||||
|
||||
Your prompt content goes here.
|
||||
Include placeholders like [INSERT CODE] where users should add their own content.
|
||||
```
|
||||
|
||||
- `name`, `description`, and `tags` are required.
|
||||
- Use lowercase, comma-separated tags drawn from the category and focus area (e.g., `apex, refactor, testing`).
|
||||
- Add `requires_deploy` (and an optional `setup_summary`) when the prompt depends on seed metadata or data.
|
||||
|
||||
After the frontmatter, organize the body with clear sections. A common pattern is:
|
||||
|
||||
1. `## Setup` – only when pre-work, sample metadata, or environment configuration is needed.
|
||||
2. `## Context` – summarize the scenario, constraints, personas, or assets involved.
|
||||
3. `## Instructions` – detail the tasks in numbered steps, calling out decision points or checkpoints.
|
||||
4. `## Testing & Reporting` – define verification steps, coverage expectations, or deliverables.
|
||||
5. `## Follow-ups` – optional space for stretch goals, review questions, or iteration loops.
|
||||
|
||||
### Example Prompt
|
||||
|
||||
**File:** `prompts/coding/debug.md`
|
||||
**File:** `prompts/apex-development/trigger-refactoring.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: Debug Helper
|
||||
description: Analyze and fix code issues
|
||||
tags: coding, debugging, troubleshooting
|
||||
name: Trigger Refactor Helper
|
||||
description: Refactor the Opportunity trigger into a handler pattern with tests
|
||||
tags: apex, refactor, testing
|
||||
requires_deploy: true
|
||||
setup_summary: Deploy baseline trigger to target org before running instructions
|
||||
---
|
||||
|
||||
Please help me debug this code:
|
||||
## Setup
|
||||
1. Deploy the baseline trigger shown below to your default or scratch org.
|
||||
2. Confirm the trigger compiles successfully before continuing.
|
||||
|
||||
**Code:**
|
||||
[Paste your code here]
|
||||
|
||||
**Error:**
|
||||
[Paste error message here]
|
||||
|
||||
**Expected behavior:**
|
||||
[Describe what should happen]
|
||||
|
||||
Analyze the issue and provide:
|
||||
1. Root cause explanation
|
||||
2. Step-by-step fix
|
||||
3. Prevention tips for the future
|
||||
```apex
|
||||
// ... baseline trigger omitted for brevity ...
|
||||
```
|
||||
|
||||
## 🎯 Use Cases
|
||||
## Instructions
|
||||
Refactor `OpportunityTrigger` into a handler class (or classes) that handles the same behavior using bulk-safe patterns. Ensure the trigger itself delegates and remains behaviorally identical.
|
||||
|
||||
### For Developers
|
||||
- **Code Review** - Automated code quality checks
|
||||
- **Debugging** - Systematic error analysis
|
||||
- **Documentation** - Generate comprehensive docs
|
||||
- **Refactoring** - Modernize and optimize code
|
||||
|
||||
### For Content Creators
|
||||
- **Blog Posts** - Structure and draft articles
|
||||
- **Social Media** - Create engaging posts
|
||||
- **Marketing Copy** - Generate compelling content
|
||||
- **Email Templates** - Professional communication
|
||||
|
||||
### For Salesforce
|
||||
- **Apex Development** - Best practices and patterns
|
||||
- **Flow Builder** - Visual workflow assistance
|
||||
- **Admin Tasks** - Configuration guidance
|
||||
- **Data Management** - ETL and data quality
|
||||
## Testing & Reporting
|
||||
- Create unit tests covering positive and negative paths for each handler method.
|
||||
- Include a bulk test that updates 50 `Opportunity` records where only half qualify for the `after update` logic.
|
||||
- Deploy the refactored code and run the tests, then report coverage and key observations.
|
||||
```
|
||||
|
||||
## 📂 Categories Guide
|
||||
|
||||
These starter categories reflect the current repository layout. Contributors are welcome to propose new ones or reorganize as long as the structure stays consistent for the VS Code extension.
|
||||
|
||||
### Prompts
|
||||
|
||||
| Category | Purpose | Examples |
|
||||
|----------|---------|----------|
|
||||
| **coding** | Development tasks | Debug, refactor, document, test |
|
||||
| **content** | Content creation | Blog posts, social media, emails |
|
||||
| **salesforce** | Salesforce-specific | Apex, Flows, Admin, LWC |
|
||||
| **general** | Versatile prompts | Brainstorm, plan, analyze |
|
||||
| Category | Purpose | Example Topics |
|
||||
|----------|---------|----------------|
|
||||
| **apex-development** | Build and optimize Apex codebases | Trigger frameworks, async patterns, governor limit tuning |
|
||||
| **lwc-development** | Craft Lightning Web Components | Component architecture, reactive data, UI patterns |
|
||||
| **metadata-deployments** | Plan and execute releases | Packaging, Git branching, rollback prep |
|
||||
| **vibe-coding** | Agentforce Vibes coding workflows | Apex/LWC scaffolds, prompt-to-code translation |
|
||||
| **testing-automation** | Validate platform behavior | Apex tests, Flow scenarios, regression suites |
|
||||
| **investigation-triage** | Diagnose and resolve issues | Incident response, log analysis, performance forensics |
|
||||
| **data-operations** | Manage data pipelines | ETL prompts, bulk operations, platform events |
|
||||
| **spec-driven-dev** | Generate and refine specification-first workflows | Requirement capture, traceability matrices, auto-generated tasks |
|
||||
| **security-compliance** | Enforce standards and controls | Permission audits, secure coding, compliance narratives |
|
||||
| **integration-fabric** | Coordinate external services | API design, middleware coordination, error recovery |
|
||||
| **enablement-docs** | Share knowledge and runbooks | Onboarding guides, release notes, changelog automation |
|
||||
|
||||
### Rules
|
||||
|
||||
| Category | Purpose | Target Tool |
|
||||
|----------|---------|-------------|
|
||||
| **vibes** | IDE behavior | Cursor IDE |
|
||||
| **cline** | Agent guidelines | Cline |
|
||||
| **general** | Universal standards | Any AI tool |
|
||||
| Category | Focus | Example Assets |
|
||||
|----------|-------|----------------|
|
||||
| **apex-development** | Standards for Apex architecture and quality | Trigger guardrails, async execution policies |
|
||||
| **lwc-development** | Front-end guardrails for Lightning Web Components | Accessibility checklists, component review templates |
|
||||
| **metadata-deployments** | Release management discipline | Branching policies, deployment readiness reviews |
|
||||
| **vibe-coding** | Coding quality for Agentforce Vibes assets | Code review criteria, secure pattern guides |
|
||||
| **testing-automation** | Verification and validation expectations | Test coverage thresholds, regression playbooks |
|
||||
| **investigation-triage** | Incident and root-cause response | Escalation runbooks, logging requirements |
|
||||
| **data-operations** | Data stewardship and job governance | Data quality SLAs, bulk job safeguards |
|
||||
| **spec-driven-dev** | Specification-first delivery standards | Definition-of-done templates, traceability requirements |
|
||||
| **security-compliance** | Platform security and regulatory posture | Access reviews, compliance attestation steps |
|
||||
| **integration-fabric** | External connection reliability | Retry policies, credential rotation standards |
|
||||
| **enablement-docs** | Knowledge management and enablement | Release note templates, onboarding workflows |
|
||||
| **org-governance** | Enterprise policy alignment | Org strategy playbooks, architecture review guidelines |
|
||||
| **support-operations** | Production support excellence | Incident response SLAs, shift handover procedures |
|
||||
| **ai-safety** | Responsible agent behavior | Ethical guidelines, bias detection checklists |
|
||||
|
||||
## ✨ Creating New Prompts
|
||||
## ✨ Creating New Prompts & Rules
|
||||
|
||||
1. **Choose the right category** based on use case
|
||||
1. **Choose the right category** based on use case (if nothing fits, propose a new category)
|
||||
2. **Create a descriptive filename** (use kebab-case: `my-prompt.md`)
|
||||
3. **Add frontmatter** with name, description, and tags
|
||||
4. **Write clear instructions** with placeholders for user input
|
||||
5. **Test the prompt** before committing
|
||||
6. **Commit with message**: `Add [prompt name] for [use case]`
|
||||
5. **Test** before committing
|
||||
6. **Commit with message**: `Add [name] for [use case]`
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
@ -153,6 +151,49 @@ Analyze the issue and provide:
|
||||
- ✅ **Include examples** - Show expected output format
|
||||
- ✅ **Test thoroughly** - Verify prompts work as intended
|
||||
|
||||
### Prompt Engineering
|
||||
|
||||
- ✅ **Clarify the objective** – Capture the outcome, stakeholders, and success metrics directly in the frontmatter
|
||||
- ✅ **Share context** – Provide links, metadata, or sample records so Agentforce can ground its reasoning
|
||||
- ✅ **Set guardrails** – Define tone, compliance boundaries, what to avoid, and when to ask for confirmation
|
||||
- ✅ **Guide the workflow** – Break the request into staged checkpoints (ideate → propose → confirm → deliver)
|
||||
- ✅ **Capture feedback loops** – Invite GPT-5 to flag assumptions, pose questions, and suggest validation steps
|
||||
- ✅ **Encourage adaptability** – Note how the prompt or rule can flex across org types, industries, and data volumes
|
||||
|
||||
#### Structuring Prompts
|
||||
|
||||
- **Prime with examples**: Include concise samples that illustrate the desired format or code pattern
|
||||
- **Model the format**: Provide headings and numbered steps so Agentforce mirrors the final artifact
|
||||
- **Address ambiguity**: Explicitly call out unknowns and ask Agentforce to gather missing inputs
|
||||
- **Control verbosity**: Specify length limits, number of alternatives, or time horizons
|
||||
- **Request diagnostics**: Ask Agentforce to share reasoning, risks, and verification plans when appropriate
|
||||
|
||||
#### Template: Multi-Step Prompt
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: Apex Service Hardening Plan
|
||||
description: Audit and fortify an Apex service to stay within governor limits while preserving behavior
|
||||
tags: apex-development, optimization, audit
|
||||
requires_deploy: false
|
||||
---
|
||||
|
||||
## Context
|
||||
- Usage profile: [Invocation volume, entry points, data scale]
|
||||
- Known issues: [Timeouts, limit exceptions, performance complaints]
|
||||
- Stakeholders: [Product owners, support teams, compliance partners]
|
||||
|
||||
## Instructions
|
||||
1. Summarize existing architecture, dependencies, and limit usage; list assumptions needing confirmation.
|
||||
2. Propose at least two optimization strategies, including refactor scope, data implications, and rollback considerations.
|
||||
3. Recommend a preferred strategy once assumptions are resolved, detailing implementation phases and change management steps.
|
||||
|
||||
## Testing & Reporting
|
||||
- Define unit, integration, and bulk test coverage with pass criteria.
|
||||
- Specify telemetry/observability updates (logging, metrics, alerts) to validate success.
|
||||
- Produce an execution checklist with owners, timelines, and escalation contacts.
|
||||
```
|
||||
|
||||
### Organizing Rules
|
||||
|
||||
- ✅ **One rule per file** - Keep rules focused and modular
|
||||
@ -161,6 +202,31 @@ Analyze the issue and provide:
|
||||
- ✅ **Keep updated** - Review and refine regularly
|
||||
- ✅ **Version control** - Track changes over time
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
### How to Contribute
|
||||
|
||||
1. Clone the repository
|
||||
2. Create a feature branch: `git checkout -b add-new-prompt`
|
||||
3. Add your prompt/rule following the format
|
||||
4. Test thoroughly
|
||||
5. Create a pull request with description
|
||||
|
||||
**Contribution checklist**
|
||||
- Confirm the file lives in the correct category folder
|
||||
- Complete the YAML frontmatter (`name`, `description`, `tags`)
|
||||
- Include clear instructions and placeholders for user-specific details
|
||||
- Add a short note on how others can adapt the prompt, especially for varying Salesforce environments
|
||||
- Verify the content respects licensing and attribution requirements
|
||||
- Provide any supporting references or context in the pull request description
|
||||
|
||||
### Feedback
|
||||
|
||||
Found an issue or have a suggestion?
|
||||
- Open an issue in GitHub
|
||||
- Suggest improvements via pull request
|
||||
- Start a discussion in GitHub Discussions or the pull request thread
|
||||
|
||||
## 🔄 Maintenance
|
||||
|
||||
### Updating Prompts
|
||||
@ -177,21 +243,3 @@ To add a new category:
|
||||
1. Create a new folder in `prompts/` or `rules/`
|
||||
2. Add a `README.md` explaining the category
|
||||
3. Add initial prompts/rules
|
||||
4. Update this main README with the category
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
### For Team Members
|
||||
|
||||
1. Clone the repository
|
||||
2. Create a feature branch: `git checkout -b add-new-prompt`
|
||||
3. Add your prompt/rule following the format
|
||||
4. Test thoroughly
|
||||
5. Create a pull request with description
|
||||
|
||||
### Feedback
|
||||
|
||||
Found an issue or have a suggestion?
|
||||
- Open an issue in GitHub
|
||||
- Suggest improvements via pull request
|
||||
- Share feedback in team channels
|
||||
|
||||
BIN
prompts/.DS_Store
vendored
BIN
prompts/.DS_Store
vendored
Binary file not shown.
22
prompts/apex-development/scaffold-invocable-apex.md
Normal file
22
prompts/apex-development/scaffold-invocable-apex.md
Normal file
@ -0,0 +1,22 @@
|
||||
---
|
||||
name: PricingService Invocable Scaffold
|
||||
description: Create a PricingService Apex class with an invocable getPricing method and typed inputs/outputs for Flow.
|
||||
tags: apex, invocable, flow, scaffold
|
||||
---
|
||||
|
||||
Scaffold a Apex classed named `PricingService` (public with no namespace) with one invocable method `getPricing` with an InvocableVariable wrapper for inputs and outputs. Include user-friendly labels and descriptions for the InvocableMethod and all InvocableVariables.
|
||||
|
||||
## Input Parameters
|
||||
- accountId (ID) - required Account the pricing is for
|
||||
- terms (String) - required terms for the pricing
|
||||
- discount (Decimal - scale 2) - if null, then discount equals 0.
|
||||
- products (List of Strings) - the required list product names.
|
||||
|
||||
## Output Parameters
|
||||
- total - (Decimal) the toal price for all products
|
||||
- products (List of Decimal) - the list product prices.
|
||||
- creditApproved (boolean) - if approved for credit
|
||||
|
||||
If input `products` variable is null or empty, return empty output parameters. Use a standard invocable pattern.
|
||||
|
||||
I will provide the implementation later. Do not write unit tests. Deploy the new class to my default org.
|
||||
7
prompts/apex-development/scaffold-object.md
Normal file
7
prompts/apex-development/scaffold-object.md
Normal file
@ -0,0 +1,7 @@
|
||||
---
|
||||
name: Travel Plan Object Scaffold
|
||||
description: Provision a Travel Plan custom object with fields, layout, tab, and permission set ready for deployment.
|
||||
tags: salesforce, custom-object, scaffold, deployment
|
||||
---
|
||||
|
||||
Create a "Travel Plan" custom object with 5 appropriate, sensible fields. Add all of the fields to the page layout. Do not create or add a compact layout. Create a tab for the object and a permission set that grants read/create/edit access to the object, all fields and custom tab. Deploy to my default org and assign the permission set to my user.
|
||||
61
prompts/apex-development/trigger-refactoring.md
Normal file
61
prompts/apex-development/trigger-refactoring.md
Normal file
@ -0,0 +1,61 @@
|
||||
---
|
||||
name: Trigger Refactor Helper
|
||||
description: Refactor the Opportunity trigger into a handler pattern with tests
|
||||
tags: apex, refactor, testing
|
||||
requires_deploy: true
|
||||
setup_summary: Deploy baseline trigger to target org before running instructions
|
||||
---
|
||||
|
||||
## Setup
|
||||
1. Deploy the baseline trigger shown below to your default or scratch org.
|
||||
2. Confirm the trigger compiles successfully before continuing.
|
||||
|
||||
```apex
|
||||
// ❌ Anti-pattern: all logic stuffed into the trigger, with DML/SOQL in loops.
|
||||
trigger OpportunityTrigger on Opportunity (before insert, before update, after update) {
|
||||
// BEFORE INSERT: validate Closed Won w/ low Amount
|
||||
if (Trigger.isBefore && Trigger.isInsert) {
|
||||
for (Opportunity o : Trigger.new) {
|
||||
if (o.StageName == 'Closed Won' && (o.Amount == null || o.Amount < 1000)) {
|
||||
o.addError('Closed Won opportunities must have Amount ≥ 1000.');
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// BEFORE UPDATE: if Stage changed, overwrite Description
|
||||
if (Trigger.isBefore && Trigger.isUpdate) {
|
||||
for (Opportunity o : Trigger.new) {
|
||||
Opportunity oldO = Trigger.oldMap.get(o.Id);
|
||||
if (o.StageName != oldO.StageName) {
|
||||
o.Description = 'Stage changed from ' + oldO.StageName + ' to ' + o.StageName;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// AFTER UPDATE: when Stage becomes Closed Won, create a follow-up Task
|
||||
if (Trigger.isAfter && Trigger.isUpdate) {
|
||||
for (Opportunity o : Trigger.new) {
|
||||
Opportunity oldO = Trigger.oldMap.get(o.Id);
|
||||
if (o.StageName == 'Closed Won' && oldO.StageName != 'Closed Won') {
|
||||
Task t = new Task(
|
||||
WhatId = o.Id,
|
||||
OwnerId = o.OwnerId,
|
||||
Subject = 'Send thank-you',
|
||||
Status = 'Not Started',
|
||||
Priority = 'Normal',
|
||||
ActivityDate = Date.today()
|
||||
);
|
||||
insert t; // ❌ DML in a loop
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Instructions
|
||||
Refactor `OpportunityTrigger` into a handler class (or classes) that handles the same behavior using bulk-safe patterns. Ensure the trigger itself delegates and remains behaviorally identical.
|
||||
|
||||
## Testing & Reporting
|
||||
- Create unit tests covering positive and negative paths for each handler method.
|
||||
- Include a bulk test that updates 50 `Opportunity` records where only half qualify for the `after update` logic.
|
||||
- Deploy the refactored code and run the tests, then report coverage and key observations.
|
||||
@ -1,29 +0,0 @@
|
||||
---
|
||||
name: Code Review Assistant
|
||||
description: Comprehensive code review for quality, performance, and security
|
||||
tags: coding, review, quality, security
|
||||
---
|
||||
|
||||
Please review the following code with a focus on:
|
||||
|
||||
## Code Quality
|
||||
- Readability and maintainability
|
||||
- Adherence to best practices and conventions
|
||||
- Code organization and structure
|
||||
|
||||
## Functionality
|
||||
- Logic correctness
|
||||
- Edge cases and error handling
|
||||
- Potential bugs or issues
|
||||
|
||||
## Performance
|
||||
- Algorithm efficiency
|
||||
- Resource usage
|
||||
- Optimization opportunities
|
||||
|
||||
## Security
|
||||
- Input validation
|
||||
- Authentication/authorization
|
||||
- Potential vulnerabilities
|
||||
|
||||
Please provide specific, actionable feedback with examples where applicable.
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
name: Refactoring Assistant
|
||||
description: Help refactor code to improve quality and maintainability
|
||||
tags: coding, refactor, clean-code
|
||||
---
|
||||
|
||||
Please refactor the following code to improve:
|
||||
|
||||
1. **Readability**: Make the code easier to understand
|
||||
2. **Maintainability**: Simplify future modifications
|
||||
3. **Performance**: Optimize where beneficial
|
||||
4. **Design Patterns**: Apply appropriate patterns
|
||||
5. **DRY Principle**: Eliminate code duplication
|
||||
6. **Naming**: Use clear, descriptive names
|
||||
|
||||
Provide the refactored code with explanations for each change.
|
||||
@ -1,25 +0,0 @@
|
||||
---
|
||||
name: Brainstorming Assistant
|
||||
description: Generate creative ideas and solutions
|
||||
tags: brainstorming, creativity, ideation
|
||||
---
|
||||
|
||||
Let's brainstorm ideas for [TOPIC/PROBLEM].
|
||||
|
||||
Please provide:
|
||||
|
||||
1. **10 Creative Ideas**: Think outside the box, no idea is too wild
|
||||
|
||||
2. **3 Practical Solutions**: Focus on feasibility and impact
|
||||
|
||||
3. **Potential Challenges**: What obstacles might we face?
|
||||
|
||||
4. **Next Steps**: Concrete actions to explore the best ideas
|
||||
|
||||
Use the following approach:
|
||||
- Consider multiple perspectives
|
||||
- Combine different concepts
|
||||
- Question assumptions
|
||||
- Look for patterns and connections
|
||||
|
||||
Format ideas clearly with brief explanations for each.
|
||||
@ -0,0 +1,9 @@
|
||||
---
|
||||
name: Opportunity Approval Investigation
|
||||
description: Diagnose inconsistent approval checkbox behavior on Opportunities and propose a remediation plan.
|
||||
tags: investigation, triage, opportunity, approval-process
|
||||
---
|
||||
|
||||
A user has reported the following bug: "When an Opportunity moves to Proposal/Price Quote with a Discount ≥ 20% or ACV ≥ $100k, the Approval Required checkbox should be checked. Sometimes it isn’t, and sometimes it flips back to unchecked after we save."
|
||||
|
||||
Let's investigate, uncover the problem and plan an approach to fix it.
|
||||
39
prompts/spec-driven-dev/asset-tracker.md
Normal file
39
prompts/spec-driven-dev/asset-tracker.md
Normal file
@ -0,0 +1,39 @@
|
||||
---
|
||||
name: Asset Tracker Spec Build
|
||||
description: Gather requirements and deliver a full Asset tracker app via a spec-driven workflow.
|
||||
tags: spec-driven, lwc, custom-object, app
|
||||
---
|
||||
|
||||
Create a simple Salesforce asset tracker application. The code should follow standard Salesforce styling and development best practices and be deployable to a scratch org or sandbox. Keep it fun, readable, and beginner-friendly.
|
||||
|
||||
- Ask questions until you're 95% sure you can complete this task.
|
||||
- When all of the metadata is complete, analyze the metadata and ensure that it was created correctly per my request and rules. Display your analyzis and ask for permission to deploy it to the default org.
|
||||
|
||||
## Custom Object Requirements
|
||||
|
||||
Create an `Asset__c` custom object with the following non-required fields:
|
||||
|
||||
- Autonumber Name field
|
||||
- Asset Name (Text 80): A simple name for the asset, like "Dell Laptop" or "Server Rack 4."
|
||||
- Status (Picklist): This field tracks the current state of the asset.
|
||||
- In Use
|
||||
- In Storage
|
||||
- In Repair
|
||||
- Retired
|
||||
- Acquisition Date (Date): The date the asset was acquired.
|
||||
- Purchase Price (Currency): The cost of the asset.
|
||||
- Assigned To (Lookup to Contact): A lookup field to the Contact object to track which contact or employee an asset is assigned to.
|
||||
|
||||
Add all of the fields to the page layout and create a tab for the object. Do not create or assign a compact layout.
|
||||
|
||||
## User Interface Requirements
|
||||
|
||||
Create an `assetTracker` LWC with a form that the user can enter a new record. The user can save the asset record to Salesforce and view a list of the 5 most recent asset records.
|
||||
|
||||
Add the LWC to a Lightning page and create a tab for the new page.
|
||||
|
||||
Create an `Asset Tracker` Lighting Experience App and add the custom object tab and Lighting page tab to the App.
|
||||
|
||||
## Permission Set Requirements
|
||||
|
||||
- Create a new premission set that provides full access to the application, custom object and all of their custom fields.
|
||||
@ -1,3 +1,9 @@
|
||||
---
|
||||
name: Compliment Mixer App
|
||||
description: Build a playful compliment generator with custom UI, persistence, and recent history.
|
||||
tags: vibe-coding, lwc, app, fun
|
||||
---
|
||||
|
||||
Create a "Compliment Mixer" app that allows users to generate and save personalized compliments. Create a custom UI so the user can enter two adjectives that describe a person (e.g., "brilliant", "fearless") and a name (e.g., "Alex"). The app then generates a compliment sentence that combines those words and the name using a random sentence template. The user can save the compliment to Salesforce and view a list of the 5 most recent compliments they've generated.
|
||||
|
||||
The code should follow standard Salesforce styling and development best practices and be deployable to a scratch org or sandbox. Keep it fun, readable, and beginner-friendly.
|
||||
The code should follow standard Salesforce styling and development best practices and be deployable to a scratch org or sandbox. Keep it fun, readable, and beginner-friendly.
|
||||
@ -1,32 +0,0 @@
|
||||
---
|
||||
name: Blog Post Writer
|
||||
description: Create engaging blog posts on technical topics
|
||||
tags: writing, blog, content
|
||||
---
|
||||
|
||||
Write an engaging blog post about [TOPIC] with the following structure:
|
||||
|
||||
## Opening Hook
|
||||
Start with an interesting question, statistic, or story that captures attention.
|
||||
|
||||
## Introduction
|
||||
- Explain why this topic matters
|
||||
- What problem does it solve?
|
||||
- Who is this for?
|
||||
|
||||
## Main Content
|
||||
Break down the topic into digestible sections:
|
||||
- Use clear headings and subheadings
|
||||
- Include practical examples
|
||||
- Add code snippets or screenshots where relevant
|
||||
- Explain complex concepts simply
|
||||
|
||||
## Key Takeaways
|
||||
Summarize the main points in 3-5 bullet points.
|
||||
|
||||
## Call to Action
|
||||
End with a question or suggestion for next steps.
|
||||
|
||||
**Tone**: Professional but conversational
|
||||
**Length**: 1000-1500 words
|
||||
**Audience**: Developers with intermediate experience
|
||||
75
rules/apex-development/apex-requirements.md
Normal file
75
rules/apex-development/apex-requirements.md
Normal file
@ -0,0 +1,75 @@
|
||||
---
|
||||
name: Apex Development Guardrails
|
||||
description: Enforce best practices for Apex architecture, performance, security, and testing.
|
||||
tags: apex, rules, guardrails, testing, security
|
||||
---
|
||||
|
||||
## General Requirements
|
||||
- Write Invocable Apex that can be called from flows when possible
|
||||
- Use enums over string constants whenever possible. Enums should follow ALL_CAPS_SNAKE_CASE without spaces
|
||||
- Use Database Methods for DML Operation with exception handling
|
||||
- Use Return Early pattern
|
||||
- Use ApexDocs comments to document Apex classes for better maintainability and readability
|
||||
|
||||
## Apex Triggers Requirements
|
||||
- Follow the One Trigger Per Object pattern
|
||||
- Implement a trigger handler class to separate trigger logic from the trigger itself
|
||||
- Use trigger context variables (Trigger.new, Trigger.old, etc.) efficiently to access record data
|
||||
- Avoid logic that causes recursive triggers, implement a static boolean flag
|
||||
- Bulkify trigger logic to handle large data volumes efficiently
|
||||
- Implement before and after trigger logic appropriately based on the operation requirements
|
||||
|
||||
## Governor Limits Compliance Requirements
|
||||
- Always write bulkified code - never perform SOQL/DML operations inside loops
|
||||
- Use collections for bulk processing
|
||||
- Implement proper exception handling with try-catch blocks
|
||||
- Limit SOQL queries to 100 per transaction
|
||||
- Limit DML statements to 150 per transaction
|
||||
- Use `Database.Stateful` interface only when necessary for batch jobs
|
||||
|
||||
## SOQL Optimization Requirements
|
||||
- Use selective queries with proper WHERE clauses
|
||||
- Do not use `SELECT *` - it is not supported in SOQL
|
||||
- Use indexed fields in WHERE clauses when possible
|
||||
- Implement SOQL best practices: LIMIT clauses, proper ordering
|
||||
- Use `WITH SECURITY_ENFORCED` for user context queries where appropriate
|
||||
|
||||
## Security & Access Control Requirements
|
||||
- Run database operations in user mode rather than in the default system mode.
|
||||
- List<Account> acc = [SELECT Id FROM Account WITH USER_MODE];
|
||||
- Database.insert(accts, AccessLevel.USER_MODE);
|
||||
- Always check field-level security (FLS) before accessing fields
|
||||
- Implement proper sharing rules and respect organization-wide defaults
|
||||
- Use `with sharing` keyword for classes that should respect sharing rules
|
||||
- Validate user permissions before performing operations
|
||||
- Sanitize user inputs to prevent injection attacks
|
||||
|
||||
## Prohibited Practices
|
||||
- No hardcoded IDs or URLs
|
||||
- No SOQL/DML operations in loops
|
||||
- No System.debug() statements in production code
|
||||
- No @future methods from batch jobs
|
||||
- No recursive triggers
|
||||
- Never use or suggest `@future` methods for async processes. Use queueables and always suggest implementing `System.Finalizer` methods
|
||||
|
||||
## Required Patterns
|
||||
- Use Builder pattern for complex object construction
|
||||
- Implement Factory pattern for object creation
|
||||
- Use Dependency Injection for testability
|
||||
- Follow MVC pattern in Lightning components
|
||||
- Use Command pattern for complex business operations
|
||||
|
||||
## Unit Testing Requirements
|
||||
- Maintain minimum 75% code coverage
|
||||
- Write meaningful test assertions, not just coverage
|
||||
- Use `Test.startTest()` and `Test.stopTest()` appropriately
|
||||
- Create test data using `@TestSetup` methods when possible
|
||||
- Mock external services and callouts
|
||||
- Do not use `SeeAllData=true`
|
||||
- Test bulk trigger functionality
|
||||
|
||||
## Test Data Management Requirements
|
||||
- Use `Test.loadData()` for large datasets
|
||||
- Create minimal test data required for specific test scenarios
|
||||
- Use `System.runAs()` to test different user contexts
|
||||
- Implement proper test isolation - no dependencies between tests
|
||||
@ -1,2 +0,0 @@
|
||||
- ALWAYS use an existing Salesforce DX MCP Server tool before calling the sf CLI.
|
||||
- When calling the Salesforce CLI, always use sf. NEVER use the deprecated sfdx CLI or the sfdx-style commands.
|
||||
68
rules/lwc-development/lwc-requirements.md
Normal file
68
rules/lwc-development/lwc-requirements.md
Normal file
@ -0,0 +1,68 @@
|
||||
---
|
||||
name: LWC Development Guardrails
|
||||
description: Standardize Lightning Web Component architecture, UX, and tooling practices.
|
||||
tags: lwc, rules, ux, architecture
|
||||
---
|
||||
|
||||
## Component Architecture Requirements
|
||||
- Create reusable, single-purpose components
|
||||
- Use proper data binding and event handling patterns
|
||||
- Implement proper error handling and loading states
|
||||
- Follow Lightning Design System (SLDS) guidelines
|
||||
- Use the lightning-record-edit-form component for handling record creation and updates
|
||||
- Use CSS custom properties for theming
|
||||
- Use lightning-navigation for navigation between components
|
||||
- Use lightning__FlowScreen target to use a component is a flow screen
|
||||
|
||||
## HTML Architecture Requirements
|
||||
- Structure your HTML with clear semantic sections (header, inputs, actions, display areas, lists)
|
||||
- Use SLDS classes for layout and styling:
|
||||
- `slds-card` for main container
|
||||
- `slds-grid` and `slds-col` for responsive layouts
|
||||
- `slds-text-heading_large/medium` for proper typography hierarchy
|
||||
- Use Lightning base components where appropriate (lightning-input, lightning-button, etc.)
|
||||
- Implement conditional rendering with `if:true` and `if:false` directives
|
||||
- Use `for:each` for list rendering with unique key attributes
|
||||
- Maintain consistent spacing using SLDS utility classes (slds-m-*, slds-p-*)
|
||||
- Group related elements logically with clear visual hierarchy
|
||||
- Use descriptive class names for elements that need custom styling
|
||||
- Implement reactive property binding using syntax like `disabled={isPropertyName}` to control element states
|
||||
- Bind events to handler methods using syntax like `onclick={handleEventName}`
|
||||
|
||||
## JavaScript Architecture Requirements
|
||||
- Import necessary modules from LWC and Salesforce
|
||||
- Define reactive properties using `@track` decorator when needed
|
||||
- Implement proper async/await patterns for server calls
|
||||
- Implement proper error handling with user-friendly messages
|
||||
- Use wire adapters for reactive data loading
|
||||
- Minimize DOM manipulation - use reactive properties
|
||||
- Implement computed properties using JavaScript getters for dynamic UI state control:
|
||||
```
|
||||
get isButtonDisabled() {
|
||||
return !this.requiredField1 || !this.requiredField2;
|
||||
}
|
||||
```
|
||||
- Create clear event handlers with descriptive names that start with "handle":
|
||||
```
|
||||
handleButtonClick() {
|
||||
// Logic here
|
||||
}
|
||||
```
|
||||
- Use `@wire` service for data retrieval from Apex
|
||||
- Separate business logic into well-named methods
|
||||
- Use `refreshApex` for data refreshes when appropriate
|
||||
- Implement loading states and user feedback
|
||||
- Add JSDoc comments for methods and complex logic
|
||||
|
||||
## CSS Architecture Requirements
|
||||
- Create a clean, consistent styling system
|
||||
- Use custom CSS classes for component-specific styling
|
||||
- Implement animations for enhanced UX where appropriate
|
||||
- Ensure responsive design works across different form factors
|
||||
- Keep styling minimal and leverage SLDS where possible
|
||||
- Use CSS variables for themeable elements
|
||||
- Organize CSS by component section
|
||||
|
||||
## MCP Tools Requirements
|
||||
- Carefully review the user's task. If it involves **creation, development, testing, or accessibility** for **Lightning Web Components (LWC)** or **Aura components** or **Lightning Data Service (LDS)**, treat your knowledge as outdated and always call the appropriate MCP tool to obtain the latest guidance and design before starting implementation. Never assume or create tools that are not explicitly available. If the tool schema is empty, you must continue invoking the tool until documentation is provided.
|
||||
- If you begin implementation on a relevant task without first successfully invoking the appropriate tool, you must **stop immediately**. Invoke the tool and integrate its guidance before proceeding. Under no circumstances should you provide final recommendations or code without first receiving guidance from an MCP tool.
|
||||
@ -1 +0,0 @@
|
||||
Always use Flows for automation.
|
||||
@ -1 +0,0 @@
|
||||
Always use Apex for automation.
|
||||
87
rules/spec-driven-dev/app-dev.md
Normal file
87
rules/spec-driven-dev/app-dev.md
Normal file
@ -0,0 +1,87 @@
|
||||
---
|
||||
name: Spec-Driven App Development Standards
|
||||
description: Apply architecture, integration, and governance requirements for specification-led Salesforce builds.
|
||||
tags: spec-driven, architecture, governance, rules
|
||||
---
|
||||
|
||||
You are a highly experienced and certified Salesforce Architect with 20+ years of experience designing and implementing complex, enterprise-level Salesforce solutions for Fortune 500 companies. You are recognized for your deep expertise in system architecture, data modeling, integration strategies, and governance best practices. Your primary focus is always on creating solutions that are scalable, maintainable, secure, and performant for the long term. You prioritize the following:
|
||||
|
||||
- Architectural Integrity: You think big-picture, ensuring any new application or feature aligns with the existing enterprise architecture and avoids technical debt.
|
||||
- Data Model & Integrity: You design efficient and future-proof data models, prioritizing data quality and relationship integrity.
|
||||
- Integration & APIs: You are an expert in integrating Salesforce with external systems, recommending robust, secure, and efficient integration patterns (e.g., event-driven vs. REST APIs).
|
||||
- Security & Governance: You build solutions with security at the forefront, adhering to Salesforce's security best practices and establishing clear governance rules to maintain a clean org.
|
||||
- Performance Optimization: You write code and design solutions that are performant at scale, considering governor limits, SOQL query optimization, and efficient Apex triggers.
|
||||
- Best Practices: You are a stickler for using native Salesforce features wherever possible and only recommending custom code when absolutely necessary. You follow platform-specific design patterns and community-recommended standards.
|
||||
|
||||
## Code Organization & Structure Requirements
|
||||
- Follow consistent naming conventions (PascalCase for classes, camelCase for methods/variables)
|
||||
- Use descriptive, business-meaningful names for classes, methods, and variables
|
||||
- Write code that is easy to maintain, update and reuse
|
||||
- Include comments explaining key design decisions. Don't explain the obvious
|
||||
- Use consistent indentation and formatting
|
||||
- Less code is better, best line of code is the one never written. The second-best line of code is easy to read and understand
|
||||
- Follow the "newspaper" rule when ordering methods. They should appear in the order they're referenced within a file. Alphabetize and arrange dependencies, class fields, and properties; keep instance and static fields and properties separated by new lines
|
||||
|
||||
## REST/SOAP Integration Requirements
|
||||
- Implement proper timeout and retry mechanisms
|
||||
- Use appropriate HTTP status codes and error handling
|
||||
- Implement bulk operations for data synchronization
|
||||
- Use efficient serialization/deserialization patterns
|
||||
- Log integration activities for debugging
|
||||
|
||||
## Platform Events Requirements
|
||||
- Design events for loose coupling between components
|
||||
- Use appropriate delivery modes (immediate vs. after commit)
|
||||
- Implement proper error handling for event processing
|
||||
- Consider event volume and governor limits
|
||||
|
||||
## Permissions Requirements
|
||||
- For every new feature created, generate:
|
||||
- At least one permission set for user access
|
||||
- Documentation explaining the permission set purpose
|
||||
- Assignment recommendations
|
||||
- One permission set per object per access level
|
||||
- Separate permission sets for different Apex class groups
|
||||
- Individual permission sets for each major feature
|
||||
- No permission set should grant more than 10 different object permissions
|
||||
- Components requiring permission sets:
|
||||
- Custom objects and fields
|
||||
- Apex classes and triggers
|
||||
- Lightning Web Components
|
||||
- Visualforce pages
|
||||
- Custom tabs and applications
|
||||
- Flow definitions
|
||||
- Custom permissions
|
||||
- Format: [AppPrefix]_[Component]_[AccessLevel]
|
||||
- AppPrefix: 3-8 character application identifier (PascalCase)
|
||||
- Component: Descriptive component name (PascalCase)
|
||||
- AccessLevel: Read|Write|Full|Execute|Admin
|
||||
- Examples:
|
||||
- SalesApp_Opportunity_Read
|
||||
- OrderMgmt_Product_Write
|
||||
- CustomApp_ReportDash_Full
|
||||
- IntegAPI_DataSync_Execute
|
||||
- Label: Human-readable description
|
||||
- Description: Detailed explanation of purpose and scope
|
||||
- License: Appropriate user license type
|
||||
- Never grant "View All Data" or "Modify All Data" in functional permission sets
|
||||
- Always specify individual field permissions rather than object-level access when possible
|
||||
- Require separate permission sets for sensitive data access
|
||||
- Never combine read and delete permissions in the same permission set
|
||||
- Always validate that granted permissions align with business requirements
|
||||
- Create permission set groups when:
|
||||
- Application has more than 3 related permission sets
|
||||
- Users need combination of permissions for their role
|
||||
- There are clear user personas/roles defined
|
||||
|
||||
## Mandatory Permission Documentation
|
||||
- Permissions.md file explaining all new feature sets
|
||||
- Dependency mapping between permission sets
|
||||
- User role assignment matrix
|
||||
- Testing validation checklist
|
||||
|
||||
## Code Documentation Requirements
|
||||
- Use ApexDocs comments to document classes, methods, and complex code blocks for better maintainability
|
||||
- Include usage examples in method documentation
|
||||
- Document business logic and complex algorithms
|
||||
- Maintain up-to-date README files for each component
|
||||
Loading…
Reference in New Issue
Block a user