boundary

name

boundary

description

Generate or update `.claude/rules/tool-boundary.md` from an approved `docs/tool-routing-report.md`. Use when the developer says "boundary", "load tools", "apply routing", "generate boundaries", or approves a routing report and wants per-tool capability, limitation, chain-pattern, and failure-behavior declarations. Requires a routing report with `status: approved`; if missing or unapproved, stop and tell the user to run `/sentinel:routing` or approve the report first. Do not use for scanning or classifying which skills a project needs; use `/sentinel:routing` for that. Preserve manual edits marked with `<!-- manual -->` when updating an existing boundary file.

Boundary Skill

Read the approved routing report and generate/update tool boundary declarations in .claude/rules/.

Prerequisite: docs/tool-routing-report.md must exist with status: approved.

Workflow

Step 0: Validate prerequisite

Read docs/tool-routing-report.md. If it does not exist or status is not approved:

• Tell the developer to run /routing first, or to mark the report as approved
• STOP

Step 1: Read project context

Read the following to understand usage patterns:

• CLAUDE.md (root)
• ARCHITECTURE.md or docs/architecture.md (if exists)
• docs/tool-routing-report.md (the approved routing report)
• .claude/rules/tool-boundary.md (if exists — this is an UPDATE)

Step 2: Generate or update .claude/rules/tool-boundary.md

If the file already exists, update it. If not, create it.

For each included skill/tool, write a boundary declaration based on:

• The skill's SKILL.md content (read via filesystem, not via Skill tool)
• The project documentation (how this project intends to use the tool)
• Known chain patterns and data boundaries

Use this structure:

# Tool Boundaries — {project name}

> Auto-generated by /boundary on {YYYY-MM-DD}
> Source: docs/tool-routing-report.md (approved {date})
> Update by running /boundary again after modifying the routing report.

## Project Scope Declaration

This project uses the following tools. Skills not listed here are global noise — deprioritize them.

### Skills

#### {skill-name}
- **Purpose in this project:** {one sentence from routing report rationale}
- **Can do:** {capabilities}
- **Cannot do:** {limitations}
- **Input constraints:** {what it needs to work}
- **Chain pattern:** {if multi-step, declare the sequence}
- **Failure behavior:** {what to do if it fails}

#### {next skill}
...

### MCP Tools

#### {mcp-server-name}

| Tool | Can do | Cannot do | Input constraints |
|------|--------|-----------|-------------------|
| {tool_name} | ... | ... | ... |

**Chain pattern:** {sequence if multi-step}
**Key boundary:** {most important limitation to remember}

### CLI Tools

#### {cli-tool-name}
- **Purpose in this project:** ...
- **Invocation:** {command pattern}
- **Constraints:** ...

## Escape Hatch

If a routing rule or boundary declaration causes repeated failures (3+ consecutive), fall back to asking the developer rather than following the stale rule. Report the failure pattern so the developer can update the routing report.

Step 3: Verify

After generating/updating:

1. Confirm the boundary file is valid markdown
2. Report to developer:
   • How many boundary declarations were written

Step 4: Suggest next steps

Tell the developer:

• Boundary file is at .claude/rules/tool-boundary.md
• It will be auto-loaded in every session from now on
• To update: modify docs/tool-routing-report.md → re-approve → run /boundary again
• New session recommended to verify skills load correctly

If updating an existing boundary file

• Preserve any manual edits the developer has added (check for <!-- manual --> markers)
• Add new skills from the updated routing report
• Remove skills no longer in the routing report
• Update boundary declarations if project context has changed
• Update the generation timestamp