Maister Fork

• Guided workflows for features, bug fixes, enhancements, performance, research, and product design
• Auto-discovered standards from your codebase - config files, source patterns, and documentation are analyzed and enforced throughout every workflow
• Test-driven implementation with automated planning, incremental verification, and full test suite runs before completion
• Pause and resume any workflow - state is preserved across sessions
• Production readiness checks including code review, reality assessment, and pragmatic over-engineering detection

• Claude Code CLI installed and configured

/plugin marketplace add norkos/forked-maister
/plugin install maister-fork@maister-fork

After installing, restart Claude Code (/exit and relaunch) to ensure the plugin is fully loaded.

Initialize your project to auto-detect coding standards and generate project documentation:

/maister-fork:init

This scans your codebase and creates .maister/ with standards, docs, and task folders. May take a few minutes on larger projects.

If you have another project already using Maister, you can reuse its standards as a starting point:

/maister-fork:init --standards-from=/path/to/other-project

/maister-fork:development Add user profile page with avatar upload

Or just discuss your task with Claude and then run:

/maister-fork:development

The plugin picks up context from your conversation - no arguments needed.

1. You describe a task - either as an argument or just in conversation
2. The plugin classifies it (feature, bug, enhancement, etc.) and proposes a workflow
3. You confirm, and it guides you through phases: requirements → spec → plan → implement → verify
4. At each phase, it asks for your input and decisions
5. You get tested, verified code with a detailed work log

All artifacts are saved in .maister/tasks/ organized by type and date.

Every workflow command works without arguments. The plugin reads your current conversation to extract the task description and auto-detect the task type:

You: "The login page throws a 500 error when the session expires"
You: /maister-fork:development
→ Auto-detects: bug fix, extracts description from conversation

You: /maister-fork:standards-update
→ Scans conversation for patterns like "we always use..." or "prefer X over Y"

You can always be explicit when you prefer - arguments and flags simply override the auto-detection.

Task type (feature/bug/enhancement) is auto-detected from context. Override with --type=feature|bug|enhancement if needed. Or use /maister-fork:work as a single entry point that routes to the right workflow.

For smaller tasks that don't need a full workflow:

This is the key differentiator. Maister doesn't just run workflows - it learns your project's conventions and enforces them:

• /maister-fork:init scans config files, source code, and documentation to auto-detect your coding standards
• Continuous checking - standards are consulted before specification, during planning, and while coding (not just at the start)
• /maister-fork:standards-discover refreshes standards from your evolving codebase
• /maister-fork:standards-update lets you add or refine standards manually, or sync from another project with --from=PATH

Standards live in .maister/docs/standards/ and are indexed in .maister/docs/INDEX.md.

Important: Run workflows with auto-accept edits enabled. Do not use Claude Code's plan mode with workflows (see Best Practices below).

This plugin is a fork of Maister by Marek Kaluzny (SkillPanel.com), originally published at SkillPanel/maister under the marketplace name maister-plugins. The fork was taken from upstream version 2.2.3 (commit f75ef4f) and renamed to maister-fork so it can coexist with, and never be confused for, the original. All credit for the workflow design belongs to the original author; this fork only removes and hardens components for use on private codebases.

Every change below was made for one reason: this fork is used against private company code, on a self-hosted model endpoint, and nothing derived from that code may leave the machine except the model call itself. Features were removed rather than disabled so that a stray instruction cannot re-enable them.

What is deliberately unchanged: the development, performance, research, and product-design workflows; all standards discovery; all verification agents; the operator dashboard and HTML companion reports; the .maister/ directory layout.

What is left to the operator (see Security posture below): the WebSearch and WebFetch tools and the gh, az, jira, and acli command-line tools are still mentioned by a few workflows and must be denied through permission settings if outbound access is not wanted.

This fork is meant to run against internal code without sending anything outside your environment beyond the model call itself.

What the plugin never does: no telemetry, no analytics, no remote endpoints, no CDN-loaded scripts, no MCP servers. Hook scripts and the mockup preview server are local-only and contain no network calls. All workflow artifacts are written under .maister/ inside the analyzed repository, and /maister-fork:init adds .maister/tasks/ to the project's .gitignore.

What still needs a permission rule: a few workflows instruct the model to use the WebSearch and WebFetch tools (research with external sources, product-design link fetching, issue URL lookup) or issue-tracker CLIs (gh, az, jira, acli). Deny them in the settings you deploy with the plugin if outbound access is not wanted:

{
  "permissions": {
    "deny": ["WebSearch", "WebFetch", "Bash(gh *)", "Bash(az *)", "Bash(jira *)", "Bash(acli *)"]
  }
}

Recommended: install jq on the host so the destructive-command hook uses exact JSON parsing (a regex fallback is used otherwise).

Don't use plan mode when starting a workflow. Planning is a built-in part of every workflow — the orchestrator creates specs, plans, and other files as it goes. Claude Code's plan mode restricts file creation, which conflicts with this. Let the workflow handle planning on its own.

Start workflows in a fresh session. This is especially useful when chaining workflows (e.g., research → development). Research and product-design artifacts already contain all the context needed, so a clean session avoids noise from prior conversation.

Chain workflows by passing a task folder. If you've completed a research or product-design workflow and want to build on those results, pass the task folder directly:

/maister-fork:development .maister/tasks/research/2026-01-12-oauth-research

You can also append additional instructions to narrow scope or guide the workflow:

/maister-fork:development .maister/tasks/product-design/2026-03-10-dashboard-redesign Implement only phase 1

Orchestrator may stall after long phases. After context compaction (which typically happens after lengthy phases like implementation), the main agent may stop progressing automatically. If you notice it's idle, just type something like "continue" or "proceed" — it will pick up where it left off. You can also re-invoke the workflow in resume mode to reload the orchestrator state:

/maister-fork:development .maister/tasks/development/2026-03-24-my-feature

MIT. The original work is copyright Marek Kaluzny (SkillPanel.com) and Maister contributors; the modifications in this fork are copyright norkos. See LICENSE. This fork is independent and is not endorsed by the original author.

• Workflow Details - phases, examples, and task structure for each workflow type
• Full Command Reference - all workflow, review, utility, and quick commands