Built to turn AI work into real results

WorkJinn

WorkJinn is the workflow-aware alternative to CLI-only AI tools.

If you already know CLI tools, WJ is what makes them safer for long-running projects: it turns one-off commands into a guided sequence with plan, execution, verification, and review gates.

WorkJinn is for when you need progress, not another endless chat. It helps you launch a task, execute a complete workflow, and finish with files and proof you can trust.

Perfect for solos and teams: launch once, work in structured cycles, and keep your project ready for review, handoff, and continuation.

Signed release Detailed CHM help Goal -> Board -> Cycle Validation, not guesswork Lower context risk Stays on course Quality checks + correction pass
Download V21 Downloads: -- WorkJinn — Your AI-Powered Engineering Co-Pilot
The signed V21 package is available now. It includes WorkJinn.exe, Txt2Book.exe, CHM help, README, checksums, and version.txt.

Older versions

Past signed releases are kept here for reference and rollback. Use them only if V21 has an issue on your system.

Why WorkJinn

Built for people who want to ship, not just brainstorm

WorkJinn is the practical middle layer between model ideas and finished work. It removes the chaos of long context-heavy prompts and turns each task into a clear sequence: plan, execute, validate, review, repeat. Every step is recorded in your project, so quality is auditable.

QuickStart tasks

Tested task starts include book projects, existing-code work, new-code plans, plan-then-code, prompts, file sets, bug fixes, tests, and documentation.

Project folders

WorkJinn can create a fresh project or adopt an existing folder. Its own state is kept in a sidecar .workjinn folder so progress can be inspected and resumed.

Book workflows

For books, WorkJinn can plan chapters, continue from existing chapter files, check rough size limits, and keep continuity notes separate from the reader-facing manuscript.

Code and docs

For software work, it is strongest on bounded edits, docs, test scaffolds, bug-fix passes, and tasks where file existence and build or smoke evidence can be checked.

What it is especially good for

WorkJinn is strongest when the work has a visible target, files to change, and evidence that can be checked. It is not a generic chatbot; it is a project-control layer for AI work that must survive interruptions and review.

Book and chapter work

Plan chapters, continue interrupted drafts, keep continuity notes separate, and check rough chapter length before accepting output.

Bounded code changes

Use it for narrow fixes, generated docs, test scaffolds, and legacy-code passes where changed files and build or smoke evidence matter.

Evidence-driven review

Accept output only after file checks, validation notes, review decisions, or command evidence make the result inspectable.

Restart-safe continuation

Resume from sidecar state and artifacts after a crash, stale lock, provider issue, or human pause instead of rebuilding context manually.

Best fit / poor fit

Best fit

Use WorkJinn when a task can be described as a goal with expected files, checks, and review criteria: book chapters, documentation, test work, bug fixes, file transformations, project adoption, and careful continuation after interruption.

Poor fit

Do not expect WorkJinn to replace human judgment, invent a full product from a vague wish, or guarantee that every local model response is correct. It improves control by making AI work structured, visible, and retryable.

QuickStart options

QuickStart is the practical entry point. It starts a project with the right folder, prompts, validation checks, and workflow type instead of leaving the user in a blank chat.

Book project

Plan and write chapter-based work with expected chapter count and chapter length limits.

Recover book

Inspect an interrupted book folder, keep valid chapters, remove broken leftovers, and continue in the original chapter location.

Existing code

Adopt a source folder, create a narrow work order, and review file changes with available build or smoke evidence.

New code plan

Turn an implementation idea into a plan before files are written.

Plan then code

Run a planning pass first, then execute the selected plan in controlled cycles.

Prompt work

Create, improve, and compare prompts while keeping prompt settings separate from project output.

File set

Run review, cleanup, transformation, or extraction work over selected files.

Bug fix

Describe a defect, let WorkJinn prepare a focused fix pass, and record what changed.

Add tests

Create or improve tests around a selected behavior, with review focused on runnable proof when available.

Write docs

Produce or update documentation from project files, logs, and the selected audience.

Settings

Configure provider routes, prompt settings, project folders, and run behavior from the desktop workflow.

Test tools

Check LM Studio and the MCP tool bridge before starting a workflow.

Other work areas

Dashboard

Project load, adoption, settings, goals, experts, cycles, batch work, prompt settings, logs, and start buttons are available from the desktop dashboard.

Autopilot

Bounded repeated cycles can continue a task while run locks and project state protect the folder from overlapping work.

Batch Lab

List, filter, transform, review, merge, retry, and improve actions for larger file groups or repeated operations.

Logs and evidence

WorkJinn stores command output, validation notes, review decisions, and generated artifacts so runs can be checked later.

Txt2Book

The package includes Txt2Book.exe as a companion utility for private, non-commercial text-to-book workflows.

CHM help

The offline help file explains setup, operation, release contents, and legal notes without requiring a web connection.

How WorkJinn works on a real project

Think of WorkJinn as the difference between one long chat and a real project assistant. It is built to keep going until your goal is reached, not to stop after a single response.

Stays on target

You give WorkJinn a goal and success criteria. If the result is not good enough yet, it keeps running another cycle. It only stops when the goal is reached or a clear blocker appears (missing files, blocked approval, unrecoverable errors, etc.). This is why many users compare it to a goal-driven workflow.

Very short prompts

WorkJinn uses mostly 1 or 2 focused prompts per step instead of carrying one huge endless chat. So each model call gets only the context it needs right now. That is easier for the model to handle, and often cheaper because you use fewer tokens.

Mix local + cloud

A normal CLI usually forces one backend setup for a task. WorkJinn can route simpler, repetitive steps to local models and switch heavy tasks to cloud models when needed. You keep control over speed, cost, and capability.

Then WorkJinn follows a concrete, visible workflow:

1. Project intake

QuickStart picks the right mode (book, code, tests, docs, bugfix), target folder, and provider settings so work starts with the right boundaries.

2. Goal and artifact plan

WorkJinn writes an explicit execution plan, defines expected outputs, and identifies what evidence will count as success for this run.

3. Expert board pass

A coordinated board breaks the task into subgoals and tasks before any large file edits happen.

4. Bounded execution

Execution runs in constrained cycles. Each cycle produces changed files, logs, and model reasoning context you can inspect.

5. Validate

WorkJinn runs checks that fit the task: file presence, chapter shape, lint/build/smoke hints, forbidden patterns, and content constraints.

6. Review and retry

If quality checks miss the target, WorkJinn requests a corrective cycle instead of accepting weak output.

7. Completion pack

When accepted, final artifacts (results, notes, validation outcomes) are packaged and the project state is ready for handoff or continuation.

What it is good for: writing or continuing books with chapter discipline, making bounded code changes with proof, generating test material, improving legacy code safely, and rebuilding tasks after interruptions without losing context.

WorkJinn — The Djinn collaborates with you in a modern engineering office

What has been verified

Real local workflow

The V21 package was built and signed, includes CHM help and Txt2Book, and passed the WorkJinn target check with zero warnings and zero failures. V21 includes clearer locking and recovery rules, an autopilot lock Yes/No dialog, a --stage publish CLI stage, a post-run summary modal with an Open Folder button, optional foreword support for book projects, and persisted chapter count plus gap-agnostic chapter recovery.

Review before acceptance

WorkJinn does not treat a model answer as success by itself. It records produced files, errors, validation results, and review decisions. Weak output can be retried instead of silently accepted.

Typical workflow

1. Choose a task

Use QuickStart for a book, code change, bug fix, tests, docs, prompt work, or file-set task.

2. Let the board plan

WorkJinn prepares subgoals and a work order before trying to write or change files.

3. Execute in cycles

A bounded cycle asks the provider to work, writes artifacts, and records what was attempted.

4. Validate evidence

Depending on the task, WorkJinn checks files, chapter size, forbidden markers, command output, or build/smoke logs.

5. Retry when needed

If review says the output is not good enough, WorkJinn can run another focused pass.

6. Hand off

Completion artifacts make it easier to see what was done and what still needs attention.

Clear limits

WorkJinn is not a guarantee that every AI run will finish a complex project. Local models can still produce weak text, bad code, or incomplete plans. The point of WorkJinn is to reduce that risk by keeping the work structured, recoverable, and reviewable. You should still inspect important output before publishing, shipping, or deploying it.

Get started

Download V21 Downloads: -- Business and team use