/development-workflow

name: development-workflow
description: Orchestrates the complete Falcon Foundry app lifecycle from requirements through deployment. TRIGGER when user asks to "create a Foundry app", "build a Foundry app", "plan a Foundry app", runs any `foundry apps` CLI command, or discusses Foundry app architecture. DO NOT TRIGGER when user is working on a specific capability (UI, function, workflow, collection) within an existing app — use the appropriate sub-skill instead. This skill OWNS the entire Foundry development flow. Do not delegate Foundry app creation to superpowers:brainstorming or superpowers:writing-plans — those skills do not know about the Foundry CLI.
version: 1.7.1
updated: 2026-11-10
tags: [foundry, lifecycle, cli, deployment]
author: CrowdStrike
license: MIT
compatibility: Claude Code >=1.0
metadata:
  category: orchestration

Foundry Development Workflow

> This skill owns the Foundry development flow. Follow the **App Creation Flow** below from user prompt to running app, scaffold with `foundry apps create` and related CLI commands, delegate capability-specific content to the Foundry sub-skills, and hand-write only what the CLI can't generate (OpenAPI content, workflow logic, UI code). > > Don't hand Foundry app creation to superpowers:brainstorming or superpowers:writing-plans. They don't know the Foundry CLI and produce plans that hand-write manifest.yml and boilerplate files. They can supplement this flow (TDD discipline, code review), not replace it. > > **CRITICAL: add `--no-prompt` to every command that accepts it** — without it, interactive prompts cause `Error: EOF`. The `create`, `validate`, `deploy`, `release`, and `delete` commands all accept it (`apps delete` also needs `--force-delete`). These reject it and fail with `unknown flag`: `foundry version`, `apps list`, `apps list-deployments`, `ui extensions list-sockets`, and `auth scopes list`. Verify with `foundry <command> --help`. When a command fails, MUST NOT fall back to `mkdir` — fix the command and retry. > > **CRITICAL: All `foundry` app commands MUST run from the app root directory** (where `manifest.yml` lives). The CLI resolves manifest paths relative to `os.Getwd()`, not relative to the manifest's location. Running `foundry apps validate`, `foundry apps deploy`, or `foundry ui run` from a subdirectory (e.g., `ui/extensions/my-ext/`) causes doubled paths and misleading "file not found" errors. Commands that work from anywhere: `foundry version`, `foundry profile *`, `foundry apps list`.

This skill coordinates the full Falcon Foundry app lifecycle — from parsing requirements through scaffolding, implementation, and deployment. It delegates capability-specific work to sub-skills that know the platform details.

Decision Tree

What does the user need?

Create a new Foundry app
└── Follow the App Creation Flow below

Upgrade a template-installed app
└── app-upgrades

Audit an existing app for anti-patterns
└── app-audit

Add a capability to an existing app
├── API integration       → api-integrations
├── Workflow              → workflows-development
├── UI page/extension     → ui-development
├── Function              → functions-development
├── Collection            → collections-development
├── AI agent / knowledge base → ai-agents-development
└── Falcon API from funcs → functions-falcon-api

Execute / test a deployed function
├── "run my function", "execute function"     → functions-development
├── "check execution status", "exec status"   → functions-development
├── "get function logs", "show logs"          → functions-development
├── "list executions"                         → functions-development
├── "test my function" (function tests.yml)   → functions-development
└── "run tests", "test cases"                 → functions-development

Debug a function failure
├── "debug my function", "why did it fail"    → debugging-workflows
├── "function returning errors"               → debugging-workflows
└── "no logs available"                       → debugging-workflows

Implement a known pattern (pagination, enrichment, ingestion)
└── Search use-cases/*.md for matching pattern → load for context

Debug / troubleshoot      → debugging-workflows
Security review           → security-patterns
E2E testing / Playwright  → e2e-testing

Standalone Fusion workflow (no app — trigger + existing actions only)
└── fusion-redirect (declines and points to the Falcon Fusion plugin)

Routing When Sub-Skills Are Not Registered

Sub-skills live beside this one as `../<name>/SKILL.md`. On a single-entry-point install only this skill is discoverable, so capability-level requests land here — that is intended, not a mis-route. Read the sub-skill file from disk before writing any capability content, then:

• **`manifest.yml` already present** — skip Steps 1-2 and Step 4. Run the Step 3 prerequisite check, add the capability with its command from **Capability Create Commands** in [references/advanced-patterns.md](references/advanced-patterns.md), and follow Manifest Coordination.
• **No app yet** — run the full App Creation Flow.

This never overrides the fusion-redirect skill: a standalone Fusion workflow request is still a redirect, not a capability to add.

App Creation Flow

Step 1: Parse Requirements

Map user requests to Foundry capabilities:

| User Says | Capability | CLI Command | |-----------|-----------|-------------| | "API integration", "connect to X API" | API Integration | `foundry api-integrations create` | | "workflow", "on-demand", "automate" | Workflow | `foundry workflows create` | | "UI", "page", "dashboard" | UI Page | `foundry ui pages create` | | "extension", "sidebar", "widget" | UI Extension | `foundry ui extensions create` | | "function", "serverless", "backend" | Function | `foundry functions create` | | "store data", "collection", "database" | Collection | `foundry collections create` | | "AI agent", "Charlotte agent", "agentic" | AI Agent | `foundry agents create` | | "knowled