Initialize FileMaker AI core
This commit is contained in:
commit
18a9a4cd67
13 files changed
+257
No files matched your search
@@ -0,0 +1,23 @@
|
||||
---
|
||||
name: ddr-analysis
|
||||
description: Analyze a FileMaker parsed DDR with evidence, identify affected objects and dependencies, and distinguish current implementation from unconfirmed intent.
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
## 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.
|
||||
6. Identify regression, permissions, data, report, and integration impact.
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
name: filemaker-scripting
|
||||
description: Prepare or review FileMaker script changes while preserving verified legacy behavior, context safety, validation, error handling, and regression coverage.
|
||||
---
|
||||
|
||||
# FileMaker Scripting
|
||||
|
||||
Use this skill for FileMaker script generation, edits, reviews, or troubleshooting.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Confirm the requirement and locate comparable current scripts in the project DDR.
|
||||
2. Establish or validate context, parameters, privilege assumptions, record state, and expected errors.
|
||||
3. Preserve the project's proven naming and framework patterns.
|
||||
4. Use the available FileMaker script-format tooling when producing `.fmscript` content.
|
||||
5. Define normal, invalid-input, empty-result, privilege, cancellation, and regression tests as relevant.
|
||||
|
||||
## Safety
|
||||
|
||||
- Never assume the current layout, found set, record, account, or PSoS context.
|
||||
- Treat deletes, commits, imports, account changes, and integrations as high-risk operations.
|
||||
- Do not replace a working legacy pattern solely because a generic convention looks cleaner.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
name: ticket-analysis
|
||||
description: Analyze a FileMaker ticket into confirmed requirements, questions, affected existing behavior, implementation steps, risks, and tests without inventing business rules.
|
||||
---
|
||||
|
||||
# Ticket Analysis
|
||||
|
||||
Use this skill before proposing implementation for a ticket, email request, or developer handoff.
|
||||
|
||||
## Output
|
||||
|
||||
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
|
||||
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.
|
||||
- Keep a proposed design distinct from verified current implementation.
|
||||
Reference in new issue
Block a user