Skip to main content

Guides & Customization

Advanced JARFIS patterns: meeting-to-work linking, role configuration, project profiles, gate interactions, learning system management, and workflow recovery.

Last updated: Sun Mar 15 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Master advanced JARFIS patterns — from linking meetings to work items, to customizing agent roles, managing gates, and recovering from interruptions.

Meeting-to-Work Linkage

JARFIS connects meeting outcomes directly to development workflows. Run a meeting first to produce structured outputs, then link those outputs to a work command so the entire pipeline starts with full context.

/jarfis:meetingsummary.md + decisions.md + meeting-notes.md/jarfis:work --meetingPhase 0 loads meeting context

Step-by-Step

  1. Run the meeting command with a topic:
/jarfis:meeting Define the authentication strategy for the mobile app

This produces summary.md, decisions.md, and meeting-notes.md.

  1. Link the meeting output to a work command using the --meeting flag:
/jarfis:work Implement mobile auth with biometric login --meeting auth-strategy-meeting
  1. Phase 0 (Pre-flight) automatically loads the meeting context. Agents reference meeting decisions throughout all subsequent phases.

Tip: The --meeting flag references the meeting output directory. Phase 0 loads all meeting artifacts so every agent in the pipeline has access to decisions and constraints discussed.

Role Configuration

JARFIS uses the required_roles field in .jarfis-state.json to determine which agent roles are active for a workflow. This controls which phases execute and how parallel work is distributed in Phase 4.

{
  "required_roles": {
    "backend": true,
    "frontend": true,
    "ux": false,
    "devops": false,
    "security": true
  }
}
Frontend Only
Phase 3 (UX) active, Phase 4 runs FE implementation only
backend:false
frontend:true
ux:true
devops:false
security:false
Full Stack + Security
All phases active, Phase 4 runs BE/FE/DevOps in parallel
backend:true
frontend:true
ux:true
devops:true
security:true
Backend API Only
Phase 3 (UX) skipped, Phase 4 runs BE + DevOps
backend:true
frontend:false
ux:false
devops:true
security:true

Note: JARFIS determines roles automatically during Phase T (Triage) based on the work description and project structure. You can override by editing .jarfis-state.json before approving Gate 1.

Continuing a Completed Workflow

Use /jarfis:continue to build on a completed workflow — add tests, fix edge cases, or extend scope without starting from scratch.

/jarfis:continue Add unit tests for the auth module
/jarfis:continue Fix the token refresh edge case --mode fix
Fix Mode
Skips Triage and Discovery. Goes directly to Implementation phase for targeted fixes.
--mode fix
Extend Mode
Skips Triage but runs Discovery to properly scope the new additions.
--mode extend

You can also specify the workflow to continue with --workflow path to target a specific previous workflow's output.

Project Profiles

Project profiles give JARFIS a complete understanding of your codebase — repo structure, dependencies, build tools, and conventions — so every workflow starts with accurate project context.

  1. 1
    /jarfis:project-init — Generates .jarfis/project-profile.md by analyzing your repository structure, dependencies, build tools, and conventions.
  2. 2
    /jarfis:project-update — Refreshes the profile when your project evolves, without losing any manual context you've added.

Tip: Run /jarfis:project-init once when you first set up JARFIS in a repo, then use /jarfis:project-update after major dependency or structure changes.

Working with Gates

Gates are the primary mechanism for human oversight. Each gate offers specific actions to control workflow direction.

Gate 1 — After Phase 1 (Discovery)
Review the PRD, feasibility analysis, and scope definition. This is your cheapest opportunity to change direction.
ApproveReviseAbort
Gate 2 — After Phase 2 & 3 (Architecture + UX)
Review architecture decisions, task breakdown, and UX designs. Check tasks.md carefully — missing tasks mean missing features.
ApproveReviseAbort
Gate 3 — After Phase 5 (Review & QA)
Review all implementation, test results, and security findings. "Revisit design" sends back to Phase 2 for fundamental architecture issues.
ApproveRevise & re-reviewAbortRevisit design

Important: Minutes spent at Gate 1 save hours at Gate 3. Early course corrections are dramatically cheaper than late ones. Review thoroughly at every gate.

Managing the Learning System

JARFIS operates a two-tier learning system that improves output quality over time through accumulated project knowledge.

Global
Global Learnings
Stored at ~/.claude/jarfis-learnings.md. Contains Agent Hints and Workflow Patterns shared across all projects.
Project
Project Context
Stored at .jarfis/context.md. Tech stack, conventions, business domain, and integration constraints specific to this project.

Learning Cycle

Phase 6 (Retro)learnings.mdPhase 0 (Pre-flight)Agents referenceBetter output

context.md Example

# Project Context
## Tech Stack
- Frontend: Next.js 15, TypeScript strict, Tailwind CSS 4
- Backend: FastAPI (Python 3.12), PostgreSQL 16, Redis
## Conventions
- API responses follow RFC 9457 Problem Details format
- All database models use UUID primary keys
- Commit format: conventional commits

Use /jarfis:upgrade to curate learning items — keep, edit, or remove entries to maintain quality.

Workflow Recovery After Context Compression

JARFIS persists phase and progress state on disk via .jarfis-state.json. No special resume command is needed — the system automatically detects and resumes interrupted workflows.

  1. 1
    Session dies — Connection loss, timeout, or context window compression
  2. 2
    Run /jarfis:work again — Use the same work description as before
  3. 3
    JARFIS detects existing state file — Finds .jarfis-state.json with in-progress workflow
  4. 4
    Resumes from last checkpoint — Picks up exactly where the previous session left off

Key point: There is no special resume command. Simply run /jarfis:work with the same description and JARFIS handles recovery automatically via the persisted state file.

Modifying JARFIS Itself

Use /jarfis:implement when you want to modify or extend JARFIS itself — add new commands, change agent behavior, or update the pipeline structure.

/jarfis:implement Add a /jarfis:standup command for daily status reports

How it works: /jarfis:implement understands the JARFIS system structure and applies changes across all affected files — prompt templates, command definitions, phase handlers, and documentation.

Practical Examples

Real-world usage patterns for common development scenarios:

Example 1 — Frontend-Only Work
/jarfis:work Redesign the dashboard with new chart components
Triage activates frontend + UX roles. Phase 3 (UX Design) runs, Phase 4 executes FE implementation only.
Example 2 — Full-Stack with Meeting
/jarfis:meeting Plan the multi-tenant architecture migration
/jarfis:work Implement multi-tenant data isolation --meeting tenant-architecture
Meeting produces decisions and constraints. Work command links meeting output for full-context pipeline execution.
Example 3 — Quick Fix
/jarfis:work Fix the broken pagination on the orders list
Triage classifies as a small fix. Streamlined pipeline with minimal ceremony.
Example 4 — Follow-Up on Completed Work
/jarfis:continue Add internationalization support to the auth module
Continues a previously completed workflow. Extends scope with new Discovery pass while preserving existing context.
Example 5 — Health Check
/jarfis:health
Diagnoses zombie processes, stale state files, and other workflow health issues.

Next Steps