/ijfw-workflow

name: ijfw-workflow
description: "Use when the user says: 'build', 'create', 'plan', 'new project', 'brainstorm', 'design', 'UI', 'website', 'dashboard', 'app', 'help me build', 'launch', 'book', 'campaign', or anything project-level. Skill body decides Quick vs Deep path."
context: fork
model: sonnet

IJFW Workflow

Two modes, same principles, same invariants.

• **Quick** -- 5 moves, 3-5 minutes, locked brief. For features, fixes, ideas.
• **Deep** -- 6 required modules + 3 optional, 20-45 minutes. For new projects, major refactors, launches.

Donahoe Loop: BRAINSTORM -> PLAN -> EXECUTE -> VERIFY -> SHIP -> MEASURE
              |<--- memory recall at every entry --->|
              |<--- Trident cross-audit on request --->|

> **Detailed downstream procedure** (PLAN / EXECUTE / VERIFY / SHIP, including wave dispatch, post-DONE pipeline, Phase-E cross-audit): see `references/post-brainstorm-workflow.md`. > **Deep-mode optional modules** (EXTERNAL BRIEF / ANTI-SCOPE / TRIDENT CROSS-CRITIQUE): see `references/deep-mode-optional.md`.

RUNTIME BOOTSTRAP AND FALLBACKS

Before the first workflow write or command invocation, inspect whether `.ijfw/memory/` exists so the auto-picker and empty-state opener can use that signal accurately. Then ensure `.ijfw/memory/` and `.planning/` exist before writing artifacts. If the `ijfw` CLI is unavailable in this session, continue with markdown files and visible chat checklists, then state the exact CLI command the user can run later. Optional commands such as `ijfw cross`, `ijfw design`, `ijfw recover`, `ijfw blackboard`, `ijfw team`, and `ijfw swarm` must degrade to explicit written artifacts instead of blocking the workflow.

---

AUTO-PICKER (runs first, every time)

Deterministic signals, visible reasoning, no friction.

| Signal | Points towards | |---|---| | Prompt < 15 words | Quick | | Prompt has clear verb + object | Quick | | Vague verbs alone ("improve", "fix", "handle", "deal with") | Deep | | "New project", "major refactor", "launch", "design" | Deep | | Project dir has no `.ijfw/memory/` | Deep | | Explicit "brainstorm", "quick idea", "just sketch" | Quick |

**Protocol:** 1. Read signals silently. 2. Say in one line: `Reading this as <Quick|Deep> -- <reason>. Say "go deeper" / "just quick" to switch.` 3. If signals tie, ask once: `Quick or Deep?` Accept any affirmative shortcut ("q" / "d"). 4. Start immediately. The user should never wait on a modal.

Mid-flow escalation: user can say `go deeper` at any Quick step; skill re-enters Deep at the equivalent module. Mid-flow de-escalation: `just quick` collapses the remaining Deep modules into a single LOCK.

---

EMPTY-STATE OPENER

First session in a project (no `.ijfw/memory/` or zero entries in it) is the onboarding moment. Do not stay silent. Open with one line:

> `Clean slate here. Want me to run a 5-minute Quick brainstorm on what we're building, or jump straight in?`

User replies `brainstorm` / `jump in` / custom intent. If they jump in, still offer memory hooks for the first 3 turns so decisions get captured. If they brainstorm, route into QUICK mode FRAME. Either way, `.ijfw/memory/` gets bootstrapped silently.

If memory is populated but the last handoff is >7 days old, open with a softer beat: `Welcome back -- last handoff was <N> days ago. Quick recap?` User says `recap` / `new task` / actual intent.

---

BRAINSTORM DISCIPLINE (invariants)

Hard rules. Violating any of these is a workflow failure worth auditing.

1. **One question at a time.** Never dump a numbered list and wait. Ask, get the answer, absorb, ask the next. 2. **No offscreen research.** If you dispatch an Explore / scout agent, paste a synthesis (3-5 bullets + contradictions + plan implications) in-chat BEFORE using it for anything. 3. **No skipping to the plan.** `plan.md` is written only after the user has explicitly confirmed the brief. 4. **No auto-advance.** Audit gates are user-facing checklists, not silent passes. 5. **Visible deliverables.** Every artifact (brief.md, research.md, plan.md) is summarized to the user in-chat when written. 6. **Intermediate thinking is tight output, not monologue.** Thirty words, then the next question.

Failure signatures to catch in yourself: about to write `plan.md` without user confirming brief; about to dispatch a research agent whose output will not be paraphrased back; about to say "Phase N complete, ready to build" in a turn where the user has not seen the intermediate findings.

---

MEMORY HOOK (every FRAME step)

At the start of every brainstorm or plan, call `ijfw_memory_recall` with the goal text when the memory tool is available. If it is unavailable, read the visible memory files under `.ijfw/memory/` when possible; if neither is available, continue and say `clean slate -- memory unavailable this turn`.

> I remember: decision from <project> on <date> -- <1-line summary>. Pull full context?

This is the single biggest superpower IJFW delivers. Never skip the attempt. If memory is empty, say so ("clean slate -- nothing recalled") so the silence is intentional, not absence of effort.

---

QUICK MODE -- 5 moves, 3-5 min

For focused work. Each move has ONE input slot.

Move 1 -- FRAME (45s)

• Parse the goal from the ask or ask: `Goal in one line.`
• Memory hook fires. Paste up to 3 related recalls inline.
• Rewrite vague asks into verifiable goals before echoing back. Examples: "Add validation" → "Tests for invalid inputs, then make them pass"; "Fix the bug" → "Failing repro test, then make it pass"; "Refactor X" → "Suite passes before and after, no public API changes"; "Make it faster" → "Profile hot path, change it, show the bench improved"; "Clean up the code" → "Pick one smell, fix only that, one-commit diff".
• If the ask cannot be reduced to a checkable outcome, surface that gap before proceeding.
• Echo: `So: <concise goal>. Yes?` User confirms or edits.

Move 2 -- WHY (30s)

Ask: `Why does this matter? What's broken