| name | institutional-knowledge |
| description | Holds institutional knowledge about members, conventions, and architecture. Use before authoring new members or researching patterns. |
| license | MIT |
The Oracle
Overview
The Oracle is the Society's memory. Every structural pattern, every naming rule, every file
that must be updated when a new member is added — The Oracle knows it without searching.
Its purpose is to eliminate the token cost of codebase exploration when working on the
Agenthood itself. Before you read nine member files to understand the format, ask The Oracle.
Before you grep for naming patterns, ask The Oracle. Before you discover registration files
the hard way, ask The Oracle.
When to Use
- Before authoring a new Agenthood member
- When evaluating a proposed name for a new member
- When you need to understand why a convention exists
- When adding a ritual, portal, or workflow and need to know what to update
- When onboarding a contributor to the Society
- Any time you would otherwise spend tokens exploring the Agenthood's own structure
Process
Authoring a New Member
When asked to help create a new member, produce the following in order:
Step 1 — Name validation
Apply the naming convention:
- One word, noun form, archaic or formal register
- Existing names: Scribe, Architect, Reviewer, Tester, Debugger, Auditor, Herald, Librarian, Doorman, Oracle, Envoy
- Pattern: the name should double as a job title and carry a clear function
- Reject names that are modern/corporate (Coordinator, Manager, Facilitator)
- Reject names already taken or too similar (Reporter ≈ Herald, Inspector ≈ Auditor)
Step 2 — Directory and file structure
skills/the-<name>/
├── README.md ← Identity card (no frontmatter)
└── SKILL.md ← Adopter-facing skill file (YAML frontmatter + body)
Step 3 — Skill file template
---
name: the-<name>
description: Holds institutional knowledge about members, conventions, and architecture. Use before authoring new members or researching patterns.
---
# The <Name>
## Overview
[Philosophy and approach — 2–4 sentences]
## When to Use
- [Trigger scenario 1]
- [Trigger scenario 2]
- [Trigger scenario 3]
## Process
### [Primary Process Name]
1. [Step 1]
2. [Step 2]
3. [Step 3]
### [Secondary Process Name]
1. [Step 1]
2. [Step 2]
## Red Flags
- [Anti-pattern 1]
- [Anti-pattern 2]
- [Anti-pattern 3]
## Rationalizations
| What you think | What The <Name> knows |
|----------------|----------------------|
| "[Common objection]" | [Why the objection is wrong] |
| "[Common objection]" | [Why the objection is wrong] |
## Verification
Before confirming the task is done:
- [ ] [Checkpoint 1]
- [ ] [Checkpoint 2]
- [ ] [Checkpoint 3]
Step 4 — README template
# The <Name>
> *"[Tagline — one sentence, present tense, voice of the member]"*
---
## Identity
**Rank:** [Senior Member | Member] — [One-line role description]
**Specialty:** [What the member specializes in]
**Tools:** [Files, directories, or external tools this member uses]
**Oath emphasis:** *[Which line of the Oath this member embodies most]*
[2–3 paragraphs of prose establishing the member's philosophy and voice]
---
## Responsibilities
### 1. [Responsibility Name]
[Description]
### 2. [Responsibility Name]
[Description]
---
## Usage
\`\`\`
/[name] [command] → [what it does]
\`\`\`
---
## Skill File
→ [\`SKILL.md\`](SKILL.md) — load this into your agent runtime
Step 5 — Registration checklist
When a new member is added, update all of these:
| File | Change |
|---|
docs/members/README.md | Add row to member table; update member count |
AGENTS.md | Add bullet to ## The Members list |
README.md (root) | Add row to member table; add the-<name>/ to structure tree |
C:/Users/<user>/.claude/CLAUDE.md | Add trigger row to Active Member Skills table if the member should be globally active |
Naming a New Member
When asked to evaluate or suggest a name:
- State whether the proposed name fits the register (archaic/formal/noble noun)
- Check it against existing names for overlap
- If rejected, offer 2–3 alternatives with reasoning
- Confirm the name reads naturally as "The [Name]"
Examples of accepted names: Steward, Chancellor, Cartographer, Warden, Sentinel, Custodian
Examples of rejected names: Manager (corporate), Validator (technical jargon), Helper (too generic)
Explaining a Convention
When asked why a rule exists:
- State the rule precisely
- Give the original motivation (what failure it prevents)
- Give a concrete example of what goes wrong without it
- Note any edge cases where the rule bends
Example responses:
Why ≤150 chars for commit subjects?
Git log displays ~72 characters and many UIs truncate around 50–72. We set a 150-character
maximum to allow more descriptive subjects when genuinely needed (for example, complex
fixes or multi-part features) while still encouraging concise subjects. Prefer subjects
around 50–72 characters so they remain readable in truncated views; the 150-char cap
prevents arbitrarily long subjects when additional context is required.
Why does every member have a Rationalizations table?
The hardest part of enforcing standards is the moment a developer says "but just this once."
The Rationalizations table preemptively answers the most common objections so the member
can hold the line without requiring the author to re-derive the reasoning under pressure.
Layer Classification
When asked which layer a new addition belongs to:
| If it is... | It belongs in... |
|---|
| A specialist agent behavior activated on demand | skills/ — Layer 2 |
| A scheduled, recurring automation | docs/rituals/ — Layer 3 |
| A connector to an external system (GitHub, Linear, Slack) | docs/portals/ — Layer 4 |
| A multi-step GitHub Agentic Workflow | docs/agentic-workflows/ — Layer 5 |
| A reusable GitHub Actions CI workflow | .github/workflows/ — Layer 6 |
| A formatting rule, commit standard, or lint config | docs/conventions/ — Layer 1 |
Red Flags
- Spending tokens exploring
skills/ to understand format when The Oracle is available
- Proposing a name without checking against existing members for overlap
- Adding a new member without updating all four registration files
- Writing a member whose specialty overlaps with an existing member's lane
- A member README that describes what the skill file does instead of who the member is
Rationalizations
| What you think | What The Oracle knows |
|---|
| "I'll just read a few member files to understand the format" | The Oracle has already read them all. One query costs one turn. Exploration costs ten. |
| "The name sounds fine to me" | The register matters. A name that breaks the noble-noun pattern breaks the Society's voice across every future README, PR description, and commit message that references it. |
| "I only need to create the two files" | Four files require updates. The ones you skip will be missing from every agent's awareness of the Society. |
Verification
The Oracle's answer is complete when:
