tm42

Flw — Testing skill for Claude Code

Testing community

agentic flow package across claude, codex, and opencode: skills rotation (spec->execute->review), OKF-inspired knowledge system, per-repo conventions, terse style and formatting for outputs, ponytail.

How to install Flw

This entry records only its repository, not the path inside it, so there is no exact command to give. Open tm42/flw and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Flw does

agentic flow package across claude, codex, and opencode: skills rotation (spec->execute->review), OKF-inspired knowledge system, per-repo conventions, terse style and formatting for outputs, ponytail-inspired approach to designs, specs, and work, etc.

Alternatives in Testing

  • Pua — Use when the user invokes /pua or asks for PUA mode, try-harder/retry help, change-approach coaching, completi 19.5k ★
  • Darwin Skill — 达尔文.skill —— 一个让你的Skill无限进化的系统:评估→改进→测试→保留或回滚 Autoresearch-inspired autonomous skill optimization for Claude C 5.7k ★
  • Claude Code Spec Workflow — Automated Kiro-style Spec workflow for Claude Code 3.6k ★

README

flw

A spec-driven workflow for coding agents, and the tool that keeps it current across them.

It takes intent to a versioned contract, works against that contract, and refuses to let the work drift from what was agreed. It also installs itself into every host you use, runs whatever checks your project declares, and extends the same way it ships — so adding your own skill is copying the shape of an existing one.

Host-agnostic: flw installs as [Agent Skills](https://agentskills.io) into Claude Code, Codex and OpenCode. Language-agnostic: it bakes in no toolchain, no test runner and no manifest — a project declares its own commands and flw runs them.

**Status: in construction.** The schemas, the four skills, the scout, the check runner and the CLI work and are tested. What running flw against a real host and a real repository has found is recorded as a comment at the code each finding explains, not in a separate document. See `plans/design-v3.md` for the full design, `specs/current.toml` for what "done" means, and its `applied` list for the order it was built in.

The idea

An agent asked to build something will happily build something adjacent to it, and the gap only becomes visible later. flw closes that gap by making the agreement a file:

  • The contract is the source of truth. One per project, complete and current, stating what exists when the work is done and how you will know it works.
  • The contract is edited, not operated on. Ordinary edits, so git diff is the review surface. Change only what was agreed and the diff shows exactly that.
  • Gaps surface as proposals. When work hits something the contract does not cover, it stops and asks rather than inventing. That refusal is the whole product.
  • Every version leaves a record. One file per version under specs/versions/, carrying what changed, why, and the reasoning behind the plan. Size follows the change: a one-line correction is a four-line file. A record is add