DEV Community: Ujjwal Kumar Singh

Stop Asking AI for Test Cases: Building a Gate-Controlled SDET Prompt

Ujjwal Kumar Singh — Tue, 28 Jul 2026 06:21:33 +0000

How to Get the Maximum Value Out of This Framework

Having built and iterated on this prompt through multiple production edge cases, here are the exact execution strategies I recommend depending on your workflow:

1. The Human-in-the-Loop Workflow (Recommended for Chat UI)
Run it in two separate chat threads: Don’t let long conversation history degrade your test accuracy. Run Phase 1 in Thread A to get your gap analysis and critical questions. Review the gaps, clarify what you can, and then update your original requirement text.

Start Thread B for Phase 2: Open a fresh conversation, paste the updated requirements + this framework, and jump straight into generation. This completely eliminates context drift and keeps the LLM laser-focused on state mutation rules.

2. The 2-Pass Programmatic Auditor (For Automated CI/CD Pipelines)
If you’re calling an LLM via API or integrating this into a pre-commit GitHub Action, split the execution into two isolated passes:

Pass 1: Run Phase 1 & 2 to generate the initial test table.

Pass 2 (The Audit Pass): Feed the generated table into an isolated, secondary prompt whose only job is to enforce the Verification Check (verifying exact boundary literals, API status codes, and non-mutation assertions). Separation produces drastically higher assertion reliability than asking a model to self-audit in a single turn.

3. How to Live-Demo or Teach This
For Live Streams & YouTube: This framework makes for a high-signal live demo. Paste an intentionally ambiguous user story (e.g., a webhook handler or payment endpoint), watch Phase 1 halt at the gate live, discuss the surfaced edge cases on camera, reply PROCEED, and review the generated DEFERRED risk rows. It shifts the content focus from “Look at this cool AI tool” to “This is how Senior SDETs think about systems.”

For Technical Writing & Post-Mortems: The progression from a naive “write me test cases” prompt to a strict 2-phase state-machine framework is a technical narrative in itself. Break down why each gate exists—like forcing non-mutation assertions for negative cases—to show the hidden pitfalls of naive LLM test generation.

`BEFORE USING THIS PROMPT: Replace [DOMAIN] below with your actual
system context (e.g. "FinTech loan disbursement API" or "B2B SaaS
user management dashboard"). Do not leave it as a placeholder.
The model will not prompt you for this information.

You are a SDET specialising in [DOMAIN]. You think like both
a tester and a software design engineer. You treat every untested
edge case as a potential production incident. You evaluate not just
the happy path, but database state consistency, side-effects,
idempotency, concurrency, data isolation, performance thresholds,
and cache invalidation on write operations. You do not make
assumptions silently — you surface them explicitly before acting
on them.

Your goal is to review the provided requirements, identify logical
gaps and ambiguities, and produce a lean, high-coverage test suite
with full traceability back to your analysis.

You will follow a strict two-phase workflow. Phase 2 does not begin
until I explicitly authorise it.

Phase 1: Requirements Analysis and Gap Identification

Thoroughly analyse the requirement text provided below across all
five dimensions before producing a single test case.

Gap Dimensions:

Functional Gaps
Unstated behaviour for error states, timeouts, retry logic, or
unexpected user inputs. Missing success and failure definitions.
Undefined default values, fallback behaviour, or missing business
logic branches.
System, Boundary, Observability, and Idempotency Gaps
Data volume limits, field length constraints, rate limits,
performance/SLA bounds, concurrency and race conditions, state
transition completeness, missing failure paths, partial failure
rollbacks, missing idempotency and duplicate-request handling, cache
invalidation on write operations, stale read risk after state-changing
calls, undefined TTL or cache invalidation trigger behaviour, and
missing audit, logging, or telemetry requirements. If the requirement
does not state a response time or throughput SLA, flag this explicitly
as a gap — undefined SLA bounds make performance regression undetectable in CI.
UX and Logic Gaps
Inconsistent business rules, missing confirmation steps, undefined
rollback or undo behaviour, unclear sequencing of multi-step flows,
and contradictions between stated rules.
Security, Data Privacy, and Isolation Gaps
Authentication and authorisation boundary conditions, privilege
escalation paths, horizontal data isolation (can a user access or
modify records belonging to another user or tenant by manipulating
IDs, tokens, or query parameters — IDOR surface), PII exposure in
logs, responses, or error messages, input injection surface area
(SQL, script, path traversal), and missing session or token
invalidation behaviour.
Integration and Contract Gaps
Assumptions about third-party API behaviour, missing upstream or
downstream error codes, undefined schema validation rules, version
compatibility gaps, and webhook or callback failure and retry
handling.

Phase 1 Output Format:

Critical Questions and Ambiguities

List your top 5 to 8 gaps as numbered bullet points. Be specific.
Reference the requirement text where possible. Do not be vague.

Format each gap as:
N. [Gap Dimension] — [Specific question or ambiguity and why it
matters for test design]

Coverage rule: Surface significant gaps across these dimensions.
If a dimension genuinely has no critical gap for this requirement,
state: "[Dimension Name]: No critical gaps identified — [one-line
reason]." Do not invent trivial gaps just to fill space, and do
not silently skip a dimension.

Stated Assumptions

If the requirement is incomplete but you can make a reasonable
assumption to unblock analysis, list each assumption with an ID.

Format:

A-1: [Assumption text and the reason it was needed]
A-2: [Assumption text and the reason it was needed]

STOP HERE.

Do not generate any test cases yet.

After completing your gap analysis and assumption list, output
exactly this line and nothing else:

"Phase 1 complete. Reply PROCEED to generate test cases using
stated assumptions, or provide clarifications and I will revise
my analysis first."

Wait for my reply before continuing to Phase 2.

Phase 2: Test Case Generation

This phase begins only after I reply with PROCEED or after I
provide clarifications that you have explicitly acknowledged.

Handling Phase 1 Transition:

If I provide specific clarifications, resolve the corresponding gaps or assumptions directly in your test design.
For any Phase 1 gap that is neither clarified by me nor covered by a stated assumption, do NOT generate a test case for that area. Instead, add a row at the bottom of the table with:
- Category: DEFERRED
- Scenario: [Gap ID] — [One-line reason]
- Risk and Priority: Your best assessment of what is at stake if this gap is not resolved before release.
- Automation Candidate: N/A
DEFERRED rows do not count toward the 12 to 20 active case target.

Strict Quality Principles:

Coverage Over Quantity: Every test case must target a distinct
failure mode, business rule, or boundary condition. No repetitive
variations of the same scenario.
Balanced Distribution: Include all three categories. If any
single category represents more than 60% of active cases, this is
flagged in the Coverage Summary as an imbalance.
- Positive: Confirms valid behavior. Must cover every valid state-machine transition explicitly (e.g., Draft -> Pending, Pending -> Approved), rather than collapsing multi-step workflows into a single generic happy path.
- Negative: Confirms error and invalid state handling. Must also cover every invalid state-machine transition explicitly (e.g., attempting Draft -> Approved while bypassing Pending). Assert the rejection response and confirm the resource state is unchanged.
- Edge or Boundary: Targets limits, state transitions, concurrency, idempotency, and unusual-but-valid paths.
Execution Blueprints for Complex Edge Cases:
- Idempotency cases: Send the identical request a second time with the same idempotency key or payload. Assert that the second response returns the same outcome (status code and body) AND no duplicate record is created in the DB AND no duplicate event is published to the queue.
- Concurrency cases: Specify two parallel requests targeting the exact same resource state at t=0. Assert that the succeeding request returns the expected outcome with full state mutation validation AND the failing request returns the conflict response (e.g., HTTP 409 Conflict) with full non-mutation validation AND the final DB state reflects exactly one completed operation with no partial write.
- Authorization & Multi-Tenant (IDOR) cases: Specify User A's valid authentication token in the request headers while supplying User B's resource ID in the payload or URI path. Assert an explicit HTTP 403 Forbidden (or 404 Not Found if resource hiding is required) AND zero DB/queue state mutation. Teardown: Verify User B's resource is in its original pre-test state regardless of whether the IDOR attempt succeeded or failed. Do not assume the system rolled back correctly — assert it.
Architectural Assertion Dialect: Assertions must match the
target level:
- API: HTTP status code + exact error or payload keys + relevant headers (+ latency SLA threshold if applicable).
- DB: Exact row state, specific field values, and row count delta.
- Queue or Event: Topic or queue name, publish status, partition key, and schema field validation.
- UI: Named element visibility, DOM state change, and exact user-facing notification text.
Deterministic Inputs and Exact Assertions: No generic terms.
Use exact boundary values (0, -1, null, 255 chars, empty string),
specific HTTP status codes (422 Unprocessable Entity, 401
Unauthorized), exact DB field values, or precise error message
strings. If an SLA/timeout exists, specify the latency bound (e.g., < 200ms).
State Mutation Validation (Positive Cases): For all Positive
cases where the operation creates, updates, or deletes a resource,
the Expected Outcome MUST assert the resulting system state
explicitly. Example: "HTTP 201 Created AND DB record exists with
status='ACTIVE' and created_by='user_id_123' AND audit log entry
written with action='USER_CREATED'."
State Non-Mutation Validation (Negative and Boundary Cases):
For all Negative and Boundary failure cases, the Expected Outcome
MUST explicitly assert system non-mutation. Example: "HTTP 400
Bad Request AND no new record written to DB AND no event published
to Kafka AND no audit log entry created."
Verification Check: Before outputting the table, verify every
row passes all of the following. Rewrite any row that fails.
- No generic input or outcome language.
- Every boundary value is a literal.
- Every expected outcome names a specific code, field value, element state, or message string.
- Every expected outcome uses the assertion format matching its Level column (API: status + payload keys; DB: row state + field values + count; Queue: topic + schema + partition key; UI: element visibility + DOM state).
- Every Positive write operation row explicitly asserts resulting DB or system state.
- Every Negative and Edge row explicitly asserts system non-mutation.
Assumption Traceability: Tag any case built on a Phase 1
assumption with [Assumption: A-N] in the Scenario column.
Suite Scope: Target 12 to 20 active test cases. DEFERRED rows
do not count. If the requirements justify more, state the reason
and ask before expanding.
Clarity and Actionability: Every case must be executable by
someone who did not write it.

Output Table:

Test ID	Category	Level	Scenario / Intent	Pre-Conditions, Setup, & Teardown	Inputs / Test Data	Expected Outcome and Assertions	Risk	Priority	Automation Candidate
TC-01	Positive	API+DB	[Summary. Add [Assumption: A-N] if applicable]	[Setup: DB seed state, auth token scope, mock states. Teardown: Cleanup user_id_123]	[Exact payload, headers, query params]	[HTTP 201 + DB row exists with field='value' + audit log action='X']	High	High	Yes
TC-N	DEFERRED	N/A	[Gap ID] — [Reason]	N/A	N/A	N/A	High / Med / Low	High / Med / Low	N/A

Column Definitions:

Level: Primary verification layer. Use API, UI, DB, Queue, Contract, or a combination (e.g., API+DB).
Pre-Conditions, Setup, & Teardown: Exact DB seed data required, auth token validity and scope, third-party mock states (e.g., "Payment gateway mock returns HTTP 503 on first call, HTTP 200 on retry"), and explicit post-test cleanup/teardown steps.
Risk: Production impact severity. Consider data loss, financial impact, security exposure, or system crash.
Priority: Execution urgency. Consider frequency of use, regression likelihood, and release blocker status.
Automation Candidate:
- Yes — deterministic, stable, high regression value.
- No — requires human judgement, visual layout verification, or one-time exploratory value only.
- Partial-E — automatable but requires one-time environment or test data setup. Note the specific dependency.
- Partial-V — automatable but one or more assertions require visual or human judgement. Note the specific assertion blocking full automation.
- N/A — DEFERRED rows only.

After the Table:

Provide a Coverage Summary of 5 to 7 lines covering:

Total active cases by category (Positive / Negative / Edge) and total DEFERRED count
Distribution health: flag if any category exceeds 60% of active cases and identify which failure modes may be under-tested
Automation readiness: count of Yes / Partial-E / Partial-V / No, and the single biggest blocker to automating the Partial cases
Highest risk areas identified in the active test cases
Deferred items listed with their Risk level so the team can prioritise which clarification conversations to have first
Recommended next steps for test automation setup or test data provisioning

Requirements to Analyse:

[PASTE YOUR REQUIREMENTS OR USER STORIES HERE]`

Github Repo Link

Logging Tells You What Happened. Observability Tells You Why.

Ujjwal Kumar Singh — Mon, 27 Jul 2026 05:28:59 +0000

Earlier in my career as a tester, I assumed logging and observability were basically the same thing, just different names for checking whether something had broken.

As I spent more time exploring them I realized they solve different problems. Logging records events that have already happened, while observability helps explain why those events happened and how the system reached that state. That distinction becomes increasingly important as systems grow in complexity.

A log entry might report a NullPointerException, but it rarely answers the questions that follow. Which release introduced the issue? Which commit caused it? How many users are affected? Which service failed first? What sequence of events led to the failure?

This is where platforms such as Sentry demonstrate the difference. Similar errors are grouped into a single issue instead of appearing as hundreds of separate alerts. Errors are linked to the relevant commit and source code, while traces, profiling, and session replay provide the context needed to understand what happened before the failure occurred.

The distinction is simple. Logging answers what happened. Observability helps answer why it happened.
Logs remain an essential part of every system, but logs alone rarely provide enough context for modern distributed applications. As software systems continue to grow, understanding system behavior becomes just as important as collecting data.

How do you distinguish between logging and observability when investigating production issues?

The Work Nobody Can See Doesn’t Count Toward Your Career

Ujjwal Kumar Singh — Fri, 24 Jul 2026 07:54:43 +0000

Priya found four bugs that mattered. Real ones, the kind that would have hit a payments flow in production: a rounding error in partial refunds, a timeout that left a transaction in limbo, two others that had been sitting in the system for months. She found them by doing one week of deep exploratory testing instead of writing new automation.

Her manager’s first question in the next 1:1 was not about the bugs. It was whether she was moving away from automation now.

Those two facts should have had nothing to do with each other. A person found critical defects. A person’s career trajectory came under quiet review. Yet in most testing organizations, those two things are tightly, almost automatically, connected. Why.

Organizations promote what they can see

Automation leaves evidence behind. A test suite, a pipeline, a framework other people adopt and point to. Someone can look at it in a sprint review, a performance packet, a GitHub profile, and immediately understand what was built.

Exploratory judgment does not leave the same trail. When it works, what you get is an absence. A bug that never shipped. An incident that never happened. Nobody writes a Jira ticket for the outage that did not occur because someone spent two days poking at an edge case out of a bad feeling. The work is real, the value is real, but it becomes visible mainly in the moment it is missing.

So when a team has to decide, often without meaning to, what growth looks like, it defaults to the thing it can point at. Not because leadership sat down and decided exploratory testing matters less. Because code is easy to measure and judgment mostly is not, until it fails.

That same week Priya was hunting timeout bugs, a teammate spent the sprint reducing CI runtime from forty minutes to nine. Nobody asked him where his career was headed. His work was visible by design.

One job title, one direction

Here is where it gets structural rather than personal. Most organizations do not actually have four or five distinct testing disciplines with their own ladders. They have one job called tester, sometimes split into junior and senior, and inside that single bucket, progress has to be represented somehow.

Proximity to code becomes the default measuring stick, not because anyone decided functional testing is worth less, but because a single ladder can only encode one kind of movement clearly.

Risk analysis, exploratory depth, the instinct for where a system is about to break, none of that fits neatly onto the same axis as commits and pipeline ownership. So it does not show up on the axis at all.

Priya was not choosing to step backward. She was doing work that had no lane built for it.

The part that stays invisible even in the roles built to fix this

A lot of organizations think they have already solved this by creating hybrid roles, people who write automation and also do exploratory testing depending on what the week needs.

In practice, the hybrid role often does not rebalance anything. It just absorbs the imbalance quietly.

The person is doing more. They are being recognized for less of it.

The automation half of their week shows up in the metrics. The exploratory half, the part where they catch the thing the suite would have missed, gets folded into “other duties” or vanishes into general competence. Nothing about the underlying structure changes. The ladder still only rewards the visible half of the job.

Why organizations understand this and still do not fix it

Ask most engineering leaders directly and they will agree the incentive structure is lopsided.

Very few will actually build a real parallel track for exploratory and risk focused testing, with its own seniority levels and its own comp band.

Not because they cannot see the problem. Because fixing it costs something specific. It means paying invisible work at parity with visible work, which is a harder argument to win internally than it sounds. It means giving that track real standing on the org chart instead of a consolation title. It means building performance metrics for judgment calls that, by their nature, resist quantification, the same way “prevented an incident” does.

Avoiding all of that is the easier choice. Most organizations take it. Not out of malice. Out of the ordinary gravity that pulls any system toward what it can already measure.

This is bigger than testing

Once you see the pattern, it stops being a testing problem specifically. It shows up anywhere visible output and invisible judgment compete for the same recognition. The engineer who ships a feature gets noticed. The engineer who spent a week arguing the feature was the wrong one to build, and was right, rarely does. The designer who ships a screen is visible. The designer who prevented five bad screens from ever reaching a sprint is not.

Testing just happens to make the pattern unusually easy to see, because the two kinds of work sit right next to each other on the same team, doing the same job, under the same title.

Priya did not stop being an automation engineer. She simply did the kind of testing the product needed that particular week. The surprising part was never the work she chose. It was that the work immediately raised a question about her career. That says very little about testing. It says a great deal about how organizations quietly decide what counts as progress.

Python for Testers : Validating a JSON API Response Without Any Framework

Ujjwal Kumar Singh — Tue, 21 Jul 2026 16:27:25 +0000

Most Testers validate API responses inside a test framework. But do we know how to do it with just Python?

Scenario: Our API returns a JSON response after creating a user. We need to verify the status, the message, and the user details are exactly what we expected.

Here is the JSON response:

*JSON data:
*

{
    "status": "success",
    "message": "User created",
    "user": {
        "id": 101,
        "name": "Ujjwal"
    }
}

Here is the Python validation:

*Python code:
*

import json

with open("data.json", "r") as file:
    data = json.load(file)

    if data["status"] == "success" and data["user"]["name"] == "Ujjwal" and data["user"]["id"] == 101:
        print("Validation Passed")
    else:
        print("Validation Failed")

Output:

Validation Passed

****Why this matters as a Tester:

Before we reach for requests or pytest, understanding how Python reads and validates JSON at the base level makes us a sharper tester. Every API assertion we write in a framework is doing exactly this under the hood.

Knowing the foundation makes us better at debugging when the framework gives us a result we did not expect.

GitHub: https://github.com/beinghumantester/Fundamental-Coding-Programs

Python for Testers: Finding Unique Status Values from an API Response String

Ujjwal Kumar Singh — Mon, 20 Jul 2026 17:47:42 +0000

Ever got a concatenated API response string and needed to know what unique status values were present?

Scenario: our API returns a long string of status codes like "Automation and Python" and we need to extract every unique status that appeared, in the order it first showed up.

Here is the Python code:

api_response = "Automation and Python"
api_response = api_response.lower().replace(" ", "")

seen = ""
for ch in api_response:
    if ch not in seen:
        print(ch)
        seen = seen + ch

No library. No regex. Just Python iterating through the string and tracking what it has already seen.

Why this matters as a Tester:

Not every API response comes in a clean, structured format. Sometimes you are dealing with concatenated strings, log outputs, or raw response bodies. Knowing how to extract unique values from messy string data is a practical skill that shows up more often than we would expect in real test automation work.

Today’s Python Challenge for Testers: Deduplicating API Response Values Before Assertion

Ujjwal Kumar Singh — Sun, 19 Jul 2026 06:24:33 +0000

Have we ever received an API response with duplicate values and our assertion failed, not because the data was wrong, but because duplicates were messing up our comparison?

Scenario: our API returns a list of user IDs, but some IDs appear more than once. Before we assert, we need a clean, unique list.

Here is the Python code :

response_data = [1, 2, 3, 4, 5, 2, 7, 8, 9]
unique_values = []

for data in response_data:
    if data not in unique_values:
        unique_values.append(data)

print(unique_values)

Output:

[1, 2, 3, 4, 5, 7, 8, 9]

Duplicate data is removed. Now our assertion runs against clean data.

Why this matters as a Tester:

Asserting against raw API responses without cleaning the data first is a common source of false failures. Understanding how deduplication works at the code level makes us a better judge of when to clean data and when the duplicate itself is the bug.

Github Repo Link

Python for SDETs: Comparing Two API Response Arrays

Ujjwal Kumar Singh — Sat, 18 Jul 2026 15:42:03 +0000

Ever got two API responses and needed to know what matched?
Classic scenario — your API returns a list of user IDs. Your expected list has what should be there. You need to know what actually matched and how many.
Here is the Python pattern I use:

expected = [10, 12, 14, 15, 16, 28]
actual = [13, 14, 16, 17]
matched = []
count = 0
for i in expected:
    for j in actual:
        if i == j:
            count += 1
            matched.append(i)

print("Number of matching elements:", count)

print(matched)

*Output *
Number of matching elements: 2
[14, 16]

Two values matched. Everything else is either missing or unexpected, both of which are bugs worth reporting.

Weekly Challenge-3: Building an AI-Powered Open Source Contribution Assistant with n8n

Ujjwal Kumar Singh — Mon, 22 Jun 2026 01:45:02 +0000

Introduction
One challenge in open source is not the lack of opportunities, it’s deciding which opportunity to work on next.

Many repositories have hundreds of open issues. Some are beginner-friendly, some require deep project knowledge, and others may no longer be relevant. As contributors, we often spend a significant amount of time reviewing issues before making a contribution.

To explore how automation could help, I built an AI-powered contribution assistant using n8n.

The goal was to automatically collect issues, evaluate them against predefined criteria, prioritize them, and generate a daily contribution digest.

The Problem
When reviewing open source repositories, contributors often face questions such as:

Which issue matches my current skill set?
Which issue can be worked on within the time I have available?
Which issue provides the best learning opportunity?
Which issue has a high probability of resulting in a merged contribution?
Which issue should I start with today?

Answering these questions manually across multiple repositories can become time-consuming.

The Solution
The workflow automates issue discovery and prioritization.

It:

Retrieves open issues from GitHub repositories
Filters out pull requests
Collects issue metadata
Uses an LLM to analyze and rank opportunities
Generates a daily digest
Stores recommendations in Notion for future tracking

The objective is not to replace contributor judgment, but to reduce the effort required to identify promising contribution opportunities.

Workflow Overview
The workflow consists of four major stages:

1. Issue Collection
Issues are fetched from GitHub repositories.

Relevant information is extracted, including:

Labels
Comment count
Last update time
Repository source

2. Issue Evaluation
An LLM evaluates issues against predefined criteria such as:

Technology relevance
Documentation relevance
Learning value
Expected effort
Probability of successful contribution

3. Recommendation Generation
The workflow generates:

Top contribution opportunities
Quick wins
Learning-focused opportunities
A recommended issue to start with

4. Knowledge Management
Recommendations are stored in Notion and delivered via email.

This creates a searchable backlog instead of requiring contributors to revisit repositories repeatedly.

Benefits
Reduced Decision Fatigue
Contributors spend less time searching and more time contributing.

Consistent Engagement
A daily recommendation can encourage regular participation in open source projects.

Personalized Prioritization
Different contributors value different things. The ranking criteria can be adjusted based on individual goals.

Better Visibility
Storing recommendations in Notion makes it easier to track contribution opportunities over time.

Challenges Encountered

Building the workflow surfaced several practical challenges:
Prompt design significantly impacted recommendation quality.
Structured JSON outputs were necessary for reliable automation.
Notion schema mismatches caused workflow failures.
LLM-generated outputs required validation before downstream processing.
Integration testing took considerably longer than expected.

The workflow itself was relatively straightforward. Making the components work reliably together required the most effort.

Possible Improvements
The current workflow works well as a personal assistant, but there are several areas for improvement.

Historical Tracking
Track previously recommended issues and avoid recommending the same issue repeatedly.

Contribution Feedback Loop
Record completed contributions and use that information to improve future recommendations.

Skill-Based Profiles
Allow contributors to define profiles such as:

Documentation Contributor
Automation Engineer
Backend Developer
Frontend Developer

and generate recommendations accordingly.

Multi-Repository Support
Expand beyond a single ecosystem and evaluate opportunities across multiple projects.

**Effort Estimation
**Use issue history and metadata to estimate actual effort more accurately.

Duplicate Detection
Avoid recommending issues that are very similar or represent the same underlying work.

Weekly and Monthly Reports
Generate summaries that show:

Issues reviewed
Contributions completed
Skills explored
Areas of growth

Key Takeaway
The most interesting lesson from this experiment was that the bottleneck was not finding open source work, it was selecting the right work.

Automating issue discovery and prioritization helped transform a large list of open issues into a smaller set of actionable recommendations.

While the workflow is still evolving, it demonstrates how automation and AI can be used to reduce overhead and help contributors spend more time learning, building, and contributing.

Github Repo Link