home / skills / splitleaseteam / splitlease_monorepo / context-router

context-router skill

/.claude/skills/context-router

This skill routes tasks through authoritative documentation before code changes to prevent regressions and ensure correct context.

npx playbooks add skill splitleaseteam/splitlease_monorepo --skill context-router

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
3.3 KB
---
name: context-router
description: Routes tasks to authoritative documentation before making changes. Use when planning implementations, debugging issues, or before any code modification to ensure correct context is loaded and regressions are prevented.
---

# Context Router

## Purpose

Before modifying code, this skill ensures Claude loads the **correct authoritative documentation** for the affected domain. This prevents:
- Regression errors (re-introducing already-fixed bugs)
- Context drift (ignoring domain-specific guardrails)
- Non-deterministic outputs (inconsistent behavior across sessions)

## Routing Protocol

When Claude receives a task that will modify code:

### Step 1: Identify Affected Domains

Analyze the task to determine which domains are affected:
- **Page-specific**: Which page(s) will be modified?
- **Backend**: Which Edge Function(s) are involved?
- **Database**: Are there schema/query changes?
- **Auth**: Does this touch authentication flows?
- **Routing**: Are routes being added/modified?

### Step 2: Load Authoritative Context

For each affected domain, load the corresponding documentation from [DOMAIN_INDEX.md](DOMAIN_INDEX.md):

```
Task: "Fix proposal submission on Listing Dashboard"
├─ Page domain     → Load: Pages/LISTING_DASHBOARD_PAGE_CONTEXT.md
├─ Backend domain  → Load: Backend(EDGE - Functions)/PROPOSAL.md
└─ Database domain → Load: Database/DATABASE_TABLES_DETAILED.md (proposal table)
```

### Step 3: Check Regression Guard (Git Tags)

Before implementing, query git tags for known critical fixes:

```bash
git tag -l "guard/*" --format="%(refname:short): %(contents:subject)"
```

For detailed context on a specific guard:
```bash
git show guard/<name> --stat
```

This ensures:
- Has this exact issue been fixed before? (check if guard tag exists)
- What patterns MUST be followed? (read the tag message)
- What was the original fix? (view the tagged commit)

### Step 4: Proceed with Context

Only after loading the correct documentation should Claude proceed with the task. Include a brief note of which docs were consulted:

```
📚 Context loaded:
- LISTING_DASHBOARD_PAGE_CONTEXT.md
- PROPOSAL.md
- REGRESSION_GUARD.md (FK constraint pattern)
```

## Context Selection Rules

| Task Complexity | Base Context | Domain Docs |
|-----------------|--------------|-------------|
| Single file, simple | miniCLAUDE.md | Relevant page/function doc |
| Multi-file, moderate | miniCLAUDE.md | All affected domain docs |
| Cross-cutting, complex | largeCLAUDE.md | All affected domain docs |
| Database changes | largeCLAUDE.md | DATABASE_*.md + affected docs |

## Integration with Orchestration Pipeline

This skill should be applied **during Phase 2 (Planning)**:

```
Phase 1: CLASSIFY → task-classifier
Phase 2: PLAN → [context-router activates here] → planner loads correct docs
Phase 3: EXECUTE → plan-executor
Phase 4: REVIEW → input-reviewer
```

The planner should reference this skill's domain index to include proper documentation in the plan.

## References

- [DOMAIN_INDEX.md](DOMAIN_INDEX.md) - Complete domain-to-documentation mapping
- [REGRESSION_GUARD.md](REGRESSION_GUARD.md) - How to use and create guard tags
- [../../Documentation/](../../Documentation/) - All documentation files
- Git tags: `git tag -l "guard/*"` - Live regression guard from git history

Overview

This skill routes tasks to authoritative documentation before making code changes to ensure correct context is loaded and regressions are avoided. It enforces a pre-change checklist so planning always references the right page, backend, database, and auth docs. Use it to reduce context drift and prevent reintroducing past bugs.

How this skill works

When a task will modify code, the skill analyzes the requested change to identify affected domains (pages, backend/Edge functions, database, auth, routing). It then loads the mapped authoritative documents from the domain index and checks for existing regression guard tags in git. Only after confirming the relevant documentation and any guard constraints does the planner proceed, and it records which docs were consulted.

When to use it

  • Before implementing any change that touches UI pages, backend functions, or database schemas
  • When debugging issues to ensure historical fixes and constraints are considered
  • During planning phase of a multi-file or cross-cutting change
  • Before altering authentication or routing logic
  • When a task may reintroduce known regressions or requires specific guard patterns

Best practices

  • Always map the task to affected domains first (page, backend, db, auth, routing)
  • Load the exact domain docs listed in the domain index for each affected area
  • Query git for guard/* tags to discover prior fixes and mandatory patterns
  • Record the consulted documents in the plan to keep the change audit-friendly
  • Apply this skill in Phase 2 (Planning) so execution has full, authoritative context

Example use cases

  • Fixing a submission flow on a dashboard page: load page, proposal backend, and proposal DB docs
  • Adding a new route that interacts with auth: load routing, auth, and related page docs
  • Changing a database schema: load DATABASE_*.md plus any affected page and backend docs
  • Debugging intermittent production behavior: load domain docs and regression guard tags before proposing fixes
  • Planning a cross-cutting refactor: use largeCLAUDE.md plus all affected domain docs

FAQ

What if a required document is missing from the domain index?

Flag the missing entry, proceed with caution, and escalate to owners to add the authoritative doc before major changes.

When should I check git guard tags?

Always run the guard/* tag query during planning for changes that touch persisted state, critical flows, or recurring bugs.