Start here
What you can hand to Jigward, and what stays with your team
A short introduction for anyone new to Jigward. The work teams give it, what comes back, and the decisions that stay with people.
Blog
What you can ask Jigward to do, how it works, and why it is built this way. Guides walk through real use step by step; engineering posts explain the mechanics.
All posts
-
Build a small internal tool with Applications
Describe a tool your team keeps in a spreadsheet, and Jigward builds it as a page with data of its own. How to ask, how to load your data, how changes and versions work, and what an Application cannot do.
-
Check your app in a real browser
Ask Jigward to click through your app the way a QA engineer would, and get a replayable recording, the console and network logs, screenshots and a report. What to set up, what you get, and the limits.
-
From a Slack message to a draft pull request
Hand Jigward a bug in the thread where it was reported, and get a draft pull request and a report back in the same thread. What to set up, what Jigward does, and where you step in.
-
How Jigward keeps your credentials out of the model
Jigward can sign in to your app, call your API and read your AWS logs without the model ever seeing a password, a key or an AWS credential. How each works, and the two places the rule stops.
-
Jigward comments on pull requests. People approve and merge them.
How Jigward's review comments fit into your team's review, and why approving, requesting changes and merging stay with the people who own the repository.
-
Why Jigward reads your database schema from the migrations, not the code
An answer about a table is only useful if it matches the real database. Jigward applies your Liquibase or Flyway migrations to an empty PostgreSQL and reads what they built, and says so when it cannot.