hf-l2-delegation-gates

Files (8)

• SKILL.md
• evals.json · evals/
• rich-gate-scorecard.md · metrics/
• boundary-guardrails.md · references/
• gates.md · references/
• rich-resource-rationale.md · references/
• check-overlaps.sh · scripts/
• validate-skill.sh · scripts/

SKILL.md (first lines)

## 6-NON Defence Table

| NON | Defence |
|-----|---------|
| NON-1 | Pre-authoring audit documented in references/ |
| NON-2 | Stacks/clashes documented in Cross-References |
| NON-3 | Entry trigger, exit criterion, and loop-back path defined |
| NON-4 | metadata.layer and metadata.role declared; description has exclusions |
| NON-5 | Eval includes stacked scenario |
| NON-6 | Pattern decision documented; scripts have non-zero exit |


<files_to_read>
.opencode/skills/hf-delegation-gates/references/gates.md
.opencode/skills/hf-delegation-gates/references/boundary-guardrails.md
.opencode/skills/hf-delegation-gates/references/rich-resource-rationale.md
</files_to_read>

# Agent Authorization Framework

## First Action

When a user requests agent authorization, immediately load `references/gates.md` for the gate structure and specialist profiles plus `references/boundary-guardrails.md` for child/tool/human boundary checks. Run the authorization checklist before proceeding.

## Authorization Workflow

```
[Task Request] → [Gate 1: Skills Check] → [Gate 2: Specialist Check] → [Gate 3: Capability Match] → [Gate 4: Scope Definition] → [Checkpoint: Human Verify] → [Agent Creation]
```

## Phase 30 Boundary Guardrails

Delegation gates are boundary checks, not just pre-flight checklists. Adapted from OpenAI guardrail tripwires and Claude hook lifecycle events, authorization must distinguish:

| Boundary | Required gate evidence |
|----------|------------------------|
| Workflow boundary | User intent, loaded skills, specialist availability, capability fit, scope document. |
| Child boundary | Handoff metadata: source agent, target agent, reason, allowed destinations, expected return. |
| Tool boundary | Permission/tool profile matches the child scope before mutation. |
| Human boundary | Checkpoint includes options, required response shape, and resume pointer. |

If any boundary is missing evidence, block before dispatch. Do not rely on final review to catch a bad handoff.

### Authorization Checklist

Complete each gate before proceeding to the next:

- [ ] **Gate 1:** Sufficient skills loaded for the task domain (typically 2-4)
- [ ] **Gate 2:** At least 2 specialist subagents available for the task domain
- [ ] **Gate 3:** Task matches specialist capabilities
- [ ] **Gate 4:** File paths and scope defined
- [ ] **Boundary:** Handoff metadata and allowed destinations defined
- [ ] **Boundary:** Tool/permission profile matches scope
- [ ] **Checkpoint:** Human verification (for blocking gates)

## Gate Definitions

### Gate 1: Skills Loaded Check

**Purpose:** Ensure the session has enough context to author an agent.

**Criteria:**
- Sufficient skills loaded from `.opencode/skills/` for the task domain (typically 2-4)
- Skills cover the relevant domain for the task

**If Gate 1 fails:**
```
⚠️ GATE 1 BLOCKED: Insufficient skills loaded
Required: Sufficient skills for task domain (typically 2-4)
Loaded: {count}
Action: Load additional skills before proceeding
```

### Gate 2: Specialist Availability Check

**Purpose:** Verify specialist subagents are available for the task domain.

**Criteria:**
- At least 2 specialist profiles defined for the task domain
- Specialists match task requirements

**If Gate 2 fails:**
```
⚠️ GATE 2 BLOCKED: Insufficient specialists available
Required: At least 2 specialists for task domain
Available: {count}
Action: Define additional specialist profiles
```

### Gate 3: Capability Match Check

**Purpose:** Ensure the task aligns with specialist capabilities.

**Criteria:**
- Task intent matches at least one specialist profile
- No capability gaps in the delegation chain

**If Gate 3 fails:**
```
⚠️ GATE 3 BLOCKED: Task capability mismatch
Task: {task_description}
Specialists: {specialist_list}
Action: Refine task scope or define new specialist profile
```

### Gate 4: Scope Definition Check

**Purpose:** Confirm file paths and task boundaries are defined.

**Criteria:**
- Target file paths identified
- Task scope written in a scope document (conventionally `.hivemind/state/planning/<session-id>/task_plan.md` if `hm-planning-persistence` is loaded, or any documented scope file)

**If Gate 4 fails:**
```
⚠️ GATE 4 BLOCKED: Scope not defined
Required: File paths + task scope in a scope document (conventionally task_plan.md)
Action: Document scope before proceeding
```

From shynlee04/hivemind-plugin, MIT.

More from shynlee04/hivemind-plugin