@salesforce/afv-skills 1.63.0 → 1.65.0

package/skills/nonprofit-volunteer-management-structure-generate/references/configuration-decisions.md

@@ -0,0 +1,159 @@
+# Configuration Decisions
+
+**When to load:** Workflow step 4, after the discovery summary is confirmed.
+
+**Purpose:** what to decide from the discovery answers, in order: Locations, parent Volunteer Initiative, Position template, shifts, recurrence, qualifications. For entity and field meaning, see `nonprofit-volunteer-management-model-get`. Field values are set by `nonprofit-volunteer-management-records-create`.
+
+---
+
+## How to run a decision turn
+
+For each decision, use one turn and then wait:
+
+1. **What I heard:** one sentence from the discovery answers.
+2. **Options:** usually two, in the user's words.
+3. **Recommendation and why**, including what the other option would cost later (see "Changing it later").
+4. **Platform behavior:** only the one that should change the choice.
+5. **Ask:** "Which do you want?", not "Does this whole plan look right?"
+
+Don't stop to ask about Status, publishing or record names; records-create handles those. Recommend the simpler option, but don't treat it as accepted until the user picks it.
+
+---
+
+## Locations
+
+**Options:** one Location / one Location per site / a "Virtual" Location.
+
+**Default:** the Locations the discovery answers describe.
+
+- Ask only for each Location's name, address, and whether it's onsite or virtual. records-create creates the address record and asks for anything else.
+- A Job Position doesn't need a Location. Matching volunteers by location does, so virtual roles usually get a "Virtual" Location.
+- For a program at several sites, plan one Location per site, and one Job Position per site where volunteers sign up per site.
+- Run the Location reuse check before recommending; an existing site is usually the one to reuse.
+
+**Reference:** model-get → Location, and Feature: Volunteer Matching.
+
+---
+
+## Parent Volunteer Initiative
+
+**Ask:** "How many Volunteer Initiatives do you need, and should they be connected?"
+
+**Default:** separate initiatives with no parent. Adding a parent later doesn't disturb anything.
+
+**Check the org first.** Run the Volunteer Initiative reuse check before this turn. If the org already has initiatives that fit, raise them here: "Your org already has separate per-site Volunteer Initiatives. Do you want to extend those, or start a new shared one?" Never recommend a structure that conflicts with what's already there.
+
+**Offer a parent (as an option, not a strong recommendation) when:**
+
+- the programs share an umbrella identity;
+- the user describes sub-programs and doesn't want them all in one initiative told apart only by role;
+- the same program runs at several sites with a coordinator at each (parent = program, children = sites).
+
+**Platform behaviors:**
+
+- Publishing and Status don't pass down; each initiative is published and updated on its own.
+- The rollup fields exist but stay empty until the customer builds Data Processing Engine automation.
+- A Job Position belongs to one Volunteer Initiative.
+- Sharing doesn't pass down the hierarchy.
+- A hierarchy holds up to 1,000 records and 5 levels.
+
+Common groupings for a parent: program type, season, location, funding source.
+
+**Reference:** model-get → VolunteerInitiative.
+
+---
+
+## Position template
+
+**Default:** no Position, unless the same role is reused across Job Positions with shared requirements.
+
+**Use a Position when:**
+
+- the same role is posted at several locations or in several programs;
+- its qualifications should be defined once and used in matching for every Job Position that uses it;
+- the role needs internal approval;
+- the role links to a Program Management benefit.
+
+**Skip it when** the role is unique to one posting, or there's no need to share qualifications.
+
+**How to ask:**
+
+- *Leaning toward it:* "You described the same role at two locations, so I'd recommend a Position template. Its qualifications are defined once, and both Job Positions use them in matching. Do you want a template?"
+- *Leaning against it:* "This role only exists in one program, so I'd skip the Position template and put the qualifications on the Job Position. You can add a template later. OK to skip?"
+
+**Platform behaviors:**
+
+- A Position's only built-in effect on its Job Positions is in matching. Anything else the customer wants passed down needs their own automation.
+- "Internal approval required" is a flag only. It does nothing until the customer builds an approval process that updates the assignment's status.
+
+Run the Position reuse check before recommending.
+
+**Reference:** model-get → Position, JobPosition.
+
+---
+
+## Shifts
+
+**Default:** no shifts, unless volunteers sign up for set times.
+
+**Use shifts when** volunteers sign up for specific dates and times, need a per-slot volunteer count, or the customer wants the Find Unfilled Shifts action.
+
+**No shifts when** volunteering is flexible ("come when you can") and there are no slots to fill.
+
+Assignments don't have to belong to a shift, a Job Position or an initiative; ad-hoc assignments are valid.
+
+**Reference:** model-get → JobPositionShift.
+
+---
+
+## Recurrence
+
+**Default:** none, unless the schedule repeats.
+
+**Recurring** fits a regular weekly or monthly pattern ("every Tuesday 9–12"). One-time events and irregular dates don't need it.
+
+**Collect the schedule details** for records-create (see `plan-output.md` → "Schedule details"): the pattern, the time window for each day (they may differ by day; don't flatten them into one), the start date, the end date or the number of shifts, and the time zone. The series always has an end: if the user gives neither an end date nor a count, ask for one.
+
+**Platform behavior:** every shift in the series is created up front as its own record. Recurrence is a convenience when the shifts are created; nothing repeats at runtime.
+
+If the Job Position already exists, plan the schedule the user wants anyway. records-create checks which of those shifts already exist and creates only the missing ones.
+
+**Reference:** model-get → Feature: Recurrence.
+
+---
+
+## Qualifications
+
+**Default:** none, unless the discovery answers showed skilled roles.
+
+| Approach | When |
+|---|---|
+| On the Position (Position Qualification) | The requirement applies wherever the role is used |
+| On the Job Position (Job Position Qualification) | The requirement is specific to one posting |
+| Both | Shared requirements on the Position, plus posting-specific extras on the Job Position. Recommended when both apply |
+| None | General volunteering, or roles filled by people who are already vetted |
+
+Matching uses QualificationLevel on Competency qualifications. A Job Position's own qualifications and its Position's qualifications are checked together, keeping the higher level per Competency. Nothing is copied from the Position to the Job Position.
+
+**Example:** the Position "Delivery Driver" requires a driver's license. The Job Position at the San Francisco site also requires a local certification. The New York Job Position needs nothing extra.
+
+- Don't repeat a Position's qualifications on its Job Positions; matching already checks both.
+- Requirements can vary by program as well as by location.
+- Ask for the required level of each Competency qualification; a qualification without one is skipped by matching. Proficiency labels (Beginner, Intermediate, Advanced) are descriptive only and not used in matching.
+- **Examinations** are optional. Matching doesn't use them; they're for manual checks and compliance tracking. A requirement a volunteer must meet before being matched (a cleared background check, a completed training) is a Competency with a required level, not an Examination.
+- Also ask whether a requirement belongs on the role or on the person. A volunteer's own competencies are out of scope for this skill.
+- Run the Competency and Examination reuse checks before recommending.
+
+**Reference:** model-get → PositionQualification, JobPositionQualification, Feature: Volunteer Matching.
+
+---
+
+## Changing it later
+
+Use this for the "what the other option costs later" part of a decision turn.
+
+| Effort | Examples |
+|---|---|
+| Easy: add later | A parent initiative, a Position template, shifts, qualifications, Locations. Nothing that exists breaks |
+| Some manual work | Moving a Job Position to another initiative, restructuring the hierarchy, moving a requirement between the Position and the Job Position |
+| Hard: review the impact first | Changing a Job Position that already has shifts or assignments. Changing a Position's qualifications changes matching for every Job Position that uses it |

package/skills/nonprofit-volunteer-management-structure-generate/references/discovery-interview.md

@@ -0,0 +1,137 @@
+# Discovery Interview
+
+**When to load:** Workflow step 3, at the start of a planning session.
+
+**Purpose:** the discovery questions, in order, with probing prompts and what each answer feeds in `configuration-decisions.md`. The interview is for understanding. It decides nothing.
+
+---
+
+## How to run it
+
+- Ask about the topics below in order, whatever the program's complexity. Use the probing questions only when an answer is unclear or incomplete; skip any the user has already answered.
+- Stay on one topic at a time. Group a few closely related questions when they're easy to answer together; split them across turns when they need long answers. Record anything the user says about a later topic, but don't move on early.
+- With several programs, get the full list first, then go deep on one at a time. Keep one program active. Note what the user says about another, but don't follow it up until the active one is finished and confirmed. For later programs, offer the decisions made for the first.
+- When every topic is done, summarize back (see the end of this file) before any configuration decision.
+
+---
+
+## Programs
+
+**Ask:** "Tell me about your volunteer program(s). What do your volunteers do?"
+
+**Probe:**
+
+- "How many distinct volunteer programs or activities do you run?"
+- "Are they connected (same volunteers, shared reporting) or independent?"
+- "Do different teams or coordinators manage them?"
+
+**Feeds:** how many Volunteer Initiatives, and the parent Volunteer Initiative decision.
+
+---
+
+## Locations
+
+**Ask:** "Where does this volunteering happen? Is there a site volunteers go to, and how many sites are involved?"
+
+**Probe:**
+
+- "Does the same program run at more than one site?"
+- "If there are several sites, is it the same program at each, or different programs?"
+
+For each site, collect only the name, the address, and whether it's onsite or virtual.
+
+**Feeds:** the Locations decision, and the parent Volunteer Initiative decision when the same program runs at several sites.
+
+---
+
+## Roles
+
+**Ask:** "What types of volunteer roles need to be signed up for and tracked separately?"
+
+**Probe:**
+
+- "Are there different jobs (Team Lead, Driver, Tutor) that need separate sign-up and tracking?"
+- "Is the same role used in more than one program, or at more than one location?"
+- "Where the same role appears in more than one place, do its requirements stay the same?"
+
+**Notes:**
+
+- Different onsite tasks that don't need separate tracking can share one Job Position.
+- A Position is a reusable role template. Matching checks a Job Position's own qualifications together with its Position's. Status, publishing and capacity are not passed from the Position to the Job Position.
+- **Suggests a Position template:** the same role across programs or locations, with requirements that should stay consistent.
+- **Suggests a Job Position only:** the role exists in one program, its requirements are unique, and no reuse is expected.
+
+**Feeds:** the Position template decision, and later the qualifications decision.
+
+---
+
+## Delivery format
+
+**Ask:** "Is the work done onsite, virtually, or both? Do any volunteers work remotely?"
+
+**Feeds:** the Locations decision. Matching volunteers by location needs a Location, so virtual roles usually get a "Virtual" Location.
+
+---
+
+## Qualifications
+
+**Ask:** "Is there anything volunteers must have or prove to sign up?"
+
+**Probe:**
+
+- "Are certifications, training or skills required for any of these roles?"
+- "Do those requirements apply everywhere the role appears, or change by program or location?"
+- "Is there anything volunteers must show before they sign up, such as a background check or a certification?"
+
+**Feeds:** the qualifications decision and the Position template decision.
+
+---
+
+## Scheduling
+
+**Ask:** "Do volunteers sign up for set times, or come when they can?"
+
+**Probe:**
+
+- "Does it happen on a regular schedule (weekly, monthly) or once?"
+- "What are the days and times? Are they the same every day, or different on some days?"
+- "When does it start, and when does it end, or how many sessions are there? Which time zone?"
+
+**Feeds:** the shifts and recurrence decisions, and the schedule details handed to records-create.
+
+---
+
+## Capacity
+
+**Ask:** "How many volunteers do you need for each shift or opportunity?"
+
+**Probe:**
+
+- "Is there a maximum number of volunteers per shift?"
+- "Is there a minimum?"
+
+**Notes:**
+
+- The maximum is counted, never enforced: the remaining capacity is a formula, and nothing blocks a signup when a shift is full. Mention it when the user describes a hard limit.
+- Matching and the Find Unfilled Shifts action rely on a maximum being set.
+- A minimum isn't a standard field; the customer may want a custom field for it.
+
+**Feeds:** the capacity in the plan.
+
+---
+
+## Summary back
+
+Summarize before any configuration decision, so the user can correct it:
+
+"Here's what I've understood about your program:
+
+- **Programs:** …
+- **Locations:** …
+- **Roles:** …
+- **Delivery format:** …
+- **Qualifications:** …
+- **Scheduling:** …
+- **Capacity:** …
+
+Does this sound right? Anything I'm missing or got wrong?"

package/skills/nonprofit-volunteer-management-structure-generate/references/edge-cases.md

@@ -0,0 +1,48 @@
+# Edge Cases
+
+**When to load:** any step, when a situation doesn't fit the standard flow.
+
+**Purpose:** hybrid programs, existing records, contradictions, several programs, and an unsure user.
+
+---
+
+## Hybrid programs ("sometimes shifts, sometimes flexible")
+
+Plan both under the same Volunteer Initiative: Job Positions with shifts for the scheduled work, Job Positions without shifts for the flexible work. Don't force the program into one model. Adding shifts to a Job Position later is easy.
+
+---
+
+## Existing records in the org
+
+Assume the org may already hold relevant records, and check every session (Workflow step 5).
+
+- Show what you find and ask before planning anything new: "You already have a Location called 'Eastside Pantry' and a Competency called 'Food Safety'. Should I use these, or plan new ones?"
+- Locations, Competencies, Examinations and Positions are meant to be shared. A "Food Safety" Competency planned for one program should be reused for the next.
+- If the user wants shifts for a Job Position that already exists, plan the schedule they want. records-create checks which of those shifts already exist and creates only the missing ones.
+- If an existing record looks incomplete or misconfigured, say what's missing. This skill doesn't change it.
+
+---
+
+## User contradicts themselves
+
+Example: "No qualifications needed", then later "oh, drivers need a license". Or: "no shifts", then "we need 5 volunteers every Saturday at 9", which is a shift.
+
+Raise it gently and let the user choose: "Earlier you said X, but now it sounds like Y. Which is right?" Don't pick the later answer silently, and don't run the reuse checks for the affected records until it's settled.
+
+---
+
+## Several programs
+
+Get the full list first, then plan one program at a time.
+
+- Reuse a Location when the same site serves several programs, and reuse Competencies across programs.
+- Each program gets its own Volunteer Initiative and Job Positions, and possibly its own Position templates.
+- For later programs, offer the earlier decisions: "You put qualifications on the Position for the first program. Same approach here?" Configure each program for its own needs.
+
+---
+
+## User is unsure about a parent Volunteer Initiative
+
+Recommend no parent: "When in doubt, start without one. You can add a parent later without changing anything already set up."
+
+If the user describes four or more related programs with shared reporting but still hesitates, ask one question: "Would it help to see combined numbers across all of them, or do you manage each one separately?" If they're still unsure, plan no parent.

package/skills/nonprofit-volunteer-management-structure-generate/references/mcp-invocation.md

@@ -0,0 +1,75 @@
+# Org Calls — headless-360 and Salesforce CLI
+
+**When to load:** Workflow steps 2 and 5. Every call here is a read and runs only after the user agrees to the org read.
+
+Each call is shown for both connections, headless-360 and the Salesforce CLI (with the org's alias); they return the same result. See SKILL.md → Mechanism.
+
+---
+
+## Volunteer Management check
+
+Every call uses API v67.0. The Salesforce CLI forms run `sf api request rest`, `sf sobject describe`, and `sf data query` against `--target-org <alias>`.
+
+**1. Org preference**
+
+```text
+headless-360:  dispatch_readonly({"path": "/services/data/v67.0/setup/org/preferences/VolunteerManagementEnabled", "method": "GET"})
+Salesforce CLI: sf api request rest "/services/data/v67.0/setup/org/preferences/VolunteerManagementEnabled" --target-org <alias>
+```
+
+Response: `{"isPreferenceEnabled": true}` (a 360 call may wrap it as `{"status_code": 200, "body": {...}}` — read `body.isPreferenceEnabled`).
+
+| Result | Meaning | Do |
+|---|---|---|
+| `true` | Volunteer Management is on | Continue to the describe |
+| `false` | It's off | Stop. An admin turns it on in Setup → Volunteer Management Settings |
+| 404 `NOT_FOUND` | The org doesn't have the preference (VM not provisioned) | Stop, same message |
+| 403 | The user can't read org settings | Stop and say so; this is not the same as "off" |
+
+**2. User access**
+
+```text
+headless-360:  dispatch_readonly({"path": "/services/data/v67.0/sobjects/VolunteerInitiative/describe", "method": "GET"})
+Salesforce CLI: sf sobject describe --sobject VolunteerInitiative --api-version 67.0 --target-org <alias> --json
+```
+
+| Result | Meaning | Do |
+|---|---|---|
+| 200 | The user can see the Volunteer Management objects | Continue |
+| 404 `NOT_FOUND` / `INVALID_TYPE`, or 403 | The user can't see them | Stop. The user needs the Manage Volunteer Data permission set |
+
+Don't query permission-set assignments up front; the describe answers the question.
+
+---
+
+## Reuse checks
+
+All reuse checks use the same query call. Put only the planned names in the `WHERE`; never query an object without one.
+
+```text
+headless-360:  dispatch_readonly({"path": "/services/data/v67.0/query", "method": "GET", "query_params": {"q": "<SOQL>"}})
+Salesforce CLI: sf data query -q "<SOQL>" --api-version 67.0 --target-org <alias> --json
+```
+
+**Apostrophes.** Escape an apostrophe in a name with a backslash: `O\'Brien`. Doubling it (`''`) fails with 400 `MALFORMED_QUERY`. Inside a headless-360 JSON argument the backslash itself must be escaped, so write `O\\'Brien` in the JSON string. In the CLI's double-quoted `-q` argument, write `O\'Brien` as is.
+
+| Check | SOQL |
+|---|---|
+| Volunteer Initiative | `SELECT Id, Name FROM VolunteerInitiative WHERE Name IN ('Weekly Food Pantry', 'O\'Brien Youth Mentoring')` |
+| Location | `SELECT Id, Name FROM Location WHERE Name IN ('Eastside Pantry', 'Virtual')` |
+| Position | `SELECT Id, Name FROM Position WHERE Name IN ('Team Lead')` |
+| Competency | `SELECT Id, Name FROM Competency WHERE Name LIKE '%Driv%' OR Name LIKE '%License%'` |
+| Examination | `SELECT Id, Name FROM Examination WHERE Name LIKE '%Background%' OR Name LIKE '%Check%'` |
+| Job Position, existing initiative | `SELECT Id, Name, VolunteerInitiative.Name, Location.Name FROM JobPosition WHERE Name IN ('Driver') AND VolunteerInitiativeId = '<initiative Id>'` |
+| Job Position, new initiative | `SELECT Id, Name, VolunteerInitiative.Name, Location.Name FROM JobPosition WHERE Name IN ('Driver')` |
+
+- For Competency and Examination, build the `LIKE` terms from the distinctive stem plus the category noun (`%Driv%` and `%License%`), not one spelling (`%Driving%` misses "Driver's License"). Escape `%` or `_` with a backslash when they're part of the name.
+- When a stem query finds nothing but the org may word the record differently, run it again with a shorter stem (`%Lic%` instead of `%License%`) before planning the record as New.
+- The Job Position initiative Id comes from the Volunteer Initiative check. With a new initiative, any match belongs to another initiative, so plan the Job Position as New.
+
+| Result | Meaning |
+|---|---|
+| 200, `totalSize: 0` | No match; plan the record as New |
+| 200 with `records` | Show each match (name and parent names) and ask whether it's the one the user means |
+| 400 `MALFORMED_QUERY` | Usually an unescaped apostrophe; fix the escape and retry |
+| 400 `INVALID_TYPE` / 404 | The object isn't visible; go back to the Volunteer Management check |

package/skills/nonprofit-volunteer-management-structure-generate/references/plan-output.md

@@ -0,0 +1,141 @@
+# Plan Output
+
+**When to load:** Workflow steps 6–8, after every configuration decision has an answer.
+
+**Purpose:** what goes in message 1 (the plan) and message 2 (the additional configuration and the create question), and what is handed to `nonprofit-volunteer-management-records-create` on yes. The consent rules and the `Reuse-check:` values are in SKILL.md.
+
+---
+
+## Message 1 — the plan
+
+### Summary table
+
+One row per planned record. The table is both the record of the user's decisions and what records-create works from, so the rest of the message never repeats it.
+
+| Column | What goes in it |
+|---|---|
+| Record | The object, written out (Volunteer Initiative, Job Position, …) |
+| Name | The record's name, or the shift pattern. Use the user's names; if one isn't given yet, propose a plain name rather than a bracketed placeholder |
+| Reuse or New | **Reuse** for an existing record (its name is in Name; never show an Id), otherwise **New** |
+| Belongs to | The parent records ("Weekly Food Pantry, at Eastside Pantry"), or "—" for a record that stands alone |
+| Decision | A few words: what the user decided and why, using only values from the interview (capacity, schedule pattern, onsite or virtual, required level, no parent, no template). Never a field name, never "TBD" |
+
+Rows, in this order, for the records the plan includes: Volunteer Initiative, Location, Competency, Examination, Position, Position Qualification, Job Position, Job Position Qualification, Job Position Shift.
+
+**Example:**
+
+| Record | Name | Reuse or New | Belongs to | Decision |
+|---|---|---|---|---|
+| Volunteer Initiative | Weekly Food Pantry | New | — | One program, no parent |
+| Location | Eastside Pantry | Reuse | — | Onsite; already in your org |
+| Competency | Driver's License | Reuse | — | Drivers transport groceries |
+| Job Position | Driver | New | Weekly Food Pantry, at Eastside Pantry | No template; only this program uses the role |
+| Job Position Qualification | Driver's License | New | Driver | Required level 1 |
+| Job Position Shift | Saturdays 9:00–12:00 | New | Driver | 12 weekly shifts, up to 5 volunteers each |
+
+### After the table
+
+Each part below is one or two lines, and only when it applies. Don't restate the table, add a record diagram, or add sections beyond these.
+
+### Left out on purpose
+
+One line naming what the user decided against (a parent Volunteer Initiative, a Position template, shifts, qualifications), and that each can be added later without recreating these records. Leave it out when the plan includes all of them.
+
+### Schedule details
+
+One line per shift series, with what records-create needs to build it: the pattern (one-time, weekly on ‹days›, monthly on ‹day›), the time windows (per day when they differ), the start date and either the end date or the number of shifts, the time zone, and the volunteers per shift if the user set a maximum. Write only what the user said; a date or time zone they haven't given goes under Outstanding inputs, never an assumed one. Never list the individual shift dates.
+
+Example: *Driver — weekly on Saturdays, 9:00–12:00, from 3 Oct 2026 for 12 shifts, Eastern Time, up to 5 volunteers.*
+
+### What these records don't do on their own
+
+One short line for each limit below that applies to this plan, each with what the customer adds to close it. Leave the section out when none applies. These lines are in the plan, not only in message 2, because the user may skip the additional configuration.
+
+| When the plan includes… | Line |
+|---|---|
+| A maximum number of volunteers per shift | Sign-ups are counted against the maximum but never blocked when a shift is full. To stop sign-ups to a full shift, add a validation rule. |
+| Qualifications on a Position or Job Position | Qualifications guide matching only. Nothing stops a volunteer who doesn't meet them from signing up unless you add a validation rule. |
+| An Examination as a qualification | Matching doesn't use Examinations; they're for manual checks and compliance tracking. |
+| A Position that requires internal approval | The approval setting does nothing on its own. Assignments wait for approval only once you build a Salesforce Approvals process that updates their status. |
+| Tracking volunteer hours or engagement totals, when the user asked for it | The engagement and hours totals stay empty until you build Data Processing Engine definitions for them. |
+
+### Outstanding inputs
+
+One line listing any value a planned record needs that the user hasn't decided yet, e.g. "the Downtown Center's address, the series start date". records-create asks for these when it writes. Leave it out when nothing is outstanding. Don't list the out-of-scope work from message 2 here.
+
+### Reuse-check line
+
+Add the one `Reuse-check:` line from SKILL.md under the table.
+
+### Completeness check (before sending)
+
+- Every child has its parent in the plan or the org: Job Position → Volunteer Initiative, Position Qualification → Position and Competency, Job Position Qualification → Job Position and Competency, Job Position Shift → Job Position.
+- Nothing points at a record that is neither planned nor reused.
+- The plan matches what the user said: shifts for a shift-based program, qualifications for skilled roles, an end date or count for every recurring schedule.
+- Raise any gap before asking: "You described a skilled Team Lead role, but no qualification is planned for it. Do you want to add one?"
+
+End message 1 with this one question and nothing after it: **"Do you want to see the additional configuration and extensions you can set up beyond these records?"**
+
+---
+
+## Message 2 — additional configuration and the create question
+
+Send after the user answers, never with the plan.
+
+- **On yes:** present both parts below in full, as information only. Say plainly that building these items is outside what this skill does and is the user's to own. Don't say "not building these now" or "we'll set these up later". End with **"Do you want to create the records from the plan?"**
+- **On no:** send only **"Do you want to create the records from the plan?"** A no here (including "skip that") declines the additional configuration only; it is never an answer to the create question.
+
+On a yes to the create question, hand off (below). On no, stop.
+
+### Additional Configuration Considerations
+
+Share this checklist as written:
+
+**Foundational configuration**
+
+- Build a way for volunteers to sign up: an internal process, an Experience Cloud portal, or another volunteer-facing channel.
+- Automate communication and engagement: Flow for confirmations, reminders and follow-ups; Notification Builder for alerts; Marketing Cloud for journeys and campaigns.
+- Confirm or update the Status values for Volunteer Initiatives, Job Positions, Job Position Shifts and Job Position Assignments (with Stage Management if you want it).
+- Build reports and dashboards for your volunteer programs.
+
+**Advanced configuration**
+
+- Data and metrics:
+  - Build Data Processing Engine definitions for the volunteer-engagement rollup fields on Donor Gift Summary.
+  - If you add engagement rollups, show the Donor Gift Summary record on the Person Account page with a related record component. A related list won't work, because each person has one summary record.
+  - Build Data Processing Engine definitions for the Volunteer Initiative metric fields.
+- Validation and approvals:
+  - If you set capacity, add a validation rule to block signups to a full shift. Capacity is counted, never enforced.
+  - If you use qualifications, add a validation rule to block signups by volunteers who don't meet them.
+  - If a Position requires internal approval, set up Salesforce Approvals.
+- Data migration:
+  - Add external ID fields to the objects you'll import data into.
+- To support volunteer groups, consider turning on Group Membership and "Allow users to relate a contact to multiple accounts".
+
+### Extensions
+
+| Extension | What it is |
+|---|---|
+| Experience Cloud Portal | Sign-up and registration for volunteers |
+| Form Framework | Registration and application forms, built on Action Plans. A simple registration form is enough if complex applications aren't needed |
+| Action Plans | Templated task checklists, such as onboarding → background check, orientation and training |
+| Stage Management | Tracks volunteers through lifecycle stages |
+| Position Benefits | Links a Position to Program Management benefits; not needed for core Volunteer Management |
+| Constituent Role | Tags a Person Account as a volunteer |
+| Agentforce Shift Capacity and Coverage | An Agentforce subagent that reports on shift capacity and coverage. Whether it's available depends on your org's licensing and setup |
+
+Show the Agentforce row as written; don't say the subagent is available in this org.
+
+---
+
+## Handoff to records-create (only on yes)
+
+Pass:
+
+- the summary table;
+- the Id of each reused record (kept out of the table the user sees);
+- the schedule details;
+- the outstanding inputs;
+- the `Reuse-check:` line.
+
+records-create sets every field value, decides the write order, checks for shifts that already exist, and asks the user to confirm each object before writing.

package/skills/platform-custom-field-generate/SKILL.md

@@ -6,6 +6,7 @@ metadata:
   domains: ["Platform"]
   minApiVersion: "60.0"
   relatedSkills:
+    - "platform-metadata-api-context-get"
     - "platform-validation-rule-generate"
     - "platform-value-set-generate"
   mcpTools:

package/skills/platform-custom-field-generate/references/advanced-picklists.md

@@ -477,7 +477,7 @@ BusinessProcess** — adding one to a custom-object record type is wrong.
 ```xml
 <!-- File 1: objects/Opportunity/businessProcesses/Enterprise_Sales_Process.businessProcess-meta.xml -->
 <BusinessProcess xmlns="http://soap.sforce.com/2006/04/metadata">
-  <fullName>Enterprise_Sales_Process</fullName>   <!-- BARE — see the api-context translation note below -->
+  <fullName>Enterprise_Sales_Process</fullName>   <!-- BARE — see the Metadata API fullName note below -->
   <isActive>true</isActive>
   <values><fullName>Prospecting</fullName></values>      <!-- these are Opportunity STAGE (StageName) values, NOT Status__c — the BP governs the standard stage picklist. Do NOT add <default> (fails: "Cannot specify a default on: Opportunity") -->
   <values><fullName>Qualification</fullName></values>
@@ -486,16 +486,16 @@ BusinessProcess** — adding one to a custom-object record type is wrong.
 </BusinessProcess>
 ```
 
-> ⛔ **`<fullName>` is BARE in the source file — strip the entity prefix that api-context gives you.**
-> The metadata grounding / api-context for `BusinessProcess` reports the fullName in its **API
-> form**, entity-qualified: `Opportunity.Enterprise_Sales_Process`. That is correct for the API —
+> ⛔ **`<fullName>` is BARE in the source file — strip the entity prefix the Metadata API gives you.**
+> The `platform-metadata-api-context-get` skill's `BusinessProcess` entry (and the live Metadata
+> API) reports the fullName in its **API form**, entity-qualified: `Opportunity.Enterprise_Sales_Process`. That is correct for the API —
 > but in the **source/DX-format file you author**, the entity is already conveyed by the
 > `objects/Opportunity/` folder path, so the `<fullName>` element is the **bare process name**:
 > `Enterprise_Sales_Process`, NOT `Opportunity.Enterprise_Sales_Process`. (Same API-vs-source split
 > as the GlobalValueSet `__gvs` suffix in §1.) Writing the entity-qualified form makes the
 > RecordType's bare `<businessProcess>Enterprise_Sales_Process</businessProcess>` reference fail to
 > resolve → `no BusinessProcess named Opportunity.Enterprise_Sales_Process found`. **When you pull
-> the BP name from api-context and it looks like `Opportunity.X`, write `X` in the file.** The BP
+> the BP name from the Metadata API and it looks like `Opportunity.X`, write `X` in the file.** The BP
 > file's `<fullName>` and the RecordType's `<businessProcess>` must be the identical bare string.
 
 ```xml

package/skills/platform-custom-metadata-type-generate/SKILL.md

@@ -9,6 +9,7 @@ metadata:
     - "platform-custom-field-generate"
     - "platform-custom-object-generate"
     - "platform-custom-setting-generate"
+    - "platform-metadata-api-context-get"
   cliTools:
     - tool: ["sf"]
       semver: ">=2.136.8"
@@ -27,6 +28,8 @@ Use this skill when you need to:
 
 ---
 
+For authoritative Metadata API type, field, and enum details beyond this skill, use the `platform-metadata-api-context-get` skill.
+
 ## 1. Overview and Purpose
 
 A Custom Metadata Type produces **two separate artifact families**, and most requests need both:

package/skills/platform-custom-object-generate/SKILL.md

@@ -5,6 +5,8 @@ metadata:
   version: "1.1"
   domains: ["Platform"]
   minApiVersion: "60.0"
+  relatedSkills:
+    - "platform-metadata-api-context-get"
 ---
 
 ## When to Use This Skill
@@ -17,6 +19,8 @@ Use this skill when you need to:
 - Troubleshoot deployment errors related to custom objects
 - **Add, update, or delete a field OR a validation rule on an existing object** — any of these may make the object's `<description>` stale, so you must refresh it (propose + confirm). This applies equally to validation-rule changes, not just fields. See Section 3.B.
 
+For authoritative Metadata API type, field, and enum details beyond this skill, use the `platform-metadata-api-context-get` skill.
+
 ## Specification
 
 ## 1. Overview and Purpose