# ClaudeFlow — full content > The toolkit for Claude Code. Production-ready agents, skill files, and workflow templates. From zero to shipping in minutes. This file concatenates every document on claudeflow.so. Each one is also served on its own at the URL in its Source line, with `.md` appended. The index lives at https://claudeflow.so/llms.txt. --- # Features Source: https://claudeflow.so/features/ ClaudeFlow's full feature set: development workflows, growth playbooks, and quality assurance systems for Claude Code. ## Ship production-quality code faster Specialized agents and workflows for every stage of the development lifecycle. ### Context-Optimized Agents Each agent ships with a purpose-built CLAUDE.md that primes Claude Code with the exact context it needs. No setup friction — just drop in and run. ### Code Review Workflow Automated code review that checks for patterns, security issues, performance anti-patterns, and style consistency — with a structured report every time. ### Test Generation Playbook Generate unit, integration, and e2e tests from existing code. The agent understands your stack and writes tests that actually catch bugs. ### Architecture Decision Templates Structured ADR templates with Claude Code integration. Document decisions, tradeoffs, and rationale with consistent, searchable formats. ## Systematic distribution without a team Marketing and growth automation built for founders and small teams who need to punch above their weight. ### Content Creation Pipeline From brief to published: research, draft, edit, and optimize content with Claude Code. Consistent voice and brand across every piece. ### SEO Playbooks Keyword research, content briefs, on-page optimization, and internal linking strategies — all orchestrated with Claude Code as the execution engine. ### Outbound Campaign Templates Cold email sequences, LinkedIn outreach, and follow-up playbooks with measurable response rate tracking built in. ### Launch Campaign Automation Coordinate Product Hunt launches, press outreach, social distribution, and community posts with a single orchestrated playbook. ## Verifiable outcomes, every time Built-in quality assurance that proves your AI workflows are actually working. ### QA Scorecards Structured pass/fail criteria for every deliverable. Know exactly what "done" looks like before you start — and prove it when you finish. ### Evidence Logging Every workflow run produces a structured evidence log: inputs, outputs, decisions made, and quality scores. Reviewable, searchable, shareable. ### Iteration Loops Built-in feedback and revision cycles that catch issues early. Run-review-refine loops that converge on quality without manual babysitting. ### Outcome Measurement Track what actually matters: pass rates, time saved, quality scores. Data-driven proof that your AI workflows are working. --- # Agents Source: https://claudeflow.so/agents/ Every ClaudeFlow agent, with its role and capabilities — engineering, growth and marketing, quality and evidence. ## Engineering agents Purpose-built for code quality, testing, architecture, and documentation. ### CodeReview — Code Quality Analyst Performs structured code reviews with pattern detection, security analysis, and actionable feedback. Produces a standardized review report with severity-ranked findings. Capabilities: - Security vulnerability detection - Performance anti-pattern identification - Style and convention enforcement - Structured severity-ranked report ### TestGen — Test Suite Engineer Generates comprehensive test suites for existing code. Covers unit tests, integration tests, and edge cases — with coverage targets and test naming conventions. Capabilities: - Unit test generation from source code - Integration test scaffolding - Edge case and boundary detection - Coverage gap analysis ### Refactor — Code Modernization Specialist Rewrites legacy code to modern patterns without breaking functionality. Produces a diff with rationale for each change and a validation checklist. Capabilities: - Legacy pattern modernization - Dead code elimination - Dependency upgrade guidance - Regression risk assessment ### ArchDecision — Architecture Advisor Creates Architecture Decision Records (ADRs) with structured tradeoff analysis. Documents the decision context, options considered, and rationale. Capabilities: - ADR document generation - Option comparison matrices - Tradeoff documentation - Decision consequence tracking ### ContextEngineer — CLAUDE.md Specialist Builds and optimizes CLAUDE.md context files for any project. Analyzes your codebase and generates context that maximizes Claude Code performance. Capabilities: - Project structure analysis - Stack-aware context generation - Workflow command configuration - Context quality scoring ### BugHunter — Root Cause Analyst Systematically diagnoses bugs using structured root-cause analysis. Produces a hypothesis tree, investigation steps, and a fix recommendation with validation criteria. Capabilities: - Structured root-cause analysis - Hypothesis generation and ranking - Fix recommendation with tests - Regression prevention checklist ### DocWriter — Technical Documentation Author Generates technical documentation from code: API references, README files, usage guides, and inline comments. Consistent style across your entire codebase. Capabilities: - API reference generation - README and guide writing - Inline comment generation - Changelog drafting ### PRReviewer — Pull Request Analyst Reviews pull requests end-to-end: code quality, test coverage, documentation completeness, and merge readiness. Outputs a structured review with clear action items. Capabilities: - PR scope and diff analysis - Test coverage check - Documentation completeness review - Merge readiness score ## Growth & marketing agents Distribution, content, and outreach automation for founders and growth teams. ### ContentFactory — Content Creation Pipeline Produces long-form content from a brief: research, outline, draft, and optimization pass. Consistent brand voice with SEO best practices built in. Capabilities: - Topic research and brief generation - Long-form drafting with structure - SEO on-page optimization - Brand voice consistency check ### OutboundCraft — Cold Outreach Specialist Writes cold email sequences, LinkedIn outreach, and follow-ups with personalization hooks. A/B variants included with subject line testing built in. Capabilities: - Multi-touch email sequence writing - Personalization hook generation - LinkedIn message variants - Subject line A/B testing ### SEOStrategist — SEO Content Planner Builds keyword clusters, content calendars, and internal linking strategies. Every brief includes search intent analysis and competitive gap identification. Capabilities: - Keyword cluster mapping - Content calendar generation - Search intent classification - Internal link planning ### LaunchOrchestrator — Launch Campaign Manager Coordinates Product Hunt launches, press outreach, and social campaigns. Produces a day-by-day execution plan with templates for every channel. Capabilities: - Launch timeline and checklist - Product Hunt submission copy - Press outreach templates - Social amplification plan ### CopyOptimizer — Conversion Copywriter Rewrites marketing copy for conversion: landing pages, CTAs, email subject lines. Uses proven frameworks (PAS, AIDA, FAB) with clarity and specificity scoring. Capabilities: - Landing page copy rewriting - CTA optimization with variants - Email subject line testing - Conversion framework application ### SocialDistributor — Social Content Repurposer Turns one piece of content into a week of social posts: Twitter threads, LinkedIn articles, short-form clips scripts, and community posts. Capabilities: - Twitter/X thread generation - LinkedIn long-form adaptation - Short-form video script writing - Community post templates ## Quality & evidence agents Verifiable outcomes and structured evidence for every workflow you run. ### QAScorecard — Quality Assurance Scorer Evaluates any deliverable against a structured rubric. Produces a pass/fail scorecard with weighted criteria and specific improvement recommendations. Capabilities: - Custom rubric application - Weighted scoring calculation - Failure mode identification - Improvement recommendation list ### EvidenceLogger — Workflow Evidence Auditor Captures structured evidence for every workflow run: inputs, outputs, decisions, and quality scores. Creates an auditable trail of AI-assisted work. Capabilities: - Structured evidence capture - Input/output logging - Decision rationale recording - Quality score trending --- # Pricing Source: https://claudeflow.so/pricing/ One-time purchase with lifetime updates. Engineer Kit $59, Growth Kit $59, Complete Bundle $89. No subscription. Every plan is a one-time purchase with lifetime updates. No subscription, no per-seat pricing, no lock-in. Prices are in USD. ## Engineer Kit — $59 (list $129) For developers who want to ship production-quality code faster with Claude Code. Includes: - 8 specialized coding agents - Code review & refactoring workflows - Test generation playbooks - Architecture decision templates - Context-engineered prompts library - QA scoring scorecards - Instant access via ZIP download - Lifetime updates | Contents | Count | | --- | --- | | Specialized Agents | 8 | | Workflow Templates | 24 | | Context Files (CLAUDE.md) | 16 | | Playbooks | 6 | | Scorecards | 4 | ## Growth Kit — $59 (list $129) For founders and growth teams running distribution and marketing with Claude. Includes: - 6 growth & marketing agents - Content creation workflows - SEO & outbound playbooks - Launch campaign templates - Social distribution automation - Conversion copywriting prompts - Instant access via ZIP download - Lifetime updates | Contents | Count | | --- | --- | | Specialized Agents | 6 | | Campaign Templates | 18 | | Content Playbooks | 8 | | Outreach Sequences | 4 | | Analytics Templates | 3 | ## Complete Bundle — $89 (list $199) Everything. Both kits combined — the complete ClaudeFlow toolkit for 10x teams. Includes: - Everything in Engineer Kit - Everything in Growth Kit - 16 named agents - Priority email support - Early access to new releases - Bonus: ClaudeFlow playbook guide - Instant access via ZIP download - Lifetime updates | Contents | Count | | --- | --- | | Total Agents | 16 | | Total Templates | 42+ | | Playbooks | 14 | | Scorecards | 6 | | Priority Support | ✓ | ## Frequently asked questions ### Is this a one-time purchase or a subscription? One-time purchase. You pay once and own it forever. No monthly fees, no annual renewals, no lock-in. Lifetime updates are included. ### What is included in "lifetime updates"? Every time we add new agents, update existing workflows, or release new playbooks, you get the update automatically at no additional cost. We ship updates regularly. ### Can I use ClaudeFlow on multiple projects? Yes. Your license is for you personally and covers unlimited projects and workspaces. No per-seat or per-project restrictions. ### Do I need Claude Code to use ClaudeFlow? Yes. ClaudeFlow is a toolkit that runs on top of Claude Code. You need an active Claude Code subscription from Anthropic. ClaudeFlow provides the agents, context files, and playbooks that make Claude Code dramatically more effective. ### What is the difference between the Engineer Kit and Growth Kit? The Engineer Kit focuses on development workflows: code review agents, testing playbooks, architecture templates, and QA scorecards. The Growth Kit focuses on marketing and distribution: content agents, SEO playbooks, outbound templates, and campaign automation. The Complete Bundle includes both at a discounted price. ### What if I am not satisfied? Email us at hello@claudeflow.so within 14 days of purchase and we will make it right. We stand behind ClaudeFlow and want every customer to be happy with their purchase. --- # Getting Started with ClaudeFlow Source: https://claudeflow.so/docs/getting-started/ Set up ClaudeFlow in four steps: browse the templates, drop a CLAUDE.md in your project root, customize it for your stack, and start building with Claude Code. Welcome to ClaudeFlow! This guide will walk you through everything you need to get started. ## What is ClaudeFlow? ClaudeFlow is a toolkit of workflow templates, context playbooks, and tools designed to help developers get the most out of [Claude Code](https://claude.ai/code). Whether you're building a SaaS product, a CLI tool, or an internal app, ClaudeFlow has the templates and guides to help you ship faster. ## Prerequisites Before you begin, make sure you have: - Claude Code installed and configured - A terminal (ClaudeFlow runs entirely through Claude Code in your terminal) - Node.js 18+ (for web project templates) ## Quick Setup 1. **Browse the templates** Visit the [tools section](/tools/) to find workflow templates for your stack. 2. **Download your starter** Pick a template and download the CLAUDE.md file to your project root. 3. **Customize the context** Edit the template to reflect your project's specific requirements, tech stack, and coding standards. 4. **Start coding with Claude** Open Claude Code in your project and start building. The context file will guide Claude to work exactly the way you want. ## Next Steps - Read the [installation guide](/docs/installation/) for detailed setup instructions - Keep the [troubleshooting guide](/docs/troubleshooting/) handy for when Claude ignores your context - Skim the [FAQ](/docs/faq/) for the questions most people hit first - Check out the [blog](/blog/) for tips and case studies --- # Installation Source: https://claudeflow.so/docs/installation/ Install ClaudeFlow by hand while the CLI is still in development: what you need first, where the CLAUDE.md file goes, and which sections to customize. ## Prerequisites - Claude Code CLI installed - Node.js 18+ (for web projects) - Git ## Install the ClaudeFlow CLI (Coming Soon) The ClaudeFlow CLI is currently in development. For now, download templates directly from the [tools](/tools/) and [downloads](/downloads/) sections. ## Manual Setup 1. Browse the available templates in the [tools section](/tools/) 2. Download the template that fits your project type 3. Place the `CLAUDE.md` file in your project root 4. Customize the sections for your specific project ## Next Steps After installation, read the [Getting Started guide](/docs/getting-started/) to learn how to get the most out of ClaudeFlow templates. --- # Troubleshooting Source: https://claudeflow.so/docs/troubleshooting/ Fixes for the three things that go wrong most: Claude ignoring your CLAUDE.md, a template that reads too generic, and build errors after adding one. ## Claude Ignores My CLAUDE.md **Symptom**: Claude Code doesn't seem to follow the instructions in your `CLAUDE.md`. **Solutions**: - Ensure `CLAUDE.md` is in the project root (same directory where you run Claude Code) - Keep the file under 4,000 tokens for best results - Use clear, specific instructions rather than vague guidelines ## Templates Feel Too Generic **Symptom**: The downloaded template doesn't match your project needs well. **Solutions**: - Edit the template — all sections are meant to be customized - Check the [blog](/blog/) for pattern-specific guides - Browse other templates in the [tools section](/tools/) ## Build Errors After Adding Template **Symptom**: Your project fails to build after adding a ClaudeFlow template. **Solutions**: - Templates don't modify your build configuration - The `CLAUDE.md` file is ignored by all build systems by default - Ensure you didn't accidentally modify other project files ## Still Stuck? Check our [FAQ](/docs/faq/) or reach out on [GitHub](https://github.com/claudeflow). --- # FAQ Source: https://claudeflow.so/docs/faq/ What ClaudeFlow is, which parts are free, how to combine CLAUDE.md templates without blowing the token budget, and how premium access and cancelling work. ## General ### What is ClaudeFlow? ClaudeFlow is a collection of workflow templates, context playbooks, and interactive tools designed to help developers get maximum productivity from Claude Code. ### Is ClaudeFlow free? Many templates and resources are free. Premium content (advanced workflows, SaaS starter kits) requires a paid plan. ### Does ClaudeFlow work with Claude API directly? ClaudeFlow templates are primarily designed for Claude Code (the CLI). Some patterns work with the Claude API but are not officially supported. ## Templates ### How do I use a CLAUDE.md template? Download the template from the [tools section](/tools/), rename it to `CLAUDE.md`, place it in your project root, and customize it for your specific project. ### Can I use multiple templates together? Yes! You can combine sections from different templates. Keep your `CLAUDE.md` under 4,000 tokens for best performance. ### Do templates work with all Claude Code versions? Templates are tested with the latest Claude Code release. Older versions may not support all patterns. ## Billing & Access ### How do I get access to premium templates? Visit the [pricing page](/pricing/) to choose a plan that fits your needs. ### Can I cancel anytime? Yes, all paid plans can be cancelled at any time from the customer portal. --- # Claude Code Guides Source: https://claudeflow.so/guides/ Task-first guides for Claude Code, written around the failure you actually hit and not the feature list: config that will not apply, settings.json, debugging. The official Claude Code documentation answers **what a thing is**. These guides answer **why it isn't working on your machine, in your repo, with your stack.** That is the whole editorial rule. Every guide opens on a symptom someone actually typed into a search box, walks the diagnosis in order, and ends with something you can keep. This section documents **Claude Code**, the tool. If you are looking for how the ClaudeFlow kit itself works — installing it, what ships in it, how the agents are wired — that lives in [the product docs](/docs/). ## Troubleshooting & config The first wave. High-intent, evergreen, and every one of them ends in a file you can drop into a project. Claude Code is behaving badly and you don't know which layer is at fault. Diagnose by symptom instead of guessing. [Diagnose by symptom →](/guides/troubleshooting-claude-code/) You edited a settings file and nothing changed. Almost always precedence — another file is winning. [Find the file that wins →](/guides/config-not-applying/) The settings file that earns its place in a real repo, grouped by what each field actually changes. [Read the walkthrough →](/guides/settings-json/) ## How these guides are built Each one follows the same shape, because the shape is what makes them useful under pressure: 1. **The symptom** — stated the way you would describe it out loud. 2. **What is actually happening** — the mechanism, briefly. 3. **The diagnosis** — ordered steps, cheapest check first. 4. **Common mistakes** — the wrong turns that cost people an afternoon. 5. **A checklist** — the part you keep. --- # Claude Code Isn't Working: Diagnose by Symptom Source: https://claudeflow.so/guides/troubleshooting-claude-code/ Stop guessing. Work out which layer is broken — install, config, permissions, context, or the model — before you change anything. Every "Claude Code not working" article gives you the same five fixes: reinstall, update, check your API key, restart the terminal, clear the cache. Sometimes one of them lands. When it does, you learned nothing, and you will be back here in a month. The problem is that "not working" is five different failures wearing the same coat. A tool that never launches and a tool that launches but ignores your `CLAUDE.md` have nothing in common except your frustration. **Fix the diagnosis and the fix falls out for free.** ## The five layers Claude Code fails at one of five layers, and they fail in a fixed order. A broken layer makes every layer above it look broken too — which is exactly why shotgunning fixes wastes your afternoon. The binary is missing, the wrong version, or shadowed by another one on your `PATH`. Symptom: it doesn't start, or `--version` disagrees with what you installed. It starts but cannot reach the model. Symptom: it hangs, or every request errors identically regardless of what you ask. It runs, but your settings are not the settings it loaded. Symptom: a change you made has no visible effect. It runs with your config, but refuses actions or asks constantly. Symptom: prompts you expected to be silent, or a tool that never fires. Everything works and the output is still wrong. Symptom: it forgets, contradicts your conventions, or answers about the wrong file. If layer 1 is broken, layers 3 to 5 will produce misleading evidence. Work upward, and stop at the first layer that fails — the layers above it are probably fine. ## Diagnose in order 1. **Ask the tool about itself first.** Before you touch a config file, get the tool's own account of its state. This one command is the cheapest information you will get all session. ```bash claude doctor ``` It checks the installation and reports what it finds. If this is unhappy, you are at layer 1 and nothing below matters yet. 2. **Confirm you are running the binary you think you are.** A stale global install shadowing a newer one is the single most common false alarm. ```bash claude --version which -a claude # every `claude` on your PATH, in resolution order ``` More than one line from `which -a` means the first one wins, and it may not be the one you upgraded. That is layer 1, and it is not a Claude Code bug. 3. **Watch it work.** If it launches but misbehaves, stop reading config and start reading logs. Debug output shows what it loaded, what it called, and where it stopped. ```bash claude --debug ``` Reproduce your problem with this running. The line immediately *before* things go wrong is usually the answer. 4. **Check what config actually loaded.** Not what you wrote — what it read. Inside a session: ``` /status ``` If the settings shown here are not the settings you edited, you are at layer 3, and you want the [config precedence guide](/guides/config-not-applying/) rather than another reinstall. 5. **Check permissions explicitly.** If tools are being refused or you are drowning in prompts, look at the rules rather than inferring them from behaviour: ``` /permissions ``` 6. **Only now suspect context.** Layers 1 to 4 are mechanical: they are either right or wrong, and you can prove which. Layer 5 is not. If everything above checks out and the output is still poor, the problem is what the model was given, not whether the tool works. ## Symptom → layer Use this to jump straight to the right layer instead of starting from the top every time. | What you see | Layer | Start here | | --- | --- | --- | | Command not found, or wrong version | Install | `which -a claude`, then reinstall | | Hangs on every request | Auth & connectivity | `claude --debug`, check network and credentials | | Every request fails identically | Auth & connectivity | `claude --debug` | | Edited settings, nothing changed | Config | [Config precedence](/guides/config-not-applying/) | | Hooks never fire | Config | Settings file location and JSON validity | | Constant permission prompts | Permissions | `/permissions` | | A tool is never used | Permissions | `/permissions`, then MCP status with `/mcp` | | Ignores your conventions | Context | `CLAUDE.md` content and placement | | Forgets earlier work mid-session | Context | Session length and compaction | | Confidently edits the wrong file | Context | What you actually pointed it at | ## Common mistakes **Reinstalling as a first move.** Reinstalling resets layer 1. If your problem was layer 3, you have destroyed your diagnosis and kept your bug — and now you cannot tell whether the config was ever the issue. **Editing settings while a session is open.** Some settings are read when the session starts. Change the file, then start a fresh session before concluding the change did nothing. **Assuming invalid JSON will announce itself.** A settings file with a trailing comma or a stray quote can be skipped quietly. Validate it before you spend an hour on the contents: ```bash python3 -m json.tool .claude/settings.json > /dev/null && echo "valid" ``` ```bash node -e "JSON.parse(require('fs').readFileSync('.claude/settings.json','utf8'));console.log('valid')" ``` **Blaming the model for a context problem.** "It gave me a bad answer" and "it was given bad inputs" look identical from the outside. Switching models on a layer 5 problem changes the flavour of the wrong answer, not its correctness. **Changing two things at once.** If you fix the install *and* rewrite your settings and it starts working, you still do not know what was broken. Next time it breaks, you are back to zero. ## Checklist Keep this next to you. Work down, stop at the first failure. - [ ] `claude doctor` reports a healthy installation - [ ] `claude --version` matches what you intended to install - [ ] `which -a claude` returns exactly one path you recognise - [ ] A trivial prompt gets a response — auth and connectivity are fine - [ ] `/status` shows the settings you actually edited - [ ] Every settings file in play is valid JSON - [ ] `/permissions` matches what you expect to be allowed and denied - [ ] The session was restarted after the last config change - [ ] Only then: look at `CLAUDE.md`, session length, and what you pointed it at Keep a note of the layer each time something breaks. After a handful of incidents the pattern is obvious, and it is almost never the layer people reinstall first. ## Where to go next --- # Your Claude Code Config Isn't Applying Source: https://claudeflow.so/guides/config-not-applying/ You edited a settings file and nothing changed. It is almost always precedence — another file is winning. Here is how to find it. You added a permission rule. Nothing changed. You added it again, in a different file. Still nothing. You reinstall, and now you have two problems. Here is the thing nobody says out loud: **your edit probably worked perfectly, and is being overridden by a file you forgot you had.** Claude Code reads settings from several places and merges them in a fixed order. Editing the wrong one produces the exact symptom of editing nothing at all. ## Why there is more than one file The multiple files are not an accident, they are the point. Three different people want to configure the same tool and they must not overwrite each other: Preferences that follow you across every project on your machine. Your theme, your personal shortcuts. Rules that belong to the project and should be identical for everyone who clones it. Committed to git. Your local overrides for one project — a path that only exists on your machine, a credential you are testing. Never committed. Managed policy on a company machine. Deliberately unbeatable by the three above. Once you see it as four *audiences* rather than four files, the precedence order stops being arbitrary. The more specific the audience, the more it wins — except policy, which wins over everything by design. ## The precedence chain From strongest to weakest. **The first one that defines a setting is the one that takes effect.** | # | Source | Where it lives | Committed? | | --- | --- | --- | --- | | 1 | Enterprise managed policy | System-wide managed settings path | Managed by IT | | 2 | Command line arguments | The flags on the command you just ran | — | | 3 | Project local | `.claude/settings.local.json` | No — gitignored | | 4 | Project shared | `.claude/settings.json` | Yes | | 5 | User | `~/.claude/settings.json` | No | Read that table twice, because two rows account for most of the confusion. **Row 3 beats row 4.** Your `settings.local.json` overrides the team file. If a teammate's setup works and yours doesn't, this is the first place to look — you probably created it weeks ago and forgot. **Row 5 loses to everything.** Editing `~/.claude/settings.json` to fix a project-specific problem is the single most common wasted afternoon. It is the weakest file in the chain. You hit a problem in a project. You open your **user** settings because that is the file you know. You fix it. Nothing happens — because that project has a `.claude/settings.json` defining the same key, and it wins. Here is the same thing as a tree, which is how it actually looks on disk: - your-project/ - .claude/ - settings.json beats your user file - settings.local.json beats everything except policy and CLI flags - CLAUDE.md - src/ - ~/.claude/ - settings.json the weakest file in the chain ## Find the file that is winning 1. **Ask the session what it loaded.** Do not reason about it. Look at it. ``` /status ``` This is the ground truth. If what you see here differs from the file you edited, you have your answer already and everything below is confirmation. 2. **List every settings file that could apply.** Run this from your project root. It finds all four candidates in one shot. ```bash ls -la .claude/settings.json .claude/settings.local.json ~/.claude/settings.json 2>/dev/null ``` Every file that prints is competing for your setting. The ones you did not know about are the interesting ones. 3. **Prove which file defines your key.** Search all of them for the setting you are fighting with. Replace `permissions` with whatever you actually changed. ```bash rg -n "permissions" .claude/settings.json .claude/settings.local.json ~/.claude/settings.json 2>/dev/null ``` If the key appears in more than one file, the highest one in the precedence table wins — and it is not necessarily the one you edited. 4. **Validate the JSON before you believe the contents.** A malformed settings file can be skipped without a loud complaint, which looks exactly like a file that is being overridden. ```bash for f in .claude/settings.json .claude/settings.local.json ~/.claude/settings.json; do [ -f "$f" ] && { python3 -m json.tool "$f" > /dev/null 2>&1 \ && echo "ok $f" || echo "INVALID $f"; } done ``` 5. **Restart the session.** Some settings are read once, when the session starts. Editing them mid-session and concluding they do not work is a self-inflicted wound. Change the file, start fresh, then judge. ## Common mistakes **Editing the user file to fix a project problem.** The weakest file in the chain. If the project defines the same key, you will never see your change. **Forgetting `settings.local.json` exists.** It is gitignored, so it is invisible in every diff and every code review. It is also the second-strongest file. That combination is why it causes so much confusion — it beats the team's config and leaves no trace in git. **Assuming the whole file is replaced.** Settings merge per key, not per file. A key you did not define is inherited from a weaker source, which means the effective config is a blend of several files and matches none of them exactly. **Trusting the file over the session.** The file is what you *wrote*. `/status` is what was *loaded*. When they disagree, the session is right and you are debugging the wrong thing. **Editing on a managed machine.** If your organisation ships a managed policy, it wins on purpose. No amount of local editing will beat it, and that is the intended behaviour — not a bug to work around. ## Checklist - [ ] `/status` shows the effective settings, and you compared them to your edit - [ ] You listed all four possible settings sources, not just the one you remembered - [ ] You searched every file for the key, not only the one you edited - [ ] `.claude/settings.local.json` was checked — it is gitignored and it beats the team file - [ ] Every settings file in play is valid JSON - [ ] The session was restarted after the change - [ ] If the machine is managed, you confirmed policy is not the thing overriding you Decide the audience before you decide the file. Everyone on the team? `.claude/settings.json`. Just you, just here? `.claude/settings.local.json`. Just you, everywhere? `~/.claude/settings.json`. Pick the file from the answer, not from habit. ## Where to go next --- # settings.json, Field by Field Source: https://claudeflow.so/guides/settings-json/ The settings file that earns its place in a real repo — grouped by what each field changes, with the ones worth touching separated from the ones that are not. There are two ways to write about `settings.json`. One is to list every field in alphabetical order — which the [official reference](https://code.claude.com/docs/en/settings) already does, exhaustively and correctly, and it will always be more current than anything we publish. This is the other way: **grouped by what it changes for you**, with a clear line between the fields that pay for themselves in the first week and the ones you should leave alone until you have a reason. A perfect settings file in the wrong location does nothing. If you are here because an edit had no effect, start with [Your config isn't applying](/guides/config-not-applying/) — this guide assumes you already know which file wins. ## Pick the file before you write a line Three questions, one answer. This is the decision people get wrong, and no amount of correct JSON survives it. | Who is this for? | File | In git? | | --- | --- | --- | | Everyone who clones this repo | `.claude/settings.json` | Yes — commit it | | Only you, only this repo | `.claude/settings.local.json` | No — gitignored | | Only you, every repo | `~/.claude/settings.json` | No — lives in your home | Anything resembling a credential, a machine-specific path, or a personal preference does not belong in the committed file. Once it is in git history it is in everyone's clone, and removing it later does not remove it from history. ## What the fields actually change Rather than the full field list, here is the grouping that matters when you are deciding what to put in a real project. What Claude may do without asking, and what it must never do. This is the group with the highest payoff and the highest blast radius — worth your attention first. Shell commands fired on lifecycle events. This is how a kit installs itself, how formatting gets enforced, how context gets loaded on every session. Variables handed to the session and the commands it runs. Useful for pointing tooling at the right place; dangerous as a home for secrets in a committed file. Which model runs, and how the tool presents itself. Easy to change, easy to over-tune — leave defaults until you have a measured reason. ## The permissions block If you only configure one thing, configure this. It is the difference between approving every `ls` for a year and approving nothing that matters. The shape is three lists — what is allowed silently, what is refused outright, and what should always stop and ask: ```json title=".claude/settings.json" { "permissions": { "allow": [ "Bash(git status)", "Bash(git diff:*)", "Bash(npm run test:*)" ], "deny": [ "Bash(rm -rf:*)", "Read(./.env)", "Read(./secrets/**)" ] } } ``` Three things worth understanding before you copy that: 1. **`deny` is the load-bearing list.** `allow` saves you keystrokes. `deny` saves you from a bad afternoon. Write the deny rules first, and write them for the things that are unrecoverable rather than merely annoying — destructive commands and files that hold credentials. 2. **Allow the read-only commands, not the categories.** `Bash(git status)` is safe because it cannot change anything. A blanket allow on `Bash` is not a shortcut, it is the removal of the feature. Grant the specific commands you find yourself approving over and over. 3. **Denying a file is not the same as securing it.** A `deny` on `./.env` stops the tool from reading it through the normal path. It is a guardrail, not a security boundary — do not treat it as a reason to keep secrets somewhere they would otherwise not belong. Do not try to predict which commands you will approve. Work for a few days, notice which prompts you approve reflexively, and promote exactly those. An allowlist written from guesswork is always both too broad and too narrow. ## The hooks block Hooks run shell commands when something happens in the session. They are the mechanism behind almost every "how do I make it always do X" question. ```json title=".claude/settings.json" { "hooks": { "SessionStart": [ { "hooks": [ { "type": "command", "command": "./.claude/scripts/load-context.sh" } ] } ] } } ``` A hook in a committed settings file runs for everyone who clones the repo. Review hooks in pull requests the way you would review a CI change, because that is what they are. Hooks earn a guide of their own — the failure modes are specific enough that a section here would mislead. That one is coming in this same wave. ## A starting file This is a defensible baseline for a project: no secrets, no machine-specific paths, nothing that assumes your setup. ```json title=".claude/settings.json" { "permissions": { "allow": [ "Bash(git status)", "Bash(git diff:*)", "Bash(git log:*)" ], "deny": [ "Bash(rm -rf:*)", "Read(./.env)", "Read(./.env.*)" ] } } ``` ```json title=".claude/settings.local.json" { "permissions": { "allow": [ "Bash(npm run dev:*)" ] } } ``` Note what is *not* there. No model pin, no environment block, no hooks. Every one of those is a decision you should make deliberately later, not inherit from a template today. ## Common mistakes **Copying a maximal settings file from the internet.** You inherit someone else's risk tolerance and someone else's machine. Every allow rule you did not write yourself is a rule you cannot justify in review. **Putting secrets in the committed file.** Environment blocks look like a convenient home for tokens. They are in git forever the moment you push. **Allowing broad command patterns to stop the prompts.** It works, briefly, and it removes the only thing standing between an agent and a destructive command. **Pinning a model and forgetting.** A pin that made sense six months ago quietly costs you every improvement since. If you pin, write down why, and revisit it. **Editing while a session is open.** Start a fresh session before you decide a change did nothing. This one wastes more time than every other mistake on this list. ## Checklist - [ ] The file matches its audience: team, local, or user - [ ] Nothing resembling a secret or a machine path is in the committed file - [ ] `deny` covers destructive commands and credential files - [ ] Every `allow` entry is a command you actually approved repeatedly - [ ] No blanket allow on an entire tool - [ ] Hooks, if any, were reviewed as carefully as CI config - [ ] The JSON validates - [ ] A fresh session was started before judging the result ## Where to go next --- # CLAUDE.md Workflow Builder Source: https://claudeflow.so/tools/workflow-builder/ Generate a custom CLAUDE.md file for your project in seconds. Tailored templates for web apps, APIs, CLIs, and more. ## About This Tool The CLAUDE.md Workflow Builder helps you create the perfect context file for your Claude Code projects. ### Features - **Project type detection**: Automatically suggests relevant workflow patterns - **Stack-aware templates**: Optimized for Next.js, Astro, FastAPI, Go, and more - **Best-practice defaults**: Pre-filled with proven context engineering patterns - **Export formats**: Copy to clipboard or download as `.md` file ### How to Use 1. Select your project type 2. Choose your tech stack 3. Customize the workflow sections 4. Copy or download your CLAUDE.md Try the interactive builder in our [tools section](/tools/workflow-builder/). --- # Claude Code Quickstart Template Source: https://claudeflow.so/downloads/quickstart-template/ A ready-to-use CLAUDE.md template with pre-filled context for new projects. Get started with Claude Code in under 5 minutes. ## What's Included This quickstart template gives you a solid foundation for any Claude Code project. ### Contents - **Project context section**: Placeholder for your project description, goals, and constraints - **Workflow commands**: Pre-configured commands for common tasks (dev, build, test, deploy) - **Coding standards**: Sensible defaults for TypeScript, formatting, and linting - **Agent behavior**: Guidelines for how Claude should approach tasks - **Common patterns**: Frequently used patterns for your stack ### Who Is This For - Developers starting a new project with Claude Code - Teams standardizing their AI-assisted development workflow - Anyone who wants a head start on context engineering Download the template and customize it for your project in minutes. --- # Changelog Source: https://claudeflow.so/changelog/ Every ClaudeFlow release: new agents, updated workflows, fixes, and improvements. ## 1.0.0 — Initial Release Released 2026-04-01 · feature ## What's New ### ClaudeFlow Launch We're thrilled to announce the initial release of ClaudeFlow. - **Workflow templates**: 10 battle-tested CLAUDE.md templates for common development scenarios - **Context playbooks**: 5 comprehensive guides on context engineering best practices - **SaaS starter kit**: Full-stack Next.js + Astro starter wired for Claude Code - **Blog**: Articles on Claude Code workflows, context engineering, and SaaS templates - **Docs**: Getting started guide and reference documentation --- # Hello World: Introducing ClaudeFlow Source: https://claudeflow.so/blog/hello-world/ ClaudeFlow is the missing toolkit for developers who want to supercharge their Claude Code workflows. Here's why we built it and what's coming. Welcome to ClaudeFlow — the toolkit for developers who want to get the most out of Claude Code. ## Why We Built This Claude Code is incredibly powerful, but setting up effective workflows from scratch takes time. ClaudeFlow gives you battle-tested templates, playbooks, and tools so you can go from idea to shipping in days, not weeks. ## What's Coming - **Workflow templates**: Pre-configured CLAUDE.md files for common use cases - **Context playbooks**: Best-practice context engineering guides - **SaaS starter kits**: Full-stack templates wired for Claude Code - **Agent orchestration**: Multi-agent workflow patterns Check out our [documentation](/docs/) to get started.