flow-next-prime
flow-next-prime performs a comprehensive codebase assessment across 8 pillars covering 48 criteria, evaluating agent and production readiness. It scans code style, build systems, testing infrastructure, documentation, dependencies, CI/CD, security, and operational practices, then offers targeted fixes for the 5 agent-readiness pillars while reporting the remaining production considerations. Use this command when preparing a codebase for Claude agent integration or improving agent effectiveness within existing projects.
git clone --depth 1 https://github.com/gmickel/flow-next /tmp/flow-next-prime && cp -r /tmp/flow-next-prime/plugins/flow-next/skills/flow-next-prime ~/.claude/skills/flow-next-primeSKILL.md
# Flow Prime Comprehensive codebase assessment inspired by [Factory.ai's Agent Readiness framework](https://factory.ai/news/agent-readiness). **Role**: readiness assessor, improvement proposer **Goal**: full visibility into codebase health, targeted fixes for agent readiness ## Two-Tier Assessment | Category | Pillars | What Happens | |----------|---------|--------------| | **Agent Readiness** | 1-5 | Scored, maturity level calculated, fixes offered | | **Production Readiness** | 6-8 | Reported for awareness, no fixes offered | This gives you **full visibility** while keeping remediation focused on what actually helps agents work. **Criteria counts live in [pillars.md](pillars.md), never here.** pillars.md is the single census source (the legacy scored criteria feeding the maturity level, the informational rows, and the new agent-readiness tier groups AO/DR/TO/HP). Do not restate a count in this file - a hardcoded number drifts the moment a criterion is added. The classification, operability ladder, per-shape playbooks, per-stack matrix, and harness check-set live in the four reference files: [classification.md](classification.md), [playbooks.md](playbooks.md), [stacks.md](stacks.md), [harness.md](harness.md). ## Why This Matters Existence checks lie. A repo can carry a CLAUDE.md, a hook file, and a `lint` script yet be un-agentic in practice - the file is an empty template, the build is broken, imports don't resolve, or it is really one of 99 sibling repos. Prime judges **substance**, not existence, and names the single highest-leverage next action. Agents waste cycles when: - **No closed verify loop** → can't confirm a change works without a full CI round-trip; the feedback gate belongs at the RIGHT layer (edit-time/commit format+lint, tests via the verify command + acceptance requirements + CI required check - never a test-running pre-commit hook agents `--no-verify` around or stall on) - **Undocumented env vars** → guesses, fails, guesses again - **No agent instruction file (or a generic/stale one)** → doesn't know project conventions, the operability tier, or which files are off-limits - **The app can't be built or driven** → can't verify changes work; a legacy stack with no headless build has no feedback loop at all These are **environment problems**, not agent problems. Prime grades them as layered gates and helps fix the ones that help agents work. ## Input Full request: $ARGUMENTS Accepts: - No arguments (scans current repo) - `--report-only` or `report only` (skip remediation, just show report) - `--fix-all` or `fix all` (apply all agent readiness fixes without asking) - `--classify-only` or `classify only` (print the Phase 0.5 classification block and EXIT - the cheap portfolio-triage sweep over many repos; see classification.md) - A path to a different repo root (first non-flag argument) Examples: - `/flow-next:prime` - `/flow-next:prime --report-only` - `/flow-next:prime --classify-only ~/other-project` - `/flow-next:prime ~/other-project` **Resolve `ROOT` from `$ARGUMENTS`** (the first non-flag token; default `.`). If `ROOT` is not the cwd, it MUST thread through everything: `cd "$ROOT"` before the `.flow/meta.json` pre-check, the Phase 0.5 classification probes (the `flowctl prime classify` emitter takes `ROOT` as its positional argument, e.g. `flowctl prime classify --json "$ROOT"`), and the Phase 2 verification commands; and every scout dispatch prompt in Phase 1 starts "Assess the repo at `ROOT`" (scouts scan cwd by default - without this they'd scan the wrong repo and the report would be confidently wrong end-to-end). If threading `ROOT` isn't feasible, error rather than silently scan cwd. ## Route Before Reading References Parse the mode before loading any reference: - **`--classify-only`:** read [classification.md](classification.md) directly, run its emitter + judgment-layer contract, print its fixed classification block, and EXIT. Do **not** read `workflow.md`, `pillars.md`, `playbooks.md`, or `remediation.md`; never ask, dispatch scouts, verify, report, or remediate. - **All other modes:** read [workflow.md](workflow.md) and execute it. The workflow loads classification, pillars, playbooks, stacks, harness, and remediation guidance only at their consuming phases. `--report-only` stops after the report and must never load remediation templates. This dispatch is fail-open for an unknown/malformed mode: use the full workflow, never silently skip assessment or safety instructions. ## The Eight Pillars ### Agent Readiness (Pillars 1-5) — Fixes Offered | Pillar | What It Checks | |--------|----------------| | **1. Style & Validation** | Linters, formatters, type checking, pre-commit hooks | | **2. Build System** | Build tools, commands, lock files, monorepo tooling | | **3. Testing** | Test framework, commands, coverage, verification | | **4. Documentation** | README, CLAUDE.md, setup docs, architecture | | **5. Dev Environment** | .env.example, Docker, devcontainer, runtime version | ### Production Readiness (Pillars 6-8) — Report Only | Pillar | What It Checks | |--------|----------------| | **6. Observability** | Logging, tracing, metrics, error tracking, health endpoints | | **7. Security** | Branch protection, secret scanning, CODEOWNERS, Dependabot | | **8. Workflow & Process** | CI/CD, PR templates, issue templates, release automation | ## Workflow The mode router above selects the entry reference. Do not pre-read references for branches that will not execute. ## Maturity Levels (Agent Readiness) **The maturity level is secondary metadata, NOT the headline.** The report LEADS with the verdict headline - classification line + operability tier + hard-gate status + top-5 ranked next-actions (see [playbooks.md](playbooks.md)). The level moves below the scores table: at portfolio scale a bare "Level 5" from existence checks is exactly the false signal this skill exists to retire. The level still computes for cross-repo comparab
Synthesize the current conversation context into a flow-next spec at `.flow/specs/<spec-id>.md` via `flowctl spec create + spec set-plan` — agent-native, source-tagged, with mandatory read-back before write. Triggers on /flow-next:capture, "capture spec", "lock down what we discussed", "make a spec from this conversation", "convert conversation to spec". Optional `mode:autofix` token runs without questions and requires `--yes` to commit. Optional `--rewrite <spec-id>` overwrites an existing spec; `--from-compacted-ok` overrides the incomplete-evidence refusal after compaction; `--override-strategy` proceeds despite a contradiction with an active STRATEGY.md track (and prompts to record the override as a decision); `--no-plan` sets the spec-level `no_plan` field after the write (explicit opt-in — never inferred).
Render a cognitive-aid PR body from flow-next state and open via gh. Triggers on /flow-next:make-pr with optional spec id and flags (--draft, --ready, --no-mermaid, --base <ref>, --memory, --dry-run). Auto-detects spec from current branch when no id given. NOT Ralph-blocked — autonomous loops can surface a draft PR for human review.
Audit `.flow/memory/` entries against the current codebase and decide Keep / Update / Consolidate / Replace / Delete / Harden per entry. Triggers on /flow-next:audit, "audit memory", "review memory", "refresh learnings", "sweep stale memory", "consolidate overlapping memory entries", "graduate a recurring lesson into a gate". Optional `mode:autofix` token in arguments runs without questions and marks ambiguous as stale (Harden is never auto-applied). Optional scope hint after the mode token (concept, category, module, or path) narrows what gets audited.
Show spec dependency graph and execution order. Use when asking 'what's blocking what', 'execution order', 'dependency graph', 'what order should specs run', 'critical path', 'which specs can run in parallel'.
Drive any UI surface like a real user - a web app, a Chromium-backed desktop app (Electron / WebView2, reached over CDP), or a genuinely native app (macOS AppKit/SwiftUI, or a non-CDP webview) reached via the Cua Driver / Computer Use. Detects the surface, picks the best available driver, degrades gracefully. Use to navigate sites, verify deployed UI, test web or desktop apps, capture baseline screenshots, drive a sign-in flow, scrape data, fill forms, run an e2e check, or inspect current page state. Triggers on "check the page", "verify UI", "test the site", "test this app", "drive the app", "automate this desktop app", "read docs at", "look up API", "visit URL", "browse", "screenshot", "scrape", "e2e test", "login flow", "capture baseline", "see how it looks", "inspect current", "before redesign", "Electron app", "native app".
[deprecated alias] Renamed to flow-next-spec-completion-review in flow-next 1.0 — invoke the new skill. Removed in 2.0.
Export RepoPrompt context to a markdown file for review with an external LLM (ChatGPT, Claude web, etc.). Use when you want Carmack-level review but prefer an external model. Triggers on "export context", "export for external review", "export plan for ChatGPT", "export impl review context", "review with an external model", "export review context".