跪拜 Guibai
← All articles
Cursor · AI Programming · Agent

When Agent Skills Overlap: Auditing Superpowers Against Codex Harness

By Wilson王艺谋 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Agent Skills are multiplying fast, and the default assumption that more Skills equals better engineering is breaking down. When a Skill suite silently overrides a project's branch strategy, CI gates, or source-of-truth documents, the cost is duplicated work, conflicting approvals, and governance drift that outlasts the plugin itself. The audit framework and prompts here give teams a repeatable way to cut overlap before it hardens into technical debt.

Summary

Running Superpowers alongside Codex Harness creates conflicts in how work gets planned, approved, and wrapped up, not in code execution. The overlap centers on five areas: a global Skill router that forces invocation even for simple tasks, fixed approval gates that pause every creative change regardless of risk, parallel document sources of truth that diverge from ADRs and issues, generic sub-agent and worktree orchestration that ignores project-specific branch and dependency rules, and one-size-fits-all verification that cannot substitute for lint, contract tests, or consumer canaries.

A four-layer model — Harness, Project Governance, Skill, Tool — makes the boundaries explicit. Skills that change execution order for all tasks, override existing authorization rules, or establish new long-term fact sources have crossed into Harness territory. The practical fix is a triage: keep narrow methods like systematic debugging and TDD, rewrite useful Skills whose triggers are too broad, and disable anything that duplicates Harness scheduling, approval, or branch lifecycle management.

AIHero and mattpocock/skills offer a lower-intrusion reference design: per-Skill installation, explicit vs. model-invoked distinction, and reviewable file-based Skills. Cross-Harness discovery requires placing shared Skills in `~/.agents/skills/` or the repo's `.agents/skills/`, since Cursor and Codex scan different directories. The article ships five ready-to-use audit prompts that inventory overlaps, rewrite broad Skills, decouple before plugin removal, troubleshoot discovery, and generate governance rules for AGENTS.md.

Takeaways
Superpowers and Codex conflict in workflow orchestration — global routing, approval gates, parallel docs, sub-agent scheduling, and generic verification — not in runtime code execution.
A Skill crosses into Harness territory when it changes execution order for all tasks, overrides existing authorization and delivery rules, or creates a new long-term source of truth.
Superpowers 6.3.0's `using-superpowers` forces Skill invocation whenever there is even a small probability of applicability, pushing simple tasks into full process overhead.
The `brainstorming` Skill imposes a fixed approval gate on all creative work, including small, clearly scoped changes that the Harness and user have already authorized.
Superpowers writes designs and plans into a dedicated directory; in repos with ADRs, roadmaps, and issue tracking, this produces duplicate architecture conclusions and diverging progress records.
Superpowers' worktree process auto-runs `npm install` on detecting `package.json`, ignoring repos that mandate a specific pnpm version or other tooling constraints.
A generic verification Skill cannot replace project-specific evidence requirements like lint, type checks, contract tests, security scans, consumer canaries, and artifact provenance.
Triage Skills into three categories: keep narrow methods (debugging, TDD, verification), rewrite useful Skills with overly broad triggers, and disable anything duplicating Harness orchestration.
AIHero and mattpocock/skills achieve lower intrusion through per-Skill installation, explicit vs. model-invoked distinction, and file-based Skills that users can review and delete.
Cursor scans `~/.cursor/skills/` and `~/.agents/skills/`; Codex scans only `~/.agents/skills/`. A Skill in the Cursor-only directory is invisible to Codex — a directory discovery asymmetry, not a content problem.
Shared Skills belong in `~/.agents/skills/` for personal cross-agent use or in the repo's `.agents/skills/` for teams, remote agents, and CI workers; never keep copies in both directories.
Before uninstalling a methodology plugin, audit for registered hooks, MCPs, scripts, REQUIRED Skill references in plans, and formal documents that still point to plugin-specific paths.
Five audit prompts are provided: Skill-Harness overlap inventory, broad-to-narrow Skill rewrite, plugin removal preflight, Cursor-Codex discovery troubleshooting, and AGENTS.md governance rule generation.
Conclusions

The instinct to install a comprehensive Skill suite as a quick fix for engineering discipline creates a governance debt that is harder to unwind than the original lack of process. The plugin's assumptions about branching, dependency installation, and approval gates become invisible defaults that outlive the plugin itself.

Skill intrusiveness is not about file size or count — it is about whether the Skill participates in global scheduling. A single Skill that requires invocation before every reply does more architectural damage than twenty narrowly triggered utility Skills.

The directory discovery asymmetry between Cursor and Codex (`~/.cursor/skills/` vs `~/.agents/skills/`) is a concrete interoperability gap that will produce silent failures as teams mix agents. The fix is trivial — one shared directory — but the failure mode is invisible until a Skill silently doesn't load.

Parallel document sources of truth are the hardest overlap to detect and the most expensive to fix. When architecture conclusions live in both ADRs and Skill design drafts, the repo accumulates two diverging narratives, and removing the plugin later leaves dangling references that break institutional memory.

The four-layer model (Harness → Project Governance → Skill → Tool) is a useful litmus test that generalizes beyond Superpowers and Codex: any Skill that reaches upward into Harness or sideways into Project Governance is a candidate for rewrite or removal.

Concepts & terms
Harness
The agent execution layer responsible for instruction priority, permissions, tool calling, planning state, sub-agent management, and sandbox isolation. In Codex, this is the built-in runtime that Skills and project rules operate within.
Project Governance layer
Repository-level rules encoded in AGENTS.md, architecture boundaries, issue tracking, branch strategies, CI pipelines, and acceptance contracts. This layer defines what 'done' means and how changes are authorized and delivered.
Skill intrusiveness
A measure of how much a Skill participates in global scheduling rather than providing a narrow task method. High-intrusion Skills change execution order for all tasks, override project authorization rules, or create parallel sources of truth. Low-intrusion Skills are explicitly invoked or narrowly matched and write only to user-specified artifacts.
Progressive loading
Codex's mechanism for managing Skill context budgets: at startup only Skill names, descriptions, and paths are loaded. The full SKILL.md is fetched only after a task matches, and when the directory is too large, descriptions are shortened or Skills omitted entirely.
Parallel sources of truth
A governance anti-pattern where architecture decisions, plans, and status exist simultaneously in both the project's official documents (ADRs, issues, roadmaps) and a Skill suite's dedicated directories, producing diverging narratives and dangling references when the plugin is removed.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗