$ARGUMENTS

/flfl — /fl with moflo's standing considerations loaded first

Purpose: run the normal /fl ticket workflow, but seat the three things that break moflo changes before any research, code, or review happens — not after a reviewer catches them.

These are not a preamble to acknowledge and move past. Hold all three for the whole run: research, implementation, tests, /flo-simplify, /verify, and the PR body.

The three considerations

#	Consideration	What it changes about the work you are about to do
1	Rule #1 — everything ships cross-platform	Linux, macOS and Windows, identically. Audit every edit for: path.join/path.sep over hardcoded separators; fs.realpathSync on both sides of any path comparison; no Foo.ts beside foo.ts; platform EOL; no bash/grep/sed/cat/find shell-outs (use Node fs/spawn); tasklist vs /proc for process checks; shell: true on Windows vs detached on POSIX when spawning; os.tmpdir() and test ports in 40000–44999. Verify against CI's macOS and Ubuntu runs, not just your own OS.
2	moflo is installed into a destination project	This is a library, not an app. Before writing code, name (a) the consumer surface touched — bin/, src/cli/, .claude/scripts/, hooks, init/, settings/CLAUDE.md generators, anything synced into node_modules/moflo/; (b) the failure mode for someone already on the current version who upgrades — does their .moflo/ state still parse, do their hooks still wire, is a migration needed; (c) the round-trip cost — does this need publish-then-reinstall to take effect. If you cannot name all three, re-scope before writing code.
3	moflo dogfoods itself	The daemon, hooks, statusline, MCP server and indexer all run from node_modules/moflo/…, not the source tree. A source edit changes nothing for those layers until publish + reinstall + Claude Code restart. Before diagnosing any "X is broken" symptom, establish which copy is actually running — diff bin/ against .claude/ against node_modules/moflo/ first. Expect local flapping: the session-start launcher re-syncs .claude/helpers/ from the installed package, so a local fix to a synced file reverts until published.

How to run

1. Restate the three considerations in one line each, mapped to this specific ticket — which surface it touches, which platform risks it carries, whether it needs a publish round-trip. Generic restatement is worthless; if a consideration genuinely does not apply, say so and why.

2. Invoke the real workflow with the arguments above, unchanged and in full — including every flag (-sd, -s, -w, -m, …):

   Skill({ skill: "fl", args: "<the $ARGUMENTS block above, verbatim>" })
   

3. Follow /fl from there. /flfl adds nothing to the workflow itself — same phases, same gates, same run-mode resolution. Re-check the three at each gate: they most often fail at /flo-simplify (a cross-platform miss) and at the PR body (an unnamed consumer failure mode).

Anti-patterns

Don't	Do
Acknowledge the three, then run /fl and never revisit them	Re-check them at implementation, simplify, and PR
Restate them verbatim from this file	Map each to the ticket's actual surface and risk
Drop or reorder $ARGUMENTS when calling /fl	Pass the argument string through untouched
Verify only on your own OS	Read the macOS and Ubuntu CI runs before claiming green
Debug a runtime symptom against the source tree	Confirm which copy is running first

See Also

• .claude/skills/fl/SKILL.md — the workflow this wraps
• CLAUDE.md — Rule #1, Rule #2, and the dogfooding section these three condense
• .claude/guidance/internal/dogfooding.md — required reading before diagnosing runtime symptoms or adding files under bin/