sf-project-structure

Structures Salesforce DX repositories with sfdx-project.json, source-format layouts, and .forceignore rules.

2|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/grzmol/vibe-force --skill sf-project-structure-grzmol
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sf-project-structure
Source: https://github.com/grzmol/vibe-force/tree/main/skills/sf-project-structure
Command: npx skills add https://github.com/grzmol/vibe-force --skill sf-project-structure-grzmol

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Salesforce DX projects fail in predictable ways: metadata files placed in the wrong directory become invisible to the CLI, .forceignore entries silently drop components from deploys, source-tracking conflicts overwrite teammates' work, and monolithic force-app trees make ownership and packaging impossible. This Skill provides the authoritative rules for structuring, configuring, and maintaining a DX repository so deploys, retrieves, and team workflows behave predictably. ## Core Features & Use Cases - Project configuration: Full sfdx-project.json schema coverage including packageDirectories, sourceApiVersion, namespace, replacements, and sourceBehaviorOptions, with validation commands for each property. - Metadata placement and manifests: A complete metadata-type-to-directory map, .forceignore syntax and precedence rules, and package.xml / destructiveChangesPre/Post.xml manifest generation with sf project generate manifest. - Source tracking and team conventions: Conflict resolution with --ignore-conflicts scoped per component, sf project delete source for real deletions, branch-per-story models, path ownership for parallel agents, and metadata XML diff review checklists. - Use Case: When splitting a monolithic force-app into domain-aligned package directories, use this Skill to configure sfdx-project.json correctly, sequence the deploys explicitly, and verify with sf project deploy preview that nothing is silently ignored. ## Quick Start Ask the assistant to structure a new Salesforce DX project or audit where a specific metadata file belongs in an existing repository.

Frequently Asked Questions about sf-project-structure

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a Salesforce DX project with multiple package directories?

Add each directory to packageDirectories in sfdx-project.json with relative paths and exactly one default entry. Each directory repeats the standard main/default tree, and sf project deploy start deploys all of them in one transaction unless you sequence with --source-dir flags.

Where does a metadata file go in Salesforce source format?

Each metadata type has a fixed directory under main/default, such as classes/ for ApexClass, flows/ for Flow, and objects/<Object>/fields/ for CustomField. Bundle types like lwc and aura use strict directory names, and custom objects are always decomposed into child folders.

Why is my file not deploying with sf project deploy start?

The file is likely matched by a .forceignore pattern or sits outside a directory listed in packageDirectories. Run sf project list ignored and sf project deploy preview to see exactly what the CLI excludes before deploying.

How does .forceignore precedence work with multiple files?

Project commands walk up from each source file and use the first .forceignore found, never merging files. A .forceignore inside a package directory fully overrides the project-root one for files under that directory.

How do I resolve source tracking conflicts in Salesforce CLI?

Run sf project deploy preview to list conflicts, resolve the file, then deploy or retrieve that single component with --metadata and --ignore-conflicts. Never apply --ignore-conflicts to a whole-project deploy, since it silently discards the other side's changes.

Does deleting a metadata file remove it from the org?

No, deleting a file locally and deploying leaves the component in the org. Use sf project delete source for tracked orgs, or deploy a destructiveChangesPost.xml manifest alongside an empty package.xml.