warden-sweep
Skill6.5k starsChanged 50 days agoMITView on GitHub
Full-repository code sweep. Scans every file with warden, verifies findings via deep tracing, creates draft PRs for validated issues. Use when asked to "sweep the repo", "scan everything", "find all bugs", "full codebase review", "batch code analysis", or run warden across the entire repository.
- Commits and pushes
3 other projects use a version of this, 1 of them edited.
Trending
Quiet since May.about the whole repository
Most recently taken up by
- getsentry/MobileBuildMCPword for word, first seen Sep 23, 2026
- getsentry/XcodeBuildMCPword for word, first seen Sep 23, 2026
- getsentry/wardenedited, first seen Feb 18, 2026
Who's talking about cameroncooke/XcodeBuildMCP
- @hieu-dinh.bsky.social“XcodeBuildMCP lets you build and run your iOS/macOS app directly through an agent in Cursor, Windsurf. What …”Bluesky · Apr 20, 2025 · 4 likes
- @iurysouza.dev“Question for our mobile devs out there: Do you have mcps or skills recommendations for tooling that closes …”Bluesky · Jan 29, 2026 · 3 likes
- @samwho.dev“Yeah for this one the only code I’ve read is the diffs as they fly past. Did most of it by voice on my …”Bluesky · Jul 6, 2025 · 2 likes
- getsentry/MobileBuildMCP“chore(deps): bump @modelcontextprotocol/sdk from 1.25.2 to 1.26.0”GitHub · Feb 4, 2026 · 1 reactions
- getsentry/MobileBuildMCP“chore(deps): bump hono from 4.11.4 to 4.11.7”GitHub · Jan 27, 2026 · 1 reactions
The biggest 5 of 21 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 21
Talked about on GitHub and Bluesky (21 times).
On GitHub · 17
- Feb 4, 2026chore(deps): bump @modelcontextprotocol/sdk from 1.25.2 to 1.26.0 — getsentry/MobileBuildMCP1 reaction · 1 comment
- Jan 27, 2026chore(deps): bump hono from 4.11.4 to 4.11.7 — getsentry/MobileBuildMCP1 reaction · 1 comment
- Jan 13, 2026chore(deps): bump hono from 4.11.3 to 4.11.4 — getsentry/MobileBuildMCP1 reaction · 1 comment
- Jan 7, 2026chore(deps): bump @modelcontextprotocol/sdk from 1.25.1 to 1.25.2 — getsentry/MobileBuildMCP1 reaction · 1 comment
- Jul 31, 2025feat: Add Xcode MCP marketplace support and comprehensive proposal — RooCodeInc/Roo-Code1 reaction · 1 comment
12 more on GitHub
- Jun 11, 2025Add progress notifications for build tools — getsentry/MobileBuildMCP1 reaction · 3 comments
- May 31, 2026Broken links detected (2026-06-14) — awesome-ai-tools/curated-mcp-servers0 reactions
- Dec 16, 2025XcodeBuildMCP 1.15.0 released — SwiftOldDriver/iOS-Weekly0 reactions
- Oct 9, 2025Permanently allow specific bash commands to run outside the sandbox (like `xcodebuild ...`) — openai/codex0 reactions · 2 comments
- Sep 30, 2025[MCP Catalog] New MCP server candidate: io.github.cameroncooke/XcodeBuildMCP — obot-platform/mcp-catalog0 reactions · 1 comment
- Sep 30, 2025[MCP Catalog] New MCP server candidate: com.xcodebuildmcp/XcodeBuildMCP — obot-platform/mcp-catalog0 reactions · 1 comment
- Sep 29, 2025[MCP Catalog] New MCP server candidate: com.xcodebuildmcp/XcodeBuildMCP — obot-platform/obot0 reactions
- Sep 29, 2025[MCP Catalog] New MCP server candidate: io.github.cameroncooke/XcodeBuildMCP — obot-platform/obot0 reactions
- Jul 23, 2025[Bug]: Claude Code GitHub Workflow permissions issue — getsentry/MobileBuildMCP0 reactions · 6 comments
- Jun 9, 2025Parsing error in swift-collections package — cameroncooke/xcodemake0 reactions
- May 13, 2025Application for XcodeBuildMCP — 1Password/for-open-source0 reactions · 2 comments
- Mar 28, 2025[Server Submission]: XcodeBuild MCP — cline/mcp-marketplace0 reactions · 2 comments
On Bluesky · 4
- Apr 20, 2025XcodeBuildMCP lets you build and run your iOS/macOS app directly through an agent in Cursor, Windsurf. What a great addition to the Xcode… — @hieu-dinh.bsky.social4 likes and reposts
- Jan 29, 2026Question for our mobile devs out there: Do you have mcps or skills recommendations for tooling that closes the agentic Loop? I just heard… — @iurysouza.dev3 likes and reposts · 1 reply
- Jul 6, 2025Yeah for this one the only code I’ve read is the diffs as they fly past. Did most of it by voice on my laptop this afternoon. Only notable… — @samwho.dev2 likes and reposts
- Mar 28, 2025Or use XcodeBuildMCP Cameron Cooke to run the app directly from Claude: "Can you build and run my macOS app?" github.com/cameroncook... — @tuist.dev0 likes and reposts · 1 reply
Other versions3 projects use a version of this.
Word for word · 2
- getsentry/MobileBuildMCP★ 6.5k100% same
- getsentry/XcodeBuildMCP★ 6.5k100% same
Edited · 1
- getsentry/warden★ 42316% same
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 repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- mobilebuildmcp-docs-command-reviewSkill
- mobilebuildmcp-docs-release-reviewSkill
- mobilebuildmcp-packaging-resource-reviewSkill
- mobilebuildmcp-rendering-streaming-reviewSkill
- mobilebuildmcp-runtime-boundary-reviewSkill
- mobilebuildmcp-snapshot-fixture-reviewSkill
- mobilebuildmcp-structured-output-reviewSkill
- mobilebuildmcp-test-boundary-reviewSkill
- mobilebuildmcp-tool-contract-reviewSkill
- wardenSkill
- mobilebuildmcp-cliSkill
- mobilebuildmcpSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 3 are distinctive, and 11 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Important: Run all scripts from the repository root using ${CLAUDE_SKILL_ROOT}.
- Distinctive: line 111
On failure: If exit code 1, show the error JSON and stop.
- Very specific: line 121
Check if data/verify/<finding-id>.json already exists (incrementality).
- Very specific: line 127
Read ${CLAUDE_SKILL_ROOT}/references/verify-prompt.md for the prompt template.
- Very specific: line 132
Write result to data/verify/<finding-id>.json
- Very specific: line 157
Update manifest: set phases.verify to "complete".
- Distinctive: line 183
Create a tracking issue that ties all PRs together and gives reviewers a single overview.
- Very specific: line 228
Check if finding ID already exists in data/patches.jsonl (incrementality).
- Very specific: line 230
Dedup check: Use the file index from index_prs.py output to determine if an existing open PR already addresses the same issue.
- Very specific: line 232
File match: Look up the finding's file path in the fileIndex.
- Very specific: line 233
Chunk overlap: If a PR does touch the same file, read its cached diff from data/pr-diffs/<number>.diff and check whether the PR's changed …
- Very specific: line 254
If the subagent returned "status": "skipped" (not "applied"), do NOT proceed to Steps 3-4.
- Distinctive: line 271
Create the PR with a 1-2 sentence "What" summary based on the finding and fix, followed by the finding description and verification …
- Very specific: line 368
Check data/manifest.json to see which phases are complete
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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.
Files
Warden Sweep
Full-repository code sweep: scan every file, verify findings with deep tracing, create draft PRs for validated issues.
Requires: warden, gh, git, jq, uv
Important: Run all scripts from the repository root using ${CLAUDE_SKILL_ROOT}. Output goes to .warden/sweeps/<run-id>/.
Bundled Scripts
scripts/scan.py
Runs setup and scan in one call: generates run ID, creates sweep dir, checks deps, creates warden label, enumerates files, runs warden per file, extracts findings.
uv run ${CLAUDE_SKILL_ROOT}/scripts/scan.py [file ...]
--sweep-dir DIR # Resume into existing sweep dirscripts/index_prs.py
Fetches open warden-labeled PRs, builds file-to-PR dedup index, caches diffs for overlapping PRs.
uv run ${CLAUDE_SKILL_ROOT}/scripts/index_prs.py <sweep-dir>scripts/create_issue.py
Creates a GitHub tracking issue summarizing sweep results. Run after verification, before patching.
uv run ${CLAUDE_SKILL_ROOT}/scripts/create_issue.py <sweep-dir>scripts/organize.py
Tags security findings, labels security PRs, updates finding reports with PR links, posts final results to tracking issue, generates summary report, finalizes manifest.
uv run ${CLAUDE_SKILL_ROOT}/scripts/organize.py <sweep-dir>scripts/extract_findings.py
Parses warden JSONL log files and extracts normalized findings. Called automatically by scan.py.
uv run ${CLAUDE_SKILL_ROOT}/scripts/extract_findings.py <log-path-or-directory> -o <output.jsonl>scripts/generate_report.py
Builds summary.md and report.json from sweep data. Called automatically by organize.py.
uv run ${CLAUDE_SKILL_ROOT}/scripts/generate_report.py <sweep-dir>scripts/find_reviewers.py
Finds top 2 git contributors for a file (last 12 months).
uv run ${CLAUDE_SKILL_ROOT}/scripts/find_reviewers.py <file-path>Returns JSON: {"reviewers": ["user1", "user2"]}
Phase 1: Scan
Run (1 tool call):
uv run ${CLAUDE_SKILL_ROOT}/scripts/scan.pyTo resume a partial scan:
uv run ${CLAUDE_SKILL_ROOT}/scripts/scan.py --sweep-dir .warden/sweeps/<run-id>Parse the JSON stdout. Save runId and sweepDir for subsequent phases.
Report to user:
## Scan Complete
Scanned **{filesScanned}** files, **{filesTimedOut}** timed out, **{filesErrored}** errors.
### Findings ({totalFindings} total)
| # | Severity | Skill | File | Title |
|---|----------|-------|------|-------|
| 1 | **HIGH** | security-review | `src/db/query.ts:42` | SQL injection in query builder |
...Render every finding from the findings array. Bold severity for high and above.
On failure: If exit code 1, show the error JSON and stop. If exit code 2, show the partial results. List timed-out files separately from errored files so users know which can be retried.
Phase 2: Verify
Deep-trace each finding using Task subagents to qualify or disqualify.
For each finding in data/all-findings.jsonl:
Check if data/verify/<finding-id>.json already exists (incrementality). If it does, skip.
Launch a Task subagent (subagent_type: "general-purpose") for each finding. Process findings in parallel batches of up to 8 to improve throughput.
Task prompt for each finding:
Read ${CLAUDE_SKILL_ROOT}/references/verify-prompt.md for the prompt template. Substitute the finding's values into the ${...} placeholders.
Process results:
Parse the JSON from the subagent response and:
- Write result to
data/verify/<finding-id>.json - Append to
data/verified.jsonlordata/rejected.jsonl - For verified findings, generate
findings/<finding-id>.md:
# ${TITLE}
**ID**: ${FINDING_ID} | **Severity**: ${SEVERITY} | **Confidence**: ${CONFIDENCE}
**Skill**: ${SKILL} | **File**: ${FILE_PATH}:${START_LINE}
## Description
${DESCRIPTION}
## Verification
**Verdict**: Verified (${VERIFICATION_CONFIDENCE})
**Reasoning**: ${REASONING}
**Code trace**: ${TRACE_NOTES}
## Suggested Fix
${FIX_DESCRIPTION}
```diff
${FIX_DIFF}
Update manifest: set `phases.verify` to `"complete"`.
**Report** to user after all verifications:
Verification Complete
{verified} verified, {rejected} rejected.
Verified Findings
| # | Severity | Confidence | File | Title | Reasoning |
| 1 | HIGH | high | src/db/query.ts:42 | SQL injection in query builder | User input flows directly into... |
| ... |
Rejected ({rejected_count})
{findingId}{file}: {reasoning} ...
---
## Phase 3: Issue
Create a tracking issue that ties all PRs together and gives reviewers a single overview.
**Run** (1 tool call):
```bash
uv run ${CLAUDE_SKILL_ROOT}/scripts/create_issue.py ${SWEEP_DIR}Parse the JSON stdout. Save issueUrl and issueNumber for Phase 4.
Report to user:
## Tracking Issue Created
{issueUrl}On failure: Show the error. Continue to Phase 4 (PRs can still be created without a tracking issue).
Phase 4: Patch
For each verified finding, create a worktree, fix the code, and open a draft PR. Process findings sequentially (one at a time) since parallel subagents cross-contaminate worktrees.
Severity triage: Patch HIGH and above. For MEDIUM, only patch findings from bug-detection skills (e.g., code-review, security-review). Skip LOW and INFO findings.
Step 0: Setup (run once before the loop):
uv run ${CLAUDE_SKILL_ROOT}/scripts/index_prs.py ${SWEEP_DIR}Parse the JSON stdout. Use fileIndex for dedup checks.
Determine the default branch and fetch latest so worktrees branch from current upstream:
DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
git fetch origin "${DEFAULT_BRANCH}"For each finding in data/verified.jsonl:
Check if finding ID already exists in data/patches.jsonl (incrementality). If it does, skip.
Dedup check: Use the file index from index_prs.py output to determine if an existing open PR already addresses the same issue.
- File match: Look up the finding's file path in the
fileIndex. If no PR touches that file, no conflict; proceed to Step 1. - Chunk overlap: If a PR does touch the same file, read its cached diff from
data/pr-diffs/<number>.diffand check whether the PR's changed hunks overlap with the finding's line range (startLine-endLine). Overlapping or adjacent hunks (within ~10 lines) indicate the same code region. - Same concern: If the hunks overlap, compare the PR title and the finding title/description. Are they fixing the same kind of defect? A PR fixing an off-by-one error and a finding about a null check in the same function are different issues; both should proceed.
Skip the finding only when there is both chunk overlap AND the PR addresses the same concern. Record it in data/patches.jsonl with "status": "existing" and "prUrl" pointing to the matching PR, then continue to the next finding.
Step 1: Create worktree
BRANCH="warden-sweep/${RUN_ID}/${FINDING_ID}"
WORKTREE="${SWEEP_DIR}/worktrees/${FINDING_ID}"
git worktree add "${WORKTREE}" -b "${BRANCH}" "origin/${DEFAULT_BRANCH}"Each finding branches from the repo's default branch so PRs contain only the fix commit.
Step 2: Generate fix
Launch a Task subagent (subagent_type: "general-purpose") to apply the fix in the worktree. Read ${CLAUDE_SKILL_ROOT}/references/patch-prompt.md for the prompt template. Substitute the finding's values and worktree path into the ${...} placeholders.
Step 2b: Handle skipped findings
If the subagent returned "status": "skipped" (not "applied"), do NOT proceed to Steps 3-4. Instead:
- Record the finding in
data/patches.jsonlwith"status": "error"and"error": "Subagent skipped: ${skipReason}" - Clean up the worktree
- Continue to the next finding
Step 3: Find reviewers
uv run ${CLAUDE_SKILL_ROOT}/scripts/find_reviewers.py "${FILE_PATH}"Step 4: Create draft PR
cd "${WORKTREE}" && git push -u origin HEAD:"${BRANCH}"Create the PR with a 1-2 sentence "What" summary based on the finding and fix, followed by the finding description and verification reasoning:
REVIEWERS=""
# If find_reviewers.py returned reviewers, build the flags
# e.g., REVIEWERS="--reviewer user1 --reviewer user2"
gh pr create --draft \
--label "warden" \
--title "fix: ${TITLE}" \
--body "$(cat <<'EOF'
${FIX_WHAT_DESCRIPTION}
${DESCRIPTION}
${REASONING}
Automated fix for Warden finding ${FINDING_ID} (${SEVERITY}, detected by ${SKILL}).
<!-- Only include the next line if Phase 3 succeeded and ISSUE_NUMBER is available -->
Ref #${ISSUE_NUMBER}
> This PR was auto-generated by a Warden Sweep (run ${RUN_ID}).
> The finding has been validated through automated deep tracing,
> but human confirmation is requested as this is batch work.
EOF
)" ${REVIEWERS}Save the PR URL.
Step 5: Record and cleanup
Append to data/patches.jsonl (use "created" as status for successful PRs, not the subagent's "applied"):
{"findingId": "...", "prUrl": "https://...", "branch": "...", "reviewers": ["user1", "user2"], "filesChanged": ["..."], "status": "created|existing|error"}Remove the worktree:
cd "$(git rev-parse --show-toplevel)"
git worktree remove "${WORKTREE}" --forceError handling: On failure at any step, write to data/patches.jsonl with "status": "error" and "error": "...", clean up the worktree, and continue to the next finding.
Update manifest: set phases.patch to "complete".
Report to user after all patches:
## PRs Created
**{created}** created, **{skipped}** skipped (existing), **{failed}** failed.
| # | Finding | PR | Status |
|---|---------|-----|--------|
| 1 | `security-review-a1b2c3d4` SQL injection in query builder | #142 | created |
| 2 | `code-review-e5f6g7h8` Null pointer in handler | - | existing (#138) |
...Phase 5: Organize
Run (1 tool call):
uv run ${CLAUDE_SKILL_ROOT}/scripts/organize.py ${SWEEP_DIR}Parse the JSON stdout.
Report to user:
## Sweep Complete
| Metric | Count |
|--------|-------|
| Files scanned | {filesScanned} |
| Findings verified | {verified} |
| PRs created | {prsCreated} |
| Security findings | {securityFindings} |
Full report: `{summaryPath}`On failure: Show the error and note which steps completed.
Resuming a Sweep
Each phase is incremental. To resume from where you left off:
- Check
data/manifest.jsonto see which phases are complete - For scan: pass
--sweep-dirtoscan.py - For verify: existing
data/verify/<id>.jsonfiles are skipped - For issue:
create_issue.pyis idempotent (skips ifissueUrlin manifest) - For patch: existing entries in
data/patches.jsonlare skipped - For organize: safe to re-run (idempotent)
Output Directory Structure
.warden/sweeps/<run-id>/
summary.md # Stats, key findings, PR links
findings/ # One markdown per verified finding
<finding-id>.md
security/ # Security-specific view
index.jsonl # Security findings index
<finding-id>.md # Copies of security findings
data/ # Structured data for tooling
manifest.json # Run metadata, phase state
scan-index.jsonl # Per-file scan tracking
all-findings.jsonl # Every finding from scan
verified.jsonl # Findings that passed verification
rejected.jsonl # Findings that failed verification
patches.jsonl # Finding -> PR URL -> reviewers
existing-prs.json # Cached open warden PRs
report.json # Machine-readable summary
verify/ # Individual verification results
<finding-id>.json
logs/ # Warden JSONL logs per file
<hash>.jsonl
pr-diffs/ # Cached PR diffs for dedup
<number>.diffDoes 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
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.

