Expand ticket and DDR analysis skills

This commit is contained in:
martin committed 2026-08-09 11:55:38 +02:00
1 parent 0845a033fb
commit 52ea9df76f
3 files changed
+38 -15

No files matched your search

+14 -8
View File
@@ -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.