Project Composition: Hub-and-Spoke with Inherited Knowledge Files and System Prompts

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Problem Statement
Claude Projects today are flat and isolated. Each project has its own knowledge files and system prompt with no mechanism for one project to reference, inherit from, or stay synchronized with another.
For users managing complex, multi-domain work — where a shared set of architectural principles, conventions, and reference documents governs multiple independent workstreams — this means:

Manual duplication: The same canonical documents must be uploaded to every project separately.
Drift: When the canonical document evolves, every project copy becomes stale. There is no propagation mechanism.
No composition: A "base project" cannot share its system prompt fragments or knowledge files with child projects that extend it with domain-specific context.

This is the equivalent of having a flat filesystem with no directories and no symlinks — every file must be self-contained, and shared conventions must be copy-pasted everywhere.

Proposed Solution

Allow projects to be loosely coupled in a hub-and-spoke model:

1. Project Linking (Hub → Spoke)

A project can declare one or more "parent" projects. Knowledge files and system prompt fragments from the parent are inherited — visible to conversations in the child project without duplication.

1. Autonomous Spokes

Child projects add their own domain-specific knowledge files and system prompt extensions on top of the inherited base. They are fully autonomous — they function independently even if the parent is deleted (graceful degradation, not hard dependency).

1. Propagation on Edit

When a knowledge file in the hub is updated, all linked spokes see the updated version automatically. No manual re-upload. This is the "symlink" model — one source of truth, multiple consumers.

1. Recursive Composition (Optional/Future)

A spoke can itself become a hub for its own sub-projects, enabling recursive hierarchies for complex organizations.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Feature Category does not have this as a category, "Projects / Knowledge Management / Workspace Organization"

Use Case Example
I am a Database Systems Instructor at Queens College CUNY with 40 years of industry experience, managing a multi-domain architecture that spans infrastructure, curriculum development, AI prompt engineering, and a home cluster lab environment.
The Architecture
I maintain a canonical architecture specification (architecture-spec.md) that defines:

A universal system.md prompt format deployed across Fabric, Claude Code, Codex, and Gemini CLI
A hierarchical skills taxonomy with Fully Qualified Skill Names (FQSN)
A composition model (behavioral contracts vs. delivery adapters)
Core principles (SRP, KISS, D⁴ Domain-Driven Database Design)

This specification governs ALL of my work — but the work itself spans completely independent domains.
Step-by-Step Scenario
Step 1 — Create the Hub Project: "Universal system.md Architecture"

Upload: architecture-spec.md (canonical reference)
Upload: deploy-skills.sh (deployment conventions)
System prompt: "You are the Driver in a Navigator + Driver pair programming model. All work follows SRP, KISS (Keep It Simple and Standard), and D⁴ principles. Consult architecture-spec.md before proposing structural changes."

Step 2 — Create Spoke: "Infrastructure" (linked to Hub)

Inherits: architecture-spec.md and the base system prompt from Hub
Adds: cluster-inventory.md (node specs: FreedomTower, TheBeast, MiniBeast)
Adds: network-config.md (Tailscale VPN, storage architecture)
Domain-specific prompt extension: "Infrastructure conversations concern Docker Swarm, VHDX storage, and multi-GPU compute nodes."
Fully autonomous: Conversations about Docker networking don't need to re-explain FQSN or SRP — they inherit that context.

Step 3 — Create Spoke: "Curriculum" (linked to Hub)

Inherits: architecture-spec.md and the base system prompt from Hub
Adds: csci-331-syllabus.md, csci-381-syllabus.md
Adds: academic-integrity-policy.md
Domain-specific prompt extension: "Curriculum conversations concern CSCI 331 (Database Systems) and CSCI 381 (Data Modeling, Power BI) at Queens College CUNY."
Fully autonomous: Conversations about lab exercises inherit the D⁴ methodology without restating it.

Step 4 — Create Spoke: "Skills Development" (linked to Hub)

Inherits: architecture-spec.md and the base system prompt from Hub
Adds: skills-authoring-guide.md
Domain-specific prompt extension: "Skills Development conversations author new system.md behavioral contracts following the FQSN taxonomy."
Fully autonomous: New skill authoring inherits the composition model, deploy conventions, and FQSN naming without preamble.

Step 5 — Hub Evolution (the key moment)
I discover that a new CLI tool (e.g., OpenAI Codex v2) needs to be added to the four-tool resolution map. I update architecture-spec.md in the Hub project.

Today (without this feature): I must manually re-upload the updated file to Infrastructure, Curriculum, and Skills Development projects. If I forget one, that project drifts.
With this feature: All three spokes immediately see the updated spec. Zero manual propagation. One source of truth.

Why This Matters
This is the same architectural pattern I've already implemented for AI prompt deployment:

A canonical skills-registry/ (the hub) contains hierarchical behavioral contracts
Tool-specific directories (the spokes) mirror or symlink to the registry
A deploy-skills.sh script handles propagation automatically
Each tool is fully autonomous at runtime but loosely coupled to the canonical source

Claude Projects should support the same pattern natively. The workaround today — manually duplicating files across projects — is the "copy mode fallback" in my deployment script. It works, but it doesn't scale, and it guarantees drift. The "symlink mode" equivalent for Projects would eliminate an entire class of maintenance overhead.

The Recursive Extension

Each spoke can itself become a hub. My "Infrastructure" spoke could spawn sub-projects for "Storage Architecture" and "Network Configuration" that inherit Infrastructure's context (which itself inherits the base architecture). This mirrors how my skills taxonomy works: skills-registry/CodingArchitecture/BackupAutomation/ — each level is autonomous but inherits the conventions of its parent.
This recursive hub-and-spoke model turns Claude Projects from flat, isolated workspaces into a composable knowledge architecture — which is exactly what complex, multi-domain professional work requires.

Additional Context

_No response_