Run /fl on a ticket with moflo's three standing considerations loaded first — cross-platform (Rule
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
$ARGUMENTS
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.
| # | 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. |
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.
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>" })
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).
| 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 |
.claude/skills/fl/SKILL.md — the workflow this wrapsCLAUDE.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/No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Turn a vague idea into a concrete, actionable spec through a short Socratic dialogue, then hand the result off to an existing moflo surface — a /flo ticket, a spell, or memory. Use BEFORE you have a defined unit of work, when the goal is still fuzzy.
The English summary is being prepared. Showing the original description.
Scaffold new spell step commands and connectors. Use when building new step commands for spells or extending the spell engine with new capabilities. Connectors are for new I/O transport types OR platforms requiring complex multi-step interaction (e.g., browser-based automation).
The English summary is being prepared. Showing the original description.
Alias for /flo-simplify — see that skill's description.
The English summary is being prepared. Showing the original description.
Structured multi-hop web research with explicit confidence gating — plan the inquiry, search (WebSearch/WebFetch), score your own confidence, and keep digging until the answer is well-supported or a hop cap is hit, then emit a cited synthesis. Learns across sessions by storing each research case to memory and reusing prior strategies. Use when a question needs more than one search — comparisons, current-best-practice questions, anything where a single lookup leaves you unsure.
The English summary is being prepared. Showing the original description.
Consult the Eldar — audit a project's moflo + Claude Code setup for portable, high-leverage gaps and guide remediation. Default mode is read-only audit with severity-ranked findings; --fix presents an interactive triage menu and walks the user through each chosen fix (healer, missing CLAUDE.md, sparse guidance, hook/MCP wiring, empty memory namespaces, stack→guidance gaps). Use when starting in a new project, when Claude feels lost or inefficient, when guidance/CLAUDE.md is sparse, or as a periodic health check.
The English summary is being prepared. Showing the original description.
MoFlo ticket spell - analyze and execute GitHub issues
The English summary is being prepared. Showing the original description.