ingest-spec
Ingest Spec
When to use
- After analyze-codebase, when you have a spec to parse
- When running as part of
run-testing-sessionpipeline (Stage 2) - When adding new scenarios to an existing test plan
Inputs
- Spec content: a
.featurefile path or pasted plain-English test cases - (Optional)
docs/playwright-spec-testing/project-context.mdfor context
What it does
Parse raw spec input into structured scenarios and save to docs/playwright-spec-testing/parsed-spec.md.
Phase 1: Identify input format
Gherkin has Feature:, Scenario:, Given/When/Then keywords.
Plain English has numbered steps, "Expected:" sections, or prose descriptions.
Phase 2: Parse into scenarios
For each scenario, extract:
- Name: The scenario title
- Preconditions: Setup state (from Background/Given or Prerequisites)
- Steps: Ordered actions (from When/And or numbered steps)
- Expected outcomes: Assertions (from Then or Expected section)
- URL hints: Any URL path mentioned (e.g.,
/login,/dashboard)
For plain-English input, map prose to this structure. If something is ambiguous, preserve it verbatim in a "Notes" field — do NOT infer steps not in the spec.
Phase 3: Write parsed-spec.md
Append to (or create) docs/playwright-spec-testing/parsed-spec.md:
# Test Plan
_Last updated: [DATE]_
---
## Scenario: [Name]
**Source:** [file path or "pasted input"]
**Format:** [Gherkin / Plain English]
### Preconditions
- [condition]
### Steps
1. [step]
### Expected Outcomes
- [outcome]
### URL Hints
- [url]
### Test File
_To be assigned by plan-tests_
### Exploration Report
_To be generated by explore-app_
### Status
- [ ] Planned
- [ ] Explored
- [ ] Generated
- [ ] Passing
Add one block per scenario. If parsed-spec.md already exists, append — do not overwrite.
Key Rules
- Never infer steps not in the spec
- Preserve all URLs verbatim
- Do not merge multiple scenarios into one
- Do not discard information
Output
docs/playwright-spec-testing/parsed-spec.md
Report when done:
- Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
- Number of scenarios parsed
- List of scenario names
- Any ambiguities noted
More from lautaroleonhardt/pst
analyze-codebase
Use when starting a Playwright testing session or when project structure is unknown. Scans the project for Playwright config, test conventions, routing, and tech stack. Writes output to docs/playwright-spec-testing/project-context.md.
9plan-tests
Use after explore-app to synthesize an exhaustive, human-reviewable test plan from exploration reports and project context. Reads all exploration/<slug>.md files, parsed-spec.md, and project-context.md. Outputs test-plan.md with full steps, assertions, and assigned test file paths.
9generate-tests
Use after plan-tests to write a Playwright test for one scenario by mechanically translating test-plan.md into Playwright API calls. Requires docs/playwright-spec-testing/test-plan.md. Writes the test file at the path assigned in the plan.
9debug-test
Use when a Playwright test is failing. Diagnoses the root cause and applies a minimal fix. Requires the failing test file path and the full error output.
9explore-app
Use after ingest-spec to walk through one scenario in the live app and capture real selectors and URLs. Requires a running app and a scenario from docs/playwright-spec-testing/parsed-spec.md. Writes output to docs/playwright-spec-testing/exploration/<scenario-slug>.md.
9run-testing-session
Use to run the full Playwright testing pipeline (analyze → ingest → plan → explore → generate → debug) with isolated subagent context per stage. Each stage is reviewed and fixed automatically. Requires a running target app and a spec input.
9