| name | to-tickets |
| description | Break an approved Salesforce feature specification into small GitHub Issues with explicit blocking edges. |
| disable-model-invocation | true |
Salesforce delivery tickets
Use this skill with an approved spec under .github/specs/.
Process
- Read the spec,
CONTEXT.md, relevant ADRs, and nearby tests.
- Split the work into tracer-bullet vertical slices. Each slice must be independently verifiable.
- Give every ticket a short title, user-visible outcome, acceptance criteria, test seam, and explicit blockers.
- Present the breakdown for human approval before creating or changing GitHub Issues.
- Create or update GitHub Issues only after approval. Never invent issue numbers, labels, permissions, or repository settings.
- Keep package-owned directories and red-zone changes visible in the ticket scope.
Ticket quality
- Prefer one complete behavioural path over layer-by-layer task lists.
- Keep dependencies explicit and minimal.
- Include focused test and broader validation criteria.
- Record org-dependent prerequisites for Apex, metadata, deployment, or package work.
- Do not close issues automatically.
GitHub Issues are the system of record. Local specs remain the source of the agreed behaviour; the issue should link to the spec when the platform permits it.
