Principal Agent Audit#

Use this skill to review a main AI assistant, coordinator bot, or "chief" agent that has access to user context, tools, memory, and other agents.

Default frame: the reviewed agent is the trusted principal agent. Improvements should make it more reliable, private, auditable, useful, and safe as a coordinator.

Boundaries#

• Read local memory, daily notes, learnings, skill files, and relevant workspace context.
• Do not use network access unless the user explicitly asks for external lookup.
• Do not publish skills, install packages, alter schedulers, change authentication, or edit critical config unless explicitly requested.
• Do not auto-modify personality, memory policy, routing policy, delegation rules, or coordination behavior. Propose changes first.
• Prefer reversible edits and written rationale.
• Treat private user data as sensitive. Summarize patterns; do not quote secrets or full private logs.

Review Inputs#

Inspect only what is relevant:

• Durable memory files: operating preferences, identity, durable user instructions.
• Daily notes: recent raw events, decisions, and repeated themes.
• Learning/error logs: recurring failures, corrections, known tool issues, missing capabilities.
• Tool notes: local assumptions, integration gotchas, device or host specifics.
• Installed skills: overlap, risk, permissions posture, maintenance state, and suitability for a principal agent.
• Agent/team structure: whether delegation boundaries and handoff rules are clear.

Workflow#

1. Establish the review question: general health, a specific failure, a proposed skill, a new capability, or multi-agent coordination.
2. Gather the smallest useful local context.
3. Classify findings:
   • Reliability: repeated failures, brittle commands, missing validation.
   • Privacy/security: excess permissions, external calls, token exposure risk.
   • Coordination: unclear agent roles, missing delegation rules, handoff gaps.
   • Memory hygiene: stale, missing, duplicated, or over-specific memories.
   • Tooling: missing binaries, broken assumptions, unsafe defaults.
   • User fit: whether the agent's behavior matches the user's durable preferences.
4. Decide whether action is needed:
   • No action: say so.
   • Documentation update: edit memory or local notes when the preference is durable.
   • Skill update: propose or make scoped edits if requested.
   • External action: ask first.
5. Report as a short operator briefing: verdict, evidence, risk, recommendation, and next action.

Proactive Reliability Patterns#

Use these patterns selectively. They are guardrails for a trusted principal agent, not permission to self-modify.

Write-Ahead Logging#

Before responding, preserve details that would be expensive to lose:

• User corrections.
• Durable preferences or operating rules.
• Decisions, names, IDs, URLs, dates, or published artifacts.
• Trial windows, scheduled reports, or future obligations.

Prefer raw daily notes for event capture and curated long-term memory only for distilled rules.

Working Buffer And Recovery#

When context is near compaction or a session resumes after truncation:

• Record the current task, key decisions, file paths, IDs, and next action before continuing.
• Recover from local memory and workspace artifacts before asking the user to restate context.
• Summarize private context instead of copying full logs.

Verify Implementation, Not Intent#

Before reporting completion:

• Verify the mechanism, not just the wording.
• For skill edits: read the updated SKILL.md, validate frontmatter, and confirm metadata still matches behavior.
• For scheduler edits: inspect the actual job, trigger time, delivery target, and job ID.
• For publication: inspect registry metadata after publishing when possible.

Autonomous Vs Prompted Scheduled Work#

When evaluating scheduled work:

• Use autonomous isolated jobs when the work must execute without main-session attention.
• Use main-session prompts only when live context or user interaction is required.
• Record expected output and how success will be verified.

Proactivity Gate#

Recommend proactive action only when it is local, reversible, low risk, and likely useful. External actions, public actions, broad deletes, publishing, authentication changes, and behavior-policy changes require explicit user approval.

Skill Evaluation Rule#

When evaluating a skill for the principal agent, ask:

• Does it improve reliability, privacy, judgment, coordination, or recoverability?
• Does it introduce broad shell access, network dependency, hidden state, self-modification, or unclear external effects?
• Can it operate in read-only or proposal-first mode?
• Is its output auditable and reversible?
• Does it duplicate simpler existing memory, learning, or review workflows?

Classify the skill:

• Use now: low risk, clear benefit, good fit for the principal agent.
• Adapt locally: useful idea, but needs pruning, sandboxing, or stricter boundaries.
• Avoid: risk exceeds benefit for a trusted coordinator.

Output Style#

• Be concise and direct.
• Lead with the verdict.
• Separate "use now", "adapt locally", and "avoid" when evaluating skills.
• Prefer conservative changes that make coordination clearer and safer.
• If changes were made, list exact files touched.

Decision Rule#

A capability belongs in a principal agent only if it helps the agent become more reliable, private, auditable, and useful as a coordinator. Capabilities that add autonomy, network dependency, hidden state, broad shell access, or self-modification require exceptional justification and explicit approval.