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.

Updated September 2026. This guide reflects festack’s principles-first judgment system, current skill set, and engagement ledger v2.

festack is what I built to close that gap. It’s a vendor-neutral judgment system for Solution Architects and Field Engineers. It brings the same machinery a good engineering stack uses, including evidence gathering, multi-model review, decision gates, and continual learning, to the engagement lifecycle instead of a git diff.

I’ve shared it on GitHub so others can use it and contribute.

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.

I felt this most sharply when the facts were available but the judgment was still mine. I wanted composable field-engineering skills that could gather evidence and test assumptions while leaving scope, risk, and client commitments with the FE.

What festack is

festack is a plugin with skills, agents, hooks, and scripts for Cursor, Claude Code, and Codex. The core ships with no company or product defaults. Your platform, sources, competitors, and voice live in $FESTACK_HOME/profile.md, so the same system works whether you’re selling a data platform or an AI dev tool.

Three ideas hold it together:

1. Principles before procedure. Every multi-step task checks the same craft principles before substantive work. Those principles shape evidence, design, review, and the decisions that stay with the FE.
2. A lazy front door over practical architecture. Type /festack and describe the situation once. Narrow asks route to one skill. Broad outcomes go to festack-delivery-agent, which chooses a playbook and resolves each step through the capability registry.
3. Durable engagement memory. The ledger keeps a curated brief, append-only receipts, and an engagement index under $FESTACK_HOME/engagements/. I can come back Monday and continue without reconstructing the account from chat history.

The skills, playbooks, capability wiring, and ledger are still the machinery. The change is what governs them: festack now treats field work as a sequence of judgment calls, not a collection of prompts.

How the pieces fit: skills, playbooks, capabilities, and ledger

The judgment contract sits above four working parts:

• Skills own a deliverable or decision. /problem-frame structures a fuzzy ask, /solution-critic compares approaches, /poc scopes measurable proof, and /review-work pressure-tests an artifact. Direct skills such as /discovery, /client-debug, /demo, /doc, and /compete remain available when I already know what I need.
• Playbooks sequence capabilities toward an outcome. festack-delivery-agent chooses one for broad asks, carries structured handoffs between steps, and records why conditional work was skipped.
• Capability wiring maps neutral slots such as research.account or create.client_doc to a core skill, company skill, or MCP provider. The playbook describes the work without hardcoding my company’s stack.
• The engagement ledger keeps per-account memory: an index, a curated brief.md, an append-only log.md, and quick captures via /festack log.

The profile and model roles contextualize the work. The capability registry resolves tools, and the ledger stores engagement state.

The principles-first contract

For multi-step work, festack starts by reading the craft-principles index and every leaf whose trigger matches the task. The selected constraints follow the work through routing, panels, gates, and closeout. A principle only counts when it changes a specific choice.

The ten principles are deliberately concrete:

1. No Unverified Claims. Cite material claims, state uncertainty, and withhold what the evidence cannot support.
2. Falsifiable Differentiation. Tie comparisons to a client need, name what could disprove them, and say where the alternative is strong.
3. Probe Before You Ask. Run a cheap, safe test when it can settle an observable uncertainty.
4. FE Owns Irreversible Meaning. Put client-visible scope, risk, and commitment behind a structured decision gate.
5. Design Before Build. Settle the design and acceptance checks, then require explicit approval before /autopilot.
6. Whole Shapes, Not Flavors. Compare architectures with genuinely different boundaries, ownership, migration paths, and failure behavior.
7. Scrap When The Decision Is Wrong. Reopen the approach when review invalidates it instead of polishing the artifact.
8. Prove On The Real Artifact. Verify the rendered, running, or client-consumed result against its acceptance checks.
9. Skip With A Reason. Record why a conditional step did not run; silent skips are forbidden.
10. Lessons Become Structure. Route durable feedback through /learn and change a gate, rubric, profile, or playbook when repetition justifies it.

Together they stop a playbook from becoming ceremony. They tell the system when to verify, when to compare genuinely different options, when to discard a bad direction, and when repeated feedback should change the reusable workflow.

What a playbook actually does

Say I type: “Prep me for this meeting with the BU stakeholder on agentic automation for XYZ.” That spans research, alignment, and packaging, so the delivery agent selects the account-prep playbook below.

The delivery agent runs each step and passes a handoff payload forward: what was learned, sources, confidence, open questions, applied principles, and what should run next. Conditional steps that do not fit are recorded as skip: <reason>, so the agent cannot silently drop review or packaging work.

For judgment-heavy outcomes, the sequence is Explore → Plan → Review → Reply. Explore returns an evidence package. Plan names the recommendation and the design intensity. Review brings in /review-work or a debate panel when the stakes warrant it. Reply is drafted cleanly in my voice. I no longer need to remember whether discovery comes before alignment, and the playbook still avoids naming my company’s CRM or doc system.

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. 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:

• ENGAGEMENTS.md — the index of active and dormant engagements, including the last touch and next step.
• 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.

After 30 quiet days, festack marks an engagement dormant the next time it reads the index, but the engagement remains resumable. /handoff <engagement> packages the ledger into a snapshot a colleague can pick up cold. When I declare an outcome, /retro reads the full record, sends durable lessons through /learn, then moves the engagement into archive/.

# 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. If an uncertainty is testable, probe.feasibility runs the smallest safe check that can settle it before asking me. The questions are saved for genuine forks: scope, audience, success criteria, risk, and build approval. Every gate leaves a Gate receipt, so I can 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.

The governing rule is simple: the FE owns decisions that change irreversible client meaning. An agent can recommend a scope, expose risk, or test an assumption. It cannot silently decide what I commit to a client.

Matching effort to the decision

festack records the lowest design-intensity tier that protects the decision:

• Direct for one obvious, low-blast-radius approach.
• Structured compare for two or three known options with bounded trade-offs.
• Whole-shape panel for contested or client-visible architecture.
• Probe then decide when a cheap test can settle material uncertainty.
• Stakeholder gate when the choice changes scope, risk, or commitment.

The tiers can compose. A feasibility probe might narrow the evidence before a whole-shape panel, and the panel’s recommendation can still stop at a stakeholder gate.

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, principles are carried into handoffs, gates follow the same question rules, and scripts/install.sh still wires the layout each host expects.

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 the outcome, pick the smallest skill or playbook that fits, and carry state only when the job spans phases. The route is visible in a receipt, along with the setup state and principles that shaped the handoff.

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 route: That meeting-prep request spans discovery, alignment, packaging, and review. festack-delivery-agent owns the thread, picks the playbook, and carries the work through the four-stage judgment loop.

One more pattern worth knowing: “design a demo that shows faster batch ingest, then help me build it.” /demo owns the design and decision gates; /autopilot only runs after I explicitly approve the scope.

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, such as preparing for a security review with an unfamiliar account. 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.

When the client’s ask is still fuzzy, /problem-frame separates the pain, constraints, stakeholders, and unknowns before anyone proposes an architecture. If the question is which approach to take, /solution-critic compares distinct designs and makes the trade-offs explicit.

Debug and live support

On a live integration issue, I use a feasibility probe to test the smallest uncertain piece before suggesting a fix. That evidence makes the follow-up useful: what I observed, what it rules out, how confident I am, and what the client should try next.

Prototype apps and demos

/demo combines multi-model debate, decision gates, and visual design exploration 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.

For a formal proof, /poc turns the scope into a living contract with measurable exit criteria before implementation starts.

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. /learn carries the durable guidance forward.

Configuration: profile, models, capabilities, and lessons

After install, /setup-festack wires the first three setup concerns in one guided pass. Lessons are accumulated separately through /learn:

• Profile ($FESTACK_HOME/profile.md): who you are, what you sell, where to research, and how you write.
• Models (your host model config): which models play which roles in multi-model panels.
• Capabilities ($FESTACK_HOME/capabilities.md): which tools handle each neutral workflow slot.
• Lessons ($FESTACK_HOME/lessons.md): durable guidance captured by /learn.

That walkthrough covers the environment. 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. /personalize owns this file and can update one section without rerunning the full setup.

You don’t need to fill it all in on day one. Blank fields are fine. /learn writes reusable guidance to lessons.md, deduplicates it, and promotes stable facts or preferences into the profile when they belong there.

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.md decides which installed provider answers — a core festack skill, a company skill pack, or an MCP server. capabilities.yaml is an optional stricter format for teams that prefer it.

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 to capabilities.md or capabilities.yaml, 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:

• skills/ and agents/ — the shared plugin source
• hooks/ — host-specific last-look hook configuration and scripts
• samples/ — starter capability registries
• scripts/install.sh — fallback installer for Cursor, Claude Code, and Codex

For Claude Code, the preferred path is the bundled plugin marketplace:

/plugin marketplace add <path-or-git-url-of-festack>
/plugin install festack@festack

For Cursor, run scripts/install.sh cursor. The script installer is also the Claude Code fallback when plugins are restricted, and supports --copy for locked-down environments. It installs the shared skills, agents, and hook scripts. After installation, run /setup-festack. Recipients create their own profile on first run, so client names and internal URLs stay out of the plugin source.

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 hooks/cursor-hooks.json into ~/.cursor/hooks.json. Claude Code loads hooks/hooks.json through the plugin. Set FESTACK_ORG_DOMAIN so the hook can distinguish external recipients; if it cannot establish that a send is external, it stays silent.

Command palette (the ones I actually reach for)

Full palette is in the plugin README. I start at /festack when the work spans phases and call a direct skill when I already know the deliverable or decision.

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 a draft-time writing standard for replies and deliverables. The point is to write cleanly on the first pass, not bolt on a cleanup stage after the reasoning is done.

Open source

festack is on GitHub: github.com/casper7995/festack — plugin source, install scripts, samples, and contract tests. After installing, run /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 make judgment explicit across that lifecycle without locking anyone to one vendor or one host. Skills and playbooks do the work. Principles, feasibility probes, review, and decision gates keep the work grounded. The ledger makes the judgment durable enough for a teammate or my future self to inherit.

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.