gerson-scanapieco/gflow
Gerson's development flow: scope work in Linear, plan it, and execute it.
Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for "create a verification skill", "make a control skill for this repo", or when a project has no scripted way to prove UI/CLI/service behavior.
Explain a piece of code, a file, a function, or a concept in plain language for a non-technical reader. Strips jargon, focuses on what it does and why it matters, and keeps the answer short.
Implement the plan posted on a Linear issue exactly as written. Creates a branch, writes tests first, implements each step, commits frequently, opens a PR, and updates the Linear issue. Requires a plan from the plan skill.
Periodic pass that keeps a project's verification skill and feature map honest: parallel source readers per feature, one live session driving every feature, at most one PR of proven corrections. Use for "maintain the verification skill" or "audit the verify skill".
Turn a specified Linear ticket into a scoped, detailed, step-by-step implementation plan and post it as a comment on the ticket. Researches the code, scopes the work (splitting it into issues or a project when it is too big for one), settles the technical decisions with the developer, and defines the ordered steps. Use after spec has created a ticket, and before impl implements it.
Audit a project's deterministic verification (formatters, linters, type checkers, secret scans, and similar tools), work with the developer to add the missing ones, and wire them into git hooks and a single check command. Use when starting on a project, or when a project has no automatic guardrails before code is committed.
Understand and clarify the work to be done, and define its acceptance criteria, from a vague problem description or rough Linear issue. Researches the codebase only as far as needed to ask the right questions, drafts a single well-defined Linear issue, and creates or updates it after developer approval. Scoping and technical design are left to plan. Use when starting new work.
Watch a GitHub pull request every 5 minutes for new review feedback, assess it, and address it after user approval, for at most 3 watch loops or until the pull request is merged or closed.