Less rework. Faster handoffs. Clear next steps.

Simple Guide

The shortest explanation of what Jini is for and what to type first.

Jini is for the awkward middle of work: after the meeting, before the handoff, before the recommendation, and before calling something done. It should reduce stress, not add process.

Start here

The shortest first run

1

Install Jini

Run the installer once from any terminal.

2

Start with jini

That is the front door. It should be enough for normal use.

3

Paste the work

Give Jini the messy notes, rough ask, screenshot, or draft you already have.

curl -fsSL https://raw.githubusercontent.com/maridlabsai/jini/main/install.sh | bash
jini

If setup is missing, Jini should say so in the shell. Then type Use Auto. If your company needs one strict route, use the matching setup path on the Install page instead.

jini is the front door.

jini is the front door.

Use cases

Think about normal problems

After a meeting

The follow-up is fuzzy, owners are implied, and the sendable version does not exist yet.

Before a handoff

The plan looks finished, but you are not sure it is safe to hand off or build from.

Before a decision

The choice was made, but the reasoning, tradeoffs, or open questions are getting lost.

Before real closure

The main pain stopped, but the actual aftercare work is still easy to skip.

Inside Jini

What the smallest flow should feel like

Paste messy notes Ask for the outcome you want Use Auto only if setup is missing Show what's ready Show what is missing Help me plan this Switch project

Before Jini starts a new piece of work, it should show a short decision card with the route, model, effort level, and reason. When you choose Help me plan this, it should slow down and structure the work into goal, requirements, design, steps, and run.

One concrete path

If you use Claude

Connect Claude

Jini should ask only for the missing API key, save it in the repo-local .jini folder, and let you continue. If you do not know how to begin, type help me finish this and then say something plain like turn these meeting notes into a follow-up I can send.

Output quality

What good help looks like

Visible context

  • the goal
  • the working inputs
  • the chosen route when it matters
  • what else is already active

Visible progress

  • what just finished
  • what is happening now
  • what will happen next
  • what is already done

Visible risk

  • what still needs attention
  • why that missing thing matters
  • what Jini is not sure about
  • whether the result is still safe to review before sharing

The things Jini gives back should feel like work you can use: a follow-up you can send, a recommendation you can explain, a closure checklist, a plan check, or a trip itinerary. If it only gives you a prettier status wall, it is failing.

If you only remember one rule

Jini should make the work easier to finish. If it makes you think harder about the tool than about the work, it is failing.