Skip to main content
Create repository-specific PRFlow configuration by running the init skill once in each repository. Initialization is separate from plugin installation. Run it after you install PRFlow and again after each update, so new configuration keys and new prompt-extension examples reach the repository. Local runs work on built-in defaults without it, so treat it as recommended rather than required. Claude Code invokes initialization as /prflow:init. Codex CLI and Codex in the ChatGPT desktop app invoke the same skill as $prflow:init; Codex CLI can also select it through /skills. After it scaffolds the configuration, initialization also installs the cloud-tier GitHub Actions workflows, driven by the config’s workflows block: when at least one tier is enabled — the shipped default enables workflows.prflow — it runs install.sh --apply for you; when none is enabled it asks first, and installs nothing on a decline or a non-interactive run. This replaces the old behavior where initialization scaffolded config but left the .github/workflows/ files to a separate install.sh run, so a repository whose config claimed the cloud tier was on could end up with no workflows on disk.

​
Run It

Open Claude Code anywhere inside the repository and enter:
The skill resolves the repository root itself, so the subdirectory you happen to be in does not matter.

​
What You See

The skill runs a scaffolder and then a dependency preflight, and relays their output. A first run in a repository that has no PRFlow configuration prints lines like these:
The paths are your repository’s, and the number of examples matches the number of skills in the release you installed. A repository that already has a config prints keeping existing … instead, followed by a backfill line when the release added new keys.

​
Files That Appear

Nothing here is committed for you. Initialization creates no Git commit on any path.

​
What Initialization Writes

  • Creates .prflow/config.json from the shipped example when the file is absent.
  • Backfills newly added keys at any nesting depth when the file already exists. Your values always win, and arrays you tuned, such as tool allowlists, are left alone.
  • Refreshes .prflow/config.schema.json to the schema of the release you installed, so your editor validates against the current field set.
  • After scaffolding config, runs install.sh --apply to place the .github/workflows/ and .github/actions/ cloud-tier files when the config’s workflows block enables at least one tier (the shipped default enables workflows.prflow).
  • When no tier is enabled, asks first via the runner’s question tool. An explicit yes enables workflows.prflow (never the withheld prflow-review tier) and then installs; a decline, a non-interactive run, or a runner with no question tool writes and installs nothing and just prints the install.sh --apply command.
  • Installs from the installed plugin tree with no network clone, pinning prflow_version to the installed release rather than a moving branch. The apply is idempotent and non-clobbering: a hand-edited managed file is preserved with a .prflow-new sidecar.
  • Best-effort like every other step: if the installer cannot be found or fails, it reports that and prints the manual command instead of halting. Review the .github/ diff before you commit.
See Cloud Installation for the standalone installer.
  • Adds a commented <skill>.md.example file for each skill when that example is absent, so you can see which skills accept a consumer extension.
  • The .example suffix keeps every scaffolded file inert. Rename it to <skill>.md to activate it.
  • Never overwrites an existing example or a live extension you wrote.
See Skill Extensions for what these files do.
  • Detects Node, Go, Rust, Java, Ruby, PHP, .NET, Make and Docker markers.
  • Merges the matching build, test and lint tools into the three tool allowlists, and adds the install commands that go with the lockfiles it finds.
  • Reads the repository for services, runtime versions and project-specific build or verification commands that marker detection cannot infer, and proposes those as well.
The merge is additive and idempotent. Re-running picks up tooling you added since the last run without removing custom entries and without creating duplicates. See Tool Permissions.
Initialization deep-merges the PRFlow marketplace registration into the project .claude/settings.json. The registration enables prflow@devflow-marketplace and tracks the marketplace repository’s default branch with autoUpdate: true.This write happens immediately, with no separate confirmation. It lands in a committed project file, so anyone who clones the repository inherits it, and because the registration is unpinned a change on the marketplace’s default branch changes what runs in the editor. Review it before you commit.
On recent models Claude Code leaves its task-tracking tools off by default, so PRFlow’s task-tracking skills fall back to a checklist the harness does not persist. To turn them on, initialization deep-merges env.CLAUDE_CODE_ENABLE_TODO_TOOLS set to "1" into your personal, user-scope ~/.claude/settings.json — the scope Claude Code reads that setting from.This write happens immediately, with no separate confirmation. Unlike the marketplace registration it targets your user-global file, not a committed project file, so your collaborators inherit nothing. It preserves every value you already set, and if the opt-in is already present in that file or already exported in your environment, it changes nothing.A settings write cannot affect the session that performs it — Claude Code decides a session’s tools at startup — so the tools arrive only in a session you launch after initialization. Start a new session with claude, or launch one-shot with CLAUDE_CODE_ENABLE_TODO_TOOLS=1 claude.
  • Runs the dependency preflight for Git, a runnable GitHub CLI, jq, Python 3.11 or newer and PyYAML. Authentication is a separate gh auth status check.
  • Creates the reserved PRFlow GitHub label, on a best-effort basis.
  • Looks for shared project-memory files such as CLAUDE.md and reports suggestions. It never edits them.
The repository scaffold is written before the dependency preflight runs. A missing tool is reported, but it does not roll back .prflow/ or any other change that already succeeded. Install the missing tool before you run implementation or review.

​
Older Repositories Are Migrated First

Initialization is also where a repository that predates the PRFlow rename is moved to the current layout. Before it scaffolds anything, the skill checks whether the repository still keeps its state in .devflow/ and, if so, runs the migration. The migration moves the state directory, the vendored plugin path, the configuration keys and the workflow bodies that name them. All of those move together or not at all. If any precondition fails, the migration refuses and leaves the repository byte-for-byte unchanged, then reports what blocked it. Initialization continues either way. Read Migrate from DevFlow before you review that larger diff.

​
Optional Guided Setup

Initialization can offer to do more than scaffold files. Every offer below asks first, and declining changes nothing that already succeeded.
  • Create internal documentation. If the repository has no developer documentation, the skill explains what internal and external documentation are, why written documentation makes later runs cheaper, and offers to create the internal set for you. On your explicit consent it dispatches one agent that writes only under the internal documentation location and runs no version-control command. If you decline, it prints the command so you can run it yourself. It never runs the external bootstrap, and it commits nothing.
  • Sweep remaining product-name references. After a successful rename migration, the skill can offer to update remaining DevFlow product-name mentions in your own files. See the privacy note in Migrate from DevFlow before accepting.

​
Review and Commit the Result

1

Read the Full Diff

Initialization writes files but never commits them. Look at every change before you decide what to keep.
2

Check the Paths That Matter

3

Tighten the Tool Allowlists

Grant enough access for PRFlow to run your real build and test commands, and prefer narrow patterns over broad ones. A reviewer that cannot run your test command will decline to judge anything that depends on it. See Tool Permissions.
4

Commit What Your Team Should Share

Commit the repository files through your normal review process. Do not commit a change to your user-global ~/.claude/settings.json, which is personal and lives outside the repository.

​
Next Steps

First Run

Turn a real issue into a review-ready pull request.

Settings Reference

Every key in .prflow/config.json, with its default.