agentleFS
Sign inStart free
Luis85Luis85/agentic-workflow/CLAUDE.md

agentic-workflow

CLAUDE.md0 starsChanged 6 months agoMITView on GitHub

Entry point for Claude Code in this repository. @AGENTS.md @memory/constitution.md @.claude/memory/MEMORY.md @docs/specorator-product/README.md Template for spec-driven, agentic software development. The workflow itself is the deliverable. See docs/specorator.md for the full definition and README.md for the file map. The lifecycle workflow (Stages 1–11) has two equivalent entry points: State lives in specs/<feature-slug>/workflow-state.md. Each /spec:* command spawns its specialist subagent from .claude/agents/ — don't bypass; agent scoping is intentional. Slash commands update workflow-state.md on stage completion — don't edit by hand mid-workflow. The…

The file

We split this CLAUDE.md into the rules it gives an agent

5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Run the verify gate before opening a PR.

    line 36
  2. Very specific:

    Don't add .claudeignore exclusions silently — note them in docs/steering/tech.md.

    line 42
  3. Distinctive:

    Don't expand the workflow with new stages or roles without an ADR.

    line 47
  4. Distinctive:

    Don't write code from a vague brief — run the upstream stages first or explicitly mark them skipped.

    line 48
  5. Very specific:

    Don't merge feature work directly into workflow template files (docs/, templates/, .claude/) unless you're improving the *template itself*.

    line 49

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
CLAUDE.md

CLAUDE.md

Entry point for Claude Code in this repository.

Primary context

@AGENTS.md @memory/constitution.md @.claude/memory/MEMORY.md @docs/specorator-product/README.md

What this repo is

Template for spec-driven, agentic software development. The workflow itself is the deliverable. See docs/specorator.md for the full definition and README.md for the file map.

How to work here

The lifecycle workflow (Stages 1–11) has two equivalent entry points:

  • Conversational (recommended): say "let's start a feature" or "drive this end-to-end" — the orchestrate skill gates with AskUserQuestion and dispatches the right /spec:* command per stage.
  • Manual: drive the slash commands in stage order — /spec:start, /spec:idea, /spec:research, /spec:requirements, /spec:design, /spec:specify, /spec:tasks, /spec:implement, /spec:test, /spec:review, /spec:release, /spec:retro. Optional gates: /spec:clarify, /spec:analyze.

State lives in specs/<feature-slug>/workflow-state.md. Each /spec:* command spawns its specialist subagent from .claude/agents/ — don't bypass; agent scoping is intentional. Slash commands update workflow-state.md on stage completion — don't edit by hand mid-workflow.

Other tracks

The v1.0 track taxonomy is frozen in ADR-0026. Besides the core lifecycle, opt-in / companion tracks are: Discovery (/discovery:start), Stock-taking (/stock-taking:start), Sales (/sales:start), Project Manager (/project:start), Roadmap (/roadmap:start), Portfolio (/portfolio:start), Quality Assurance (/quality:start), Project Scaffolding (/scaffold:start), Design (/design:start), Issue-breakdown (/issue:breakdown), Issue-draft (/issue:draft), Issue-tackle (/issue:tackle), and Specorator Improvement (/specorator:update). See docs/*-track.md, docs/specorator.md, and .claude/skills/README.md for methodology and conductor details.

Conventions specific to Claude Code

  • Subagents are project-scoped (.claude/agents/) with intentionally narrow tool lists. Missing tool = feature, not bug. Agent-class table lives in AGENTS.md.
  • Skills live in .claude/skills/ — see .claude/skills/README.md. Auto-trigger from natural language; explicit invoke via /<skill-name>.
  • Operational bots live under agents/operational/. Each = PROMPT.md + README.md; the prompt is the source of truth the scheduled run loads.
  • Permission rules live in .claude/settings.json. Pushes to main / develop / demo are denied; --no-verify is denied. See docs/branching.md.
  • Topic branches live in worktrees under .worktrees/<slug>/. See docs/worktrees.md.
  • Run the verify gate before opening a PR. See docs/verify-gate.md.
  • For irreversible architectural decisions, use record-decision (wraps /adr:new).
  • For glossary terms, use /glossary:new "<term>" (wraps new-glossary-entry). Entries live one-per-file under docs/glossary/.
  • For long-running session goals, use /create-goal [slug] (wraps create-goal). Goal documents live under docs/goals/.
  • Where every markdown artifact lands is documented in docs/sink.md. Don't invent new sink locations.
  • New work packages (briefs, RFPs, zips, reference material) land in inputs/. Every conductor consults inputs/ at the start of its scope phase. No auto-extract — see docs/inputs-ingestion.md.
  • Don't add .claudeignore exclusions silently — note them in docs/steering/tech.md.
  • For agentic security review (opt-in for agent-facing features), use /agentic-security-review. Procedure and checklists in docs/agentic-security-review.md.

What not to do

  • Don't expand the workflow with new stages or roles without an ADR.
  • Don't write code from a vague brief — run the upstream stages first or explicitly mark them skipped.
  • Don't merge feature work directly into workflow template files (docs/, templates/, .claude/) unless you're improving the template itself.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free