45 lines
2.7 KiB
Markdown
45 lines
2.7 KiB
Markdown
---
|
||
name: ticket-delivery
|
||
description: Prepare a concise project-manager reply and billable work report for reviewed FileMaker ticket work. Use when summarizing completed or reviewed work for a client, project manager, invoice, or handoff.
|
||
---
|
||
|
||
# FileMaker Ticket Delivery
|
||
|
||
## Preconditions
|
||
|
||
- Read the current ticket, relevant confirmed decisions, and the project's delivery rules.
|
||
- 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
|
||
|
||
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.
|
||
```
|