New Skill: Async State Reasoning

LLMs reason in sequential chain-of-thought and naturally miss concurrent timelines in async systems. The new async-reasoning skill provides structured timeline enumeration — after any state-changing operation, enumerate ALL concurrent read
paths, not just the write path.

Applicable across frontend, backend, and infrastructure — anywhere write and read paths have different latencies.

Includes:

• 5-step analysis process (data flow mapping, init order, concurrent timeline trace, persistence boundaries, resolution strategy)
• references/patterns.md — 7 resolution patterns in pseudocode (cancel-set, enabled gating, write-through, event-driven invalidation, optimistic with rollback, disable affordances, sequential init)
• references/checklist.md — compact checklist for quick use during coding and review

Triggers on: "stale data", "cache invalidation", "optimistic update", "init order", "race condition", "data not updating", "UI shows old data after save", and more.

/plan: Layered Discovery & Scope Assessment

The planning workflow now detects when a feature spans multiple architectural concerns and recommends splitting into separate plans.

Layered Discovery

Phase 1 is now three steps:

1. Overall discovery — high-level questions only
2. Scope assessment — identify architectural concerns (presentation, domain logic, data access, infrastructure, integration). If multi-concern, recommend splitting per the separation of concerns principle. Each concern gets its own plan with explicit interface contracts to adjacent concerns.
3. Domain-specific detail — deep questions per concern, avoiding cascaded question overload

Async State Management in Architecture Design

Phase 3 now prompts for explicit state management design when the concern involves async data flows. Covers:

• Data flow mapping: source of truth, all read paths, write-to-read latency
• Init order: dependency graph, gating on prerequisites
• Concurrent timeline trace: after a write, what happens on ALL read paths simultaneously
• Persistence boundaries: what survives restarts, what the consumer expects to survive
• For presentation concerns without a UI mockup: what actions are available/disabled during async gaps

Without explicit state management design, these decisions will be made ad-hoc during implementation and will produce bugs.

Integration Templates

03_integration_summary.md and 04_integration_plan.md are now explicitly generated when the plan includes both backend and frontend work, instead of being silently skipped.

Plan Template

02_plan.md gains a "Frontend State Management" section with tables for data source latency, persistence strategy, initialization order, and user action constraints.

Full Changelog: https://github.com/Langerrr/distributed-architect/commits/v0.2.0

/review rewrite — spawn/monitor pattern

The /review command now uses the same spawn/monitor architecture as /feature-orchestrate. Each reviewer runs as an independent claude -p process with its own tools, eliminating the permission prompt spam caused by Task sub-agent tool inheritance.

New features

• --only flag for selective reviewer execution (e.g. --only simplicity,bugs). Defaults to all. See the slug table in the command for available options.
• spawn-codex.sh — dedicated spawner for OpenAI Codex CLI agents (codex exec --full-auto)

Improvements

• monitor.sh — configurable file glob via 4th parameter; extracted clear_signals() helper to reduce duplication
• spawn-agent.sh — optional PID file path override (4th arg); unset CLAUDECODE to fix nested session spawning
• review.md — references code-reviewer.md as single source of truth for focus areas and scoring rubrics instead of duplicating content
• Sentinel files — reviewer output files are touched before spawn so the monitor can detect orphaned agents

Fixes

• Nested claude -p spawning now works by unsetting CLAUDECODE and CLAUDE_CODE_ENTRYPOINT env vars

zforge v1.0.0

Template-aware development workflow plugin for Claude Code.

Features

• /plan <name> — Interactive planning with discovery, codebase exploration, and architecture design
• /compare <name> — Parallel architecture comparison with different trade-off focuses
• /plan-status — Feature status overview across all plans in the workspace
• /review [scope] — Multi-reviewer code review with two-stage verification and confidence scoring
• /track <name> — Progress tracking for features
• /feature-resume <name> — Resume implementation on existing features
• /feature-orchestrate <name> — Autonomous multi-phase execution with signal monitoring

Agents

• code-architect — Parallel architecture proposals with trade-off analysis
• code-reviewer — Confidence-scored code review (>=80 threshold)
• phase-agent — Isolated phase implementation for orchestrated execution

Scripts

• monitor.sh — Signal-based phase file watcher with liveness detection
• spawn-agent.sh — Fire-and-forget agent spawner with PID tracking
• kill-process.sh — Graceful process termination (SIGTERM → SIGKILL)
• safe-run.sh — Mutex wrapper preventing concurrent command execution

Template System

Scales from zero-file bug fixes to full 11-file feature plans in docs/{feature_name}/, including refactoring templates (10–12) and a dedicated 05_progress/ directory for phase tracking and reviews.

Compatibility

• Linux and macOS (bash 3.2+)
• All scripts use POSIX-compatible constructs — no GNU-only dependencies