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

The 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 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 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. 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 through 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 + 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:

[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 — Declares the PRIMARY skill (current execution hub).
• role-map.md — Determines who is responsible and records this in scope.md.
• 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

# 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.

Timeline Entry with Role Prefix

[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

# 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 that lead → cie requires scope and known IPs.

File Reference for Role-Based Access Implementation

File	Purpose
skills/ops/role-map.md	Central role-to-skill mapping, lead protocol, handoff rules
skills/ops/scope-contract.md	Declares lead_role, specialist list, handoff conditions
skills/MASTER-ROUTING.md	Orchestrates PRIMARY skill, consumes role-map for decisions
skills/ops/IDENTITY.md	Operator identity linked to role assignments
skills/ops/evidence-finding-path.md	Evidence chain with role-determined ownership

Summary

• 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, scope-contract.md, and 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 determines what skill runs (the PRIMARY execution hub), while role-map.md determines who executes it. The routing engine uses both: it selects the skill from MASTER-ROUTING.md, then checks role-map.md to confirm the assigned operator has responsibility for that phase and records this in 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. The routing engine enforces this through 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 and known IPs/domains—automated scripts can verify presence, while lead review ensures content quality.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}