Transcripted Summary
Now that we have our strategy, let's look at the mechanics of how these components interact with each other. By keeping our rules separate from our active worker personas, we can update the laws of our framework in one place without needing to rebuild or rewrite our agents.
# System Rules and Execution Prompts
Let's go to VS Code. Notice our project tree has been set up to reflect a real code base. We have separated our AI orchestration into two folders: system rules and execution prompts.
First, under core skills, we have the laws for our framework. This includes our API skills, assertion skills for handling hard versus soft assertions, and the POM creation skill. This creation file contains the engineering guardrails that dictate how elements are mapped to prioritize native locators like getByRole. It also has POM execution skills and test design skills.
Second, inside our agent core request folder, we have prepackaged our templates to include CLI request prompts for generating, healing, and planning. By maintaining these as reusable files inside our repo, we eliminate writing the same instructions over and over. This goes back to what we uncovered in station two — these instructions will help us bypass writing a wall of information for Claude Code. Now in our chat window, we only need to pass in a requirement ID or test case ID to trigger one of these templates.
# The Assembly Line Request
However, for this station, we are taking this a step further. Instead of executing three separate prompts for three different tools, I'm going to demonstrate our specialized assembly line request agent file, which orchestrates this lifecycle into one end-to-end automation sequence.
For our grand finale, we are moving away from our registration form to a new page on my website. The Add Book page is for testing APIs. This test page serves a purpose to manage authenticated users so they can generate and access profiles for the backend API automation testing suites.
Let's look at our source of truth, which are the requirements in Inflectra SpiraPlan. The parent requirement is 793. At a high level, I created four requirements, but the focus is only on two requirements under this parent requirement.
First is requirement 795. We have our data validation constraints: if a required field is left blank, a red validation message must appear for that field. Notice there are no BDD scenarios or test cases under test coverage for this requirement.
Second is requirement 796. We have our happy path: the system must capture all fields and commit the record upon clicking submit. This requirement also has no scenarios and no test cases.
Now, imagine the hours required to read both requirements, plan the test cases, analyze the DOM, map the locators, expand the page object file or add a new page object file, then write your test. Watch how we collapse that lifecycle into one interaction.
So I'm switching back over to VS Code. Let's review the assembly line request. As you can see, it has a system role and persona, and it has the responsibility to operate as a master traffic controller. It takes an ID and processes the ID to fulfill the end-to-end implementation.
Look at the execution chain. It runs a three-pillar lifecycle:
- Pillar one passes our target ID to our Planner request template.
- Pillar two generates the test by enforcing the rules inside our POM creation skill. If the test fails, then it will loop through the CLI heal request markdown before advancing to pillar three.
- Pillar three is an audit. It triggers our two-gate quality and financial review. It invokes our five-star review agent to make sure it has the Created By AI tag, and the token auditor analyzes the runtime logs.
# Running the Line
Let's drop our command into the chat window and watch the line execute. It's so small that I could just write it out, but let me go ahead and paste what I have. Now notice all those lines of information are not necessary — only a few lines are good enough. It says: process requirement 795 and requirement 796 through our agentic assembly line.
Now, let's run.
When our Planner sub-agent calls the Spira MCP, it reads every requirement and generates a multi-scenario test suite. But as a senior architect, we do not trust an automated generator. Our time is spent reviewing this code as a human-in-the-loop validation gate before a line touches our repository.
"Do you want to proceed with MCP Inflectra?" Yes. I want to search for the artifacts. "Do you want to proceed with Inflectra Spira workspace search?" Yes. And also, before it gets too far up, look at the updated to-dos. It shows pillar one, pillar two, and pillar three. Normally, you would not just select yes, yes all the time, but I know what it's trying to do. That is why I am accepting these without reading all of the information.
Bingo. Now we see the to-dos are all checked and complete. And it shows assembly line complete, requirement 795 and requirement 796.
# Reviewing What Was Created
Now, let's open up the test files to see what was created. We see the Add Book folder and we see it has one, two, three... six test specs.
Line one has the // Created By AI tag, which was mandatory. And we see there are no locators in the test. How about the other test? It's the same thing — Created By AI. It has a note and there are no locators in the test. I'm just double-checking now, making sure it had the tag in each one of these files. Yes.
Now on my project, I like to search for "Created By AI," because it helps to check if I reviewed all code created by AI. You can press Ctrl+Shift+F and then search for Created By AI, and you will see every file that has that tag. For Mac, just press Cmd+Shift+F.
For the page object files, let's look at those. We see page object, we see Add Book. And yes, it has the interface that it created. And it has the declarations. And it has the definitions. So we went ahead and created the methods as well. Bingo.
# Closing the Loop with Sync Agents
Now that our human-in-the-loop review is complete, we are ready to close the loop with our enterprise repository. To do this, we are bringing in two specialized micro agents inside our sync folder — two files: Spira requirement and our test case creator.
Think of these sync agents as your automated admin workforce. Their job is to translate your verified code back into SpiraPlan. All of it is managed behind the scenes through our Spira MCP server connection. Instead of copy-pasting code, we are letting our synchronization layer handle the heavy lifting.
I am going to drop a prompt into the chat window that calls our two automated sync agents at the same time. Watch how this works. Bring back Claude Code and paste. I requested to update requirement 795 with the new test case and generate BDD scenarios for requirement 796. Let's run.
Bingo. Claude Code is finished. Now let's go back to SpiraPlan. I'm going to refresh or reload the page for requirement 795. And we see it has a test case — 295. And the test case has a description and it has steps.
Now let's go to requirement 796 and hit refresh. For this, we see it has a description. Well, we had the description already, but we see it has the BDD scenario: successful submission with all fields completed shows confirmation. Bingo. And with that, let's check one more thing real quick and see if it did anything extra. Has a test case? Yes. And it shows the requirement link.
And with that, we have come to the end of the journey with Playwright MCP, Playwright Test MCP, Playwright CLI, Inflectra SpiraPlan, and Inflectra Spira MCP. You now possess the cutting-edge mindset, the foundations, and the skills to lead your organization with confidence into the future of agentic quality engineering.
I will see you in the next video.
Quiz
The quiz for this chapter can be found in 5.3.
