Consider making it langauge agnostic?

[HuskyDanny]

I see a lot of concepts revolves around ts/js. Would it be a plan to make it agnostic or code language configurable across all components?

[pangerlkr]

I think this is a valuable direction. Right now configs and tooling are JS/TS-centric because that’s where many current scripts live. To make this truly language-agnostic, we could:

1. Define core agents, skills, hooks, and commands in a neutral format (e.g., JSON + Markdown metadata).
2. Build language adapters so different ecosystems (Python, Go, Rust, etc.) can load and interpret the same definitions.
3. Create examples showing how these configs work across languages.

Before coding, I’d suggest an RFC in this repo to formalize the schema and approach. I’m happy to contribute a draft and some prototypes if maintainers are open to it.

[prathamkhairmode15]

This sounds like a great evolution for the project. Moving away from a purely JS/TS-centric config would definitely help widen adoption.

I agree that an RFC is the best first step. We need to make sure the schema (JSON/Markdown) is flexible enough to capture the nuances of different languages without becoming too complex.

Please go ahead and open the RFC! I’d be very interested to see your draft and the prototype for the language adapters. Let us know if you need any specific context on the current internal hooks before you start.

[MawJPhysics]

I have weak coding background but I have done my best to feed it to another LLM to convert it to something for my C# projects

[pangerlkr]

RFC: Language-Agnostic Configuration Schema for Everything-Claude-Code

Thank you @prathamkhairmode15 for the encouragement. Here's a comprehensive RFC addressing the language-agnostic architecture proposal.

Executive Summary

This RFC proposes a neutral configuration schema (JSON + Markdown) that decouples the core Claude Code framework from JS/TS ecosystems, enabling seamless adaptation to Python, Go, Rust, C#, and other languages through language-specific adapters.

Problem Statement

Current State:

• Agents, skills, hooks, and commands are currently stored as individual Markdown files
• Hooks configuration uses JSON (hooks.json) with embedded shell commands
• Package management is JS-centric (.claude/package-manager.json)
• Deployment scripts are Node.js based

Challenges:

• No unified schema for cross-language compatibility
• C# developers (like @MawJPhysics) must manually convert configs using external LLMs
• Adding a new language requires reimplementing the entire framework
• Configuration discovery is implicit rather than explicit

Proposed Solution

1. Unified Core Schema (YAML + JSON)

Define a language-agnostic schema for all core components:

# agents.schema.yml
agent:
  name: string
  description: string
  role: string
  tools:
    - name: string
      executor: reference
      parameters: object
  hooks:
    - name: string
      trigger: enum[pre, post, error]
      executor: reference

# skills.schema.yml
skill:
  name: string
  description: string
  capabilities: string[]
  executor: reference
  language_specifics:
    python: object
    go: object
    rust: object

# hooks.schema.yml
hook:
  name: string
  type: enum[command, function, workflow]
  matcher: regex | glob
  actions: 
    - executor: reference
      command_template: string
      language_overrides:
        python: string
        go: string
        rust: string
        csharp: string

2. Language Adapter Architecture

Create language-specific adapters that conform to a standard interface:

adapters/
  ├── base/
  │   ├── executor.interface
  │   ├── schema_validator
  │   └── config_loader
  ├── nodejs/
  │   ├── executor.js
  │   ├── command_builder.js
  │   └── hook_runner.js
  ├── python/
  │   ├── executor.py
  │   ├── command_builder.py
  │   └── hook_runner.py
  ├── go/
  │   ├── executor.go
  │   └── ...
  ├── csharp/
  │   ├── executor.cs
  │   └── ...
  └── rust/
      ├── executor.rs
      └── ...

Adapter Interface:

interface LanguageAdapter {
  loadConfig(schemaPath): Config
  instantiateExecutor(spec): Executor
  resolveCommand(template, context): string
  executeHook(hook, context): Result
}

3. Directory Structure Redesign

everything-claude-code/
├── schemas/
│   ├── agents.schema.json
│   ├── skills.schema.json
│   ├── hooks.schema.json
│   ├── commands.schema.json
│   └── mcp-configs.schema.json
├── configs/
│   ├── agents/
│   │   └── *.config.json (or .yaml)
│   ├── skills/
│   │   └── *.config.json
│   ├── hooks/
│   │   └── hooks.json (universal format)
│   └── mcps/
│       └── *.config.json
├── implementations/  # Language-specific implementations
│   ├── nodejs/
│   ├── python/
│   ├── go/
│   ├── rust/
│   └── csharp/
├── adapters/  # Language adapter runtime
│   ├── base/
│   ├── nodejs-adapter/
│   ├── python-adapter/
│   ├── go-adapter/
│   ├── rust-adapter/
│   └── csharp-adapter/
├── documentation/  # Keep existing Markdown docs
│   ├── agents/
│   ├── skills/
│   └── hooks/
└── examples/  # Cross-language usage examples
    ├── nodejs-setup/
    ├── python-setup/
    ├── go-setup/
    ├── rust-setup/
    └── csharp-setup/

4. Configuration Format Example

Current (agents/architect.md):

• Mixed Markdown + metadata
• Human-readable but non-machine-parseable

Proposed (configs/agents/architect.config.json):

{
  "$schema": "schemas/agents.schema.json",
  "name": "architect",
  "description": "Software architecture specialist",
  "role": "senior software architect specializing in scalable, maintainable system design",
  "tools": [
    {
      "name": "read",
      "executor": "fs:read",
      "parameters": {"mode": "binary"}
    }
  ],
  "documentation": {
    "path": "documentation/agents/architect.md",
    "format": "markdown"
  }
}

5. Implementation Roadmap

Phase 1: Schema Definition (Weeks 1-2)

• Define JSON Schemas for agents, skills, hooks, commands, MCPs
• Create schema validation tooling
• Get community feedback

Phase 2: Core Adapter Framework (Weeks 3-4)

• Implement base adapter interface
• Create Node.js adapter (POC)
• Documentation and examples

Phase 3: Multi-Language Adapters (Weeks 5-8)

• Python adapter
• Go adapter
• Rust adapter
• C# adapter

Phase 4: Migration & Validation (Weeks 9-10)

• Migrate existing configs to new schema
• Comprehensive testing across languages
• Performance benchmarking

Phase 5: Release & Community Support (Week 11+)

• v2.0 release with language-agnostic support
• Migration guides
• Language-specific documentation

Migration Strategy

Backward Compatibility:

• Support existing Markdown configs during v1.x-2.0 transition
• Provide config converter tool (Markdown → JSON Schema)
• Clear deprecation timeline

Adoption Path:

1. New projects use JSON schema configs
2. Existing projects gradually migrate
3. By v2.1, Markdown configs fully deprecated

Security Considerations

1. Schema Validation: All configs validated against JSON Schema before loading
2. Executor Sandboxing: Language adapters implement execution contexts
3. Command Injection Prevention: Template variables properly escaped per language
4. Access Control: Schema defines capability boundaries per agent/skill

Benefits

Language Agnostic: Write once, run in any language
Developer Experience: Clearer semantics, better IDE support
Ecosystem Expansion: C#, Go, Rust communities can now contribute
Maintainability: Single source of truth for configurations
Validation: JSON Schema enables upfront config validation
Tooling: Enables config generators, linters, validators

Open Questions

1. Should we use JSON or YAML for configs? (Proposal: JSON for validation, YAML support via transpiler)
2. How do we handle language-specific nuances? (Proposal: language_specifics section in schema)
3. Should executors be versioned? (Proposal: Yes, executor_version field)
4. How do we handle context injection across languages? (Proposal: Standard context object interface)

Next Steps

1. Community Feedback (This week): Get input on schema design
2. Prototype: Build Node.js adapter as POC
3. Iterate: Refine based on findings
4. Implement: Begin Phase 1 of roadmap

References

• Current Implementation: /hooks/hooks.json, /agents/*.md, /skills/ directory
• Related Discussion: Broader language support request from @HuskyDanny
• Stakeholders: @prathamkhairmode15, @MawJPhysics (C# use case), Community

---

I'm ready to start implementation on Phase 1 immediately. Would appreciate feedback on:

• Schema structure and field naming
• Adapter interface design
• Directory reorganization approach
• Timeline feasibility

Looking forward to your thoughts!