# Fledge Workflows

> Discover and run repository-defined Fledge workflows without guessing commands.

- Skill: `corvidlabs/fledge-workflows` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add corvidlabs/fledge-workflows`
- Raw SKILL.md: https://api.skillmd.com/api/skills/corvidlabs/fledge-workflows/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: CorvidLabs (https://skillmd.com/u/corvidlabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/corvidlabs/fledge-workflows

---


# Fledge Workflows

Use Fledge first when working in a CorvidLabs repository. Treat the repository's own
tasks, lanes, plugins, and instructions as the source of truth. Fledge is the core CLI
(not a product plugin). Extra tools come from `fledge plugins install …` when a repository
needs them.

## Discover before running

Start from the repository root. Prefer machine-readable discovery when acting as an agent:

```sh
fledge --help
fledge introspect --json
fledge plugins list
fledge run --list --json
fledge lanes list --json
fledge work status --json
```

Use the documented task or lane that matches the change:

```sh
fledge run <task>
fledge lanes run <lane>
fledge lanes validate . --strict
```

If no appropriate Fledge task exists, report that fact and use the repository's documented
fallback; do not invent a new universal command. Prefer common lane names when present
(`pre-commit`, `check`, `verify`, `ci`) after listing—do not invent a `trust` lane name.

For agent runs, set non-interactive mode (`--non-interactive` / `--ni` or
`FLEDGE_NON_INTERACTIVE=1`) to avoid hanging on prompts. This mode accepts default confirmations; it is not a
permission check. Use it only for actions already authorized by the task.

## Select tools by capability

Prefer the current maintainer-designated release, including the latest RC when that is
the supported path forward. Do not downgrade to an older stable line just to avoid a
prerelease suffix. Check upstream release guidance when installing or upgrading; keep
reproducible pins in the repository and CI rather than in shared skills. An installed
version tells you which commands can run now, not which version should be preferred.

Use `trust` for repositories with a composed Trust gate and `spec-sync-routing` for
SpecSync lifecycle guidance. Preserve existing pins until an upgrade is in scope.

## Work deliberately

`fledge work start` takes a **name** argument that Fledge sanitizes and formats (default
shape is often `{author}/{type}/{name}` from config—pass a short slug such as `my-change`,
not a prebuilt `feat/my-change` path, unless you override with `--prefix`):

```sh
fledge work start my-change -t feat
fledge work status --json
# Stage and commit non-interactively (needs -m or --ai; use --all if nothing staged)
fledge work commit -m "feat: describe the change" --all
fledge work push
```

`work start` fails on a dirty tree—commit or stash first. `work push` refuses the default
branch (`main`/`master`). Before a commit or push, run the smallest relevant
repository-defined verification lane. Before a release, run the repository-defined
**verify / release-style** lane from the **committed** tree (discover via
`fledge lanes list --json`). Version bumps use `fledge release <bump>` when the repo uses
it—that is separate from `fledge lanes run`.

## Keep evidence honest

Record which committed revision was checked. A local result on an earlier tree does not
prove a later commit. Treat hosted CI as the final confirmation when the repository
requires it, and distinguish still-running checks from stale results on an old head.

For multi-agent session work, use `agent-coordination`. For CI/tag readiness language, use
`ci-release-hygiene`.