festack: A Shareable Agent Stack for Field Engineering

Most of my week as a Field Engineer happens in the messy middle: researching a prospect before a first call, digging into whether a product capability actually fits a customer’s constraint, debugging a failing integration live on a screen share, spinning up a prototype app to make an abstract architecture tangible, and writing the business case that helps a champion sell internally.

Engineering-oriented agent stacks are great at the last mile — code, tests, deploys. But they’re weaker at everything that happens before anyone opens an IDE: alignment, research, packaging, and the human checkpoints that keep client-facing output from reading like generic AI text.

festack is what I built to close that gap. It’s a vendor-neutral workflow stack for Solution Architects and Field Engineers — the same machinery a good engineering stack uses (multi-model debate, setup skills, retro and continual learning), just pointed at the engagement lifecycle instead of a git diff.

I’ve shared it on GitHub so others can contribute or leverage.

The gap: engineering stacks vs field work

Most agent tooling and harnesses assume code as the deliverable, but field work operates with key differences:

• The artifact might be a brief, a diagram, a demo script, or a one-pager — not a pull request.
• Quality means citations, confidence, and audience fit, not just passing tests.
• Context is per engagement: who the account is, what was promised last week, what shipped to the client yesterday.
• You need human checkpoints at scope and build approval. Not because agents can’t do the work — because a wrong guess in front of a client costs more than a wrong guess in a codebase.

What I want are composable skills relevant for field engineering — each focused on its deliverable — plus an easy routing system for days when I’m too busy to remember which slash command I need.

What festack is

festack is a plugin: skills, agents, hooks, and scripts that install into Cursor, Claude Code, or Codex. The core skills ship with no company or product defaults — your platform, sources, competitors, and voice all live in one place ($FESTACK_HOME/profile.md), so the same stack works whether you’re selling a data platform or an AI dev tool.

Three ideas hold it together:

1. Lazy front door. Type /festack, describe the situation once. Narrow asks route to a single skill; broad outcomes hand off to festack-delivery-agent, which picks the right playbook and runs it.
2. Vendor-neutral core, local wiring. Skills ask for neutral capabilities like research.account or create.client_doc. Your capabilities.yaml decides which MCP server or skill actually handles each one.
3. Engagement ledger. A log and memory of work being tracked per account under $FESTACK_HOME/engagements/ — a brief of curated facts plus an append-only log of receipts. Come back Monday and pick up where you left off without re-explaining the account.

How the pieces fit: skills, playbooks, and ledger

There are three primitives that do different jobs:

• Skills are single-deliverable workflows — /discovery, /client-debug, /demo, /doc, /compete, and the rest. Call one directly when you know what you need, or let a playbook invoke them in sequence.
• Playbooks are multi-step recipes — account-prep, demo-design, competitive-poc, and others. festack-delivery-agent picks one for broad asks, resolves each step through the capability registry, and carries state between steps.
• The engagement ledger is per-account memory: a curated brief.md, an append-only log.md, and quick captures via /festack log.

Configuration — profile, model roles, capabilities — feeds all three. The skills stay vendor-neutral; your MCP wiring and company sources arrive through capabilities.yaml and profile.md.

What a playbook actually does

A skill does one job: research this account, answer this product question, design this demo.

A playbook chains those jobs toward a whole outcome. Say I type: “Prep me for this meeting with the BU stakeholder on agentic automation for XYZ.” That’s not one skill — it’s the account-prep playbook below.

The delivery agent runs each step and passes a handoff payload forward: what was learned, sources, confidence, open questions, and what should run next. This is also why I don’t need to remember whether discovery comes before alignment — the sequence is written down once, without naming my company’s CRM or doc system anywhere.

What the ledger actually does

Skills and playbooks get the work done. The ledger is what remembers.

As a field engineer I’m constantly switching context — different accounts, different tasks on each account. Memory and a durable record matter. I can’t re-brief festack from scratch every time I jump from a Monday prep call to a Wednesday debug thread on another client. When an ask names an account — “where were we on XYZ?”, “prep me for Thursday’s call” — festack resolves or creates an engagement folder for it:

• brief.md — one page of curated facts: stakeholders, goals, constraints, what we currently believe is true. Facts get superseded when reality changes; it’s not a transcript dump.
• log.md — append-only receipts: routing decisions, gate answers, outbound sends, quick notes.

Resume is always announced. /festack tells you which engagement it picked, when you last touched it, and what the next step was. After a hallway chat I can type /festack log "Sarah cares about egress costs — revisit in the proposal" and that line is waiting for me next time.

/handoff packages the whole ledger into a snapshot a colleague can pick up cold. /retro closes an engagement out and feeds the durable lessons into /learn.

# XYZ Corp — agentic automation eval

## Current picture
- BU stakeholder: Sarah L. (automation lead), technical
- Pain: manual triage workflow, ~4 FTE equivalent
- Evaluating us vs incumbent RPA vendor
- Budget frozen until Q3 unless TCO case lands

## What we've promised
- Architecture walkthrough Thursday (not live demo — gate decision 06-28)
- TCO one-pager to follow

## Next step
> Send revised proposal with egress cost section

Why it asks so many questions (on purpose)

festack leans heavily on AskQuestion at real decision points, and that’s deliberate.

Skills resolve observable facts themselves and pick reversible defaults on their own. The questions are saved for genuine forks: scope, audience, success criteria, risk, and build approval. Every gate leaves a Gate receipt, so I can always trace why the work went the direction it did.

Many field tasks don’t have a crisp pass/fail bar like shipping a feature and running tests. Success is audience fit, scope, and whether the client can actually use what you produced — harder to verify after the fact. Coding-oriented agent workflows tend to skip upfront questioning and brainstorming; festack biases the other way. I’d much rather answer one focused question early than discover halfway through a /demo build that the agent assumed a technical audience when the room is all executives.

Keeping the stack from drifting

festack also ships contract tests — not customer acceptance tests, and not “did the demo work in the room.” They’re automated checks that the plugin still hangs together: routing points at real skills, playbook steps use valid capability names, gates follow the same AskQuestion rules, and install.sh still wires the layout Cursor and Claude expect.

When someone edits a skill or adds a playbook step, scripts/test.sh fails if those internal agreements break — before the next teammate installs a broken stack. Field usage surfaces what to fix; the tests keep the wiring consistent release to release.

How routing works

The mental model is close to a router agent in software: classify intent, pick the right depth, and carry state only when the job spans phases.

Narrow example from my week: a customer asks on a call whether feature X supports workload Y. That’s /client-debug — one question, cited answer, confidence stated. No orchestration theatre.

Broad example: “prep me for this meeting with the BU stakeholder on agentic automation for XYZ.” That’s multi-phase — discovery, maybe alignment, packaging, review. festack-delivery-agent owns the thread, picks the playbook, and resolves capabilities along the way.

One more pattern worth knowing: “design a demo that shows faster batch ingest, then help me build it.” /demo owns the design and debate gates; /autopilot only runs after I explicitly approve the scope. The stack is deliberately bad at inventing builds from vague asks. That’s a feature.

A week in the stack (personal)

Here is how the same install covers the variety I mentioned — without maintaining separate prompt files for each task type.

Client and account research

Before a first meeting I run /discovery or hand a broad ask to /festack — something like “prep me for this meeting with the BU stakeholder on agentic automation build for XYZ.” The skill pulls from profile-declared sources — public docs, internal search, CRM hints wired through capabilities — and outputs a structured picture with citations. When I only have thirty minutes, I still get something I can skim on the way to the call.

Deep product research

Product questions are not all equal. “Does the API support OAuth device flow?” is /client-debug. “Compare our approach to how Customer Z runs inference today, and draft something I can send their architect” routes through the delivery agent: facts first, packaging second. The routing table encodes that distinction so I do not accidentally write a ten-page doc when I needed a two-paragraph answer.

Debug and live support

Clients come with tricky technical bugs. These need multiple reviewers and research — synthesized into the easiest writeup to understand.

Prototype apps and demos

/demo is the flagship path: multi-model debate, decision gates, canvas understanding — before build. /autopilot executes an approved design phase by phase. I have used this for notebook demos, small React sandboxes, and slide-backed walkthroughs. The stack does not care which build adapter you wire in capabilities; it cares that design approval happened first.

Business cases and competitive positioning

/compete for fast “why us over X” with profile-supplied differentiators. Broader asks — battlecards, leave-behinds, proof assets — go through the delivery agent so research, packaging, and review stay sequenced. /review-work stress-tests a draft before it leaves my machine.

Across all of this, the engagement ledger means I can /festack log "call with Sarah — they care about egress costs" after a hallway conversation and have it show up next time I resume that account.

Configuration: profile, models, and capabilities

After install, /setup-festack is the initial setup — one guided pass to wire your environment. Under the hood, festack separates three concerns:

That walkthrough covers all three layers. Focused commands — /personalize, /setup-models, /setup-capabilities — cover the case where you only want to refresh one layer.

The profile: one file, all your context

The core skills ship with no company or product defaults. Everything specific to you lives in profile.md: your role and vendor, your differentiators and named competitors (which feed /compete), where to research first, who’s usually in the room, and how you write — down to banned phrases and writing samples that /fe-deslop uses to match your voice.

You don’t need to fill it all in on day one. Blank fields are fine; /learn deepens the profile from real engagements over time.

This is the part I find most interesting in practice: two field engineers on the same team run identical festack skills but get different output — one positions a data platform, the other an AI dev tool — purely because their profiles differ. The skills stay portable. The profile is the local truth.

Capabilities: the bridge to your internal tools

Playbooks never say “search Glean” or “query Salesforce.” They ask for neutral slots like research.account or fetch.open_risks, and capabilities.yaml decides which installed provider answers — a core festack skill, a company skill pack, or an MCP server.

Browse the two files below to see what this looks like filled in. The short version: preferred providers are tried in order, every provider returns a structured handoff (summary, sources, confidence), and if nothing is wired for a slot, festack says so instead of pretending your CRM exists.

Capability samples ship for common field stacks (Databricks, Cursor AI, OpenAI-shaped teams). Copy the closest one, rename providers to match what you actually have, and run /setup-capabilities to validate.

# festack profile

## Identity
- Role: Field Engineer
- Company: <your platform vendor>

## What you sell or support
- Differentiators: governed data + AI on one platform,
  serverless cost model
- Named competitors: <incumbent A>, <hyperscaler B>

## Research resources
- Public docs: docs.yourcompany.com
- Internal KB: Glean
- CRM: Salesforce (account notes)

## Voice profile
- Tone: casual-but-sharp
- Em-dashes: ban
- Writing samples: [2–3 paragraphs of your writing]

The Setup Package

Sharing agent configuration is awkward. The plugin source is safe to put on GitHub; your filled-in profile, engagement ledgers, and company MCP wiring are not.

So festack ships as a GitHub repo you clone — with:

• festack/ — plugin source (skills, agents, hooks, scripts)
• config-templates/ — blank profile, model roles, capability samples, Cursor hooks merge snippet
• install.sh — one-command install for your host
• SETUP-GUIDE.md — recipient instructions

The installer symlinks (or copies, with --copy) skills and agents into the host’s config directory, places the hook scripts, and points you at /setup-festack. Recipients create their own profile on first run — so there’s no way to accidentally ship client names or internal URLs along with the tool.

Optional: engagement hooks (Cursor)

For client-facing work, festack can watch outbound sends made through agent tools — email, Drive, Slack — and append awareness receipts to the engagement ledger. It never blocks; it prints one line when something ships without review and logs the outbound event.

This is optional but recommended. On Cursor, merge config-templates/cursor-hooks.merge.json into ~/.cursor/hooks.json and set FESTACK_ORG_DOMAIN so external vs internal recipients are detected correctly.

Command palette (the ones I actually reach for)

Full palette is in the plugin README. These are the commands that earned permanent muscle memory:

Two commands worth highlighting:

• festack-debate is an internal engine, not a slash command. Skills compose multi-model runners and reviewers when the work benefits from diverse lenses — demo design, competitive positioning, deliverable critique.
• /fe-deslop is the anti-slop prose standard. Every writing skill composes it; I also run it directly before pasting into a client doc.

Open source

festack is on GitHub: github.com/casper7995/festack — plugin source, install scripts, config templates, samples, and contract tests. Clone it, run ./install.sh cursor (or claude / codex), then /setup-festack to wire your own profile and capabilities. Your engagements stay local under $FESTACK_HOME.

Issues and PRs welcome. The architecture and install model above are the contract; the repo is where it ships.

Closing

Field engineering isn’t “coding with extra slides.” It’s a lifecycle — research, align, design, package, review, sometimes build — and agent tooling should respect that shape.

festack is my attempt to bring engineering-grade agent patterns to that lifecycle without locking anyone to one vendor or one host. The setup package is how I make it real for teammates; open source is how I hope others make it better.

If you’re building something similar — or want to stress-test the routing model against your own stack — I’d genuinely like to hear what resonates and what’s missing.