self-audit-tools

Name: self-audit-tools
Author: omnigentx

31stars13forks

How to install self-audit-tools?

omnigentx/jarvis/self-audit-tools

$npx -y skills add omnigentx/jarvis --skill self-audit-tools

Installs into the current project.

Summary

Protocol for an agent to audit its OWN visible toolset. Read when a task asks you to "audit your tools" / "list and verify your capabilities" / "self-audit". Defines what to call vs. what to only describe, the markdown exchange format, and what an aggregator (PM) actually can — a

Files · 1

View on GitHub

SKILL.md

1	# Self-Audit Tools Skill
2
3	When a task asks you to audit your own toolset, follow this protocol exactly.
4	This skill is the single source of truth for self-audit; the task brief
5	will not duplicate these rules, so read this in full before acting.
6
7	## Capability honesty — read this first
8
9	This skill is written around what each role can actually observe:
10
11	\| Role \| Can observe \| Cannot observe \|
12	\|---\|---\|---\|
13	\| Member (audit subject) \| Own tool catalog, own tool-call results, own message history \| Other members' tools, other members' message history \|
14	\| Aggregator (orchestrator / PM) \| Emails received, meeting transcripts, `agent_spawner__get_team_status` (high-level state per member) AND its own toolset \| Members' tool catalogs, members' tool-call counts, anything not explicitly emailed or said in a meeting \|
15	\| Requester (Jarvis / user) \| Whatever the aggregator delivers \| Same blind spots as the aggregator \|
16
17	That table is load-bearing. Rules below honour it — the aggregator never
18	"verifies counts" of another member because it cannot. The aggregator only
19	checks what is plainly present in the text it receives.
20
21	## Which role are you?
22
23	Answer this first, in your own head, before reading further:
24
25	- No team around you (solo spawn, no PM, no peers in roster). You are
26	a standalone member. Run Part A and email the report to the
27	requester named in your context (Jarvis / parent agent). Part B does
28	not apply.
29	- You are a team member (BA / SA / Dev / Designer / QE / DSO / etc.,
30	with a PM in your roster). Run Part A and email your report to the
31	PM. Do not run Part B — only the orchestrator aggregates.
32	- You are the orchestrator (PM, role tagged `orchestrator` in the
33	template, or first spawned by `spawn_team_tool`). Run both
34	parts: Part A for your own toolset (no email — you are the
35	recipient), then Part B to collect member emails and produce the
36	combined roll-up that interleaves your own audit with theirs.
37
38	Re-read the table above and the bullet list whenever you forget which
39	half of the skill applies to you.
40
41	## TL;DR (read first, act second)
42
43	As a member doing the audit:
44
45	1. Enumerate every tool you can see — not just the ones you happened to use.
46	2. Classify each: READ (safe to call) vs WRITE/DESTRUCTIVE (do NOT call).
47	3. For READ tools: call once with the safest minimal valid args. Record the
48	outcome verbatim.
49	4. For WRITE/DESTRUCTIVE tools: do NOT call. Record purpose + the call shape
50	you would use, based on the tool's schema.
51	5. Email the markdown report to the requester (usually PM). Use a meeting
52	only to point at the email — never paste the table into a transcript.
53	6. Even if early steps fail (turn errors, ACK errors, etc.) — keep going.
54	The audit deliverable is the inventory, not the meeting choreography.
55
56	As an orchestrator (PM) running an audit round:
57
58	7. Do Part A on your own toolset first. Keep your inventory table
59	in memory (or save it as a workspace draft) — you do NOT email
60	yourself, you do NOT speak it in a meeting. Your audit becomes the
61	first entry in the roll-up at Step 10.
62	8. Wait until `agent_spawner__get_team_status` shows all members done,
63	or a sane deadline. Collect the inbox.
64	9. For each report received, do only the checks plainly observable in
65	the text: structure present, summary internally reconciles, table
66	non-empty.
67	10. Concatenate your own audit and every member's report verbatim
68	under a single header. Name who replied and who did not. Do NOT
69	invent counts or thresholds across members.
70
71	## When to apply
72
73	- Brief contains "audit your tools" / "self-audit" / "list and verify tools".
74	- You are asked to characterise your own capabilities.
75	- This skill is only about your own tools. Do not audit other agents.
76
77	---
78
79	# Part A — Member protocol
80
81	## Step 1 — Enumerate your tools
82
83	You see every tool you can call (the tool catalog is given in your
84	system context). Do not guess from role title; enumerate. List every
85	tool with full canonical name (e.g. `filesystem__list_directory`,
86	`github__search_repositories`, `meeting_room__speak`).
87
88	Anti-pattern: reporting only the 2-3 tools you happened to use for
89	housekeeping (ACK, leave_meeting, get_meeting_status) and calling that an
90	audit. That is the meeting trace, not a tool audit.
91
92	## Step 2 — Classify each tool: READ vs WRITE/DESTRUCTIVE
93
94	Rule of thumb: does calling the tool change observable state anywhere
95	(filesystem, database, external API, queue, agent memory, other agent's
96	inbox)?
97
98	\| Class \| Definition \| Examples \|
99	\|---\|---\|---\|
100	\| READ \| Retur

People who liked this also viewed

6 picks

Type

self-audit-tools

31stars13forks

View on GitHub

How to install self-audit-tools?

omnigentx/jarvis/self-audit-tools

$npx -y skills add omnigentx/jarvis --skill self-audit-tools

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Self-Audit Tools Skill
2
3	When a task asks you to audit your own toolset, follow this protocol exactly.
4	This skill is the single source of truth for self-audit; the task brief
5	will not duplicate these rules, so read this in full before acting.
6
7	## Capability honesty — read this first
8
9	This skill is written around what each role can actually observe:
10
11	\| Role \| Can observe \| Cannot observe \|
12	\|---\|---\|---\|
13	\| Member (audit subject) \| Own tool catalog, own tool-call results, own message history \| Other members' tools, other members' message history \|
14	\| Aggregator (orchestrator / PM) \| Emails received, meeting transcripts, `agent_spawner__get_team_status` (high-level state per member) AND its own toolset \| Members' tool catalogs, members' tool-call counts, anything not explicitly emailed or said in a meeting \|
15	\| Requester (Jarvis / user) \| Whatever the aggregator delivers \| Same blind spots as the aggregator \|
16
17	That table is load-bearing. Rules below honour it — the aggregator never
18	"verifies counts" of another member because it cannot. The aggregator only
19	checks what is plainly present in the text it receives.
20
21	## Which role are you?
22
23	Answer this first, in your own head, before reading further:
24
25	- No team around you (solo spawn, no PM, no peers in roster). You are
26	a standalone member. Run Part A and email the report to the
27	requester named in your context (Jarvis / parent agent). Part B does
28	not apply.
29	- You are a team member (BA / SA / Dev / Designer / QE / DSO / etc.,
30	with a PM in your roster). Run Part A and email your report to the
31	PM. Do not run Part B — only the orchestrator aggregates.
32	- You are the orchestrator (PM, role tagged `orchestrator` in the
33	template, or first spawned by `spawn_team_tool`). Run both
34	parts: Part A for your own toolset (no email — you are the
35	recipient), then Part B to collect member emails and produce the
36	combined roll-up that interleaves your own audit with theirs.
37
38	Re-read the table above and the bullet list whenever you forget which
39	half of the skill applies to you.
40
41	## TL;DR (read first, act second)
42
43	As a member doing the audit:
44
45	1. Enumerate every tool you can see — not just the ones you happened to use.
46	2. Classify each: READ (safe to call) vs WRITE/DESTRUCTIVE (do NOT call).
47	3. For READ tools: call once with the safest minimal valid args. Record the
48	outcome verbatim.
49	4. For WRITE/DESTRUCTIVE tools: do NOT call. Record purpose + the call shape
50	you would use, based on the tool's schema.
51	5. Email the markdown report to the requester (usually PM). Use a meeting
52	only to point at the email — never paste the table into a transcript.
53	6. Even if early steps fail (turn errors, ACK errors, etc.) — keep going.
54	The audit deliverable is the inventory, not the meeting choreography.
55
56	As an orchestrator (PM) running an audit round:
57
58	7. Do Part A on your own toolset first. Keep your inventory table
59	in memory (or save it as a workspace draft) — you do NOT email
60	yourself, you do NOT speak it in a meeting. Your audit becomes the
61	first entry in the roll-up at Step 10.
62	8. Wait until `agent_spawner__get_team_status` shows all members done,
63	or a sane deadline. Collect the inbox.
64	9. For each report received, do only the checks plainly observable in
65	the text: structure present, summary internally reconciles, table
66	non-empty.
67	10. Concatenate your own audit and every member's report verbatim
68	under a single header. Name who replied and who did not. Do NOT
69	invent counts or thresholds across members.
70
71	## When to apply
72
73	- Brief contains "audit your tools" / "self-audit" / "list and verify tools".
74	- You are asked to characterise your own capabilities.
75	- This skill is only about your own tools. Do not audit other agents.
76
77	---
78
79	# Part A — Member protocol
80
81	## Step 1 — Enumerate your tools
82
83	You see every tool you can call (the tool catalog is given in your
84	system context). Do not guess from role title; enumerate. List every
85	tool with full canonical name (e.g. `filesystem__list_directory`,
86	`github__search_repositories`, `meeting_room__speak`).
87
88	Anti-pattern: reporting only the 2-3 tools you happened to use for
89	housekeeping (ACK, leave_meeting, get_meeting_status) and calling that an
90	audit. That is the meeting trace, not a tool audit.
91
92	## Step 2 — Classify each tool: READ vs WRITE/DESTRUCTIVE
93
94	Rule of thumb: does calling the tool change observable state anywhere
95	(filesystem, database, external API, queue, agent memory, other agent's
96	inbox)?
97
98	\| Class \| Definition \| Examples \|
99	\|---\|---\|---\|
100	\| READ \| Retur

People who liked this also viewed

6 picks

Type