App context

/ff-context creates or updates .fixtureframe/APP_CONTEXT.md: reusable knowledge about the app, its users, feature relationships, demonstration data and evidence gaps. It is a coding-agent skill, not a terminal command. There is no ff context subcommand.

Install the agent skills, open your agent in the Fixtureframe workspace, and use:

/ff-context

For a more specific starting point:

/ff-context Use the staging environment and its cached survey. The product source
is C:/work/acme-app. Create or update .fixtureframe/APP_CONTEXT.md for walkthroughs
aimed at new operators. Identify the main jobs, related features, representative
detail views, suitable demo data and gaps that need targeted discovery.

For URL-only work, omit the source directory and provide the app's URL and environment. A codebase, persona document or complete feature list is optional. The agent gathers a draft you can correct.

Where it fits

An initial ff survey provides observed screen vocabulary. /ff-context connects that evidence to what people accomplish in the app. Missing record details may lead to a targeted survey using verified --seed paths; rerun /ff-context to incorporate the findings. /ff-suggest then ranks useful journeys, and /ff-script chooses the scope of an individual walkthrough.

Follow From sign-in to a published flow for the complete sequence and survey switches.

What the context should contain

Distinguish observed facts, source-supported behavior, user-stated intent and unknowns. A local checkout is not proof of what is deployed, and a missing survey entry does not prove a feature is absent.

Optional template

Use the parts that help your app. You can give these facts in a conversation instead of filling out the file yourself.

# App context

## Product and evidence

- Purpose:
- Environment and target URL:
- Source and documentation, if available:
- Evidence date, revision and signed-in role:

## People and jobs

- Persona and prior knowledge:
- Important questions and tasks:
- Terms and relationships between objects:

## Capabilities

| Area | User question | Representative proof | Evidence | Gap |
| ---- | ------------- | -------------------- | -------- | --- |

## Demonstration and replay

- Example records and required states:
- Data that should vary: names, emails, phone numbers, locations, branding, rows, inputs:
- Supported way to prepare that data before capture:
- Permitted actions and what each run leaves behind:
- Saved-session or adapter reference, without credentials:

## Editorial preferences

- Audience and outputs:
- Preferred depth or duration:
- Priorities and topics to defer:

Product labels remain unchanged. Record the need for suitable displayed data without copying real personal records or authentication tokens into this document. Context describes those needs; it does not implement data substitution or create application records by itself.

Keep app knowledge separate from a flow's brief

APP_CONTEXT.md is agent-readable Markdown, not CLI configuration. <slug>.plan.md describes one flow's proposed questions, proof and deferrals. <slug>.brief.yaml carries that flow's beats and their provenance. Adding a fact to app context does not confirm a new set of beats or authorize a capture or publication.

Update the context when the app, audience or environment changes. Preserve user corrections and keep unresolved gaps visible so the next walkthrough does not repeat the same assumptions.