Initialize FileMaker AI core
This commit is contained in:
commit
18a9a4cd67
13 files changed
+257
No files matched your search
+29
@@ -0,0 +1,29 @@
|
|||||||
|
# Operating system and editor state
|
||||||
|
.DS_Store
|
||||||
|
.local/
|
||||||
|
tmp/
|
||||||
|
|
||||||
|
# Secrets and machine-specific configuration
|
||||||
|
.env
|
||||||
|
.env.*
|
||||||
|
!.env.example
|
||||||
|
*.pem
|
||||||
|
*.key
|
||||||
|
*.p12
|
||||||
|
*.pfx
|
||||||
|
credentials/
|
||||||
|
secrets/
|
||||||
|
|
||||||
|
# Local agent and editor configuration
|
||||||
|
.claude/settings.local.json
|
||||||
|
.claude/worktrees/
|
||||||
|
.codex/
|
||||||
|
.vscode/*.local.json
|
||||||
|
.idea/
|
||||||
|
|
||||||
|
# Generated dependencies and logs
|
||||||
|
node_modules/
|
||||||
|
dist/
|
||||||
|
build/
|
||||||
|
coverage/
|
||||||
|
*.log
|
||||||
@@ -0,0 +1,34 @@
|
|||||||
|
# FileMaker AI Core
|
||||||
|
|
||||||
|
This repository contains reusable, client-neutral guidance for FileMaker AI work. It is designed to be consumed by client workspaces as a pinned Git submodule.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
- Keep this repository free of client names, DDR exports, tickets, production data, credentials, and client-specific business rules.
|
||||||
|
- Put project facts, confirmed decisions, raw DDR locations, and client communication requirements in the consuming project repository.
|
||||||
|
- Treat this repository as a baseline, not as permission to overwrite legacy project conventions.
|
||||||
|
|
||||||
|
## Project Integration
|
||||||
|
|
||||||
|
The consuming project's root `AGENTS.md` must direct agents here explicitly and identify the relevant skill. A project normally gives this repository lower priority than:
|
||||||
|
|
||||||
|
1. Confirmed client decisions and current ticket requirements
|
||||||
|
2. The project's own `AGENTS.md`, notes, and documented conventions
|
||||||
|
3. Verified current DDR or direct FileMaker inspection
|
||||||
|
4. This core guidance
|
||||||
|
5. General FileMaker practice
|
||||||
|
|
||||||
|
## Core Rules
|
||||||
|
|
||||||
|
- Separate confirmed behavior from assumptions and open questions.
|
||||||
|
- Do not invent business rules, schema details, permissions, or implementation status.
|
||||||
|
- Preserve established legacy patterns unless a confirmed requirement deliberately changes them.
|
||||||
|
- Treat parsed DDR as generated reference data; do not edit it manually.
|
||||||
|
- Before sharing parsed DDR, run the project's secret-redaction and review process.
|
||||||
|
- Keep reusable instructions concise and split them into relevant skills instead of growing this file indefinitely.
|
||||||
|
|
||||||
|
## Available Skills
|
||||||
|
|
||||||
|
- `skills/ddr-analysis/`: analyze FileMaker DDR safely and evidence-first.
|
||||||
|
- `skills/filemaker-scripting/`: prepare or review FileMaker script work.
|
||||||
|
- `skills/ticket-analysis/`: turn a request into confirmed scope, questions, risks, and tests.
|
||||||
@@ -0,0 +1,29 @@
|
|||||||
|
# FileMaker AI Core
|
||||||
|
|
||||||
|
Private, reusable guidance for FileMaker projects that use AI assistants.
|
||||||
|
|
||||||
|
This repository deliberately contains no client DDR, tickets, production data, credentials, or client-specific rules. Client workspaces consume a pinned version as a Git submodule, usually at `shared/filemaker-ai-core/`.
|
||||||
|
|
||||||
|
## Phase 1 status
|
||||||
|
|
||||||
|
The initial skeleton establishes the shared contract, three generic skills, a ticket-analysis prompt, and project templates. It intentionally does not yet include a DDR parser wrapper or any material copied from a client workspace.
|
||||||
|
|
||||||
|
## Layout
|
||||||
|
|
||||||
|
- `AGENTS.md`: stable core policy and skill routing.
|
||||||
|
- `skills/`: focused reusable FileMaker workflows.
|
||||||
|
- `docs/`: common project, DDR, and security guidance.
|
||||||
|
- `prompts/`: reusable starting points for agent output.
|
||||||
|
- `templates/`: files for a new client AI workspace.
|
||||||
|
- `scripts/`: future client-neutral automation only.
|
||||||
|
|
||||||
|
## Intended consumption
|
||||||
|
|
||||||
|
```text
|
||||||
|
<project>-ai/
|
||||||
|
AGENTS.md
|
||||||
|
shared/
|
||||||
|
filemaker-ai-core/ # pinned Git submodule
|
||||||
|
```
|
||||||
|
|
||||||
|
The project root remains the normal VS Code folder. Its `AGENTS.md` explicitly directs the agent to the core resources when relevant.
|
||||||
@@ -0,0 +1,19 @@
|
|||||||
|
# DDR Workflow
|
||||||
|
|
||||||
|
Raw DDR is generated input and belongs beside the client project, outside the AI workspace Git repository. Parsed DDR is useful for diffs and analysis, but only after a security review.
|
||||||
|
|
||||||
|
## Portable project layout
|
||||||
|
|
||||||
|
```text
|
||||||
|
<client>/<project>/
|
||||||
|
ddr/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
archive/
|
||||||
|
<project>-ai/
|
||||||
|
DDR-Parsed/
|
||||||
|
```
|
||||||
|
|
||||||
|
Projects should store relative source definitions, not absolute workstation paths. A future parser wrapper must validate the source, parse into a temporary directory, run redaction checks, and only then update `DDR-Parsed/`.
|
||||||
|
|
||||||
|
Do not enable automatic commits from the parser. Review the sanitized diff before committing it.
|
||||||
@@ -0,0 +1,23 @@
|
|||||||
|
# Project Contract
|
||||||
|
|
||||||
|
Every client AI workspace owns its client context. Keep the project root small, explicit, and safe to open directly in VS Code.
|
||||||
|
|
||||||
|
## Project-owned material
|
||||||
|
|
||||||
|
- client name and project scope
|
||||||
|
- confirmed business rules and decisions
|
||||||
|
- tickets, project notes, and approved analysis
|
||||||
|
- sanitized parsed DDR
|
||||||
|
- FileMaker work scripts and project-specific prompts
|
||||||
|
- the location and environment names of raw DDR exports
|
||||||
|
|
||||||
|
## Core-owned material
|
||||||
|
|
||||||
|
- generic FileMaker analysis and scripting workflow
|
||||||
|
- reusable prompts and templates
|
||||||
|
- generic DDR handling and secret-safety guidance
|
||||||
|
- client-neutral helper scripts
|
||||||
|
|
||||||
|
## Instruction precedence
|
||||||
|
|
||||||
|
When guidance conflicts, preserve project evidence and confirmed client decisions. A project may opt into an additional organization-specific standard without applying it to other clients.
|
||||||
@@ -0,0 +1,13 @@
|
|||||||
|
# Security and Redaction
|
||||||
|
|
||||||
|
Private Git hosting does not make secrets safe to commit. FileMaker DDR can expose credentials through custom functions, calculations, scripts, data sources, and integration settings.
|
||||||
|
|
||||||
|
Before a parsed DDR is committed or shared:
|
||||||
|
|
||||||
|
1. Scan for private keys, tokens, passwords, client secrets, API keys, and connection strings.
|
||||||
|
2. Redact values deterministically while retaining the object name and enough structure for analysis.
|
||||||
|
3. Review the resulting diff.
|
||||||
|
4. Rotate any active credential that may have entered Git history.
|
||||||
|
5. Keep raw DDR and original secret-bearing exports outside Git.
|
||||||
|
|
||||||
|
Never add a real secret to this core repository, examples included.
|
||||||
@@ -0,0 +1,9 @@
|
|||||||
|
# Ticket Analysis Prompt
|
||||||
|
|
||||||
|
Analyze the supplied request using the project `AGENTS.md`, confirmed notes, and current parsed DDR.
|
||||||
|
|
||||||
|
- Do not invent missing business rules.
|
||||||
|
- Cite exact FileMaker object names when DDR evidence matters.
|
||||||
|
- Separate confirmed requirements, current behavior, assumptions, and questions.
|
||||||
|
- Identify affected scripts, fields, layouts, relationships, permissions, reports, and integrations where relevant.
|
||||||
|
- End with practical tests and concise client questions only when a decision is needed.
|
||||||
@@ -0,0 +1,5 @@
|
|||||||
|
# Scripts
|
||||||
|
|
||||||
|
This directory is reserved for small, client-neutral automation that belongs to the common AI framework.
|
||||||
|
|
||||||
|
Do not add a bundled `DDRparser` binary here. The existing parser is an external developer dependency; future wrappers should validate its presence and operate through project-relative configuration.
|
||||||
@@ -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.
|
||||||
@@ -0,0 +1,9 @@
|
|||||||
|
# Copy into a project AI workspace and adjust only relative paths.
|
||||||
|
sources:
|
||||||
|
dev: ../ddr/dev/Summary.xml
|
||||||
|
prod: ../ddr/prod/Summary.xml
|
||||||
|
|
||||||
|
output: DDR-Parsed
|
||||||
|
|
||||||
|
# Future parser tooling must parse to a temporary location, sanitize values,
|
||||||
|
# and require review before replacing the tracked output.
|
||||||
@@ -0,0 +1,16 @@
|
|||||||
|
# <Project> AI Workspace
|
||||||
|
|
||||||
|
This repository contains client-specific FileMaker AI work. Project evidence and confirmed client decisions take priority over shared guidance.
|
||||||
|
|
||||||
|
## Shared Core
|
||||||
|
|
||||||
|
For generic FileMaker workflow, read `shared/filemaker-ai-core/AGENTS.md` and then the relevant skill. The core does not replace this project's business rules, legacy conventions, or current DDR.
|
||||||
|
|
||||||
|
## Project Sources
|
||||||
|
|
||||||
|
- Tickets: `TICKETS/`
|
||||||
|
- Confirmed notes: `NOTES/`
|
||||||
|
- Parsed DDR: `DDR-Parsed/`
|
||||||
|
- Raw DDR: sibling `../ddr/`
|
||||||
|
|
||||||
|
Record the project-specific source priority, DDR environments, naming standards, required output format, and known business rules below this line.
|
||||||
Reference in new issue
Block a user