jigward
Sign in Early access
Explore Jigward

How Jigward works

One coworker with many ways in. It starts from what it already knows about your project, and uses a workspace only when the work needs one.

An example at Orbit Cab, a made-up cosmo-taxi company.

Ways in

  • Team chat

    Mention it in the conversation.

  • Issue tracker

    Assign it an issue.

  • Code review

    Ask it to review a pull request.

  • Jigward app

    Ask in Chat or use an Application.

  • Scheduled work

    Set a Duty to run later.

Explore integrations

Context

One lasting area of work, shared with Jigward.

Repositories
The code, database schema, APIs and dependencies.
Project knowledge
What earlier work established, with its sources.

What comes back

  • An answer or investigation

    Findings the team can act on.

  • A draft pull request

    A change for a person to review and merge.

  • Browser check results

    What it checked and what happened.

  • An internal tool

    A page the team can keep using.

The report goes back to the thread, issue, pull request or Chat where the work was requested.

How the parts connect

Every way in lands in the same Context, so one piece of work can lean on another: what a Task finds is there for the next one, a Task can set a Duty, a Duty gives a Task, and an Application records what a Task did. The model above plays this story. Here it is step by step, numbered as it is there.

  1. A question in Slack

    What a Task finds is kept as project knowledge, with where it came from, so the next piece of work starts from it instead of from scratch.

    1. Team chat Mira in #fares: @Jigward why are night fares doubled?
    2. Tasks A Task starts from the thread
    3. Repositories Reads the fare job in orbit-cab-api
    4. Tasks Searches CloudWatch Logs for night rides
    5. An answer or investigation The midnight job applies the night rate twice. Answered in the thread.
    6. Project knowledge Remembers the cause, with the log lines

  2. An issue assigned on Jira

    The Task recalls the cause found in Slack before it touches the code, and sets a Duty when asked, so the check keeps running after the fix is merged.

    1. Issue tracker ORB-218 on Jira: Apply the night rate once, and check it every morning.
    2. Tasks A Task starts from ORB-218
    3. Project knowledge Recalls the cause found in #fares
    4. Repositories Fixes the job in a workspace and runs the tests
    5. A draft pull request Draft pull request #142, linked on ORB-218.
    6. Duties Sets a Duty: check night fares, weekdays at 07:00

  3. A pull request to review

    A review weighs the change against the schema, the API and what earlier work settled, and leaves the approval to the people who own it.

    1. Code review Pull request #139 by Leo: Review requested from Jigward.
    2. Tasks A Task starts from the pull request
    3. Repositories Compares the change with the schema and the API
    4. Project knowledge Recalls: the night rate applies once
    5. An answer or investigation A comment on #139: the new discount also runs at midnight.

  4. An Application from a Chat

    A Chat reads the Context’s own Tasks and builds an Application on them: a page and the data it keeps, shared with the team.

    1. Jigward app Mira in a Chat: Make a board of the night fare checks.
    2. Chat Reads the Tasks that checked fares
    3. Applications Builds the board and the data it keeps
    4. An internal tool The night fare board is ready for the team.

  5. The Duty wakes

    The Duty set on Jira wakes on time and gives a Task. When that Task finishes, the board built in the Chat records its result.

    1. Scheduled work Duty, weekdays at 07:00: Check the night fares on staging.
    2. Duties Wakes and gives a Task
    3. Tasks Books a night ride on staging in a browser
    4. Browser check results The night fare is right. Recording and logs attached.
    5. Applications The night fare board adds this check

The story is set at Orbit Cab, a made-up cosmo-taxi company. It describes what Jigward does; it is not a recording of a real Task.

Four ideas behind everything

  1. Context first

    Most questions are answered from what Jigward already knows about the project: the code on its default branch, the schema its migrations build, its API, what earlier work settled. Nothing is cloned or run for that.

  2. Execution when it is needed

    Changing code, building and running tests take a temporary workspace, a copy of the repository acquired for that work and removed when it ends.

  3. Back where it came from

    A Task asked in a Slack thread reports in that thread. One assigned on Jira reports on the issue, and one given in a Chat reports in the Chat.

  4. A person decides

    A change arrives as a draft pull request that a person merges. Jigward never approves or blocks a pull request, and never moves an issue to Done.

Concepts

Each one in a few minutes: what it is for, what changes, how it works, how it connects to the rest.

How it reads your repositories

Jigward works with repositories in any language and keeps what it learned about them. It is tuned most deeply for the stacks below, and each reading records the commit it was taken at.

Backend
Java and Kotlin, with Spring Boot, Gradle and Maven.
Front end
Angular, React and Vue, with npm, pnpm or Yarn.
Database
PostgreSQL, from the Liquibase or Flyway migrations in the repository.
API
OpenAPI 3, committed, or generated by supported project tooling.
Dependencies
Maven, Gradle and npm dependency trees, as the build tool reports them.

Meet your next engineering coworker

Bring a question
from your own project.

See how Jigward can help your team understand the system and move the next task forward.

Request early accessRequest a demo by email

Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.