lean-flow

A lean agentic dev loop for Claude Code — twelve standalone skills, a one-command conductor, an opt-in decision council, and a writing utility. 15 skills · a repo scaffolder (/lean-doc-generator init) · no hooks and no agent definitions in the roster today. Drop it into any repo and adapt.

Quickstart · The skills · How it works · Architecture · Report a bug

• Why lean-flow
• Quickstart
• The loop
• The skills
• How it works
• What you get
• Adapting to your repo
• What lean-flow does NOT do
• Architecture
• Design principles
• Provenance
• License

[!NOTE] Why this exists. dev-flow was a brutal implementation — every reference bulk-imported, docs bloated past managing. lean-flow is the answer: curated, not copied — each component reviewed against "genuinely useful · important · actually used" and approved before adding. The point isn't fewer features by rule; it's that nothing gets in unreviewed.

---

Why lean-flow

Coding agents fail in recognizable ways. Each skill is the fix for one of them.

1 · It built the wrong thing. You assumed it understood you; it didn't. → /task-decomposer grills ambiguous intent at intake — by frontier round: everything whose prerequisites are settled is asked together, dependent questions wait their turn, and it stops when nothing is left assumed. It presents interpretations rather than picking silently, and its assumption registry surfaces what it's guessing; G1 Scope restates the task as one verifiable sentence; G2 re-grills anything still open (an unconfirmed assumption blocks the gate). Align before building.

2 · We keep reworking it. Scope and design problems surface only after the code exists. → The gates run before any commit; /task-decomposer cuts work into tracer-bullet vertical slices; /prototype answers a shaky design with throwaway code before you commit to it.

3 · The code doesn't work. The agent flies blind without feedback. → /tdd writes the failing test first (red-green-refactor); /diagnose builds a fast, deterministic feedback loop before hypothesising — the loop is the skill.

4 · It became a ball of mud. Agents accelerate coding, so they accelerate entropy. → /refactor-advisor finds shallow modules (the deletion test) and designs the deepening into small interfaces over deep implementations. Run it every few days.

5 · The docs rotted; the thread vanished between sessions. → /lean-doc-generator keeps docs WHY/WHERE-only against locked templates; /prime reloads context in a fixed order; /handoff carries the live thread to the next session.

6 · The backlog is chaos. Priorities drift, duplicates pile up, rejected ideas keep returning. → /triage re-ranks, states each task (ready / needs-info / blocked), and routes rejects to an .out-of-scope/ memory so they aren't re-litigated.

---

Quickstart

Claude Code

Add the marketplace and install the plugin:

claude plugin marketplace add https://github.com/aldianriski/lean-flow
claude plugin install lean-flow@lean-flow

Start a new Claude Code session, then invoke skills with slash commands such as /prime.

Codex

Add the GitHub repository as a Codex marketplace:

codex plugin marketplace add aldianriski/lean-flow

Then start Codex, enter /plugins, select the lean-flow marketplace, and install and enable Lean Flow. Start a new Codex session so its bundled skills are loaded.

Codex invokes skills with $ mentions rather than custom slash commands. Plugin skills are namespaced, so use $lean-flow:prime instead of /prime:

$lean-flow:prime Prime this repository.

You can also enter /skills and select any lean-flow:* skill. The command examples below use Claude Code's shorter /skill-name spelling; in Codex, use the corresponding $lean-flow:skill-name mention.

Kimi Code CLI

Install the plugin from GitHub (or from a local checkout), then reload:

/plugins install https://github.com/aldianriski/lean-flow
/plugins install /path/to/lean-flow     # local checkout instead
/reload

Kimi invokes skills with /skill: slash commands, so /prime becomes /skill:prime, /flow becomes /skill:flow, and so on — or just describe the task and let the model auto-invoke the skill from its description. Manifest → .kimi-plugin/plugin.json.

Two ways to run it — conducted or à la carte.

Conducted — the whole disciplined loop in one command (gates + governance enforced, never auto-approved):

/flow "add OAuth login"     # drives: prime → feed → gated build → governed close

À la carte — the same loop, your hand on each step:

/prime                               # load context + health check
/task-decomposer "add OAuth login"   # intent → TASK-NNN backlog entries
/lean-doc-generator promote          # form a sprint from the backlog
/orchestrator sprint-bulk            # build it through the G1 / G2 gates
/lean-doc-generator close            # retro → CHANGELOG · TD · LEARNINGS, then /release-patch

The rest — /triage · /diagnose · /tdd · /refactor-advisor · /prototype · /handoff — is invoked as the work needs it. Every skill also runs alone; /flow just conducts them in order.

---

The loop

  /prime ──▶ /lean-doc-generator ──▶ /orchestrator ──┐
   load          plan & document         build, gated │
     ▲           (promote / close)       (G1 → G2 → ship)
     │                                                 │
     └──────────────────── repeat ◀────────────────────┘

  session end → /handoff  ──▶  temp-dir doc  ──▶  next session: /prime reads it

1. /prime — load project context in a fixed order, emit a health check (including a Skills: row: is the plugin copy this session loaded the same version as the repo, or stale?).
2. /lean-doc-generator — capture WHY/WHERE (never HOW); run the sprint lifecycle.
3. /orchestrator — execute through the G1 Scope and G2 Design gates, then commit.
4. Repeat. When a session ends mid-work, /handoff compacts it so /prime can resume next time.

Run it conducted (/flow drives every stage in order, gates enforced) or à la carte (each skill by hand) — same artifacts either way.

---

The skills

One conductor + twelve standalone stages + an opt-in decision council + a writing utility (/humanizer). /flow conducts; the twelve stage-skills each also run standalone (none require another); /council is for hard forks.

Stage	Skill	Use it for
conduct	/flow	opt-in — run the whole loop in order; enforces gates + governance, never auto-approves
orient	/prime	session start — ordered context load + health check (incl. whether the installed skills match the repo)
plan	/lean-doc-generator	docs / ADRs / sprint promote + close (WHY & WHERE only) — ships its own templates + standard
	/task-decomposer	intent / ticket / PRD → TASK-NNN backlog entries (tracer-bullet slices; or a fog-map for foggy work too big to plan)
	/triage	re-prioritise + state the backlog; route rejects to .out-of-scope/
build	/orchestrator	gate-driven execution — quick · mvp · sprint-bulk · overnight
	/prototype	throwaway code to answer one design question (logic TUI / web UI variants / customer-review demo)
	/tdd	build NEW behaviour test-first — vertical-slice red-green-refactor
maintain	/diagnose	6-phase systematic debugging with a regression test
	/refactor-advisor	find shallow→deep refactors (seams · deletion test) and design them
ship	/release-patch	manifest-detect PATCH bump + changelog; stops before push
continuity	/handoff	compact the conversation → temp-dir doc for the next session
learn	/insights	capture a friction → an L-NNN learning candidate anytime; bumps a match toward promotion
decide	/council	opt-in — pressure-test a hard/ambiguous call via 5 advisors → a calibrated (pre-mortem · confidence+dissent · optional gated fact-verify) → feed an ADR (uses sub-agents)

The feed side is a pipeline: /task-decomposer (intake) → /triage (groom) → /lean-doc-generator promote (form sprint) → /orchestrator (build). Canonical roster · gates · modes → .claude/CONTEXT.md.

[!NOTE] Standalone, not isolated. Skills cross-reference each other only as routing/handoff suggestions (→ try /X next), never as requirements — invoke any one cold and it completes its own job. The pipeline and routing are the optimal composition, not a dependency graph. The only inherent ordering is the sprint lifecycle (you can't close a sprint you didn't promote).

Workflow packs

packs/ holds workflow packs: lean-flow procedures written to packs/CONTRACT.md so that any agent can follow one from its single file, with nothing installed. Take one by copying its file. The packs so far are packs/software-implementation.md, packs/verification.md and packs/solution-analysis.md.

---

How it works

A gated loop: you give intent → it becomes tasks → executes with human checkpoints → ships. The gates are inline checklists (lean-flow ships no agent definitions of its own), and the loop dispatches Claude's built-in agents where they help — recon → Explore, review → /code-review, verify → /verify, security → /security-review. /council is the one skill that orchestrates sub-agents internally.

Gates — humans approve; the skill never self-approves:

• G1 Scope (all modes) — goal restated as one verifiable sentence · size S/M/L (an L splits) · files / blast-radius · out-of-scope named · assumptions confirmed.
• G2 Design (mvp · sprint-bulk) — approach + one-line WHY · verifiable micro-tasks · an ADR only if the decision is hard-to-reverse and surprising and a real trade-off · a fresh-reader builder check before sign-off (contradictions with the Done-when, open questions) · residual grill until the goal is unambiguous (the detailed grill already ran at intake, in /task-decomposer).

Before any parallel wave, sprint-bulk also runs a mechanical pre-dispatch preflight — cycle · shared-file single-owner · declared-base-vs-HEAD · wave computation — all derived from tokens your sprint Plan already carries, so there is nothing extra to maintain. A failure halts that wave with a named finding. Not a human gate (nothing to approve); it just refuses to fan out work whose ordering is unsafe.

Validation runs where the work happens, not only at close. A worktree builder or reviewer installs your dependencies by your own install procedure and runs the leg that needs them (a typecheck, usually) before it reports, so a type error surfaces before merge-back. After each merge the coordinator runs your documented merge-back check, a fixed set of cross-cutting legs (or your discovered gate, the repo-wide one over a unit-only script), and ticks verified boxes in that same session. A review also runs the existing tests that pin what the change touches, searched by path, file name and exported names, and reports them in their own section. The self-review checklist also carries a code-slop box.

Plan-mode approvals — quick/mvp record the owner's G1/G2 approval on the task file (gates_signed: + ## Approved design). You MAY set Claude Code's plansDirectory setting to a repo folder so plan mode's own plan file is kept; the task's record then cites that file. lean-flow never edits a settings file.

Modes (/orchestrator <mode>) — three: quick (single small low-risk task, G1 only) · mvp (feature work, medium+, G1+G2) · sprint-bulk (auto-loop the active sprint's member tasks, G1+G2 once) — full mode/gate contract → .claude/CONTEXT.md (SSOT).

Unattended runs (overnight) — a promoted sprint can be executed headless while you sleep: claude -p "/orchestrator overnight" --permission-mode dontAsk --allowedTools "<scoped list>", fired by cron / Task Scheduler. overnight is the canonical name — it names the contract the mode runs, not the script that launches it — and the older night-run · unattended · sprint-bulk unattended all still work, so nothing you have already scripted breaks. An unrecognised mode string is refused rather than quietly defaulted. The charter is execute-only — the run executes a Plan a human already approved and decides nothing new. Two rules make that safe. Unattended is declared, never inferred (no signal → it behaves interactively). And absence ≠ consent: a headless session has no ask channel at all — AskUserQuestion isn't registered there and dontAsk auto-denies anything that would prompt — so a missing channel, a denial, or a missing human is a BLOCK, never a default-yes and never an invitation to reason the answer out and carry on. Anything needing a human (a gate, a grill, promote's governance sign-off, close's §11 retention, a /triage apply) is parked — recorded with its unblock condition — while disjoint AFK work carries on; the run then halts cleanly through /handoff, and morning /prime reads it back. It never reshapes a task to dodge a gate. bypassPermissions is never the fallback.

Every run reports how much of the Plan it finished. A sprint-bulk loop is driven by the model, and nothing outside it checks the Plan was exhausted — so a run can end after four of seven tasks with every commit correct and still exit success, saying nothing about the three it never began. The morning rollup therefore opens with run · N of M DoD ticked at every exit, and unattempted is a state alongside blocked, parked, denied and stalled. Asking the run to write that was tried and measured: it completed all its work and wrote none of its bookkeeping. So the bundled launcher scripts/night-run.sh emits the rollup and the cost row itself, from the wrapper that outlives the model — and the QA gate fails a recorded run that is missing one. It also writes a fired · line to the sprint's log before the run starts, so a run that dies before reporting is still on record and the sprint cannot close past it. Fire claude -p directly instead and the format still applies; you just have no guarantee it was written (ADR-016). Pre-flight + contract → skills/orchestrator/references/night-run.md.

Implement routing — at the build step, orchestrator routes by work type: new testable behaviour → /tdd · a bug or failing test → /diagnose · hard-to-change code → /refactor-advisor · docs / config / spikes implement directly. It also wires Claude's built-in commands — /goal (drive-until-DoD) · /plan (G2) · /batch (parallel sprint) · /run + /verify (Review).

Documentation discipline — /lean-doc-generator follows the LEAN DOCUMENTATION STANDARD: WHY and WHERE only, never HOW. Its core is the TemiDev repo-structure standard (ADR-012) — a tiered scaffold (base → backend/integration → medium/complex → multi-service) where every doc carries a full create/update/archive lifecycle trigger, gated by a §12 Git-boundary rule (what belongs in the repo vs a secret manager / document store) that migrate also scans for on adoption. It bundles its own canonical templates and reads the matching one before generating any core doc, so output matches a fixed format instead of free-improvising; init's only non-doc writes are a safe-scaffold allowlist (.env.example · .gitignore · LICENSE, write-if-absent, never overwritten). Standard → spec/STANDARD.md, versioned independently (spec/CHANGELOG.md).

Continuous learning — every iteration feeds the next. At Sprint Close the Retro auto-files four buckets to durable homes — shipped → CHANGELOG, tech debt → TD-NNN (root TECH-DEBT.md), follow-ups → TASK-NNN backlog, learnings → LEARNINGS.md. At Sprint Promote a governance checkpoint promotes any learning that recurs (count ≥ 2) into a durable rule and ages tech debt. Learning and debt can't silently rot. Governance → STANDARD §10.

---

What you get

The skills write durable, human-readable state into your repo — plain markdown, no database, no lock-in:

Artifact	Written by	Holds
docs/work/<status>/TASK-NNN-*.md	/task-decomposer · /triage · /orchestrator	one file per task — the folder is its status (backlog/ → todo/ → in_progress/ → review/ → done/ | cancel/)
TECH-DEBT.md	sprint close · /triage	tech-debt ledger (TD-NNN — filed at close, aged at promote)
docs/product/roadmap.md	/lean-doc-generator roadmap	a phased delivery plan across ≥ 2 sprints or epics: one row per vertical slice with Status + Covered by. /task-decomposer --roadmap <row> decomposes one row; /prime and /triage flag an active row nothing covers; promote warns. Skip it for a single-sprint plan
docs/epic/EPIC-NNN-*.md	/lean-doc-generator epic	a multi-sprint outcome + the sprints that carried it. Skip it when the work fits one sprint. While active, each open Closed-when line ends → TASK-NNN or → next slice: <name>; /triage and /prime flag the uncovered ones and promote refuses to form a sprint over one
docs/sprint/SPRINT-NNN-*.md	/lean-doc-generator	active sprint plan · files changed · retro (400-line hard cap)
docs/sprint/logs/SPRINT-NNN-*.md	/lean-doc-generator at promote · /orchestrator during execution	that sprint's execution log (created at promote) — append-only, uncapped, so it never eats the Plan's budget (ADR-014)
docs/DECISIONS.md / docs/adr/	/lean-doc-generator	ADRs — the WHY behind hard-to-reverse choices
CHANGELOG.md	/release-patch · sprint close	what shipped, per release
docs/LEARNINGS.md

Commit them, and your team — and their agents — start from the same map.

---

Check your repo against the standard

The documentation standard lean-flow follows lives in spec/STANDARD.md, versioned independently of the plugin. One script tells you how your repository measures against it — no install required, and it works on a repo that has never heard of lean-flow:

sh conformance.sh /path/to/your-repo

You get a conformance level, the named findings preventing the next one, and the items the standard deliberately leaves to a human:

FAIL  ownership-header-missing: docs/architecture.md -- no YAML frontmatter block; §3 makes the
      ownership header mandatory on every doc (S3.SCHEMA)
GAP   S2.F-FILE  -- rule-unimplemented: the spec marks this mechanical at level Structural and this
      engine has no assertion for it yet ... it is a gap in THIS ENGINE, so it does not enter the
      level below or the exit code
      level: none -- Structural not yet reached. 2 finding(s) at Structural prevent it
      coverage: 33 checkable rule(s) have an assertion in this engine; 18 are unchecked

Three things it will not do:

• No score, no grade, no percentage. Counts only. A ratio would improve every time the standard declined to automate something, which is backwards.
• Our gaps are not your findings. A rule the standard states that the engine cannot yet check is a GAP — always named, never silently skipped, but it never blocks your level or fails your build. Coverage is reported as its own number so you can see what was actually checked.
• It never blocks. Exit code is non-zero exactly when a finding about your repository was printed, so you may gate CI on it if you want to — but lean-flow ships no workflow file and owns no pipeline (ADR-027).

Three conventions you can set, all optional: --spec <path> points it at your own vendored copy of the standard; --rev <commit-ish> chooses the commit §13's attestation rules read (default HEAD); and three declared files let a repository state facts the standard says are judged, not detected — .conformance-roles (one role per line) declares the role vocabulary owner: is checked against, .conformance-tier (one token: base · backend · medium · multi-service) declares your §6 tier, and .conformance-exempt (one row per line, <path> -- <reason>) declares a tier doc you have ruled unnecessary and can say why — the reason is required, every accepted exemption is printed back to you with it, and a row without one is reported while the doc stays owed (ADR-031). A declared file replaces the built-in default, so "only these roles" is sayable. Undeclared, the tier rules still check Base — §6 makes that every dev repo's by trigger — and the rest tell you which fact is missing instead of guessing one.

Coverage is growing: 45 of the standard's 51 checkable rules have an assertion in the engine today, with the rest reported as gaps by name. That number is printed by every run, so it never has to be taken on trust — and it is the engine's own count, not the repo's wider checker set.

---

Adapting to your repo

Skills auto-discover at the repo root after install. There is nothing to scaffold — the skills read whatever context files your project already has (CLAUDE.md, README.md, docs/CHANGELOG.md, docs/ARCHITECTURE.md — legacy root locations still matched) and degrade gracefully when one is missing. /prime aborts on nothing. No code-graph dependency — lean-flow neither integrates nor depends on graphify; it's a fine on-demand tool if you're onboarding an unfamiliar repo or doing a pre-refactor audit (usage + maintenance recipe: docs/research/graphify-daily-value.md § Consumer path — a lean-flow-repo decision record, not required reading).

Already have docs (or ran dev-flow / adlc-flow)? /lean-doc-generator migrate aligns them to lean-flow's placement · format · wiring — plan → approve → apply, surgically (never deletes your content), so you're not hand-reconciling or lost in existing code.

Requirements: Claude Code CLI. (Node / language toolchains matter only for whatever your own project needs — lean-flow itself is Markdown.)

---

Upgrading to 2.x

2.0.0 is a hard cut: TODO.md + the sprint-Plan-copy layout is replaced by the work-item store (docs/work/<status>/TASK-NNN-slug.md, one file per task — status is the folder, title is the filename, sprint/epic membership is frontmatter). It's a breaking change, by design, not a graceful window — every 2.x queue skill carries exactly one read path.

1. Install 2.x, then restart the session — a live session keeps whatever plugin copy it started with, so a mid-session update never takes effect.
2. Run /lean-doc-generator migrate. It reads your TODO.md Backlog and your active sprint's Plan, maps each task onto docs/work/, plan → approve → apply — never silently, never overwriting an existing file it doesn't recognize. Once every task has moved, it removes TODO.md; any non-task prose in it is listed for you to relocate or drop, never dropped silently. Interrupted mid-run? Just run it again — already-migrated tasks are left alone.
3. Resume normal use. /prime, /triage, /task-decomposer, /handoff, /flow, /orchestrator and promote/close all read the store from here on. A sprint now references its member task files instead of copying their DoD into its Plan. Each task's DoD lives only in its own ## Done when, and plan_commit is the freeze (ADR-047); with no git, a verbatim snapshot in the promote entry is (ADR-054).

New requirement: bun for checking a 2.x tree. conformance.sh (and the gate and night-run) read a sprint's members through one TypeScript lookup, so checking a migrated repo needs bun on the machine that runs it, CI included. Without it the run fails with a named bun-required finding and is never silently green. A 1.x tree is still checked with sh alone (ADR-049).

Why the refusal instead of dual support? A 2.x queue skill that finds TODO.md still present (alone, or alongside docs/work/) names the layout it found and does nothing else — it never guesses which one is authoritative. /prime is the one exception: read-only, so it reports the layout and keeps priming rather than aborting. migrate is the only 2.x path a v1 or mixed repo can take.

---

What lean-flow does NOT do

• No app-code generation, CI/CD pipeline, or automated coverage tooling.
• No hooks and no agent definitions in the roster today — the loop leans on Claude's built-in agents (Explore, /code-review, /verify, /security-review) rather than re-shipping them. Neither is banned: ADR-044 holds both to ADR-001's curation bar, and the first hook candidate was withdrawn at review rather than shipped (see TASK-366). The one skill that orchestrates sub-agents internally is the opt-in /council.
• No project scaffold written into your repo (that was dev-flow's /orchestrator init).
• No telemetry. Nothing is sent anywhere.

If you want the richer agent roster, gated init scaffold, and ADLC modes, use dev-flow / adlc-flow instead. lean-flow is the lean cut.

---

Architecture

Full map — composition rule, the loop, integration points, boundaries → docs/architecture/overview.md.

.claude-plugin/   plugin.json · marketplace.json        (lockstep versions)
.codex-plugin/    plugin.json                           (Codex CLI manifest, lockstep version)
.kimi-plugin/     plugin.json                           (Kimi Code CLI manifest, lockstep version)
skills/           15 skills — /flow conductor + 12 stages + /council + /humanizer (auto-discovered)
  lean-doc-generator/
    references/   STANDARD.md · migration-map.md · ADR-example.md
    templates/    34 canonical doc templates (core, incl. EPIC · SPRINT · ADR · RESEARCH ·
                  DEPLOYMENT · ROLLBACK · BUG · TECH-DEBT · CONTRIBUTING · CODE_OF_CONDUCT ·
                  SECURITY · AGENTS; +2 non-core: DESIGN · QA-TESTCASE = 36 total)
  tdd/references/             testability.md
  diagnose/references/        feedback-loops.md
  task-decomposer/references/ prd-and-slices.md · fog-map.md
  refactor-advisor/references/ deepening.md
  prototype/references/       logic.md · ui.md · demo.md
  council/                    opt-in agent decision aid
  humanizer/references/       patterns-en.md (vendored from blader/humanizer, MIT) · patterns-lf.md (lean-flow overlay) · patterns-id.md
.claude/          CLAUDE.md (shape) · CONTEXT.md (vocab · loop · gates · roster — SSOT)
docs/             architecture/ · development/ · deployment/ · DECISIONS.md · LEARNINGS.md · adr/ · sprint/

  ── TypeScript tooling on Bun (maintainer-side; ADR-051 retired the engine port) ──
package.json      root manifest — Bun runs TypeScript directly; the maintainer gate's
tsconfig*.json    typecheck leg needs `bun install` (dev-only `typescript`, ADR-037)
bunfig.toml
test/             gate-discovery guard and its fixtures
  ────────────────────────────────────────────────────────────────────────────────
TECH-DEBT.md · README.md · CHANGELOG.md · AGENTS.md · SECURITY.md · LICENSE

You do not need Bun to use the skills. The Shell implementation is the only conformance engine (ADR-051); Bun is needed only to check a 2.x tree (ADR-049). The tree above ships in the plugin cache because plugin.json declares no file manifest — it is inert weight, not a dependency.

---

Design principles

• Curated, not copied — the core discipline. Every component was reviewed against "genuinely useful · important · actually used" and approved before adding — the opposite of bulk-importing from every reference. The bar is review, not a feature ban.
• Standalone, conducted when you want — the twelve stage-skills each run alone (none require another); the opt-in /flow conductor sequences them through the full loop without bypassing a gate.
• No hooks or agent definitions in the roster today; leverages the built-in agents — the loop dispatches Claude's built-in agents (Explore · /code-review · /verify · /security-review) in isolated passes. /council is the one skill that orchestrates sub-agents internally.
• Lean — most SKILL.md ≤ ~140 lines; the one skill that needs a canonical format (lean-doc-generator) bundles its own templates + standard and stays self-contained.
• Adaptable — no required scaffold; skills detect the host project's layout and degrade gracefully.
• Human-gated — G1 Scope and G2 Design need explicit sign-off; /release-patch never pushes.

---

Provenance

Distilled from dev-flow. Techniques adapted from mattpocock/skills: the ADR "offer sparingly" test + glossary discipline + grilling moves (grill-with-docs) · /handoff · /triage + .out-of-scope/ · /tdd · /diagnose's feedback-loop discipline · /refactor-advisor's deep-module vocabulary (improve-codebase-architecture) · /prototype · this README's failure-mode framing. Behavioral Guidelines borrow Karpathy's LLM-coding guidelines; /council adapts the LLM Council method; this README's layout follows the Best-README-Template. All re-cut for lean-flow's markdown-first, agent-free-core, stack-agnostic constraints.

Further reading: .claude/CONTEXT.md (SSOT) · .claude/CLAUDE.md · STANDARD.md (the standard).

---

License

MIT — see LICENSE. Built and maintained by Aldian Rizki.

Doc owner: Maintainer · last updated 2026-10-28 · status: current · v2.19.1