If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sharkdp/fd shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 5d ago
• 17 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 53% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sharkdp/fd repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sharkdp/fd.

What it runs against: a local clone of sharkdp/fd — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sharkdp/fd | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sharkdp/fd. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sharkdp/fd.git
#   cd fd
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sharkdp/fd and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sharkdp/fd(\\.git)?\\b" \\
  && ok "origin remote is sharkdp/fd" \\
  || miss "origin remote is not sharkdp/fd (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/main.rs" \\
  && ok "src/main.rs" \\
  || miss "missing critical file: src/main.rs"
test -f "src/cli.rs" \\
  && ok "src/cli.rs" \\
  || miss "missing critical file: src/cli.rs"
test -f "src/walk.rs" \\
  && ok "src/walk.rs" \\
  || miss "missing critical file: src/walk.rs"
test -f "src/config.rs" \\
  && ok "src/config.rs" \\
  || miss "missing critical file: src/config.rs"
test -f "src/filter/mod.rs" \\
  && ok "src/filter/mod.rs" \\
  || miss "missing critical file: src/filter/mod.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sharkdp/fd"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A software project. See architecture tab.

Developers.

See activity metrics.

Standard open source risks apply.

Check recent commits.

Check README for instructions.

• src/main.rs — Application entry point that orchestrates CLI parsing, config initialization, and the filesystem walk—every developer must understand the control flow here.
• src/cli.rs — CLI argument parsing and validation using a structured approach—essential for understanding supported options and how they map to internal behavior.
• src/walk.rs — Core filesystem traversal logic and filtering pipeline—the heart of fd's parallelized directory walking that differentiates it from standard find.
• src/config.rs — Central configuration struct that ties together CLI args, filters, and execution settings—critical for understanding how options flow through the system.
• src/filter/mod.rs — Filter abstraction layer for name patterns, file types, sizes, ownership, and timing—defines how search criteria are applied uniformly.
• src/exec/mod.rs — Parallel command execution module for -x flag—handles job queuing and thread pool coordination for running commands on matched files.
• Cargo.toml — Project manifest defining dependencies (ignore, regex, aho-corasick, nu-ansi-term) and binary configuration—needed to understand the tech stack.

Add a new filter type (e.g., inode-based)

1. Create a new filter module in src/filter/ (e.g., src/filter/inode.rs) implementing the Filter trait (src/filter/inode.rs)
2. Export the new filter from src/filter/mod.rs and add it to the filter composition logic (src/filter/mod.rs)
3. Add CLI arguments to src/cli.rs for the new filter (e.g., --inode flag) (src/cli.rs)
4. Integrate the filter into Config initialization in src/config.rs (src/config.rs)
5. Add test cases to tests/tests.rs covering the new filter behavior (tests/tests.rs)

Add a new output format (e.g., JSON)

1. Create a new formatter struct in src/fmt/mod.rs implementing the Formatter trait (src/fmt/mod.rs)
2. Add a CLI flag in src/cli.rs to select the new format (e.g., --json) (src/cli.rs)
3. Update src/config.rs to initialize the appropriate formatter based on CLI args (src/config.rs)
4. Integrate formatter selection into src/output.rs (src/output.rs)

Add support for a new command-execution option (e.g., batch mode improvements)

1. Add CLI argument in src/cli.rs for the new execution mode (src/cli.rs)
2. Extend src/exec/job.rs to handle the new job scheduling strategy (src/exec/job.rs)
3. Update src/exec/mod.rs Exec struct and coordinator logic to support the new mode (src/exec/mod.rs)
4. Test the new behavior in tests/tests.rs with integration tests (tests/tests.rs)

• ignore crate (0.4.25) — Provides fast, parallel directory traversal with native .gitignore/.ignore support; core differentiator from standard find for performance.
• regex crate (1.12.2) — Enables flexible pattern matching with smart case handling and performance optimizations; default search mode in fd.
• aho-corasick (1.1) — Efficient multi-pattern string matching for glob expansion and file type checks.
• nu-ansi-term (0.50) — Cross-platform ANSI color output for file type highlighting, matching Unix ls conventions.
• argmax (0.4.0) — Prevents command-line argument overflow when passing many matched files to -x commands.

• Default regex matching instead of glob patterns

  • Why: Regex is more powerful and intuitive for ad-hoc searches; requires fewer quotes/escaping than find.
  • Consequence: Users must use --glob flag for traditional shell glob syntax; regex learning curve for power users.

• Respect .gitignore by default (via ignore crate)

  • Why: Aligns with developer expectations and dramatically reduces spurious results in VCS-tracked projects.
  • Consequence: Adds hidden filtering logic; users seeking all files must use --no-ignore flag; non-VCS projects unaffected.

• Parallelized directory traversal instead of sequential

  • Why: Massive performance improvement on modern multi-core systems and network filesystems.
  • Consequence: Output order is non-deterministic; some use cases (e.g., sorting large result sets) may benefit from --threads 1.

• Opinionated defaults (smart case, colors, readable paths)

  • Why: Reduces cognitive load and eliminates need for common flag combinations; 80/20 rule.
  • Consequence: Less flexibility than find for obscure use cases; mitigated by comprehensive flag coverage.

• Does not aim to replicate all of find's powerful functionality (e.g., -exec with complex shell grammar, -printf formatting).
• Not a Windows-native tool (relies on Unix-like environment; Windows support via WSL or Unix layer).
• Does not handle extremely large result sets with streaming output to avoid memory overhead (buffered in some modes).
• Does not support all find's predicate logic combinations (e.g., negation, arbitrary boolean expressions).

Standard debugging applies.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive tests for src/filter/ modules (owner.rs, size.rs, time.rs)

The filter modules in src/filter/ (owner.rs, size.rs, time.rs) handle critical filtering logic for fd's search capabilities, but tests/tests.rs shows minimal coverage of these filter types. Adding dedicated unit tests would ensure edge cases like boundary conditions in size filters, time parsing variations, and cross-platform owner resolution work correctly across platforms.

• [ ] Create tests/filter_owner_tests.rs with test cases for user/group resolution on Unix and Windows
• [ ] Create tests/filter_size_tests.rs with boundary tests (0 bytes, 1KB, 1GB+, invalid units)
• [ ] Create tests/filter_time_tests.rs for relative/absolute time parsing and timezone handling
• [ ] Add test fixtures in tests/testenv/ if needed for file ownership setup

Add tests for src/exec/ modules (command.rs, job.rs) with edge cases

The exec module handles command execution with parallel job management via crossbeam-channel. Current test coverage appears limited for: shell escaping across platforms, signal handling (SIGINT via ctrlc), argument overflow with argmax, and concurrent execution edge cases. These are critical for reliability.

• [ ] Add tests/exec_command_tests.rs covering shell escaping for Windows vs Unix paths with spaces/special chars
• [ ] Add tests/exec_job_tests.rs for job queue behavior with crossbeam-channel scenarios
• [ ] Test argmax boundary conditions (src/exec/command.rs) with very long file lists
• [ ] Add integration tests for --exec with --parallel flag and signal interruption

Expand doc/fd.1 man page with undocumented features and add EXAMPLES section

The man page (doc/fd.1) is comprehensive but missing detailed examples for complex queries. Given fd's regex support (src/regex_helper.rs), glob patterns (globset 0.4), and the various filter combinations (size, time, owner, type), a structured EXAMPLES section with real-world use cases would significantly improve discoverability and reduce support burden.

• [ ] Add EXAMPLES section to doc/fd.1 with 8-10 real-world patterns (regex, globs, filter combinations)
• [ ] Document examples for --size with different units, --changed-within/--changed-before date formats
• [ ] Include examples combining --type with --exec for common workflows
• [ ] Verify examples align with actual behavior by adding integration tests in tests/tests.rs that match the documentation

Check the issue tracker.

The fd codebase demonstrates generally good security practices with proper dependency management, a security reporting policy, and no obvious injection risks or hardcoded credentials. However, there is a critical build configuration issue (invalid Rust edition) that must be fixed before the project can compile correctly. The incomplete tikv-jemalloc dependency specification and unfinished SECURITY.md documentation are minor concerns that should be addressed for completeness. The project uses well-maintained dependencies and follows Rust best practices for memory safety.

• Medium · Invalid Rust Edition in Cargo.toml — Cargo.toml, line: edition= '2024'. The Cargo.toml specifies edition = '2024', which is not a valid Rust edition. Valid editions are 2015, 2018, and 2021. This will cause build failures and may prevent security updates from being applied correctly. This could be a typo for '2021'. Fix: Change edition to '2021' (the latest stable edition as of Rust 1.90.0). This is likely a typo.
• Low · Incomplete tikv-jemalloc Dependency Declaration — Cargo.toml, tikv-jemalloc dependency. The tikv-jemalloc dependency is declared in Cargo.toml with only the package name and no version specification. This could lead to unpredictable dependency resolution and potential compatibility issues across different build environments. Fix: Specify an explicit version for tikv-jemalloc, e.g., 'tikv-jemallocator = "0.5"' (or appropriate version). Update the package name to match the actual crate name if needed.
• Low · Incomplete SECURITY.md File — SECURITY.md. The SECURITY.md file has incomplete content - it ends abruptly with 'Vulnerabilities will be handled' without completing the section. This may indicate the security policy is not fully documented. Fix: Complete the SECURITY.md file with full details on vulnerability handling timelines, disclosure policies, and escalation procedures.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.