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.
+- `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.
+- `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.

skills/ticket-delivery/SKILL.md

@@ -11,22 +11,34 @@ description: Prepare a concise project-manager reply and billable work report fo
 - For early analysis, label the response as a draft or return only the questions needed to continue.
 - Do not describe a proposal, an unverified assumption, or an open dependency as completed implementation.
 - Never send, post, or otherwise deliver the reply unless explicitly asked.
+- Provide a completed or reviewed-work reply only after all major changes have been closed and reviewed, or when explicitly requested.
 
 ## Project-manager reply
 
 - Lead with completed work, followed only by unresolved questions or confirmations needed.
 - Use concise, practical, client-facing English. Remove internal exploration and unused architecture proposals.
 - Distinguish completed work from proposed next steps.
+- For a larger ticket, use concise sections such as `COMPLETED`, `QUESTIONS`, and `KEY CALCULATIONS` when they improve readability.
 - When useful for verification, give a friendly label followed by the exact FileMaker object name in brackets, for example `Utility Switch [APPROVE::UtilitySwitch]`.
 - Include exact layout, script, custom function, or value-list names only when they materially help verification.
 - Include FileMaker code only when a calculation or script rule is central to approval. Put it at the end under a concise `KEY CALCULATIONS` or `KEY SCRIPT LOGIC` heading.
+- If current architecture already fulfills the present requirement, omit unused future tables or designs from the completed-work summary. Raise them only when a distinct business decision is needed.
 
 ## Short work report
 
-Create one only when the project requires it or the user requests it.
+Every project-manager reply must end with a short work report. It is a compact billable-work summary, not a list of questions.
 
 - Maximum 450 characters, including title, bullets, and line breaks.
 - Start with the ticket number and a short title.
 - Use one to three short past-tense bullets describing completed work.
 - Exclude code, open questions, testing instructions, and unconfirmed claims.
 - Put the report in a fenced `text` block so it is easy to copy.
+
+Example:
+
+```text
+52926 Fuel Switch – Phase Tracking
+- Added start and end timestamps, duration tracking and status fields across the current Customer, Evaluation, Approval, Installation and QA phases.
+- Verified funding stream eligibility and its default value during import.
+- Kept the new status tracking separate from the fields currently used by reports.
+```