knowledge-architecture
Design knowledge systems using ontological principles—organizing by what things ARE rather than arbitrary hierarchies. Use when structuring personal knowledge bases, designing documentation systems, creating cross-domain linking patterns, building the {OS.me} ecosystem, or architecting information that reveals rather than obscures essential nature. Triggers on knowledge management, documentation architecture, information ontology, or systematic organization of complex domains.
Best use case
knowledge-architecture is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Design knowledge systems using ontological principles—organizing by what things ARE rather than arbitrary hierarchies. Use when structuring personal knowledge bases, designing documentation systems, creating cross-domain linking patterns, building the {OS.me} ecosystem, or architecting information that reveals rather than obscures essential nature. Triggers on knowledge management, documentation architecture, information ontology, or systematic organization of complex domains.
Teams using knowledge-architecture should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/knowledge-architecture/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How knowledge-architecture Compares
| Feature / Agent | knowledge-architecture | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Design knowledge systems using ontological principles—organizing by what things ARE rather than arbitrary hierarchies. Use when structuring personal knowledge bases, designing documentation systems, creating cross-domain linking patterns, building the {OS.me} ecosystem, or architecting information that reveals rather than obscures essential nature. Triggers on knowledge management, documentation architecture, information ontology, or systematic organization of complex domains.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Knowledge Architecture
Organize knowledge by being, not bureaucracy.
## Ontological Foundations
### The Problem with Arbitrary Categories
Most knowledge systems fail because they organize by:
- **Convention**: "This is how it's always been done"
- **Convenience**: "This was easiest at the time"
- **Accident**: "It just ended up here"
Result: Knowledge fragments. Connections hide. Understanding atrophies.
### Ontological Alternative
Organize by asking: **What is this thing, essentially?**
Not "where should this file go?" but "what is the nature of this entity, and what does it relate to by that nature?"
## Categories of Being
### Substances (Primary Entities)
Things that exist in themselves, not as properties of other things.
| Category | Examples | Identifying Question |
|----------|----------|---------------------|
| Persons | You, collaborators, mentors | Who acts? |
| Projects | in-midst-my-life, AI Council | What is being built? |
| Tools | Claude, Figma, modular synth | What enables action? |
| Works | Essays, code, art pieces | What has been created? |
| Concepts | Ideas, theories, frameworks | What is understood? |
### Properties (Dependent Entities)
Exist only as aspects of substances.
| Category | Examples | Identifying Question |
|----------|----------|---------------------|
| States | In-progress, complete, abandoned | What phase? |
| Qualities | Elegant, experimental, stable | What character? |
| Relations | Depends-on, extends, contradicts | How connected? |
| Measures | Size, duration, complexity | What quantity? |
### Events (Temporal Entities)
Things that happen, with beginning and end.
| Category | Examples | Identifying Question |
|----------|----------|---------------------|
| Actions | Decisions, commits, publications | What was done? |
| Processes | Learning, building, evolving | What unfolds? |
| Occasions | Meetings, deadlines, milestones | What marks time? |
## Structural Principles
### Essential vs. Accidental Properties
**Essential**: What makes the thing *that* thing. Remove it, and it's something else.
**Accidental**: Could be otherwise without changing identity.
Example: A "portfolio website"
- Essential: Displays work, represents identity
- Accidental: Uses React, hosted on Vercel, blue color scheme
**Organizing principle**: Group by essential properties. Tag/filter by accidental.
### Genus and Differentia
Classical definition structure: "A is a B that C"
```
Project
├── Software Project (produces code)
│ ├── Library (produces reusable code)
│ ├── Application (produces usable program)
│ └── Infrastructure (produces enabling system)
├── Creative Project (produces art/writing)
│ ├── Visual Work (produces images)
│ ├── Written Work (produces text)
│ └── Interactive Work (produces experience)
└── Research Project (produces knowledge)
├── Academic (produces citable work)
└── Applied (produces practical insight)
```
### Relations as First-Class Citizens
Don't bury relations in properties. Make them navigable.
| Relation Type | Meaning | Inverse |
|---------------|---------|---------|
| depends-on | Cannot exist without | enables |
| extends | Builds upon foundation | is-extended-by |
| contradicts | In tension with | is-contradicted-by |
| implements | Realizes abstraction | is-implemented-by |
| exemplifies | Is instance of pattern | is-exemplified-by |
| supersedes | Replaces previous | is-superseded-by |
## Architecture Patterns
### The Atomic Note
Each note captures ONE thing:
- One concept
- One decision
- One reference
- One connection
Connections emerge from linking atoms, not from cramming compounds into single containers.
### The Index Pattern
Create navigational hubs, not hierarchical folders.
```
# Project Index
## By Nature
- [[Software Projects]]
- [[Creative Projects]]
- [[Research Projects]]
## By State
- [[Active Work]]
- [[Completed Work]]
- [[Archived Work]]
## By Relation
- [[Dependencies Map]]
- [[Influence Graph]]
```
### The Context Layer
Same entity, different contexts:
```
/entities/project-alpha.md # The thing itself
/contexts/technical/project-alpha.md # Technical view
/contexts/business/project-alpha.md # Business view
/contexts/personal/project-alpha.md # Personal meaning
```
### The Temporal Layer
Knowledge changes. Track it:
```
/current/concept-x.md # Current understanding
/history/concept-x/ # Evolution
├── 2024-01-understanding.md
├── 2024-06-revision.md
└── changelog.md
```
## Naming Conventions
### Entity Naming
```
[type]-[identifier]
project-in-midst-my-life
concept-modular-synthesis
person-mentor-name
tool-claude-desktop
```
### Relation Naming
```
[source]--[relation]--[target]
project-alpha--depends-on--library-beta
concept-x--contradicts--concept-y
```
### State Naming
```
[entity].[state-type]
project-alpha.status = active
project-alpha.phase = development
project-alpha.health = stable
```
## Cross-Domain Integration
### The Translation Pattern
Same concept, different domain vocabularies:
```yaml
concept: feedback-loop
domains:
synthesis: "output patches to input, creating evolving timbre"
systems: "output affects input, creating dynamic behavior"
learning: "results inform practice, creating improvement"
biology: "effect influences cause, creating homeostasis"
```
### The Isomorphism Pattern
Find structural similarities across domains:
```
Modular Synthesis ←→ Software Architecture
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Oscillator ←→ Data Source
Filter ←→ Transformer
Patch Cable ←→ API Connection
Mixer ←→ Aggregator
CV ←→ Configuration
Audio Signal ←→ Data Payload
```
### The Emergence Pattern
Document what emerges from combination:
```
Component A + Component B = Emergent Property C
# Example
Note-taking + Linking + Time = Evolving understanding
(None of the parts alone produces this)
```
## Implementation
### File System Mapping
```
knowledge/
├── entities/ # Primary substances
│ ├── projects/
│ ├── concepts/
│ ├── works/
│ └── tools/
├── relations/ # Connection maps
│ ├── dependencies.md
│ ├── influences.md
│ └── contradictions.md
├── contexts/ # Perspective layers
│ ├── technical/
│ ├── personal/
│ └── temporal/
├── indices/ # Navigation hubs
│ ├── by-nature.md
│ ├── by-state.md
│ └── by-domain.md
└── meta/ # About the system itself
├── ontology.md
├── conventions.md
└── changelog.md
```
### Metadata Schema
```yaml
---
type: [entity-type]
nature: [essential description]
state: [current state]
created: [date]
modified: [date]
relations:
depends-on: [list]
extends: [list]
relates-to: [list]
contexts: [list of applicable contexts]
tags: [accidental properties for filtering]
---
```
## References
- `references/ontological-terms.md` - Philosophical vocabulary
- `references/implementation-patterns.md` - Concrete file/linking patternsRelated Skills
posse-distribution-architecture
Implement POSSE (Publish on Own Site, Syndicate Elsewhere) content distribution with canonical URLs, cross-platform syndication, backfeed collection, and resilient delivery. Covers multi-platform publishing automation and IndieWeb patterns. Triggers on POSSE implementation, content syndication architecture, or IndieWeb publishing requests.
knowledge-graph-builder
Designs and builds knowledge graphs to represent entities, relationships, and semantic connections, with query patterns for Neo4j, RDF, and property graphs.
taxonomy-modeling-design
Phase 2 of the pentaphase structural-overhaul protocol. Classifies entities, standardizes attributes, establishes relationships, and designs the access framework. Use when the user invokes phase 2 of an overhaul, asks to "design the taxonomy" or "model the structure", or has completed a landscape audit and is ready to redesign. Consumes phase-1-landscape-report.md; produces phase-2-taxonomy-model.md.
systemic-ingestion-normalization
Phase 4 of the pentaphase structural-overhaul protocol. Purges redundancies, enriches and aligns legacy entities to the new schema, executes phased ingestion into the new environment, and audits integrity. Use when the user invokes phase 4 of an overhaul, asks to "migrate the data" or "ingest into the new system", or has a configured environment ready to accept legacy entities. Consumes phase-3-environment-spec.md; produces phase-4-ingestion-report.md.
system-environment-configuration
Phase 3 of the pentaphase structural-overhaul protocol. Translates the taxonomy model into objective technical criteria, evaluates candidate mechanisms or frameworks, instantiates the chosen architecture, and programs validation rules. Use when the user invokes phase 3 of an overhaul, asks to "select a system" or "configure the environment", or has a taxonomy model and is ready to choose technology. Consumes phase-2-taxonomy-model.md; produces phase-3-environment-spec.md.
pentaphase-orchestrator
Threads the full five-phase structural-overhaul protocol — landscape discovery, taxonomy design, environment configuration, systemic ingestion, governance evolution — for any substrate the user names. Use when the user requests a structural overhaul, system redesign, or end-to-end restructuring of a documentation system, asset registry, code monorepo, knowledge base, or operational workflow; or when they explicitly invoke the pentaphase methodology. Coordinates handoffs between phase-skills and seats validation gates between phases.
landscape-discovery-audit
Phase 1 of the pentaphase structural-overhaul protocol. Inventories assets, maps current flow, identifies friction, and defines value metrics for any substrate. Use when the user invokes phase 1 of an overhaul, requests a baseline audit, asks to "discover the landscape" of a system, or wants to understand current state before redesigning. Produces phase-1-landscape-report.md.
governance-evolution-protocol
Phase 5 of the pentaphase structural-overhaul protocol. Codifies operational protocols, onboards the ecosystem of participants, programs behavior monitoring, and establishes an iteration cadence so the substrate evolves rather than calcifies. Use when the user invokes phase 5 of an overhaul, asks to "establish governance" or "lock in the protocols", or has completed ingestion and is ready to declare the substrate operational. Consumes phase-4-ingestion-report.md; produces phase-5-governance-charter.md, which closes the protocol.
dimension-surfacing
Surfaces the parallel domain dimensions implicit in a dense or minimal prompt. Use when a user prompt is small on the surface but plainly implies multiple independent domains needing different expertise; when explicitly invoked by the coliseum-orchestrator skill as Phase 1; or when the user asks "what dimensions does this prompt encode" or "what axes does this break into." Produces a named dimension set where each dimension is independently executable and not a paraphrase of another.
coliseum-dispatch
Dispatches a composed set of assignment envelopes to domain-expert subagents in parallel, in a single message with multiple Agent tool calls. Enforces the no-pingpong gate via the pingpong-detector agent before any dispatch fires. Use when invoked by the coliseum-orchestrator as Phase 3; when envelopes are already composed and the next step is parallel execution; or when the user asks to "fan out" or "dispatch in parallel." Produces a dispatch log capturing what was sent, when, and where returns land.
assignment-composition
Wraps each surfaced dimension as a self-contained 9-section autonomous-work-assignment envelope — scope, context, success criteria, allowed tools, return format, handoff — all the recipient subagent needs to execute without coming back. Use when invoked by coliseum-orchestrator as Phase 2; when dimensions are named and the next step is to make each independently dispatchable; or when the user asks "compose this as an assignment." The no-pingpong gate validates each envelope before dispatch.
workspace-autopsy-governance
Conducts a full automated autopsy of the current workspace directory to map files, identifies structural issues, proposes a restructuring plan (the signal), and establishes unified governance using templates. Use this skill when a user asks to map, restructure, reorganize, or apply new governance to an existing messy repository.