Expand ticket and DDR analysis skills

prompts/ticket-analysis.md

@@ -1,6 +1,6 @@
 # Ticket Analysis Prompt
 
-Analyze the supplied request using the project `AGENTS.md`, confirmed notes, and current parsed DDR.
+Read `skills/ticket-analysis/SKILL.md`, then analyze the supplied request using the project `AGENTS.md`, confirmed notes, and current parsed DDR. When current implementation may be affected, also use `skills/ddr-analysis/SKILL.md`.
 
 - Do not invent missing business rules.
 - Cite exact FileMaker object names when DDR evidence matters.

skills/ddr-analysis/SKILL.md

@@ -1,23 +1,29 @@
 ---
 name: ddr-analysis
-description: Analyze a FileMaker parsed DDR with evidence, identify affected objects and dependencies, and distinguish current implementation from unconfirmed intent.
+description: Inspect a parsed FileMaker DDR to verify current FileMaker implementation, trace affected objects and dependencies, and identify risks without treating generated output or assumptions as confirmed behavior. Use for schema, script, calculation, layout, relationship, security, reporting, or integration analysis.
 ---
 
 # DDR Analysis
 
-Use this skill when a FileMaker task may affect existing tables, fields, calculations, relationships, layouts, scripts, custom functions, value lists, privileges, integrations, reports, or stored data.
+Follow the consuming project's `AGENTS.md` for the active parsed DDR location, data freshness, source priority, and redaction requirements.
 
 ## Workflow
 
-1. Read the current ticket and confirmed project notes.
-2. Confirm that the DDR is current enough for the question; state uncertainty if it is not.
-3. Search every affected object type, not only the first matching script or field.
-4. Record exact object names and relevant relationship paths as evidence.
-5. Separate confirmed behavior, existing implementation, inference, and open questions.
+1. Read the current ticket and confirmed project notes. Confirm that the parsed DDR is current enough for the question; state uncertainty if it is not.
+2. Search every affected object type, not only the first matching script or field. Consider tables, fields, table occurrences, relationships, layouts, scripts, custom functions, value lists, privileges, reports, integrations, and stored data as relevant.
+3. Record exact object names and relationship paths as evidence.
+4. Inspect the properties that affect the request: field type and storage, calculations and source fields, layout placement and editability, locking, environment visibility, script behavior, reporting, permissions, and integrations.
+5. Separate verified current implementation from proposed design, inference, and open questions.
 6. Identify regression, permissions, data, report, and integration impact.
 
+## Conflicts and generated data
+
+- If parsed DDR conflicts with a direct FileMaker check, report the discrepancy and defer to the verified FileMaker definition.
+- Do not manufacture a correction from ambiguous parser output.
+- When the project provides a regenerated DDR, repeat the affected searches and evidence checks.
+- Treat secrets found in a DDR as a security issue; do not reproduce their values in analysis or output.
+
 ## Rules
 
 - Parsed DDR is generated reference data: do not edit it manually.
 - Do not call a proposal implemented unless the current DDR or direct FileMaker verification proves it.
-- Treat secrets found in DDR as a security issue; do not reproduce their values in analysis or output.

skills/ticket-analysis/SKILL.md

@@ -1,11 +1,27 @@
 ---
 name: ticket-analysis
-description: Analyze a FileMaker ticket into confirmed requirements, questions, affected existing behavior, implementation steps, risks, and tests without inventing business rules.
+description: 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
 
-Use this skill before proposing implementation for a ticket, email request, or developer handoff.
+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
 
@@ -13,14 +29,15 @@ Return only the sections needed by the project, normally:
 
 1. Summary
 2. Confirmed requirements
-3. Existing behavior and affected DDR evidence
-4. Open questions and assumptions
+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 or an old ticket.
-- Ask short, decision-oriented questions instead of filling gaps with guesses.
+- 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.