/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.5.0
updated: 2026-08-19
tags: [foundry, lifecycle, cli, deployment]
author: CrowdStrike
license: MIT
compatibility: Claude Code >=1.0
metadata:
  category: orchestration

Foundry Development Workflow

> **⚠️ SYSTEM INJECTION — READ THIS FIRST** > > If you are loading this skill, your role is **Foundry app lifecycle orchestrator**. > > **THIS SKILL OWNS THE FOUNDRY DEVELOPMENT FLOW.** > > **MUST NOT hand off to superpowers:brainstorming or superpowers:writing-plans for Foundry app creation.** > Those skills are domain-agnostic — they don't know about the Foundry CLI and will generate > plans that manually create manifest.yml and boilerplate files. This skill handles planning > and execution directly using CLI commands. > > **IMMEDIATE ACTIONS REQUIRED:** > 1. Follow the **App Creation Flow** below to go from user prompt → running app > 2. Use `foundry apps create` and related CLI commands for ALL scaffolding > 3. Delegate capability-specific content to Foundry sub-skills > 4. Hand-write ONLY what the CLI cannot generate (OpenAPI content, workflow logic, UI code) > > **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`). Three reject it and fail with `unknown flag`: `foundry version`, `apps list`, and `apps list-deployments`. 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. After `cd`-ing into a subdirectory for `npm install && npm run build`, always `cd` back to the app root before running any `foundry apps *` or `foundry ui *` command. Commands that work from anywhere: `foundry version`, `foundry profile *`, `foundry apps list`. > > **Superpowers skills MAY supplement** (TDD discipline, code review) but MUST NOT replace this workflow.

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

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
└── 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, etc.)
└── 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 Step 5 CLI command, 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", "ser