joedevflow
Development workflow. Use when building a feature, creating an MVP, refactoring code, fixing a bug, or any task that involves writing or changing implementation code.
Free to install — no account needed
Copy the command below and paste into your agent.
Instant access • No coding needed • No account needed
What you get in 5 minutes
- Full skill code ready to install
- Works with 4 AI agents
- Lifetime updates included
Description
--- name: joedevflow description: Development workflow. Use when building a feature, creating an MVP, refactoring code, fixing a bug, or any task that involves writing or changing implementation code. argument-hint: "[design|test|implement|debug]" --- Work happens in exactly 4 modes. Operate in one mode at a time. Do not finish working on a mode without the consent of the user. --- ### How to identify your current mode If `$ARGUMENTS` is provided, jump directly to that mode: | `$ARGUMENTS` | Action | |---|---| | `design` | Enter Mode 1 — Design | | `test` | Enter Mode 2 — Test (Red) | | `implement` | Enter Mode 3 — Implement (Green) | | `debug` | Enter Mode 4 — Observe & Debug | | empty | Read HANDOFF.md if present; otherwise ask the user which mode to start in | Fallback: infer from codebase state | Mode | You're here when... | |------|-------------------| | 1 - Design | No implementation plan exists yet, OR the user asks to plan/architect | | 2 - Test (Red) | Design is complete; no tests exist yet (or tests need to be written) | | 3 - Implement (Green) | Failing tests exist; task is to make them pass | | 4 - Observe & Debug | Tests pass; task is coverage, logging, or a bug was reported | --- ### Mode 1 — Design **Goal:** Establish the *why*, *what*, and *how* before any code is written. **Activities:** Ideation, architecture, stack/tooling choices, infrastructure scoping. **Forbidden:** Writing or editing any code in the codebase. **Output (contract to Mode 2):** A concrete, agreed spec of what will be built — specific enough that tests can be written against it. --- ### Mode 2 — Test (Red) ⚠️ Most critical mode **Goal:** Prove the spec is testable before implementation begins. **Input:** The design contract from Mode 1. **Activities:** - Write tests that will pass *only if* the correct behavior is implemented - Cover happy paths, edge cases, failure modes, and interface boundaries - Install dependencies / set up boilerplate so tests fail at *assertions*, not imports **The one rule:** A test that cannot fail for the right reasons is worse than no test. **Forbidden:** Writing implementation code (test scaffolding/boilerplate is the only exception). **Output (contract to Mode 3):** Full test suite — all red, all failing at assertions. --- ### Mode 3 — Implement (Green) **Goal:** Make the red tests pass. **Input:** The failing test suite from Mode 2. **Activities:** Write implementation code guided by what the tests express. **Forbidden:** Editing tests. If a test seems wrong, stop and ask the user — do not modify it. **Output (contract to Mode 4):** All tests passing. No test was changed. --- ### Mode 4 — Observe & Debug **Goal:** Verify the system works end-to-end and regressions are caught. **Activities:** - Run coverage; flag untested lines to the user - Write e2e tests that exercise the system from the outside — real inputs, real outputs, no mocks - If a bug is found: understand it, fix it, add a **regression test** before touching the code **Forbidden:** Fixing a bug before writing a regression test that reproduces it. **Output:** Coverage report, e2e tests passing, zero known regressions. --- **Context note:** Each mode may run in a separate agent/context window. Treat the mode's input contract as the only shared state you can rely on. ### Mode Handoff At the end of each mode, (over)write a handoff to `HANDOFF.md` at the repository root. `HANDOFF.md` is the canonical cross-mode handoff artifact. It should contain the latest authoritative handoff, replacing any previous handoff content unless the user explicitly asks for a historical log. **Mode:** <DESIGN | TEST_RED | IMPLEMENT_GREEN | OBSERVE_DEBUG> **Goal:** <what this mode was trying to accomplish> **Inputs used:** <user request, files read, tests examined, errors seen> **Changes made:** <specific files edited or created — paths and a one-line summary each> **Outputs produced:** <design doc, list of failing tests with names, passing test run output, debug findings> **Open issues:** <blockers, risks, unknowns — be specific, not vague> **Next recommended mode:** <next mode + one sentence on why>
Security Status
Scanned
Passed automated security checks
Related AI Tools
More Save Money tools you might like
Family History Research Planning Skill
FreeProvides assistance with planning family history and genealogy research projects.
Naming Skill
FreeName products, SaaS, brands, open source projects, bots, and apps. Use when the user needs to name something, find a brand name, or pick a product name. Metaphor-driven process that produces memorable, meaningful names and avoids AI slop.
Profit Margin Calculator
$7.99Find hidden profit leaks — see exactly where your money goes
guard-scanner
Free"Security scanner and runtime guard for OpenClaw skills, MCP servers, and AI agent workflows. Detects prompt injection, identity hijacking, memory poisoning, A2A contagion, secret leaks, supply-chain abuse, and dangerous tool calls with 364 static th
Life OS · Personal Decision Engine
Free"A personal decision engine with 16 independent AI agents, checks and balances, and swappable cultural themes. Covers relationships, finance, learning, execution, risk control, health, and infrastructure. Use when facing complex personal decisions (c
bbc-skill — Bilibili Comment Collector
FreeFetch Bilibili (哔哩哔哩) video comments for UP主 self-analysis. Use when the user asks to collect, download, export, or analyze comments on a Bilibili video (BV号 / URL / UID). Produces JSONL + summary.json suitable for further Claude Code analysis (senti