loki-mode
Autonomous multi-agent orchestration for end-to-end product deployment.
Install
mkdir -p .claude/skills/loki-mode && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/6805" && unzip -o skill.zip -d .claude/skills/loki-mode && rm skill.zipInstalls to .claude/skills/loki-mode
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Multi-agent autonomous startup system for Claude Code. Triggers on "Loki Mode". Orchestrates 100+ specialized agents across engineering, QA, DevOps, security, data/ML, business operations, marketing, HR, and customer success. Takes PRD to fully deployed, revenue-generating product with zero human intervention. Features Task tool for subagent dispatch, parallel code review with 3 specialized reviewers, severity-based issue triage, distributed task queue with dead letter handling, automatic deployment to cloud providers, A/B testing, customer feedback loops, incident response, circuit breakers, and self-healing. Handles rate limits via distributed state checkpoints and auto-resume with exponential backoff. Requires --dangerously-skip-permissions flag.Key capabilities
- →Orchestrate specialized agent sub-tasks
- →Manage parallel code review pipelines
- →Execute autonomous deployment tasks
- →Maintain task state via JSON orchestrator
- →Self-heal via error-catching loops
How it works
Uses a distributed task queue and multi-agent consensus to progress through defined project phases based on state updates.
Inputs & outputs
When to use loki-mode
- →Executing end-to-end product deployment
- →Orchestrating specialized subagents for development tasks
- →Managing complex project state and task queues
- →Automatic incident response and self-healing
About this skill
Loki Mode - Multi-Agent Autonomous Startup System
Version 2.35.0 | PRD to Production | Zero Human Intervention Research-enhanced: OpenAI SDK, DeepMind, Anthropic, AWS Bedrock, Agent SDK, HN Production (2025)
Quick Reference
Critical First Steps (Every Turn)
- READ
.loki/CONTINUITY.md- Your working memory + "Mistakes & Learnings" - RETRIEVE Relevant memories from
.loki/memory/(episodic patterns, anti-patterns) - CHECK
.loki/state/orchestrator.json- Current phase/metrics - REVIEW
.loki/queue/pending.json- Next tasks - FOLLOW RARV cycle: REASON, ACT, REFLECT, VERIFY (test your work!)
- OPTIMIZE Opus=planning, Sonnet=development, Haiku=unit tests/monitoring - 10+ Haiku agents in parallel
- TRACK Efficiency metrics: tokens, time, agent count per task
- CONSOLIDATE After task: Update episodic memory, extract patterns to semantic memory
Key Files (Priority Order)
| File | Purpose | Update When |
|---|---|---|
.loki/CONTINUITY.md | Working memory - what am I doing NOW? | Every turn |
.loki/memory/semantic/ | Generalized patterns & anti-patterns | After task completion |
.loki/memory/episodic/ | Specific interaction traces | After each action |
.loki/metrics/efficiency/ | Task efficiency scores & rewards | After each task |
.loki/specs/openapi.yaml | API spec - source of truth | Architecture changes |
CLAUDE.md | Project context - arch & patterns | Significant changes |
.loki/queue/*.json | Task states | Every task change |
Decision Tree: What To Do Next?
START
|
+-- Read CONTINUITY.md ----------+
| |
+-- Task in-progress? |
| +-- YES: Resume |
| +-- NO: Check pending queue |
| |
+-- Pending tasks? |
| +-- YES: Claim highest priority
| +-- NO: Check phase completion
| |
+-- Phase done? |
| +-- YES: Advance to next phase
| +-- NO: Generate tasks for phase
| |
LOOP <-----------------------------+
SDLC Phase Flow
Bootstrap -> Discovery -> Architecture -> Infrastructure
| | | |
(Setup) (Analyze PRD) (Design) (Cloud/DB Setup)
|
Development <- QA <- Deployment <- Business Ops <- Growth Loop
| | | | |
(Build) (Test) (Release) (Monitor) (Iterate)
Essential Patterns
Spec-First: OpenAPI -> Tests -> Code -> Validate
Code Review: Blind Review (parallel) -> Debate (if disagree) -> Devil's Advocate -> Merge
Guardrails: Input Guard (BLOCK) -> Execute -> Output Guard (VALIDATE) (OpenAI SDK)
Tripwires: Validation fails -> Halt execution -> Escalate or retry
Fallbacks: Try primary -> Model fallback -> Workflow fallback -> Human escalation
Explore-Plan-Code: Research files -> Create plan (NO CODE) -> Execute plan (Anthropic)
Self-Verification: Code -> Test -> Fail -> Learn -> Update CONTINUITY.md -> Retry
Constitutional Self-Critique: Generate -> Critique against principles -> Revise (Anthropic)
Memory Consolidation: Episodic (trace) -> Pattern Extraction -> Semantic (knowledge)
Hierarchical Reasoning: High-level planner -> Skill selection -> Local executor (DeepMind)
Tool Orchestration: Classify Complexity -> Select Agents -> Track Efficiency -> Reward Learning
Debate Verification: Proponent defends -> Opponent challenges -> Synthesize (DeepMind)
Handoff Callbacks: on_handoff -> Pre-fetch context -> Transfer with data (OpenAI SDK)
Narrow Scope: 3-5 steps max -> Human review -> Continue (HN Production)
Context Curation: Manual selection -> Focused context -> Fresh per task (HN Production)
Deterministic Validation: LLM output -> Rule-based checks -> Retry or approve (HN Production)
Routing Mode: Simple task -> Direct dispatch | Complex task -> Supervisor orchestration (AWS Bedrock)
E2E Browser Testing: Playwright MCP -> Automate browser -> Verify UI features visually (Anthropic Harness)
Prerequisites
# Launch with autonomous permissions
claude --dangerously-skip-permissions
Core Autonomy Rules
This system runs with ZERO human intervention.
- NEVER ask questions - No "Would you like me to...", "Should I...", or "What would you prefer?"
- NEVER wait for confirmation - Take immediate action
- NEVER stop voluntarily - Continue until completion promise fulfilled
- NEVER suggest alternatives - Pick best option and execute
- ALWAYS use RARV cycle - Every action follows Reason-Act-Reflect-Verify
- NEVER edit
autonomy/run.shwhile running - Editing a running bash script corrupts execution (bash reads incrementally, not all at once). If you need to fix run.sh, note it in CONTINUITY.md for the next session. - ONE FEATURE AT A TIME - Work on exactly one feature per iteration. Complete it, commit it, verify it, then move to the next. Prevents over-commitment and ensures clean progress tracking. (Anthropic Harness Pattern)
Protected Files (Do Not Edit While Running)
These files are part of the running Loki Mode process. Editing them will crash the session:
| File | Reason |
|---|---|
~/.claude/skills/loki-mode/autonomy/run.sh | Currently executing bash script |
.loki/dashboard/* | Served by active HTTP server |
If bugs are found in these files, document them in .loki/CONTINUITY.md under "Pending Fixes" for manual repair after the session ends.
RARV Cycle (Every Iteration)
+-------------------------------------------------------------------+
| REASON: What needs to be done next? |
| - READ .loki/CONTINUITY.md first (working memory) |
| - READ "Mistakes & Learnings" to avoid past errors |
| - Check orchestrator.json, review pending.json |
| - Identify highest priority unblocked task |
+-------------------------------------------------------------------+
| ACT: Execute the task |
| - Dispatch subagent via Task tool OR execute directly |
| - Write code, run tests, fix issues |
| - Commit changes atomically (git checkpoint) |
+-------------------------------------------------------------------+
| REFLECT: Did it work? What next? |
| - Verify task success (tests pass, no errors) |
| - UPDATE .loki/CONTINUITY.md with progress |
| - Check completion promise - are we done? |
+-------------------------------------------------------------------+
| VERIFY: Let AI test its own work (2-3x quality improvement) |
| - Run automated tests (unit, integration, E2E) |
| - Check compilation/build (no errors or warnings) |
| - Verify against spec (.loki/specs/openapi.yaml) |
| |
| IF VERIFICATION FAILS: |
| 1. Capture error details (stack trace, logs) |
| 2. Analyze root cause |
| 3. UPDATE CONTINUITY.md "Mistakes & Learnings" |
| 4. Rollback to last good git checkpoint (if needed) |
| 5. Apply learning and RETRY from REASON |
+-------------------------------------------------------------------+
Model Selection Strategy
CRITICAL: Use the right model for each task type. Opus is ONLY for planning/architecture.
| Model | Use For | Examples |
|---|---|---|
| Opus 4.5 | PLANNING ONLY - Architecture & high-level decisions | System design, architecture decisions, planning, security audits |
| Sonnet 4.5 | DEVELOPMENT - Implementation & functional testing | Feature implementation, API endpoints, bug fixes, integration/E2E tests |
| Haiku 4.5 | OPERATIONS - Simple tasks & monitoring | Unit tests, docs, bash commands, linting, monitoring, file operations |
Task Tool Model Parameter
# Opus for planning/architecture ONLY
Task(subagent_type="Plan", model="opus", description="Design system architecture", prompt="...")
# Sonnet for development and functional testing
Task(subagent_type="general-purpose", description="Implement API endpoint", prompt="...")
Task(subagent_type="general-purpose", description="Write integration tests", prompt="...")
# Haiku for unit tests, monitoring, and simple tasks (PREFER THIS for speed)
Task(subagent_type="general-purpose", model="haiku", description="Run unit tests", prompt="...")
Task(subagent_type="general-purpose", model="haiku", description="Check service health", prompt="...")
Opus Task Categories (RESTRICTED - Planning Only)
- System architecture design
- High-level planning and strategy
- Security audits and threat modeling
- Major refactoring decisions
- Technology selection
Sonnet Task Categories (Development)
- Feature implementation
- API endpoint development
- Bug fixes (non-trivial)
- Integration tests and E2E tests
- Code refactoring
- Database migrations
Haiku Task Categories (Operations - Use Extensively)
- Writing/running unit tests
- Generating documentation
- Running bash commands (npm install, git operations)
- Simple bug fixes (typos, imports, formatting)
- File operations, linting, static analysis
- Monitoring, health checks, log analysis
- Simple data transformations, boilerplate generation
Parallelization Strategy
# Launch 10+ Haiku agents in parallel for unit test suite
for test_file in test_files:
---
*Content truncated.*
When not to use it
- →For small, single-file edits
- →When full autonomy poses risk to production data
Prerequisites
Limitations
- →High token usage cost per execution
- →Complexity makes debugging state transitions difficult
How it compares
It manages an entire multi-agent startup system internally instead of performing single-agent operations.
Compared to similar skills
loki-mode side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| loki-mode (this skill) | 1 | 6mo | Review | Advanced |
| workflow-router | 1 | 7mo | Review | Intermediate |
| wg | 0 | 2mo | Review | Advanced |
| run-tasks | 0 | 7mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by davila7
View all by davila7 →You might also like
workflow-router
parcadei
Goal-based workflow orchestration - routes tasks to specialist agents based on user goals
wg
graphwork
Use this skill for task coordination with WG. Triggers include "wg", task graphs, multi-step projects, tracking dependencies, coordinating agents, or when you see a .wg directory.
run-tasks
JeremyKalmus
Orchestrate task execution via beads and sub-agents. Gets ready work from beads, spawns appropriate agents based on labels, monitors completion, and updates status. Use after /approve-spec has created tasks.
start-dev-team
trysmr
>
rudhra-swarm
Abhishek21g
Orchestrate multiple specialized agents or agent roles for a project. Use when the user says "rudhra swarm", "spin multiple agents", "orchestrate agents", "parallel agents", "agent team", "multi-agent review", or asks Rudhra to split work across mapper, researcher, implementer, tester, reviewer, and
sprint-checkin
twardcox
Start of sprint: carry-over, goals, blockers, sprint plan artifact; get_slash_command: sprint-checkin