Dev-Flow Intelligent Development Workflow

Problem It Addresses

devauto-flaw targets the common failure mode of jumping from a one-line requirement directly into code. Requirements are under-confirmed, scenarios are not enumerated, edge cases are missing, and completion claims lack evidence. The issue becomes visible late, especially in multi-module systems, APIs, front-end interactions, quant strategies, or script tools, where rework costs can quickly grow.

How It Works

It organizes development into lightweight / standard / full modes. Lightweight fits bug fixes and config changes; full fits web apps and multi-module systems. Key steps include:
- Phase 1 requirement deep-dive: reads project context and wiki, then asks for goals, constraints, and success criteria before writing code.
- Phase 2 scenario modeling: captures users, environments, triggers, and failure paths, then ranks P0, P1, and P2 scenarios.
- Phases 3-4 risk and planning: produces task splits, file paths, acceptance criteria, and dependencies, rejecting placeholders such as TBD or TODO.
- Phase 5 quality gates: checks correctness, quality, security, and consistency, requiring evidence such as test output.
- Phase 5.5 enumeration testing: in full mode, can degrade through L3, L2, and L1 and use different matrices for web, scripts, and quant strategies.
- Phases 6-7 review and capture: validates requirement, scenario, and integration coverage, then writes experience into wiki or triggers self-evolution checks.

Fit and Limits

This skill fits development tasks with clear context and verifiable deliverables. Its rule that completion needs evidence can feel strict for ambiguous requirements, blocked validation, or external approval dependencies. Use lightweight mode to avoid overprocess; use full mode when P0 scenarios must pass in system-level projects.