The HUB.yaml Format
Hubify uses two related YAML formats:
HUB.yaml — The workspace manifest. Every workspace has one at its root. It is the source of truth for the workspace: hub identity, connected agents, model routing, installed skills, vault config, and privacy settings.
.hub files — Individual skill manifests. Each published skill is a .hub YAML file with metadata and instructions.
This page documents both formats completely.
HUB.yaml — Workspace Manifest
Every Hubify workspace has a HUB.yaml at its root. Every connected agent reads it on startup. It is the single source of truth for workspace configuration.
Full Example
hub :
version : "2.0"
id : "hub_abc123"
name : "Houston's OS"
owner : "houston"
template : "myos"
created : "2026-02-19T00:00:00Z"
# Intelligence layer configuration
intelligence :
global : opt-in
org : null
# Connected agents (auto-updated by hubify connect)
agents :
- id : "agent_cloud"
platform : "hubify-cloud"
url : "https://houston.hubify.com"
role : "orchestrator"
active : true
- id : "agent_local"
platform : "openclaw-local"
host : "macbook-air"
role : "primary"
active : false
# Memory configuration (Convex-backed, real-time)
memory :
hub_id : "hub_abc123"
retention_days : 365
# Reserved context files (auto-loaded by all agents)
context :
reserved_files :
- AGENTS.md
- SOUL.md
- USER.md
- MEMORY.md
- HEARTBEAT.md
memory_dir : "./memory"
learnings_dir : "./learnings"
knowledge_dir : "./knowledge"
# Model routing
models :
default : "anthropic/claude-sonnet-4-6"
routing :
orchestrator : "anthropic/claude-sonnet-4-6"
builder : "openai/gpt-5.2-codex"
researcher : "kimi/k2.5"
automation : "google/gemini-flash"
reviewer : "anthropic/claude-haiku-4-5"
free_tier :
- "kimi/k2.5"
- "google/gemini-flash"
- "zhipu/glm-4"
byok :
anthropic : { key_ref : "vault://keys/anthropic" }
openai : { key_ref : "vault://keys/openai" }
openrouter : { key_ref : "vault://keys/openrouter" }
# Tool vault
vault :
id : "vault_abc123"
# Installed skills
skills :
registry : "hubify"
installed :
- { id : "strava" , version : "1.2.3" }
- { id : "github" , version : "2.0.1" }
- { id : "telegram-topics" , version : "1.0.0" }
# Privacy
privacy :
contribute_to_global : false
vault_shared_across_workspaces : true
# Workspace mode
mode : "guided"
HUB.yaml Field Reference
hub (required)
The hub identity block.
Field Type Required Description hub.versionstring Yes Manifest format version (current: "2.0") hub.idstring Yes Unique hub identifier, assigned by Hubify on init hub.namestring Yes Human-readable workspace name hub.ownerstring Yes Owner username hub.templatestring Yes Template slug used to create this workspace hub.createdstring Yes ISO 8601 creation timestamp
intelligence (optional)
Controls how the workspace participates in the intelligence network.
Field Type Default Description intelligence.globalstring "opt-out""opt-in" or "opt-out" for the Singularity layerintelligence.orgstring nullOrganization ID for shared intelligence, or null
agents (auto-managed)
List of connected agents. Updated automatically by hubify connect and the cloud provisioning system.
Field Type Description agents[].idstring Unique agent identifier agents[].platformstring Platform: hubify-cloud, openclaw-local, claude-code, cursor, etc. agents[].urlstring Agent URL (for cloud agents) agents[].hoststring Hostname (for local agents) agents[].rolestring Agent role: orchestrator, primary, researcher, builder, reviewer, automation agents[].activeboolean Whether the agent is currently online
memory (optional)
Field Type Default Description memory.hub_idstring Same as hub.id Hub ID for Convex memory store memory.retention_daysnumber 365How many days to retain episodic memory
context (optional)
Defines which files agents should auto-load on startup.
Field Type Default Description context.reserved_filesstring[] See below List of reserved filenames to auto-load context.memory_dirstring "./memory"Path to episodic memory directory context.learnings_dirstring "./learnings"Path to learnings directory context.knowledge_dirstring "./knowledge"Path to knowledge base directory
Default reserved files: AGENTS.md, SOUL.md, USER.md, MEMORY.md, HEARTBEAT.md
models (optional)
Model routing configuration. This is the single authority for which model each agent role should use.
Field Type Description models.defaultstring Default model for all agents models.routingobject Map of role -> model identifier models.free_tierstring[] Models available on the free tier (Hubify-provided keys) models.byokobject Bring-your-own-key configuration with vault references
vault (optional)
Field Type Description vault.idstring Vault identifier for encrypted credential store
skills (optional)
Field Type Description skills.registrystring Registry source (default: "hubify") skills.installedobject[] List of installed skills with id and version
privacy (optional)
Field Type Default Description privacy.contribute_to_globalboolean falseWhether to contribute anonymized learnings to the global layer privacy.vault_shared_across_workspacesboolean trueWhether all workspaces share the same vault
mode (optional)
Value Description "guided"Reserved structure on, template active, skills pre-installed (default) "power"Reserved structure on, user customizes freely "open"All reserved structure off, raw OpenClaw
Creating HUB.yaml
# Interactive creation
hubify init
# This generates HUB.yaml in the current directory with a new hub ID
.hub Files — Skill Manifests
Each skill in the registry is defined by a .hub YAML file. This is the file you create when building a skill and the file agents read when executing one.
File Location
my-skill/
my-skill.hub # The skill manifest
prompt.md # Optional: external prompt file (for long prompts)
examples/ # Optional: example files
Minimal Example
---
name : my-skill
version : 1.0.0
type : skill
category : coding
description : A brief description of what this skill does
author : your-username
license : MIT
human_editable : false
---
# My Skill
## Instructions
Your skill instructions here...
Complete Example
---
name : typescript-strict-mode
display_name : TypeScript Strict Mode
version : 1.2.0
type : skill
description : |
Enforce strict TypeScript configuration for improved type safety.
author : houstongolden
license : MIT
human_editable : false
category : coding
subcategory : configuration
complexity : intermediate
platforms :
- claude-code
- cursor
- windsurf
tags :
- typescript
- configuration
- type-safety
- tsconfig
use_cases :
- Configure tsconfig.json for strict mode
- Add strict type checking rules
- Enforce null checks
- Migrate existing projects to strict TypeScript
tool_calls :
- file_read
- file_write
dependencies :
requires : []
extends :
- typescript-base-config
integrates_with :
- eslint-typescript
- prettier-config
conflicts_with :
- typescript-loose-mode
evolution :
min_executions : 100
confidence_threshold : 0.85
manual_approval : false
canary_duration : 48
scope :
- prompt_refinement
- example_addition
- platform_compatibility
examples :
- title : "New Next.js Project"
prompt : "Set up strict TypeScript for my new Next.js app"
expected : "Configure tsconfig.json with all strict flags enabled"
- title : "Existing Project Migration"
prompt : "Migrate my existing project to strict TypeScript"
expected : "Provide incremental migration strategy"
- title : "Monorepo Setup"
prompt : "Configure strict TypeScript for a Turborepo monorepo"
expected : "Set up base tsconfig with strict mode, extend in packages"
---
# TypeScript Strict Mode
## When to Apply
Apply this skill when configuring TypeScript for any project that values type safety.
## Instructions
### 1. Enable Strict Mode
Add or update your `tsconfig.json` :
``` json
{
"compilerOptions" : {
"strict" : true ,
"noUncheckedIndexedAccess" : true ,
"exactOptionalPropertyTypes" : true ,
"noImplicitReturns" : true ,
"noFallthroughCasesInSwitch" : true ,
"noImplicitOverride" : true
}
}
2. Handle Existing Errors
For projects with many existing type errors:
Start with strict: false
Enable flags incrementally
Use // @ts-expect-error sparingly for legacy code
Add TypeScript ESLint for runtime checks:
npm install -D @typescript-eslint/parser @typescript-eslint/eslint-plugin
Common Pitfalls
Do not disable strictNullChecks to avoid fixing null errors
Do not use any as a workaround for strict typing
Do not skip the incremental migration for large existing projects
### .hub Field Reference
#### Core Fields (Required)
| Field | Type | Description |
|-------|------|-------------|
| `name` | string | Unique skill identifier. Lowercase, hyphens, 3-50 characters. |
| `version` | string | Semver version (e.g., `"1.0.0"`) |
| `type` | string | Always `"skill"` for skill files |
| `category` | string | One of: `coding`, `workflow`, `documentation`, `testing`, `security`, `devops`, `research` |
| `description` | string | Brief description (max 200 characters) |
| `human_editable` | boolean | Must be `false` for publishable skills |
Either `prompt` (inline in the YAML body after `---`) or `prompt_file` (path to external file) is required.
#### Metadata Fields (Optional)
| Field | Type | Description |
|-------|------|-------------|
| `display_name` | string | Human-readable display name |
| `author` | string | Author username |
| `license` | string | License identifier (MIT, Apache-2.0, etc.) |
| `homepage` | string | URL to documentation |
| `repository` | string | Source repository URL |
| `subcategory` | string | More specific category |
| `complexity` | string | `beginner`, `intermediate`, `advanced` |
#### Platform and Targeting (Optional)
| Field | Type | Description |
|-------|------|-------------|
| `platforms` | string[] | Supported platforms: `claude-code`, `cursor`, `windsurf`, `copilot`, `cody`, `custom` |
| `use_cases` | string[] | When to use this skill |
| `tags` | string[] | Searchable tags |
| `tool_calls` | string[] | Tools the skill uses: `file_read`, `file_write`, `terminal`, `browser`, etc. |
#### Dependencies (Optional)
| Field | Type | Description |
|-------|------|-------------|
| `dependencies.requires` | string[] | Skills that must be installed first |
| `dependencies.extends` | string[] | Skills this builds upon |
| `dependencies.integrates_with` | string[] | Compatible skills |
| `dependencies.conflicts_with` | string[] | Incompatible skills |
#### Evolution Settings (Optional)
| Field | Type | Description |
|-------|------|-------------|
| `evolution.min_executions` | number | Minimum executions before auto-evolution triggers |
| `evolution.confidence_threshold` | number | Minimum confidence score to trigger evolution |
| `evolution.manual_approval` | boolean | Whether the author must approve evolutions |
| `evolution.canary_duration` | number | Hours to run canary test before promoting |
| `evolution.scope` | string[] | Allowed evolution types: `prompt_refinement`, `example_addition`, `platform_compatibility` |
#### Examples (Optional)
| Field | Type | Description |
|-------|------|-------------|
| `examples` | object[] | Usage examples |
| `examples[].title` | string | Example title |
| `examples[].prompt` | string | What the user would ask |
| `examples[].expected` | string | What the agent should produce |
### Name Conventions
```yaml
# Valid
name: my-skill
name: typescript-strict-mode
name: api-error-handling-v2
# Invalid
name: My Skill # No spaces
name: mySkill # No camelCase
name: ab # Too short (min 3)
name: this-is-a-very-long-skill-name-that-exceeds-the-fifty-character-limit # Too long
Inline Prompt vs External File
For short skills, inline the prompt in the markdown body after the YAML frontmatter:
---
name : my-skill
version : 1.0.0
# ... metadata
---
# My Skill
Instructions here...
For long skills (500+ lines), use an external file:
---
name : my-skill
version : 1.0.0
prompt_file : ./prompt.md
# ... metadata
---
Reserved Structure
Every Hubify workspace uses a standard directory structure. These filenames and directories are reserved — no agent, user, or tool may repurpose them.
Reserved Filenames
File Purpose Auto-Created HUB.yamlWorkspace manifest Yes AGENTS.mdAgent instructions Yes SOUL.mdIdentity / persona Yes (from template) USER.mdUser profile Yes (from signup) MEMORY.mdLong-term curated memory Yes HEARTBEAT.mdProactive checklist Yes (from template) BOOTSTRAP.mdFirst-run setup (deleted after use) Yes, then deleted PROJECTS.mdProject index (auto-generated) Yes TASKS.mdTask index (read-only, rendered from Convex) Yes LEARNINGS.mdLearnings index (auto-updated) Yes KNOWLEDGE.mdKnowledge base index Yes
Reserved Directories
workspace/
.hub/ # Runtime state (gitignored, synced via Convex)
agents.json # Live agent registry
sync.log # Sync history
cache/ # Local intelligence cache
memory/ # Episodic memory (time-based)
YYYY-MM-DD.md # Daily logs
*-intel-*.md # Research/intel files
*-state.json # State tracking
skills/ # Installed skills
skill-name/
SKILL.md
knowledge/ # Curated knowledge base (evergreen)
topic-name.md
INDEX.md
learnings/ # Extracted learnings (structured, API-synced)
YYYY-MM-DD.md # Daily learnings log
INDEX.md
monthly.json # Structured monthly export
projects/ # User space (anything goes)
vault/ # Encrypted credential cache (gitignored)
.vault.enc
TASKS.md is read-only and auto-generated. It renders what is in the real task store (Convex). Agents write tasks to the API, not to this file. The file is regenerated on every sync.
CLI Commands
# Create HUB.yaml in current directory
hubify init
# Create a skill .hub file
hubify hub init --type skill
# Validate a .hub file
hubify hub validate ./my-skill.hub
# View parsed info
hubify hub info ./my-skill.hub
# Update content hashes for integrity verification
hubify hub update ./my-skill.hub
Next Steps
First Skill Create your first skill step-by-step
Publishing Publish to the registry
For Agents How agents read HUB.yaml and .hub files
CLI Reference All CLI commands