Fuska

"Cheating is good" — (kinda) Gordon Gekko (and every smart developer)

"Fuska" means "to cheat" in Swedish — because sometimes the smartest way to build software is to let AI do the heavy lifting.

Fuska is a project management system for solo agentic development, using MegaMemory's persistent knowledge graph for semantic search and typed relationships.

Works with OpenCode and (probably, maybe, very little testing) Claude Code.

Based on gsd-opencode and Get Shit Done.

"Fuska is like having three navigators who raise the alarm if they independently spot the same hazard — and a co-driver who inspects every metre you actually drove." — Read the full pitch

It works. In a real session, the code reviewer caught a typo (this.config.workflow.workflow.mode) that would have silently broken the display — the builder fixed it, the second review passed, and the commit landed clean. See it in action ↓

New here? Check the FAQ.

See it in action — Fuska has two workflows:

• Ad-hoc tasks (/fuska-do): one command, full agent chain — real session · Quick Start
• Full projects (chapter lifecycle): init through milestone — tutorial · Getting Started

THE AUTHOR TAKES NO RESPONSIBILITY FOR DATA LOSS IN EXISTING PROJECTS. USE AT YOUR OWN PERIL.

---

What is Fuska

Fuska manages your project through initiatives (efforts), chapters (work buckets), and plans (task lists with dependencies). All state is stored in MegaMemory's knowledge graph — persistent across sessions, searchable, and compact.

The difference from regular AI coding: Fuska maintains persistent state across sessions. Your project context, decisions, and progress survive forever in MegaMemory's knowledge graph. Resume a task next week and the AI remembers exactly where you left off.

But memory is just the start. Fuska doesn't hand a vague prompt to a model and hope for the best — it plans every piece of work as structured task lists with explicit dependencies, then validates those plans before a single line of code gets written.

That validation isn't a generic checklist. A panel of three specialized reviewers interrogates each plan from different angles: one always present for baseline quality, one derived from your project type (a security auditor for web apps, a resource guardian for embedded systems), and one dynamically selected for the specific domain of the work (auth, payments, data architecture, real-time systems). When two reviewers independently flag the same problem, severity escalates automatically. By the time an executor agent touches your codebase, the plan has already survived a gauntlet designed around your project.

And validation doesn't stop at the plan. After the builder finishes, a code reviewer agent examines the actual diff — checking for bugs, security issues, and deviations from the plan. If it finds problems, the builder fixes them automatically, up to three review-fix iterations. Code gets reviewed before it's committed, not after. If the working directory was already dirty before the task started, Fuska warns you and offers options (commit, stash, skip review, or proceed) — preventing the reviewer from accidentally "fixing" unrelated changes.

Lessons learned are captured automatically — when plan-checker or code-reviewer find issues, they create lesson concepts in MegaMemory. The planner and executor query these lessons before each run, applying solutions to prevent recurring mistakes. The system gets smarter over time.

---

Quick Start

Prerequisites: Fuska must be installed and your project initialized before running these commands.

See It In Action

Just tell Fuska what you want. It researches, plans, verifies the plan, and executes with atomic commits.

Checked Mode — Validated Plans:

/fuska-do checked add dark mode toggle to settings page

1. Planner creates a focused plan (2-3 tasks, target files, verification steps)
2. Plan Checker validates the plan is complete and achievable
3. You review and approve
4. Builder runs all tasks with atomic commits
5. Code Reviewer validates the implementation against the plan (up to 3 iterations)

Verified Mode — Full Assurance:

/fuska-do verified implement OAuth login with Google and GitHub

1. Researcher investigates OAuth flows, your existing auth patterns, security considerations
2. Planner creates a detailed plan with security checkpoints
3. Plan Checker validates completeness, security, error handling
4. Builder implements with atomic commits, handles any deviations
5. Code Reviewer validates the implementation against the plan (up to 3 iterations)
6. Reviewer confirms the implementation actually works end-to-end

Four Workflow Modes

| Mode | Pipeline | Plan Review | Best For | |------|----------|-------------|----------| | planned | Planner -> Builder -> Code Reviewer | Skipped | You have a plan, just build it | | checked | Planner -> Plan Checker -> Builder -> Code Reviewer | Prompted | Plan gets validated, you review before building | | researched | Researcher -> Planner -> Plan Checker -> Builder -> Code Reviewer | Prompted | Research adds context, review before committing | | verified | Researcher -> Planner -> Plan Checker -> Builder -> Code Reviewer -> Reviewer | Skipped | Full pipeline with post-build review |

Override plan review with --review or --no-review, or set it permanently via fuska config (interactive_review). Commit always prompts by default — override per-invocation with --auto-commit to skip the prompt. Skip code review with --no-code-review. For details, see workflow.md.

Prefer hands-on control? The chapter lifecycle gives you the full step-by-step sequence — design, plan, build, review — each as a separate command you run when you're ready. More deliberate, more visibility at each stage. See workflow.md or follow the tutorial.

---

Key Concepts

Initiative — An effort, not a codebase. "I want to build push notifications" is an initiative. You can have multiple in one codebase, each with its own requirements and roadmap.

Chapter — A deliverable work bucket with a goal, requirements, and success criteria. Chapters are worked through sequentially: plan -> build -> review.

Plan — A detailed task list with dependencies, grouped into batches (parallel execution groups). Generated by the planner agent for each chapter.

MegaMemory — The persistent knowledge graph backing everything. Replaces .planning/ markdown files with O(1) semantic search, typed relationships, and 4.4x more compact storage.

For the full mental model, glossary, and edge relations, see concepts.md.

---

Installation

npm install -g fuska-magistern@latest
fuska install

Select your provider (opencode, claude, or both) when prompted. Fuska creates symlinks to the npm package — updates are immediate, no reinstall needed.

For platform notes, troubleshooting, and migration from old installs, see getting-started.md.

---

Getting Started

Initialize Your Project

Prefer a guided walkthrough? The tutorial walks through building a complete todo app — from fuska init through all 5 chapters to milestone completion — with real session output at every step. For a quicker look at the ad-hoc workflow, see the /fuska-do session.

fuska init [description]

Creates the project foundation:

• Initializes git repo (if needed)
• Creates .megamemory/ database
• Creates a "main" initiative automatically (with state, roadmap, milestones, todos, and research modules)
• Registers MegaMemory as an MCP server (megamemory install --target <target>)
• For Claude Code: writes .claude/settings.local.json with mcp__megamemory permission so tool calls proceed without prompts
• Maps codebase structure, business domains, and import graph (unless --no-map)

Requires a provider configured via fuska install. See MegaMemory MCP Setup for details and manual fallback.

Arguments:

• description — Optional description stored with the initiative

Options:

• --no-map — Skip codebase mapping (run fuska map later)

Examples:

# Full init with description and mapping
fuska init "A blog platform with user authentication"

# Quick init without mapping
fuska init --no-map "My new project"

Configure the Initiative

Launch OpenCode (or Claude Code), then run:

/fuska-configure [--mode yolo|interactive] [--depth quick|standard|comprehensive] 
                 [--parallel true|false] [--commits per-chapter|per-plan|per-task]
                 [--research yes|no] [--plan-check yes|no] [--verifier yes|no]

Walks through initiative configuration:

• Deep questioning (or uses stored description if provided)
• Workflow preferences (mode, depth, parallelization, commits)
• Research domain ecosystem (optional)
• Define requirements
• Create roadmap with chapters

If you provided a description during init: Questioning is streamlined — Fuska derives context from your description.

If no description: Full interactive questioning.

With all arguments: Skip all questions entirely:

/fuska-configure --mode yolo --depth quick --parallel true --commits per-chapter --research yes --plan-check yes --verifier yes

CLI Quick Reference

Outsi