agentleFS
ahmadAlMezaalahmadAlMezaal/noctra/CLAUDE.md

noctra

CLAUDE.md3 starsChanged 29 days agoMITView on GitHub

AGENTS.md at the repo root is a symlink to this file, so the Codex backend (AGENT_BACKEND=codex) reads the same project guidance Claude does. Edit CLAUDE.md; AGENTS.md follows. Autonomous Linear-to-PR agent in Go. Polls Linear (or GitHub Issues / Jira) for tickets in a trigger state or with a trigger label, dispatches a coding agent to implement them, creates PRs, and moves tickets to review. Up to three work loops share one WaitGroup, worker pool (MAX_CONCURRENT) and active-set, plus a credential…

  • Reads credentials
  • Commits and pushes

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. onelastcommit/noctra★ 4100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository11 other files it gives its agents.

The file

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

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read .claude/skills/<name>/SKILL.md before working in its area.

    line 61
  2. Distinctive:

    Run all of these before every push.

    line 79

≈ “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

Noctra

AGENTS.md at the repo root is a symlink to this file, so the Codex backend (AGENT_BACKEND=codex) reads the same project guidance Claude does. Edit CLAUDE.md; AGENTS.md follows.

Autonomous Linear-to-PR agent in Go. Polls Linear (or GitHub Issues / Jira) for tickets in a trigger state or with a trigger label, dispatches a coding agent to implement them, creates PRs, and moves tickets to review. Up to three work loops share one WaitGroup, worker pool (MAX_CONCURRENT) and active-set, plus a credential check that only alerts:

ticket loop  → source.Fetch → pipeline.process (bounded goroutine)
  → repo.Resolve → repo.CreateOrResumeWorktree → agent.Run → check output
  → (optional) review.Gate → commit/push → gh pr create → source.MarkReady
PR loop      (AUTO_ITERATE_PRS) → watch.Scan → pipeline.iteratePR → push to the same branch
sweep loop   (SWEEP_ENABLED)    → scheduler.Plan → pipeline.processSweepTask → maintenance PR
auth loop    (AUTH_CHECK_SCHEDULE, daily at noon by default) → authcheck.RunAll (logins + cloned repos reachable) → authcheck.Tracker → notify while broken / on recovery
  • TRIGGER_MODE=state (default) polls the TRIGGER_STATE column. TRIGGER_MODE=label polls for TRIGGER_LABEL regardless of column and removes the label after dispatch so the ticket isn't re-polled; the trigger-state ID is then not resolved, but the in-review state still is.
  • Worktrees live at ~/.noctra-worktrees/<IDENTIFIER> so tickets run concurrently.

Guardrails

Each of these has caused a real incident; a plausible-looking patch breaks them easily.

  • ⚠️ The noctra/ branch prefix is reserved for branches Noctra creates — applies to humans and any agent working here. For hand-written work use fix/, feat/, docs/, chore/ or eng-<n>-<slug>. In personal-token mode a running instance claims any noctra/* PR authored by its own GitHub account (ListNoctraPRs filters --author @me plus the prefix), iterates on its review feedback and pushes commits that collide with yours (PR #143). App mode filters by --author app/<slug>, but the rule holds for anyone in token mode.
  • Zero comments in Go source — see Code style.
  • log_offset: agent logs (logs/<IDENTIFIER>.log under the config dir) append across attempts, each headed --- Attempt <timestamp> ---. agent.OffsetBefore records the size before a run and agent.ReadAfter reads only the new tail; BlockedLine and HasRateLimit scan that tail. Scanning the whole file re-detects failures from earlier attempts.
  • Every gh call goes through github.Command / CommandInDir, never a raw exec.CommandContext(ctx, "gh", …), or app mode silently falls back to personal credentials (github-identity).
  • Fresh ticket dispatch uses repo.CreateOrResumeWorktree, not CreateWorktree. A run that pushed but died before gh pr create leaves an orphaned remote branch; re-branching from origin/<main> builds a non-descendant that origin rejects, so the ticket burns a full run per retry until MAX_RETRIES.
  • Any git call that mutates a shared clone runs inside repo.lockRepo. Two tasks on one clone otherwise race on .git/config and one is silently dropped.
  • Names and hidden markers are read back by the PR watcher and lessons extractor. Change branch names, identifiers, commit/PR wording, footers or markers only through the naming skill.
  • Manual sweeps go through Pipeline.TriggerSweep into the existing sweep loop; a second dispatcher would bypass the worker-pool cap (sweeps).
  • After changing internal/dashboard/web/, run yarn build and commit static/, and keep the bundle a single inlined file (dashboard).
  • Report an agent failure through pipeline.describeAgentFailure, not runErr.Error(). The exec error is just exit status 1; the CLI's own reason (and an expired login, via agent.AuthFailureLine + agent.LoginHint) is in the log tail.
  • Start agent runs with p.runAgent, never backend.Run directly. It appends the ENGLISH_VARIANT spelling rule (agent.LanguageSection) to every prompt; a direct call writes in whatever spelling the model defaults to.
  • Keep new operationally significant config visible in the startup banner (pipeline.banner).

Multi-repo routing

The target repo is chosen per ticket; there is no repo registry.

  1. Linear project directive — a Repo: <owner/name | git URL> line (optionally Branch: <name>) in the project's content, falling back to description (linear.Project.RepoDirective). repo.ResolveDirect clones it on demand into ~/.noctra-repos/<slug> (lock-guarded via mkdir(2)). owner/name expands to GitHub HTTPS; full https:///git@ URLs are used verbatim. With no Branch:, the default branch comes from origin/HEAD (fallback MAIN_BRANCH).
  2. REPO_PATH — single-repo fallback (repo.Resolve); otherwise the ticket is skipped with a Linear comment.

Auto-iterate resolves the same way from the PR URL (prRepoOwnerRepo → ResolveDirect). The set of known repos is whatever has been cloned: repo.Resolver.AllRepoPaths scans ReposBase (plus REPO_PATH), and AllRepoRemotes feeds the PR watcher, re-read on every scan.

Config directory

Config defaults to ~/.noctra/ (.env, logs/, state.db). If the current directory contains .env, .env.example or go.mod, Noctra uses cwd instead, so go run works without touching ~/.noctra/ (resolveScriptDir() in cmd/noctra/main.go; config.DefaultConfigDir()). Every variable is documented in .env.example.

Code style

⚠️ Zero comments

This codebase contains no comments. Do not add any. This applies to humans and every agent, and covers doc comments on exported symbols, package docs, TODO/FIXME, section banners and end-of-line asides. The urge to explain is a signal to rename a symbol or extract a function.

The only permitted // lines are directives: //go:embed, //go:build, //go:generate, //nolint:…, // Code generated … DO NOT EDIT. Enforced in CI by make check-comments (scripts/check-comments.sh).

The why lives in this file for cross-cutting behaviour, in the subsystem skills below, and in architecture Invariant 7 for file-level facts (lock ordering, cursor semantics, flag quirks, encoding traps). When a change's reasoning isn't evident from the diff, add a row there — not in the source.

Skills

Read .claude/skills/<name>/SKILL.md before working in its area. Codex and Copilot don't auto-discover skills but can open these paths.

SkillWhen to use
architectureModifying Noctra's source — package map, invariants, testability conventions
auto-iterateThe PR watcher: claiming PRs, feedback and CI triggers, cursors, per-finding replies
sweepsMaintenance sweeps: scheduler, tasks, cost guards, aborted-run salvage, manual trigger
github-identityGITHUB_AUTH_MODE, the GitHub App, token scopes, git credential helper, agent credentials
agent-backendsAdding or changing a coding-agent backend: invocation, rate limits, auth quirks
dashboardThe Preact dashboard: building, committing static/, dev server, auth
namingBranch names, identifiers, commit messages, PR footers, model label, hidden markers
build-and-releaseBuilds, Pi cross-compile, Docker image, systemd upgrade, GoReleaser, cutting releases
setup-and-configInstalling, the setup wizard, .env, the Repo: directive
troubleshootingTickets not picked up, agent errors, PR creation, auto-iterate not reacting
writing-good-ticketsDrafting Linear tickets Noctra can implement autonomously

Build and test

Run all of these before every push; CI fails on any of them.

go build -o noctra ./cmd/noctra
go test -race ./...
go vet ./...          # must be clean
golangci-lint run ./...   # CI pins v2.5.0 (.github/workflows/ci.yml); catches errcheck, which vet doesn't
make check-comments

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.