@docyrus/docyrus 0.0.19 → 0.0.21

package/resources/pi-agent/skills/changelog-generator/SKILL.md

@@ -0,0 +1,425 @@
+---
+name: changelog-generator
+description: >
+  Parse git history and produce or update a CHANGELOG.md following the Keep a Changelog convention. Supports Conventional Commits, basic prefix conventions, and unstructured commit messages. Intelligently categorizes changes, detects breaking changes, links to PRs/issues, and handles both initial generation and incremental updates.
+
+**Triggers — use this skill when:**
+- User asks to "generate", "create", "update", or "write" a changelog
+- User mentions "CHANGELOG", "changelog", "release notes"
+- User says "document changes", "what changed since last release"
+- User wants to "prepare a release" and needs a changelog entry
+- User asks to "clean up" or "reformat" an existing changelog
+
+**Covers:** Any git-based project.
+
+Handles Conventional Commits (feat/fix/chore), Angular convention, basic prefixes (Add/Fix/Remove), and freeform commit messages. Outputs Keep a Changelog format with optional Common Changelog enhancements.
+---
+
+# Changelog Generator
+
+Parse a project's git history and produce a high-quality CHANGELOG.md following the [Keep a Changelog](https://keepachangelog.com/) convention.
+
+## Philosophy
+
+A changelog is for **humans**, not machines.
+
+It answers: "What meaningful changes happened between version X and version Y?"
+
+Raw commit logs fail at this because they contain noise — typo fixes, merge commits, CI tweaks, and refactors that don't affect users. This skill filters signal from noise and writes entries that a user or contributor can actually understand.
+
+---
+
+## Workflow
+
+### Phase 1 — Repository Analysis
+
+Before generating anything, understand the project's commit and versioning patterns.
+
+```bash
+# 1. Check if we're in a git repo
+git rev-parse --is-inside-work-tree 2>/dev/null
+
+# 2. Get all tags (versions) sorted by date
+git tag --sort=-creatordate | head -30
+
+# 3. Detect versioning scheme
+# SemVer: v1.2.3 or 1.2.3
+# CalVer: 2025.01, 2025-01-15
+# Other: named releases, build numbers
+git tag --sort=-creatordate | head -10
+
+# 4. Detect commit convention
+# Sample recent commits to identify the pattern
+git log --oneline -30
+
+# 5. Check for existing changelog
+cat CHANGELOG.md 2>/dev/null
+cat HISTORY.md 2>/dev/null
+cat CHANGES.md 2>/dev/null
+
+# 6. Check for existing config that hints at convention
+cat .commitlintrc* commitlint.config.* 2>/dev/null    # Commitlint
+cat .czrc .cz.toml 2>/dev/null                        # Commitizen
+cat cliff.toml 2>/dev/null                            # git-cliff
+cat .versionrc* 2>/dev/null                           # standard-version
+
+# 7. Get remote URL for PR/issue links
+git remote get-url origin 2>/dev/null
+
+# 8. Package manifest for current version
+cat package.json 2>/dev/null | grep '"version"'
+cat pyproject.toml 2>/dev/null | grep 'version'
+cat Cargo.toml 2>/dev/null | grep '^version'
+```
+
+**Extract from the analysis:**
+
+| Fact | How to determine |
+|------|-----------------|
+| Commit convention | Pattern match on recent commits (see detection rules below) |
+| Versioning scheme | Tag format analysis |
+| Latest version/tag | Most recent tag |
+| Remote URL | `git remote get-url origin` — needed for PR/issue links |
+| Existing changelog | Check for CHANGELOG.md or variants |
+| Unreleased commits | Commits since the latest tag |
+
+### Phase 2 — Commit Convention Detection
+
+Analyze the last 30–50 commits to detect which convention is in use.
+
+Apply these rules in order:
+
+**Conventional Commits / Angular**
+
+```
+Pattern: ^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?!?:
+Example: feat(auth): add OAuth2 support
+Example: fix!: resolve race condition in queue
+```
+
+→ If >50% of commits match this pattern, use Conventional Commits parsing.
+
+**Basic Prefix**
+
+```
+Pattern: ^(Add|Fix|Remove|Update|Change|Deprecate|Security)[: ]
+Example: Add user export feature
+Example: Fix login redirect loop
+```
+
+→ If >50% of commits match this pattern, use basic prefix parsing.
+
+**Freeform / No Convention**
+
+→ If neither pattern dominates, use AI-assisted categorization (see Phase 3).
+
+Report the detected convention to the user before proceeding.
+
+### Phase 3 — Commit Extraction & Categorization
+
+Extract commits for the target range and categorize them.
+
+```bash
+# All commits since last tag (for Unreleased section)
+git log $(git describe --tags --abbrev=0 2>/dev/null)..HEAD \
+  --pretty=format:"%H|%s|%b|%an|%ae|%aI" 2>/dev/null
+
+# Commits between two tags (for a specific version)
+git log v1.1.0..v1.2.0 \
+  --pretty=format:"%H|%s|%b|%an|%ae|%aI"
+
+# If no tags exist, get all commits
+git log --pretty=format:"%H|%s|%b|%an|%ae|%aI"
+
+# Get PR/merge info if available
+git log --merges --oneline -20
+```
+
+#### Category Mapping
+
+Map commits to Keep a Changelog categories:
+
+| Keep a Changelog Category | Conventional Commits types | Basic prefixes | Description |
+|---------------------------|---------------------------|----------------|-------------|
+| **Added** | `feat` | Add, Create, Implement | New features |
+| **Changed** | `refactor`, `perf`, `style` | Change, Update, Refactor, Improve | Changes to existing functionality |
+| **Deprecated** | — (detect from message) | Deprecate | Soon-to-be removed features |
+| **Removed** | — (detect from message) | Remove, Delete, Drop | Removed features |
+| **Fixed** | `fix` | Fix, Resolve, Correct | Bug fixes |
+| **Security** | — (detect from message) | Security | Vulnerability fixes |
+
+#### Entries to SKIP (noise filtering)
+
+Do NOT include these in the changelog unless they have user-facing impact:
+
+- Merge commits (`Merge branch...`, `Merge pull request...`) — extract the PR title instead
+- CI/CD changes (`ci:`, `build:`, changes only to `.github/workflows/`)
+- Chore commits (`chore:`, dependency bumps without breaking changes)
+- Typo fixes in code comments
+- Formatting/linting-only changes (`style:` that don't affect behavior)
+- Version bump commits (`chore: bump version to...`)
+- Commits that only touch test files (unless adding test coverage is noteworthy)
+
+#### Freeform Commit Categorization
+
+When commits don't follow a convention, categorize by analyzing the message content:
+
+- Contains "add", "new", "create", "implement", "introduce" → **Added**
+- Contains "fix", "resolve", "correct", "patch", "bug" → **Fixed**
+- Contains "remove", "delete", "drop" → **Removed**
+- Contains "deprecate" → **Deprecated**
+- Contains "security", "vulnerability", "CVE" → **Security**
+- Contains "update", "change", "refactor", "improve", "optimize" → **Changed**
+- If unclear, use the diff to determine: new files = Added, deleted files = Removed, modified = Changed
+
+#### Breaking Change Detection
+
+Flag breaking changes regardless of convention:
+
+- Conventional: `!` after type/scope, or `BREAKING CHANGE:` in footer
+- Message content: "breaking", "incompatible", "migration required"
+- SemVer major bump between tags
+- Removal of public API functions/endpoints
+
+Mark breaking entries with **BREAKING:** prefix in the changelog.
+
+### Phase 4 — Entry Writing
+
+Transform raw commit data into human-readable changelog entries.
+
+#### Writing Rules
+
+1. **Write for the user, not the developer.**
+   "Add dark mode support" not "feat(ui): implement dark-mode toggle via CSS custom properties in ThemeProvider"
+2. **Use imperative mood.**
+   "Add", "Fix", "Remove" — not "Added", "Fixed", "Removed"
+3. **One entry per meaningful change.**
+   Squash related commits into a single entry
+4. **Include references.**
+   Link to PR numbers and issues: `(#123)`, `([#123](url))`
+5. **Credit authors for external contributions.**
+   `(@username)` for non-core contributors
+6. **Lead with impact.**
+   Put the most important changes first within each category
+7. **Be specific.**
+   "Fix crash when uploading files larger than 10MB" not "Fix upload bug"
+8. **Keep entries to one line.**
+   If you need more, the change probably needs multiple entries or a migration guide
+
+#### Entry Format
+
+```markdown
+- Add dark mode support with automatic system preference detection (#142)
+- **BREAKING:** Remove deprecated `v1/users` endpoint; use `v2/users` instead (#138)
+- Fix memory leak in WebSocket connection handler (#145)
+```
+
+### Phase 5 — Assemble the Changelog
+
+#### File Format (Keep a Changelog)
+
+```markdown
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+- Description of new feature (#PR)
+
+### Fixed
+- Description of bug fix (#PR)
+
+## [1.2.0] - 2025-09-15
+
+### Added
+- Add OAuth2 authentication support (#89)
+- Add CSV export for user data (#92)
+
+### Changed
+- Improve query performance for large datasets (#91)
+
+### Fixed
+- Fix timezone handling in scheduled reports (#88)
+- Fix incorrect pagination count on filtered results (#90)
+
+### Removed
+- **BREAKING:** Remove legacy XML API endpoint (#87)
+
+## [1.1.0] - 2025-06-01
+
+### Added
+- ...
+
+[Unreleased]: https://github.com/user/repo/compare/v1.2.0...HEAD
+[1.2.0]: https://github.com/user/repo/compare/v1.1.0...v1.2.0
+[1.1.0]: https://github.com/user/repo/compare/v1.0.0...v1.1.0
+```
+
+#### Critical Format Rules
+
+1. **H1 for title.** `# Changelog` — only one H1
+2. **H2 for versions.** `## [1.2.0] - 2025-09-15` — square brackets around version, ISO date
+3. **H3 for categories.** `### Added`, `### Changed`, etc. — only use categories that have entries
+4. **Comparison links at the bottom.** Every version heading must have a corresponding comparison link
+5. **Unreleased section at top.** Always present, even if empty (remove if the project prefers not to have it)
+6. **Newest version first.** Reverse chronological order
+7. **ISO 8601 dates.** `YYYY-MM-DD` — no exceptions
+8. **Empty categories.** Do NOT include a category heading if there are no entries under it
+
+---
+
+## Operating Modes
+
+### Mode A: Generate from Scratch
+
+No existing changelog. Generate the full history.
+
+1. Get all tags sorted chronologically
+2. For each tag pair (oldest to newest), extract and categorize commits
+3. Assemble full changelog
+4. If there are many tags (>10), ask the user if they want all history or just recent versions
+
+```bash
+# Get tags in chronological order
+git tag --sort=creatordate
+
+# Get date of a tag
+git log -1 --format=%aI v1.0.0
+```
+
+### Mode B: Update Existing Changelog
+
+A CHANGELOG.md already exists. Add new entries.
+
+1. Parse the existing changelog to find the latest documented version
+2. Determine the commit range: latest documented version → HEAD (or → new tag)
+3. Generate entries only for the new range
+4. Insert the new version section after `## [Unreleased]` (or at the top if no Unreleased)
+5. Update comparison links at the bottom
+6. Preserve all existing content exactly as-is
+
+**Never modify existing entries** unless the user explicitly asks for a reformat.
+
+### Mode C: Reformat / Clean Up
+
+User has a messy or inconsistent changelog. Rewrite to match the standard.
+
+1. Parse all existing entries
+2. Re-categorize under Keep a Changelog headings
+3. Fix date formats to ISO 8601
+4. Add missing comparison links
+5. Fix heading hierarchy
+6. Show a diff/summary of changes to the user before writing
+
+### Mode D: Prepare Release
+
+User wants to create a changelog entry for an upcoming release.
+
+1. Extract commits since the last tag
+2. Categorize and write entries
+3. Ask the user for the new version number (or suggest one based on changes: major if breaking, minor if features, patch if only fixes)
+4. Move entries from `## [Unreleased]` to the new version section
+5. Update comparison links
+6. Optionally suggest a SemVer bump
+
+---
+
+## Handling Edge Cases
+
+### No Tags
+
+If the project has no tags, treat all commits as unreleased.
+
+Ask the user if they want to:
+
+- Generate a single `## [Unreleased]` section
+- Create a `## [0.1.0]` retroactively from the initial commit
+
+### Monorepo
+
+If the project is a monorepo with multiple packages:
+
+- Ask which package to generate for
+- Filter commits by path: `git log -- packages/package-name/`
+- Consider separate changelogs per package
+
+### Squash Merges
+
+If the project uses squash merges, the PR title becomes the commit message. These are often well-written and can be used directly as changelog entries.
+
+### Very Large History
+
+If there are >500 commits to process:
+
+- Process in batches by tag range
+- Ask the user if they want full history or just the last N versions
+- For initial generation, suggest starting from the latest 3-5 versions
+
+### Pre-1.0 Projects
+
+For projects that haven't reached 1.0:
+
+- Minor bumps may contain breaking changes (per SemVer spec)
+- Still flag breaking changes but note the pre-1.0 context
+
+---
+
+## Quality Checklist
+
+After generating, verify:
+
+### Format
+
+- [ ] Single H1 (`# Changelog`)
+- [ ] Each version is H2 with brackets and ISO date: `## [X.Y.Z] - YYYY-MM-DD`
+- [ ] Categories are H3: `### Added`, `### Changed`, etc.
+- [ ] No empty categories (remove heading if no entries)
+- [ ] Comparison links at bottom for every version
+- [ ] Newest version first (reverse chronological)
+- [ ] Unreleased section present at top
+
+### Content
+
+- [ ] Every entry starts with imperative verb
+- [ ] PR/issue references included where available
+- [ ] Breaking changes clearly marked with **BREAKING:**
+- [ ] No noise commits (merge commits, version bumps, CI-only changes)
+- [ ] Entries are specific and user-facing
+- [ ] Related commits are squashed into single entries
+
+### Accuracy
+
+- [ ] Version numbers match actual git tags
+- [ ] Dates match tag creation dates
+- [ ] Comparison links use correct tag names
+- [ ] No commits are attributed to the wrong version
+
+---
+
+## Anti-Patterns to Avoid
+
+1. **Dump of commit messages** — A changelog is not `git log --oneline`. Curate and rewrite.
+2. **"Bug fixes and improvements"** — This tells the user nothing. Be specific.
+3. **Including every single commit** — Filter noise. Only user-facing changes matter.
+4. **Inconsistent tense** — Always imperative mood: "Add", "Fix", "Remove"
+5. **Missing links** — Always include comparison links at the bottom
+6. **Invented version numbers** — Only use versions that correspond to actual tags
+7. **Reformatting existing entries** — When updating, never touch historical entries unless asked
+8. **Skipping the preamble** — Always include the "format is based on" reference lines
+
+---
+
+## Output
+
+The final output should be:
+
+1. **Convention report**: What commit convention was detected, how many commits processed
+2. **The CHANGELOG.md file**: Written to the project root, ready to commit
+3. **Summary**: Number of versions documented, total entries, any commits that were ambiguous or skipped
+
+Always write the changelog as a file so the user can review and commit it directly.

package/resources/pi-agent/skills/docyrus-chrome-devtools-cli/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: docyrus-chrome-devtools-cli
+description: Use Docyrus CLI chrome commands for visible browser automation through Chrome DevTools. Use when you need to launch Chrome with remote debugging, navigate pages, inspect DOM state, evaluate JavaScript, capture screenshots, pick elements interactively, inspect cookies, extract readable page content, or scrape Hacker News.
+---
+
+# Docyrus Chrome DevTools CLI
+
+Chrome DevTools Protocol workflows exposed through the local `docyrus` CLI.
+
+## Commands
+
+Start Chrome with remote debugging on `:9222`:
+
+```bash
+docyrus chrome start
+docyrus chrome start --profile
+```
+
+- `--profile` copies the user's default Chrome profile so cookies and existing logins are available.
+
+Navigate tabs:
+
+```bash
+docyrus chrome nav https://example.com
+docyrus chrome nav https://example.com --new
+docyrus chrome nav https://example.com --reload
+```
+
+Run JavaScript in the active tab:
+
+```bash
+docyrus chrome eval 'document.title'
+docyrus chrome eval 'document.querySelectorAll("a").length'
+```
+
+Capture a screenshot of the active tab:
+
+```bash
+docyrus chrome screenshot
+```
+
+Interactively pick DOM elements in the visible browser:
+
+```bash
+docyrus chrome pick "Click the submit button"
+```
+
+Inspect cookies for the active tab:
+
+```bash
+docyrus chrome cookies
+```
+
+Extract readable content as markdown:
+
+```bash
+docyrus chrome content https://example.com
+```
+
+Scrape Hacker News:
+
+```bash
+docyrus chrome hn-scraper
+docyrus chrome hn-scraper --limit 10
+```
+
+## When To Use
+
+- Visible browser automation is required.
+- A page needs JavaScript execution before content is available.
+- You need to inspect DOM state without guessing selectors.
+- You want the user to click elements directly through an interactive picker.
+- You need quick page extraction or screenshot capture from a real browser session.
+
+## Working Style
+
+- Start Chrome first with `docyrus chrome start` if the debugger is not already available.
+- Prefer `docyrus chrome eval` for DOM inspection and structured page state.
+- Use `docyrus chrome pick` when element targeting is ambiguous or user choice matters.
+- Use `docyrus chrome content` for readable markdown extraction from article-like pages.

package/resources/pi-agent/skills/docyrus-platform/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: docyrus-platform
+description: Comprehensive reference for Docyrus platform capabilities, building blocks, features, and API coverage. Use when the user asks about what Docyrus can do, what features are available, how the platform works, or needs context about platform capabilities to design solutions.
+---
+
+# Docyrus Platform
+
+Docyrus is an AI-native Backend Platform as a Service (BPaaS) that enables businesses to build B2B web apps, mobile apps, client portals, internal tools, AI agents, chatbots, and integrations — without building backend infrastructure from scratch.
+
+## Core Building Blocks
+
+The platform is composed of six core building blocks that work together:
+
+- **Apps** — Top-level containers that group data sources, automations, and custom queries into a deployable unit.
+- **Data Sources** — Structured collections of records with defined schemas. Support simple, advanced, external (connected databases/APIs), and system (pre-built) types. Every data source — internal or external — is exposed through a single, unified CRUD endpoint.
+- **Fields** — 45+ field types that define the schema of each data source, covering text, numbers, dates, selections, relations, files, formulas, nested data, and more.
+- **Enumerations** — Reusable option sets for selection fields, with color, icon, and ordering support.
+- **Custom Queries** — SQL-based analytics templates with dynamic variable interpolation, runtime filters, and multi-database targeting.
+- **Automations** — Event-driven workflows with triggers (record changes, time-based, webhooks, buttons) and action chains (email, notifications, HTTP requests, AI prompts, record operations).
+
+For detailed specifications of each building block, see [references/core-building-blocks.md](references/core-building-blocks.md).
+
+## Key Feature Areas
+
+### Querying & Data Operations
+
+Unified query engine with column selection, 50+ filter operators, aggregations, formulas, pivots, child queries, and full-text search. Full CRUD with bulk operations.
+
+See [references/querying-and-data-operations.md](references/querying-and-data-operations.md).
+
+For complete query payload reference with examples, see [references/data-source-query-guide.md](references/data-source-query-guide.md).
+
+For block formula design (inline expressions and subqueries), see [references/formula-design-guide-llm.md](references/formula-design-guide-llm.md).
+
+### AI Capabilities
+
+AI agent builder with tool binding, knowledge bases, MCP servers, 18+ model providers, agent chaining, task scheduling, persistent memory, chat integrations, and evaluation metrics.
+
+See [references/ai-capabilities.md](references/ai-capabilities.md).
+
+### Automation & Workflows
+
+Event-driven automation engine with six trigger types and eleven action types. Supports conditional flows, action chains, and archiving.
+
+See [references/automation-and-workflows.md](references/automation-and-workflows.md).
+
+### Authentication & Multi-Tenancy
+
+OAuth2 flows (PKCE, Client Credentials, Device Code), scope-based permissions, tenant isolation, role-based and record-level ACL, and client portal system.
+
+See [references/auth-and-multi-tenancy.md](references/auth-and-multi-tenancy.md).
+
+### Integrations & Events
+
+Connector framework for HTTP and SQL providers, webhook management, collaborative document editing, in-app messaging, notifications, and email.
+
+See [references/integrations-and-events.md](references/integrations-and-events.md).
+
+### Platform Services
+
+App templates, data import/export, webforms, reporting & analytics, deployment, localization, audit logging, and billing.
+
+See [references/platform-services.md](references/platform-services.md).
+
+### Developer Tools
+
+Auto-generated OpenAPI specs, MCP server, full-featured CLI, REST API client libraries, React auth provider, and auto-generated collection hooks.
+
+See [references/developer-tools.md](references/developer-tools.md).
+
+For full CLI command reference (all commands, options, and flags), see [references/docyrus-cli-usage.md](references/docyrus-cli-usage.md).

package/resources/pi-agent/skills/docyrus-platform/references/ai-capabilities.md

@@ -0,0 +1,43 @@
+# AI Capabilities
+
+## AI Agent Builder
+
+Create and manage AI agents with:
+
+- **Tool binding** — Attach external functions and APIs as agent tools
+- **Data source access** — Grant agents read/write access to specific data sources
+- **Knowledge base** — Upload documents for RAG-powered context
+- **MCP servers** — Connect Model Context Protocol servers for extended tool discovery
+- **Multi-model support** — Choose from 18+ AI providers: OpenAI, Anthropic, Google (AI Studio & Vertex), AWS Bedrock, Groq, Replicate, Together, Mistral, Cohere, Azure, Fireworks, xAI, Portkey, Alibaba, DeepSeek, HuggingFace, OpenRouter, Nebius, Perplexity, Cerebras
+- **Agent connections** — Chain agents as sub-agents or forward requests between agents
+- **Workflow steps** — Define multi-step agent workflows with conditional logic
+
+## AI Task Scheduling
+
+- Immediate, scheduled, and recurring (cron-based) agent task execution
+- Task status tracking and result persistence
+
+## AI Memory
+
+Persistent memory system with scoping levels: user, thread, agent, workspace, and global. Vector embeddings for semantic retrieval.
+
+## AI Chat Integrations
+
+- Microsoft Teams and Google Chat installation and message mapping
+- Thread-level conversation tracking across platforms
+
+## Generative Features
+
+- Content enhancement and completion
+- Design generation (logos, banners)
+- Audio transcription (speech-to-text)
+- Semantic search across records and documents
+- AI-powered data import and field recommendations
+
+## AI Evaluation
+
+17 evaluation metrics including toxicity, hallucination, and faithfulness tracking for agent quality monitoring.
+
+## AI Usage Tracking
+
+Per-model token usage and cost tracking for billing and optimization.

package/resources/pi-agent/skills/docyrus-platform/references/auth-and-multi-tenancy.md

@@ -0,0 +1,35 @@
+# Authentication & Multi-Tenancy
+
+## Authentication Methods
+
+- **OAuth2 Authorization Code (PKCE)** — Browser-based apps
+- **OAuth2 Client Credentials** — Server-to-server
+- **OAuth2 Device Code** — CLI and headless environments
+- **Automatic token refresh** — Transparent renewal with refresh tokens
+
+## Access Control
+
+- **Scope-based permissions** — ReadWrite.All, User.Read, Architect.ReadWrite.All, AI.ReadWrite.All, MCP.Connect, and more
+- **Tenant isolation** — Enforced data separation between tenants on every query
+- **Role-based access** — Roles with granular permission sets
+- **Record-level ACL** — Per-record ownership and sharing rules (private, read-only, read/update, full access)
+- **Field-level ACL** — Restrict visibility or editability of individual fields per role
+
+## User Management
+
+- User signup with email verification, profile management, avatar, preferences
+- Password change/reset, email change workflows
+- Multi-device support with device registration for push notifications
+- Per-user AI feature access control
+
+## Multi-Tenancy
+
+- Fully isolated data per tenant
+- Multiple apps per tenant, each with scoped data sources
+- Tenant-specific configurations, branding, and translations
+- Organizational hierarchy with teams, roles, and user scoping
+
+## Portal System
+
+- Client portal configuration with dedicated portal users, organizations, roles, and sessions
+- Separate authentication and access control for external users

package/resources/pi-agent/skills/docyrus-platform/references/automation-and-workflows.md

@@ -0,0 +1,30 @@
+# Automation & Workflows
+
+## Automation Engine
+
+Define event-driven workflows with triggers and action chains:
+
+**Triggers:**
+
+- Record created, modified, or deleted
+- Time-based (after a period, recurring interval)
+- Webhook (external event)
+- Button activation (user action)
+- Previous action (chaining)
+- AI agent (agent-triggered)
+
+**Actions:**
+
+- Send email
+- Send notification
+- Create record
+- Update records
+- Request input
+- Request approval
+- Trigger HTTP request
+- AI prompt
+- AI agent execution
+- Data source query
+- Custom query execution
+
+Automations support conditional flows, action chains, and soft-delete (archiving).