filemaker-ai-core/skills/ticket-analysis/SKILL.md

name, description

name	description
ticket-analysis	Analyze a FileMaker ticket, request, email, or developer handoff into confirmed requirements, verified current behavior, open questions, safe implementation steps, risks, and tests without inventing business rules. Use before planning, reviewing, or closing a FileMaker change.

Ticket Analysis

Follow the consuming project's AGENTS.md for source priority, project folders, client terminology, and any client-specific reply or report format.

Evidence-first workflow

1. Read the complete ticket, its latest developer note, and relevant project README, handoff summary, and confirmed notes.
   • For a project with several tickets, use its current summary as the handoff source; update a project summary or checklist only when explicitly asked.
2. Identify the requested business outcome. Keep these categories distinct:
   • confirmed requirements and their source
   • verified current behavior
   • completed implementation
   • assumptions, contradictions, and open or TBA rules
3. If existing FileMaker behavior may be affected, use the relevant ddr-analysis skill before proposing the change.
4. Resolve only the implementation details supported by the ticket and verified evidence. Turn missing rules into short, decision-oriented questions.
5. Identify data, permissions, workflow, layout, reporting, integration, and regression impact where relevant.
6. After implementation and DDR regeneration, re-check the affected definitions and dependencies before describing the work as complete.

Do not silently resolve conflicting sources. Report the conflict and defer to the source priority defined by the project.

Output

Return only the sections needed by the project, normally:

1. Summary
2. Confirmed requirements
3. Verified current behavior and affected DDR evidence
4. Open questions, assumptions, and contradictions
5. Suggested implementation steps
6. Risks and regression impact
7. Test cases

Rules

• A client decision is not confirmed merely because it appears in a draft, old ticket, or inferred implementation.
• Keep a proposed design distinct from verified current implementation.
• Do not call a ticket complete while a required rule is TBA, a required dependency is unreviewed, a calculation uses the wrong source, or a requested control is exposed to the wrong role or environment.
• Do not send client replies or modify project files unless explicitly asked.