# AUDIT-recursive-audit

> v2.0: Multi-surface skill audit (10 agent homes) with cross-surface contrast, drift/orphan/dual-name detection. Load when reviewing the skill portfolio, after modifying skills, or after adding/removing agent harnesses.

- Skill: `ariffazil/audit-recursive-audit` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add ariffazil/audit-recursive-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ariffazil/audit-recursive-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ariffazil (https://skillmd.com/u/ariffazil)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ariffazil/audit-recursive-audit

---


# arifos-recursive-audit v2.0 (O_Ω Constitutional Layer)

## v2.0 Upgrade (2026-08-08)

> Cross-surface methodology added. Now audits ALL 10 agent surfaces (AAA canonical, kimi, opencode, grok, claude, codex, hermes, hermes-asi, openclaw-ws, openclaw-bundled), not just one directory.
> **Contrast template:** `/root/AAA/skills/CONTRAST_ANALYSIS_2026-08-08.md`

## Cross-Surface Inventory (NEW)

```bash
# 1. Dump each surface (example for AAA vs kimi)
comm -23 <(ls /root/AAA/skills/ | sort) <(ls /root/.kimi-code/skills/ | sort)   # orphans: AAA has, kimi lacks
comm -13 <(ls /root/AAA/skills/ | sort) <(ls /root/.kimi-code/skills/ | sort)   # drift: kimi has, AAA lacks
```

### 10 Surfaces

| # | Surface | Path | Type |
|---|---------|------|------|
| 1 | AAA canonical | `/root/AAA/skills/` | SOT |
| 2 | kimi | `/root/.kimi-code/skills/` | copy |
| 3 | opencode | `/root/.arifos/agents/opencode/skills/` | symlink |
| 4 | grok | `/root/.grok/skills/` | symlink |
| 5 | claude | `/root/.claude/skills/` | symlink |
| 6 | codex | `/root/.codex/skills/` | symlink |
| 7 | hermes | `/root/.hermes/skills/` | copy |
| 8 | hermes-asi | `/usr/local/lib/hermes-agent/skills/` | copy |
| 9 | openclaw-ws | `/root/.openclaw/workspace/skills/` | copy |
| 10 | openclaw-bundled | bundled | built-in |

### Classification Matrix (NEW)

| Verdict | Condition | Action |
|---------|-----------|--------|
| ✅ PROMOTE | kimi/agent has it, AAA lacks, universal | Copy to AAA, register V3, add alias |
| 📦 ARCHIVE | agent has it, AAA has better version | Move to `_retired/<date>/` |
| 🔧 HARNESS-NATIVE | agent-specific (claude-xml, copilot, grok-profile) | OK — don't promote |
| 🔲 NEED MIRROR | AAA has it, agent lacks | Copy/symlink to agent |
| ⚠️ DUAL-NAME | Same skill, different names across surfaces | Alias table entry or symlink |
| ☠️ VOID | Zero invocations, zero evidence | SKILL.md → SKILL.md.VOID |


## arifOS-ACT Embedding

Before using this skill on any mutating, irreversible, or high-blast-radius task:
1. **ART** — Attune (what is the real task?), Recognize (what class of power?), Test (fit · authority · evidence · blast · reversible).
2. **Kernel** — Route to arifOS for F1–F13 judgment if action class is Maker/Messenger/Mutator/Destroyer/Sovereign.
3. **ACT** — Apply narrow, Constrain scope, Trace witness, STOP before corruption.
4. **Receipt** — Leave evidence of what changed, why, and under whose authority.


## Purpose
Audit all installed skills for overlap, stale docs, prompt bloat, trigger ambiguity, and broken references.

## Use When
1. Reviewing the overall capabilities, naming conventions, and performance of the active skill portfolio.
2. A new skill is drafted or proposed for installation into any workspace or global directory.
3. An existing skill's `SKILL.md` is updated or modified.
4. Executing portfolio maintenance checks to clean up outdated APIs, dead links, or legacy documentation.
5. Tuning the triggering accuracy of skills when experiencing trigger drift.

## Do Not Use When
1. Creating a single new skill from scratch (use `skill-creator` for capture and bootstrapping instead).
2. Linting individual skill trigger statements (use `skill-trigger-linter` instead).
3. The task is a general system performance audit unrelated to L2 Skills.

## Inputs
*   **Skill Directories:** Path to `/root/.agents/skills/` or individual skill directories.
*   **Dependency Files:** package.json, pyproject.toml, wrangler.jsonc configurations.
*   **Audit Manifest:** List of currently configured tools and their execution limits.

## Operational Age Thresholds
*   **Freshness Threshold:** Any skill whose `SKILL.md` has not been modified for **>30 days** MUST be cross-checked against its dependent packages/APIs to verify compatibility.
*   **De-activation Candidate:** Any skill that has not been active in the last **90 days** must be classified as `unused-rot` and flagged for graceful de-activation or archive.

## Rot Classification Schema
Each checked skill must receive a specific Rot Rating in the audit report:
*   **`doc-rot`:** The skill references external URLs, guidelines, or paths that are no longer accessible or have been superseded.
*   **`api-rot`:** The SDK or CLI packages that the skill coordinates (e.g. Wrangler, Agents SDK) have moved past the compatibility versions listed in the skill.
*   **`trigger-rot`:** The skill's triggering criteria overlap semantically with other skills, leading to multiple activations or trigger failures.
*   **`unused-rot`:** The skill is structurally valid but has not registered a telemetry execution record within the threshold window.
*   **`archive-void-rot`:** (Added 2026-08-04) The skill has been physically moved to `.archive-20260804/` but remains discoverable by the skill loader. Physical archive without deactivation (SKILL.md → SKILL.md.VOID) creates drift between filesystem and registry. This is a new rot class discovered during the first autonomous VOID audit.
*   **`drift-rot`:** (Added 2026-08-08) Skill exists on agent surface but NOT in AAA canonical, or vice versa. Classify per matrix: PROMOTE / ARCHIVE / HARNESS-NATIVE / MIRROR.
*   **`dual-name-rot`:** (Added 2026-08-08) Same skill has different names on different surfaces (e.g. FORGE-act-federation-ingress vs FORGE-sct-federation-ingress). Fix via alias table or symlink.

## Procedure
1.  **Portfolio Scan:** Map all active `SKILL.md` files and resolve their frontmatter definitions. Include `.archive-*` directories in the scan — archived skills still discoverable by the loader are `archive-void-rot`.
2.  **Staleness Analysis:** Apply **Age Threshold** rules. Check all embedded documentation URLs and reference scripts against the latest system files and packages.
3.  **Prompt Bloat Check:** Calculate the token density of each skill. Flag files where instruction length exceeds 500 lines.
4.  **Collision Auditing:** Run semantic cross-checks on skill descriptions to flag potential trigger overlaps.
5.  **Rot Classification tagging:** Assign rot ratings (`doc-rot`, `api-rot`, `trigger-rot`, `unused-rot`, `archive-void-rot`) to flagged skills.
6.  **VOID Candidate Surfacing:** Rank candidates by: zero invocations + zero outcome_delta + archive-void-rot. Surface top 3. The VOID pattern: rename SKILL.md → SKILL.md.VOID (F1-reversible), ingest as VERIFY into arifFlow, seal to VAULT999. This is the FQ predator feed — VOIDing dead skills is a VERIFY act that breaks execute-heavy skew.
7.  **Report Generation:** Write a structured markdown analysis identifying critical flaws, warnings, and remediation paths.

## Postconditions
1.  All skills are checked for age thresholds and direct system dependency freshness.
2.  A complete rot matrix mapping overlap risk and prompt size is successfully outputted.
3.  Any identified broken file reference is cataloged in the telemetry report.

## Failure Modes & Escalation
*   **Infinite Loop Detect:** Circular references between skills (e.g. Skill A loads Skill B, which loads Skill A). *Action:* Immediately break recursion, output a warning block, and log the path loop.
*   **Workspace Access Error:** Missing permissions on global or shared folders. *Action:* Degrade gracefully and audit only local workspace skills, raising a warning flag in the report.

## Telemetry per Run
```json
{
  "skill_name": "arifos-recursive-audit",
  "version": "1.1.0",
  "trigger_phrase": "{{trigger_phrase}}",
  "selected_reason": "{{selected_reason}}",
  "latency_ms": 0,
  "token_in": 0,
  "token_out": 0,
  "commands_run": 0,
  "artifacts_written": 0,
  "postcondition_pass": false,
  "human_approval_required": false,
  "hold_code": "{{hold_code}}"
}
```

## Recursive Scorecard
*   **Activation Precision:** [0.0 - 1.0] (Target: >0.90)
*   **Task Completion Rate:** [0.0 - 1.0] (Target: >0.95)
*   **Rollback Safety:** [0.0 - 1.0] (Target: 1.00)
*   **Context Efficiency:** [0.0 - 1.0] (Target: >0.95)
*   **Doc Freshness:** [0.0 - 1.0] (Target: 1.00)
*   **Cross-Skill Collision Rate:** [0.0 - 1.0] (Target: 0.00)
*   **Human Trust Score:** [0.0 - 1.0] (Target: >0.95)

---

## Independent Verification Lane (WAJIB 2 — added 2026-07-19)

A-FORGE planning, execution, AND verification in the same trust chain is the **primary substrate defect** identified in the readiness audit (ARIFOS-READINESS-2026-07-20). This skill documents the required separation so the next agent can implement it.

### The defect (current state)

```
Hermes/A-FORGE plans
    ↓
A-FORGE executes
    ↓
A-FORGE verifies  ← same chain → cannot self-attest
    ↓
A-FORGE summarizes success
```

"Completed and verified" is currently too easy to self-attest. A deployment that returns exit code 0 but leaves the public service broken is reported as success.

### The required separation

```
A-FORGE executes mutation
    ↓
Independent observe-lane verifier reads resulting reality
    ↓
Kernel checks evidence against original success criteria
    ↓
Only then may completion be recorded to VAULT999
```

### Verifier contract (minimum)

```yaml
verification_request:
  original_intent_hash: <sha256>
  success_criteria: <structured>
  mutation_receipt: <VAULT999 entry id>
  executor_identity: <actor_id>
  target_state: <expected world state after mutation>
  permitted_observation_tools: [<list>]   # read-only
  freshness_requirement: <max staleness in ms>

verification_result:
  state: VERIFIED | MISMATCH | INCONCLUSIVE | STALE
  raw_evidence_refs: [<list>]
  method: <how evidence was obtained>
  verifier_identity: <actor_id>
  verifier_independence_proof: <signed assertion>
  observed_at: <unix_ms>
  residual_uncertainty: <OBS/DER/INT/SPEC label + confidence>
```

### Verifier hard rules

The verifier MUST:
- NOT have performed the mutation
- Use independently obtained state (its own MCP reads, not the executor's claim)
- Receive the original success criteria, NOT the executor's rewritten summary
- Be unable to modify the state it is checking
- Record raw evidence and method (not just a verdict)
- Distinguish **command success** (exit code 0) from **outcome success** (real world matches criteria)
- Return one of: VERIFIED, MISMATCH, INCONCLUSIVE, STALE
- NEVER issue constitutional approval — only the kernel may SEAL

### Kernel rejection rules

The kernel MUST reject "completion" when:
- Verifier identity == executor identity
- Evidence originated ONLY from the executor (no independent observation)
- Verifier had mutation permission over the target
- Evidence is older than freshness_requirement
- Original success criteria are missing from the request
- Results cannot be independently reproduced (no second source)

### Audit-discoverable evidence

This skill, when loaded, MUST trigger the audit checklist:
- [ ] Does the proposed verification lane have a distinct identity (not just a flag)?
- [ ] Does the kernel reject self-verification at the contract layer?
- [ ] Are original success criteria preserved through the receipt chain?
- [ ] Can the verifier be invoked without executor cooperation?

### Authority scope

WAJIB 2 is **T3 (F13 ratification required)**. This skill section documents the protocol only. Implementation requires the verification lane to be a new constitutional role, not a mode of A-FORGE.