# How Role-Based Access Is Mapped in role-map.md for Multi-Operator Setups

> Discover how role-based access is mapped in role-map.md for multi-operator setups. This guide explains the metadata-driven approach for seamless responsibility handoffs.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-18

---

**The [`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md) file in `skills/ops/` defines a lightweight metadata-driven role-to-skill mapping that orchestrates responsibility handoffs across security engagement phases without requiring separate agent processes.**

In the **reverse-skill** repository, multi-operator coordination relies on declarative role definitions rather than process isolation. The [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/role-map.md) file serves as the central authority for who does what, when, and with which tools—enabling both distributed teams and single-operator workflows to maintain the same logical structure.

## Role Table: The Core Mapping Structure

The **role-map.md** table (lines 9‑18) assigns eight standard roles to specific skill directories. Each role code maps to a localized name, primary responsibility, and the tool skills they invoke:

| Code | Name | Responsibility | Primary Skill Directories |
|------|------|--------------|---------------------------|
| **lead** | Lead / 总指挥 | Task breakdown, scope gating, synthesis | `attack-chain/`, `docs-generator/` |
| **cie** | 情报收集 (intelligence) | Asset discovery, exposure surface | `pentest-tools/` (recon), `browser-automation/`, `cloud-k8s/` |
| **cpe** | 渗透验证 (penetration) | Exploit validation, impact confirmation | `pentest-tools/`, `api-security/`, `windows-ad/`, `wifi-wireless/`, `database-security/`, `identity-federation/`, `ot-ics/` |
| **cre** | 逆向分析 (reverse) | Binary, firmware, mobile, front-end logic | `ida-reverse/`, `ghidra-reverse/`, `radare2/`, `apk-reverse/`, `mobile-reverse/`, `macos-reverse/`, `js-reverse/`, `browser-extension-reverse/`, `dotnet-reverse/`, `go-rust-reverse/`, `firmware-pentest/`, `hardware-security/`, `malware-analysis/`, `protocol-reverse/`, `thick-client/`, `reverse-engineering/` |
| **cae** | 代码审计 (audit) | Source code, supply-chain | `code-audit/`, `supply-chain-security/` |
| **cbe** | 蓝队/取证 (blue/forensics) | Threat hunting, digital forensics | `threat-hunting/`, `digital-forensics/` |
| **cce** | 密码学 (crypto) | Algorithm review, key misuse | `reverse-engineering/` (documentation mode) |
| **llm** | AI 安全 | Prompt/Agent security | `llm-security/` |
| **doc** | 文档官 (documentation) | Reports, diagrams | `docs-generator/`, `diagram-generator/` |

This mapping allows the routing engine in [`MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/MASTER-ROUTING.md) to dispatch work to the correct skill implementation based on active role assignment.

## Lead Role Protocol and Stage Gating

The **lead** role enforces mandatory workflow controls through [`ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/ops/scope-contract.md). Its five-step protocol prevents scope creep:

1. Emit **PRIMARY** via `master-route` with `lead_role=lead` (lines 22‑23 in role-map.md).
2. Author [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) through [`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md) (line 25).
3. Declare `specialist_roles[]` and handoff criteria in the contract.
4. At stage completion, update `timeline` and `workitems`; route to next role or finalize report.
5. **Explicitly prohibited**: Skipping scope definition to jump directly to scanning (`cpe`).

This gating ensures that **role-based access control** is enforced at the workflow level, not just file permissions.

## Handoff Rules: Concrete Triggers and Deliverables

Role transitions follow a documented matrix (lines 31‑38) that specifies triggers and required deliverables:

| From → To | Trigger | Required Deliverable |
|-----------|---------|---------------------|
| **lead → cie** | Asset surface needed | [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) + known domains/IPs |
| **cie → cpe** | Live services discovered | Asset list + ports/URLs |
| **cpe → cre** | Reverse verification needed | Sample path + suspicious indicators |
| **cre → cpe** | Protocol/key reconstructed | Algorithm description + reproducible command |
| **any → doc** | Stage/task completed | Draft evidence/finding/path |
| **any → lead** | Block, privilege escalation, or path change | Timeline note + block reason |

These **handoff conditions** are parsed by routing scripts to automate role transitions while maintaining audit trails.

## Single-Agent Workflow: Role Prefixes Preserve Multi-Operator Logic

The repository supports **single-agent mode** without losing role-based structure. Outputs are prefixed with bracketed role tags:

```text
[lead] 规划阶段 → scope.md
[cie] 发现资产 → https://example.com
[cpe] nuclei high findings → E-003

```

The timeline parser filters these prefixes to reconstruct per-role event streams. This design lets one operator execute all roles sequentially while the system maintains the same logical separation as a six-person team.

## Integration with Routing Engine

Three files cooperate to implement **role-based access mapping**:

- **[`MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/MASTER-ROUTING.md)** — Declares the **PRIMARY skill** (current execution hub).
- **[`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md)** — Determines **who** is responsible and records this in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md).
- **[`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md)** — Binds `lead_role`, specialist roster, and handoff conditions.

The routing engine consults all three to enforce stage gates and orchestrate transitions.

## Practical Configuration Examples

### Configuring Lead Role and Specialists in scope-contract.md

```yaml

# ops/scope-contract.md

lead_role: lead                     # see role-map.md line 22

specialist_roles:
  - cie
  - cpe
hand_off_conditions:
  - when: assets_discovered
    to: cie
  - when: live_services
    to: cpe

```

The `lead_role` field (line 25) anchors the workflow to the lead protocol defined in [`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md).

### Timeline Entry with Role Prefix

```text
[timestamp] [lead] set scope → scope.md created
[timestamp] [cie] recon → discovered 3 hosts, 2 domains
[timestamp] [cpe] exploit → CVE-2023-XXXXX confirmed
[timestamp] [doc] draft → evidence.md updated

```

Routing scripts parse bracketed tags to update `timeline` and trigger handoffs per the matrix.

### Automated Handoff in Routing Script

```powershell

# In master-route.ps1

if ($role -eq 'lead' -and $stage -eq 'recon_needed') {
    Set-Role -NextRole 'cie' -Deliverables 'scope.md, known_ips.txt'
}

```

The script validates against [`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md) that `lead → cie` requires scope and known IPs.

## File Reference for Role-Based Access Implementation

| File | Purpose |
|------|---------|
| [`skills/ops/role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/role-map.md) | Central role-to-skill mapping, lead protocol, handoff rules |
| [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) | Declares `lead_role`, specialist list, handoff conditions |
| [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) | Orchestrates PRIMARY skill, consumes role-map for decisions |
| [`skills/ops/IDENTITY.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/IDENTITY.md) | Operator identity linked to role assignments |
| [`skills/ops/evidence-finding-path.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/evidence-finding-path.md) | Evidence chain with role-determined ownership |

## Summary

- **[`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md)** provides a declarative, metadata-driven **role-based access** system for security engagements.
- **Eight standard roles** map to specific skill directories, with `lead` enforcing mandatory scope gating.
- **Handoff matrix** defines concrete triggers and deliverables for role transitions.
- **Single-agent mode** uses bracketed role prefixes to preserve multi-operator logic without process overhead.
- The routing engine combines [`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md), [`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md), and [`MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/MASTER-ROUTING.md) to orchestrate work distribution.

## Frequently Asked Questions

### What is the difference between role-map.md and MASTER-ROUTING.md?

[`MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/MASTER-ROUTING.md) determines **what** skill runs (the PRIMARY execution hub), while [`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md) determines **who** executes it. The routing engine uses both: it selects the skill from [`MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/MASTER-ROUTING.md), then checks [`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md) to confirm the assigned operator has responsibility for that phase and records this in [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md).

### Can a single operator use the multi-operator workflow?

Yes. The **single-agent workflow** (lines 44‑52) lets one operator prefix outputs with role tags like `[cie]` or `[cpe]`. The timeline parser filters these tags to maintain per-role event separation, giving the same logical structure as a distributed team without spawning multiple processes.

### What happens if the lead skips the scope definition?

The lead protocol **explicitly prohibits** jumping directly to `cpe` (penetration) without a [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md). The routing engine enforces this through [`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md) validation; attempts to bypass scope gating should fail or require explicit override documentation in the timeline.

### How are handoff deliverables validated?

Each handoff in the matrix (lines 31‑38) specifies required deliverables. Routing scripts or manual review check for these files before role transition. For example, `lead → cie` requires both [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) and known IPs/domains—automated scripts can verify presence, while lead review ensures content quality.