write-path-mapping

name	write-path-mapping
description	Map the write path of a project across multiple frameworks — entry points, validation, auth, persistence, side-effects. Outputs report, Mermaid diagrams, JSON sidecar. Flags unauth writes, missing RLS, cache gaps. Use for write path, mutation audit, RLS audit.
argument-hint	["target-directory-or-package"]
allowed-tools	Read Grep Glob Write Edit Bash(git:*, ls:*, wc:*, find:*, cat:*, mkdir:*, test:*) Agent
effort	high

Write Path Mapping

ultrathink

Output path directive (canonical — overrides in-body references). All file outputs from this skill MUST be written under .anthril/reports/write-path-mapping/. Run mkdir -p .anthril/reports/write-path-mapping before the first Write call. Primary artefact: .anthril/reports/write-path-mapping/<artefact>. Do NOT write to the project root or to bare filenames at cwd. Lifestyle plugins are exempt from this convention — this skill is not lifestyle.

Before You Start

1. Locate the target. Use $ARGUMENTS if provided, otherwise the current working directory. If neither resolves to a real directory, ask the user for the target path before continuing.
2. Detect the stack. Run scripts/detect-stack.sh to identify languages, frameworks, and monorepo layout. This determines which framework matrix to apply in Phase 2.
3. Detect the persistence layer. Run scripts/detect-db.sh to identify Supabase, Prisma, Drizzle, TypeORM, SQLAlchemy, Django ORM, ActiveRecord, Eloquent, Doctrine, Redis, etc. This determines which mutation matrix to apply in Phase 5.
4. Check tooling availability. Run scripts/check-tools.sh. Missing tools degrade depth but never abort the mapping — ripgrep is the only strongly recommended tool.
5. Load .write-path-ignore. If the target contains this file, parse it and treat entries as suppression rules during Phase 8.
6. Map project structure. Inventory the codebase excluding node_modules/, .venv/, venv/, target/, dist/, build/, .next/, .nuxt/, coverage/, .git/, .turbo/.

User Context

$ARGUMENTS

Detected stack: !bash "${CLAUDE_PLUGIN_ROOT}/skills/write-path-mapping/scripts/detect-stack.sh" .

Detected persistence: !bash "${CLAUDE_PLUGIN_ROOT}/skills/write-path-mapping/scripts/detect-db.sh" .

Tool availability: !bash "${CLAUDE_PLUGIN_ROOT}/skills/write-path-mapping/scripts/check-tools.sh" .

Candidate write entries (fast ripgrep seed): !bash "${CLAUDE_PLUGIN_ROOT}/skills/write-path-mapping/scripts/find-write-endpoints.sh" .

---

Mapping Phases

Execute every phase in order. For each path, record: entry (type, file, line, verb, route, framework), middleware chain, validator, auth layer, handler, persistence targets, fan-out count, downstream effects, risks, verification depth. Use the rubric in ${CLAUDE_PLUGIN_ROOT}/skills/write-path-mapping/reference.md §7 for completeness scoring. Never skip a phase — mark as N/A if genuinely not applicable to the detected stack.

Read-only guarantee. This skill never modifies source files. It emits three new artifacts into the target project:

• write-path-map.md — the main report
• write-path-map.json — the JSON sidecar
• risk-register.md — the standalone risk register

Completeness, not quality. The completeness score measures how thoroughly the skill traced the system, NOT how good the system is. A clean codebase and a messy codebase can both score 100%. System quality is captured separately in the Risk Register.

---

Phase 1: Discovery & Inventory (context only — no score)

Objective: Build an accurate picture of the codebase and its persistence layer before any mapping begins.

1. Read top-level config: package.json, pyproject.toml / setup.py / requirements*.txt, go.mod, Cargo.toml, pom.xml / build.gradle*, composer.json, Gemfile, *.csproj / *.sln.
2. Detect monorepo layout: pnpm-workspace.yaml, lerna.json, nx.json, turbo.json, Cargo.toml [workspace], go.work, rush.json. Each package becomes a mapping target.
3. Run scripts/extract-schema.sh to collect tables, columns, and schema file inventory.
4. Run scripts/extract-triggers.sh to collect CREATE TRIGGER, CREATE FUNCTION, and CREATE POLICY statements.
5. Run scripts/extract-cron.sh to collect scheduled job sources (BullMQ repeat, pg_cron, Celery beat, Rails whenever, GitHub Actions schedule, Vercel Cron, etc.).
6. Run scripts/extract-queues.sh to collect queue producers and consumers (BullMQ, SQS, Kafka, NATS, Celery, Sidekiq, Supabase queue, Cloudflare Queues).
7. Live DB enrichment (optional): run scripts/live-db-probe.sh. If Supabase MCP is configured or DATABASE_URL is set, enrich the schema data with live pg_policies, pg_trigger, and information_schema queries. When Supabase MCP is available, prefer the mcp__*Supabase__execute_sql (SELECT only) and mcp__*Supabase__list_tables tools over psql. If no live source is available, continue with static data.
8. Load .write-path-ignore if present. Surface unjustified entries and stale patterns as Phase 1 warnings.

This phase produces the context block at the top of the report. No completeness score of its own — phase 1 failures become adjustments to overall completeness.

---

Phase 2: Entry-Point Discovery

Objective: Find every write entry point in the project.

1. Consume the seed list from scripts/find-write-endpoints.sh (already run in User Context).
2. Optionally run python3 scripts/ast-entrypoints.py for richer AST-level extraction. Its output is merged with the seed list via scripts/normalize-findings.py.
3. Classify every candidate using the taxonomy in reference.md §1.
4. MANDATORY sub-agent sweep when >30 candidates. Partition the seed list by top-level domain folder (e.g. app/, src/api/, supabase/functions/, workers/, each monorepo package) and spawn one Agent(subagent_type=Explore) per domain in parallel (multiple tool calls in one assistant message). Each sub-agent receives the prompt shape from reference.md §9 and returns a JSON array. Merge via scripts/normalize-findings.py.
5. Deduplicate by (file, line, verb).
6. Drop entries that are clearly read-only (GET routes, pure-query GraphQL queries, reader RPCs).

Phase completeness = traced_entries / discovered_candidates × 100.

---

Phase 3: Middleware & Auth Layer Capture

Objective: For every entry, capture the middleware chain and the auth layer.

1. For each entry, walk the router registration back to the framework bootstrap and record every use(), decorator, guard, before_action, Depends(...), middleware alias, or firewall entry. Use the matrix in reference.md §5.
2. Resolve framework-specific auth: Next.js middleware.ts, NestJS @UseGuards(AuthGuard), FastAPI Depends(get_current_user), Django @login_required / permission classes, Rails before_action :authenticate_user!, Laravel ->middleware('auth'), Symfony firewalls.
3. Supabase RLS cross-reference. For Supabase projects, run scripts/rls-policy-check.sh and intersect each write target table with the RLS policies discovered in Phase 1. Tables with no policy covering the relevant role become missing-rls candidates.
4. Tentatively flag risks (final resolution in Phase 7):
   • Entry with no resolvable auth layer → unauth-write
   • Webhook entry with no signature verification → unverified-webhook
   • Edge function using SUPABASE_SERVICE_ROLE_KEY to write on behalf of user input → service-role-overreach
5. Record the middleware chain in each path's middleware array.

Phase completeness = entries_with_auth_layer_recorded / entries × 100.

---

Phase 4: Validator Detection

Objective: Confirm each entry validates its input.

1. Detect the project's validator libraries (Zod, Yup, Joi, class-validator, Valibot, ArkType, Pydantic, DRF serializers, Go struct tags, PHP voters, Rails strong parameters).
2. For each entry, walk the first N lines of the handler for a .parse(...), .validate(...), @Body(new ValidationPipe()), class SomeDto, schema=ModelSerializer, request.validate(...), or struct-binding pattern.
3. Record the validator in path.validator = { lib, schema, file, line }. If none is found, tentatively flag missing-validation (confirmed in Phase 7).
4. Where possible, cross-reference validator fields against target table columns to detect fields accepted without validation.

Phase completeness = entries_with_validator_recorded_or_confirmed_none / entries × 100.

---

Phase 5: Handler & Persistence Trace

Objective: For every entry, walk the handler into every persistence target.

1. For each handler, resolve imports transitively and enumerate every call matching the persistence matrix in reference.md §4. Start with python3 scripts/ast-write-calls.py on the handler file (and the files it imports). Record each target: kind, target, file, line.

2. Run python3 scripts/transaction-boundary-check.py on the handler file(s) and merge in_transaction flags into the target records.

3. MANDATORY sub-agent sweep when any of:

   • Project has >30 entries total.
   • Any single handler reaches 3+ service-layer hops (e.g. route → service → repo → util).
   • The stack is polyglot (JS frontend + Python worker + Go gateway).

   Partition handlers into batches of 10 and spawn parallel Agent(subagent_type=Explore) calls. Each sub-agent receives the prompt shape from reference.md §9 Phase 5 and returns JSON per handler matching the path block of templates/paths-schema.json.

4. Merge all outputs via scripts/normalize-findings.py.

5. Count fan_out_count = len(persistence_targets) for every path.

6. Paths with zero targets are reclassified as read-only and dropped from the write map (surfaced in §11 Suppressed Paths).

Phase completeness = entries_with_at_least_one_persistence_target / entries × 100. Depth = % of handlers where every delegate was resolved vs. stopped at dynamic dispatch.

---

Phase 6: Async / Fan-Out / DB-Side Effects

Objective: Map non-obvious writes that run after the initial handler returns.

1. Queue fan-out. For every queue-publish found in Phase 5, locate the consumer. If not found in the immediate directory, spawn one sub-agent per unresolved queue with the Phase 6 playbook prompt in reference.md §9. Cross-package search includes ../cloudflare-workers/, ../workers/, docker-compose services, and supabase/functions/. Record consumers as secondary entry points and run Phases 2–5 on them.
2. Cron / scheduled jobs. Using the extract-cron.sh output from Phase 1, treat every scheduled job as a secondary entry point and run Phases 2–5 on its handler.
3. DB trigger chains. For every table touched in Phase 5, look up triggers from the extract-triggers.sh output. For each trigger, record its target table(s) as downstream_effects of kind db-trigger. If there are >5 triggers on the project's schema, spawn one sub-agent to walk the full trigger graph.
4. Domain events. For every event-emit found in Phase 5, locate the subscribers. Record as downstream_effects of kind event-subscriber.
5. Supabase realtime broadcasts. For every channel.send({type: 'broadcast'}) found, note the channel as a downstream effect.
6. Orphan detection. Queues with producers but no consumer → orphan-queue-consumer (HIGH). Consumers with no producer → orphan-queue-publish (LOW). Triggers referencing functions that no longer exist → dead-trigger (HIGH).

Phase completeness = resolved_async_targets / discovered_async_targets × 100.

---

Phase 7: Risk Analysis

Objective: Walk every mapped path through the risk taxonomy and record evidence.

For each path, check every risk subtype from reference.md §6. Record evidence per flagged risk. Apply context-aware severity adjustments:

• unauth-write on a path protected by RLS → downgrade to HIGH. Note the RLS mitigation in evidence.
• missing-transaction where only one persistence target exists → suppress.
• missing-rls confirmed via rls-policy-check.sh → CRITICAL.
• cross-tenant-leak detected when a Supabase/ORM write omits workspace_id (or equivalent) on a workspace-scoped table → CRITICAL.
• dynamic-dispatch-write → always INFO. The skill cannot evaluate dynamic dispatch; the human reviewer must.
• fan-out-write with ≥3 targets but all inside a transaction → INFO. Without a transaction → HIGH.

Deep-dive sub-agents (optional). For any CRITICAL-flagged path with ≥3 middleware layers, spawn one Agent(subagent_type=Explore) to deep-verify the finding before publishing it. The sub-agent confirms whether a compensating control (RLS policy, signature verification, rate limit, tenancy filter) exists elsewhere in the chain and returns {confirmed, evidence, severity_adjustment}.

Phase completeness = paths_with_all_risks_checked / paths × 100.

---

Phase 8: Reporting

Objective: Produce the final artifact set.

1. Merge all findings. Run python3 scripts/normalize-findings.py one final time to produce the unified write-path-map.json under the target project root.
2. Render the main report. Use templates/output-template.md as the structural skeleton. The report must include:
   • Header table (date, stack, persistence, totals, risks by severity, completeness, tier)
   • §1 Executive summary (top paths by fan-out, top risks, top data-domain hotspots)
   • §2 Stack & persistence
   • §3 Write paths by severity (CRITICAL/HIGH/MEDIUM/INFO/OK)
   • §4 Write paths by domain
   • §5 Per-endpoint detail blocks (top 20, ordered severity then fan-out)
   • §6 Data-domain write map (tables, caches, queues, external APIs, file stores)
   • §7 Risk register (inline copy)
   • §8 Suggested .write-path-ignore entries
   • §9 Visual artifacts (all four Mermaid diagrams)
   • §10 JSON sidecar pointer with example
   • §11 Suppressed paths
3. Render the Mermaid diagrams. Run python3 scripts/mermaid-render.py write-path-map.json --out diagrams.md and paste the four diagrams into §9 of the main report. All four are required:
   • A. System write flowchart
   • B. Per-endpoint sequence diagrams (top 20)
   • C. Data-domain write map (bipartite)
   • D. DB trigger / function graph
4. Render the standalone risk register. Use templates/risk-register-template.md. Write to risk-register.md alongside the main report. Cross-link from §7 of the main report.
5. Write artifacts. Using the Write tool, create write-path-map.md, write-path-map.json, and risk-register.md at the project root (or under .claude/ if the project has one). Never overwrite an existing file without asking first.
6. Emit completeness summary. Print the final tier and score to the chat response. Surface any phase that scored <80% as a known gap the user should rerun.

Phase completeness = required_report_sections_rendered / 11 × 100.

---

Completeness Summary

Phase	Focus	Weight
Phase 1 — Discovery	Schema, triggers, cron, queues, ignore file	Phase-1 adjustments
Phase 2 — Entry points	Every write entry found	Coverage
Phase 3 — Middleware & auth	Auth layer recorded per entry	Depth
Phase 4 — Validators	Input validation recorded	Depth
Phase 5 — Persistence trace	Targets + transaction state	Coverage + depth
Phase 6 — Async / triggers	Queue consumers, cron, triggers	Coverage
Phase 7 — Risk analysis	Every risk subtype walked	Depth
Phase 8 — Reporting	All required sections rendered	Depth

Tiers:

• 95–100 — FULLY MAPPED
• 80–94 — MOSTLY MAPPED (gaps listed)
• 60–79 — PARTIALLY MAPPED
• <60 — INSUFFICIENT — rerun with sub-agents or narrower scope

---

Important Principles

• The map is a hypothesis backed by trace evidence. Reports describe what the skill observed; they never refactor or delete code.
• This skill never modifies source files. It only emits three new artifacts (write-path-map.md, write-path-map.json, risk-register.md) at the project root. If those files already exist, ask before overwriting.
• Every mapped path must carry: entry → middleware chain → validator → auth layer → handler → persistence target(s) → downstream effects. A path missing any of these is incomplete.
• Paths without a persistence target are not writes. Drop them or reclassify as reads. Listing GETs in the write map is a bug.
• Completeness measures trace thoroughness, not quality. A 100%-complete map of a broken system is still 100% complete. Quality is captured in the Risk Register.
• DB writes include triggers, functions, policies, and cron jobs. A write path is incomplete until DB-side effects are enumerated via Phase 6.
• Never trust dynamic dispatch silently. Flag dynamic-dispatch-write wherever a write target is resolved at runtime and leave it as INFO for human review.
• Prefer live DB data when available. Static schema files can be out of sync with the live database. If Supabase MCP or DATABASE_URL is available, enrich via Phase 1 step 7.
• Respect .write-path-ignore. Treat entries as load-bearing and surface stale patterns as warnings.
• Sub-agents must be used aggressively. Phase 2 and Phase 5 MUST spawn parallel Explore agents when the project has >30 candidates or any handler has 3+ service-layer hops. Cutting corners here directly reduces completeness.
• Document tool versions (ripgrep, Python, Node) in the report header so runs are reproducible.

---

Edge Cases

1. Empty / prototype project. If fewer than 10 candidate entries exist, produce a minimal map without spawning sub-agents. Completeness tier "FULLY MAPPED" is achievable on small projects.
2. Monorepo. Treat each workspace package as a separate mapping target and produce a per-package map plus a workspace-level rollup. Cross-package writes (a service in package A writing via an import from package B) become fan-out edges.
3. Serverless / edge functions. Each function file is an entry point. Cold-start logic (auth clients, DB pool init) counts as middleware.
4. GraphQL. Every mutation resolver is an entry point. Subscriptions are NOT writes unless they trigger DB publishes. GraphQL queries are never writes.
5. Event-driven / CQRS. Commands are writes. Events emitted from commands are fan-out. Projections that write to read stores are secondary entry points.
6. Multi-tenant. Missing workspace_id / tenant_id filter on a scoped table is cross-tenant-leak CRITICAL. Verify every Supabase/ORM write against the table's column list.
7. Background workers. Queue consumers are secondary entry points. Map both the producer and the consumer. Orphans (producer with no consumer, or vice versa) are flagged in Phase 6.
8. DB triggers and functions. These are persistence-layer write paths with no application code entry point. Map them in Phase 6 from extract-triggers.sh. Include them in the DB trigger graph (Diagram D).
9. Dynamic SQL. Flag sqli-risk if the skill detects string interpolation with user input. Flag dynamic-dispatch-write if routing is resolved at runtime. Never attempt to evaluate dynamic SQL — it's the human reviewer's responsibility.
10. Generated clients (tRPC codegen, Prisma client, GraphQL codegen). Trace to the generator input (schema, router definition), not the generated output. Add generator directories to the suggested .write-path-ignore.
11. Pure read-only project. If zero write paths are detected, emit a "zero write paths detected" report with only Phase 1 output and exit cleanly. This is a valid outcome, not a failure.
12. Unsupported language (Elixir, Haskell, OCaml, Crystal, Zig). Emit "stack not fully supported" in Phase 1 and dump the ripgrep seed list as the map without structural guarantees. Do not fabricate findings.
13. Tool failures. If ast-entrypoints.py or any other helper crashes, record it as a Phase 1 limitation and continue. The skill must never abort on a single-tool failure.