Share standard FileMaker delivery workflow

AGENTS.md

@@ -25,8 +25,8 @@ Report meaningful conflicts instead of silently resolving them.
 Use these locations for a workspace that follows the standard project layout. A project may document only deviations in `PROJECT.md`.
 
 - `../DDR/`: local raw FileMaker DDR input. Never copy it into the repository or commit it; move it only as part of an explicitly approved filesystem migration.
-- `TICKETS/`: one folder per ticket or workstream. Keep its source requests, handoffs, analysis, questions, reports, assets, and ticket-specific scripts together.
-- `FMSCRIPTS/`: tracked complete `.fmscript` files that are not clearly ticket-specific or apply across several workstreams.
+- `TICKETS/`: one folder per ticket or workstream. Keep its source requests, handoffs, analysis, questions, reports, assets, and ticket-specific scripts together. Use a `scripts/` subfolder when it helps navigation.
+- `FMSCRIPTS/`: tracked complete `.fmscript` files that are not clearly ticket-specific or apply across several workstreams; keep one `.fmscript` file per FileMaker script.
 - `NOTES/`: confirmed knowledge and business rules that apply across more than one ticket.
 - `DDR-Parsed/`: tracked generated FileMaker reference material. Do not edit it manually.
 - `ddr-parse.sh`: run `zsh ddr-parse.sh` from the project root to parse the latest DDR into `DDR-Parsed/` when an up-to-date reference is needed.
@@ -41,6 +41,15 @@ Read only the skill that matches the work; do not load every shared reference by
 - New or changed FileMaker object, field, variable, parameter, or result names: `skills/filemaker-naming/SKILL.md`
 - Project-manager reply or short billable work report: `skills/ticket-delivery/SKILL.md`
 
+## Standard workflow
+
+1. Put a new ticket, request, or email in its own `TICKETS/<ticket or workstream>/` folder.
+2. Analyze it with the relevant shared skill before proposing implementation.
+3. Review affected current definitions and dependencies in `DDR-Parsed/`.
+4. Turn unclear business rules into concise confirmation questions rather than assumptions.
+5. After implementation and DDR regeneration, re-check affected definitions, calculations, layouts, scripts, and report dependencies.
+6. Prepare client-facing delivery only after the work is reviewed or when explicitly requested.
+
 ## Core rules
 
 - Do not invent business rules, schema details, permissions, or implementation status. Separate confirmed behavior, verified current behavior, proposals, and open questions.