Feature Request: Support Sub-directory .qoder Inheritance in Multi-module Projects

Feature Requests
1

Feature Request: Support Sub-directory .qoder Inheritance in Multi-module Projects

Background

In embedded development, it is common to organize projects as a monorepo or multi-module structure, where:

  • The outer project (eb-fdk-for-linux) is a platform-specific application built on top of a shared SDK.
  • The inner SDK (eb-fdk) is maintained as a Git submodule from a company/team repository.
eb-fdk-for-linux/            ← Developer opens this as workspace root in Qoder
├── .qoder/                  ← Outer project's Qoder config
│   ├── agents/
│   ├── repowiki/
│   └── skills/
├── eb-fdk/                  ← Git submodule: company-maintained SDK
│   ├── .qoder/              ← SDK's own Qoder config (skills, wiki, agents for FDK)
│   │   ├── agents/
│   │   ├── repowiki/
│   │   └── skills/
│   ├── eb_core/
│   ├── eb_utils/
│   └── ...
├── eb-fdk-platform-linux/
├── main.c
└── CMakeLists.txt

The eb-fdk SDK has its own .qoder configuration including:

  • Skills: reusable prompts and commands specific to the FDK codebase
  • RepoWiki: architecture documentation, API references, porting guides for the SDK
  • Agents: specialized sub-agents for FDK-related tasks

Currently, when the developer opens eb-fdk-for-linux as the workspace root, Qoder only recognizes the root-level .qoder and completely ignores the eb-fdk/.qoder configuration.

Problem

1. Skills are not inherited from sub-directory .qoder

When opening the outer project, skills defined in eb-fdk/.qoder/skills/ are not available. Developers who primarily work with the FDK must either:

  • Duplicate all FDK skills into the root .qoder/skills/ (leads to maintenance burden and drift)
  • Use a symlink workaround (ln -s eb-fdk/.qoder .qoder) which is fragile and platform-dependent (especially problematic on Windows)
  • Always open eb-fdk/ separately as the workspace, losing context of the outer project

2. RepoWiki cannot be scoped to a sub-module

The RepoWiki feature currently only shows documentation for the workspace root. There is no way to:

  • Browse the FDK’s own RepoWiki while working in the outer project
  • Switch between the outer project’s wiki and the FDK’s wiki
  • Keep SDK documentation co-located with the SDK source (which is the natural place for it)

3. No synchronization path for SDK-level Qoder config

Since eb-fdk is a shared Git submodule distributed to all team members, any Qoder configuration maintained inside eb-fdk/.qoder would naturally sync to all developers via git. However, because Qoder ignores this directory when it’s not the workspace root, there is no effective way to distribute SDK-level Qoder configurations to the team.

Feature Request

Request 1: Recursive .qoder Discovery and Inheritance

Qoder should scan the workspace for all .qoder directories within sub-directories and merge/inherit their configurations alongside the root .qoder.

Suggested behavior:

  • Skills from all discovered .qoder/skills/ directories are available in the current workspace
  • Skills can optionally be namespaced or tagged by their source directory (e.g., [eb-fdk] prefix) to avoid naming conflicts
  • A configuration option in root .qoder to opt-in or opt-out of sub-directory inheritance
# Possible config in root .qoder/config.yaml (example)
inherit_subdirectory_qoder: true
subdirectory_scan_depth: 3

Request 2: Multi-source RepoWiki Support

Allow RepoWiki to aggregate and display documentation from multiple .qoder/repowiki/ directories.

Suggested behavior:

  • A wiki source selector in the RepoWiki UI to switch between:
    • Root project wiki (eb-fdk-for-linux)
    • Sub-module wikis (e.g., eb-fdk)
  • Or a unified view that merges all wikis with clear source labels
  • Breadcrumb or tab navigation to distinguish wiki sources

Request 3: Sub-directory Agents Aggregation

Similar to Skills, sub-agents defined in eb-fdk/.qoder/agents/ should be accessible when working in the outer project.

Use Case Summary

Scenario Current Behavior Expected Behavior
Open outer project, use FDK skill :cross_mark: Skill not found :white_check_mark: FDK skills available
Browse FDK API docs via RepoWiki :cross_mark: Only outer wiki visible :white_check_mark: Can select FDK wiki
Team syncs FDK submodule :cross_mark: Qoder config not distributed :white_check_mark: FDK .qoder synced via git
Use FDK sub-agent from outer project :cross_mark: Agent not available :white_check_mark: FDK agents accessible

Workaround Attempted

We attempted to use a symlink at the workspace root:

ln -s eb-fdk/.qoder .qoder

This works on Linux but:

  • Requires manual setup by each developer
  • Does not work reliably on Windows without administrator privileges or Developer Mode enabled
  • Git does not handle symlinks consistently across platforms

This is not a scalable solution for a team environment.

Environment

  • OS: Linux Ubuntu 24.04 (primary), Windows (some team members)
  • Project type: Embedded C SDK (eb-fdk) + Platform application (eb-fdk-for-linux)
  • Version control: Git with submodules
  • Qoder: latest version

Priority / Impact

This feature would significantly benefit teams that:

  1. Maintain shared SDKs or libraries as Git submodules
  2. Want to co-locate Qoder configuration with the code it describes
  3. Need to distribute AI development tooling consistently across the team via version control

We believe this is a common pattern in professional embedded and platform engineering, and supporting it would make Qoder much more powerful for team-based SDK development workflows.