Hand a whole task to an AI assistant — and keep a paper trail

Agents & automation

Flicker's agent skills let you hand a whole development task to an AI assistant — in Claude Code, Pi, or Codex — and have it actually do the work: plan it, write the code, open a pull request, take it through review, and (with your go-ahead) ship it. You drive it with simple slash commands like /flicker-plan and /flicker-ship.

The difference from just chatting with an AI is the paper trail. As the agent works, it records each step in Flicker — the plan, what "done" means, what it changed, what review found. So the work isn't trapped in one chat window: you, a teammate, or a different agent can pick it up later and see exactly where things stand and why.

How it works

Four ideas. You don't have to manage them by hand — the skills do — but knowing them makes the rest of this page click.

Tickets

A ticket is one unit of work — a feature, a bug, a chore. It moves through a fixed set of states (backlog → selected_for_dev → in_progress → done), and everything the agent learns or produces hangs off of it. It's the thing you point a command at.

The task contract

Before writing any code, the agent writes a task contract: a short, explicit statement of what "done" looks like for this ticket — the acceptance criteria, scope, and anything intentionally left out. It's the agreement you approve up front. /flicker-implement builds against it, and /flicker-test checks the result against it, so the agent can't quietly drift from what you asked for.

Documents

Each ticket accumulates a chain of markdown documents, one per stage — so the reasoning and evidence live next to the work, not in a lost thread. Every write keeps the previous version, so you always have the latest and the full history.

There's a fixed document kind for each stage — feature_brief, task_contract, implementation_notes, test_verdict, release, and a few more. The Tickets docs define the full set.

documents are versioned — read the latest or the whole history 
$ flicker ticket document read 42 task_contract --json
$ flicker ticket document read 42 task_contract --history --json

Memory

Documents belong to one ticket; memory is the durable, searchable record that outlives any single ticket — decisions, findings, release records, and learnings. It's how the agent (or you) answers "why did we do it this way?" months later. /flicker-recall searches it and labels each result with its source, so an answer is traceable rather than a guess.

memory is durable evidence, not live task state 
$ flicker memory search "why we chose unnamed prepared statements" --json
$ flicker memory add "<finding or decision>" --title "<title>" --json
i
Current truth is the ticket's fields and the latest document; memory and older document versions are history — evidence of how the work got here, not the current state.

The workflows

Each command maps onto a stage of the workflow and writes its result back to Flicker:

  • /flicker-plan — search, adopt, or create tickets; write the planning documents (feature brief, plan consensus, task contract, design); record memory; and select approved work for development.
  • /flicker-implement — start the selected ticket (→ in_progress), implement its task contract on a feature branch behind a PR, and write implementation notes back to the ticket.
  • /flicker-test — drive the PR review loop (PR-Agent / the Claude review action via gh), write review and regression evidence, file child tickets for findings, and produce a test verdict. It never merges.
  • /flicker-release — verify readiness and write release evidence; merging (which deploys) requires explicit approval, then it completes the ticket.
  • /flicker-ship — the autonomous loop: pick up a selected ticket → implement → PR → review-until-clean → auto-merge, within safety rails (tests must be green; changes touching the database proxy, core infrastructure, billing, or migrations are never auto-merged — they escalate to a human).
  • /flicker-recall — search current tickets and documents plus historical memory, with source labels.

Install the skills

The playbook is embedded in the Flicker CLI. One command installs it into every coding harness you use — no monorepo clone required. The open methodology mirror lives at github.com/go9/flicker-workflow.

preferred: install via the Flicker CLI 
$ curl -fsSL https://flickercloud.com/install.sh | sh
$ flicker auth login <api-key>
$ flicker project use <project-slug>
$ flicker skill install --workflow --global
$ flicker doctor
# then restart Pi / Claude Code / Codex

Each harness gets the playbook in its native format:

  • Pi — real Agent Skills under ~/.pi/agent/skills/flicker-*/
  • Claude Code — skills under ~/.claude/skills/flicker-*/
  • Codex — a short managed pointer block in AGENTS.md plus the full contract at ~/.flicker-agent/shared/flicker-workflow.md. Your other AGENTS.md content outside the managed markers is never clobbered; the full workflow is not pasted into AGENTS.md.
✦

Optional npm installer

npx @flickercloud/agent-skills install … installs the same package content. Prefer the CLI path so flicker doctor compares against the embed your binary carries.

Updating

Updates are always explicit — nothing overwrites skills in the background. Refresh the CLI (new embed), re-run skill update, verify with doctor, then restart the client so it re-scans.

update the playbook 
$ curl -fsSL https://flickercloud.com/install.sh | sh
$ flicker skill update --workflow --global
$ flicker doctor
# restart Pi · Claude Code · Codex