dev-flow

name

dev-flow

description

Lightweight development flow — the default track for everyday work. source-only changes, dev/staging live applies, and zero-user production (owner-declared). Evidence is a merged PR + green CI + one ledger line; no sealing, no successor tickets, no verdict ping-pong. Includes the one-question track test that routes irreversible or customer-visible work to prod-flow, hollow-green defenses, and a fix-plus-regression-gate rule for problems found live. Trigger phrases: "dev-flow", "start the flow", "which track", "can we ship this?".

dev-flow — lightweight development flow (default track)

English | 日本語

Principle (one line)

Concentrate rigor at irreversible mutation gates; everywhere else, ship fast and let CI + PR review + regression gates carry the discipline. Ceremony that duplicates a runtime fail-closed check is paying for the same safety twice.

This split was distilled from a real failure mode: a flow built for one-shot irreversible launches (sealed receipts, successor tickets, verdict documents) leaked into everyday development and made everything slow — while adding no safety where it was applied.

The track question (ask first, every time)

"If this fails, do we lose a non-refundable consumable (approval, signature, publication, quota) — or does a real customer see it?"

• No → this skill (lightweight, the default).
• Yes → prod-flow — the full staged flow with packet sealing and a human GO gate.

Examples:

• Lightweight: source-only changes (PR/CI cycle), live applies to dev/staging estates, production with zero real users (owner-declared — see below).
• prod-flow: customer-visible production mutation, signing/publication semantics, org-level authority (account vending, permission changes), anything that consumes a one-shot tuple.

Never carry prod-flow equipment (packets, sealing, successor tickets, write-ahead receipts) into the lightweight track.

Lightweight rules

• No sealing, no receipt-SHA reporting, no successor tickets. A failure means: fix it and run again.
• Evidence = merged PR + green CI + one appended line in the project ledger (CHANGELOG/EVENT or equivalent).
• Scout = look (read-only) and paste your notes into the issue. Read-only discipline still applies; guessing instead of looking is still forbidden.
• PoC and certification collapse into "show it working once in an isolated environment" — necessity at the implementer's discretion.
• After a live apply, leave a one-line readback (the fact, no ceremony).
• No state file. The issue / PR is the source of truth.

What is NOT cut (real gates, not ceremony)

• Hollow-green defenses. Test ownership separation (RED tests written and owned by a different lane; any implementer diff to tests = instant rejection), a held-out test at review, and real-boundary green as the merge gate. A fake environment cannot tell an honest implementation from a hollow one.
• 1 issue = 1 lane (issue-lane skill).
• Environment identification is measured, not assumed — estate mix-ups are an accident class unrelated to speed, and cutting ceremony does not license cutting this.

Zero-user production (owner-declared exception)

Production with no real users may run on this track by explicit owner ruling. The trade is a single rule:

• A problem found live is closed only with fix + a recurrence gate (regression test / QA walk / harness addition) in the same change.
• The same problem appearing live twice = the gate is defective → circuit breaker: stop and redesign the gate, don't just try harder.
• The exception expires the day real users arrive. Expiry is declared by the owner, never assumed.

This flips the discipline from pre-emptive ceremony to post-hoc hardening: release fast, find problems live, make each one structurally unrepeatable.

Review rules (no verdict ping-pong)

• No CONFORMS / NOT-CONFORMS verdict documents on this track. Review = PR approve / request-changes with inline comments.
• Reviewers state all blocking findings in the first pass (no drip-feeding). A late blocking finding that was visible in round 1 is a reviewer defect (breakage newly introduced by rework is exempt).
• Re-review checks only the delta of the requested changes.
• Two rounds without convergence = circuit breaker: stop the async ping-pong; put reviewer and implementer in one conversation, or have the owner adjudicate the remaining points.

Circuit breaker

Count progress in outcomes (merged PRs, readbacks) — not process artifacts. On 2 rejections of the same operation, 30 minutes of stall, or a second hollow-green from the same lane: stop and change the method (re-slice the issue, switch to contract-test-first, or apply a ledger-controlled gear boost).

Project adaptation

If the project has its own canonical flow document, that document wins; this skill is the default for projects without one. Pair it with prod-flow for the heavy path, and record the track ruling ("what counts as consumable / customer-visible here") in the project's canonical doc as it accumulates.