reliant-labs/reliant/reliant-config

Reliant Configuration

Use this skill to configure any aspect of Reliant: memory/instructions, skills, MCP servers, presets, or config YAML.

Scope model

Reliant uses three configuration scopes, merged with higher priority winning:

This pattern repeats across all config types. Local always wins over project, which wins over global.

1. Memory system (reliant.md)

Memory files inject persistent instructions into every LLM call as "User defined rules, memories, and context."

Precedence: All three are merged (not overridden). Global loads first, then project, then local. All content is concatenated.

Add project instructions

# Create or edit project instructions (shared with team)
cat > reliant.md << 'EOF'
## Project Guidelines
- Use Go 1.22+ features
- All PRs require tests
- Follow existing naming conventions
EOF

Add personal local instructions

# Create or edit local instructions (gitignored, just for you)
cat > reliant.local.md << 'EOF'
## My Preferences
- I prefer verbose explanations
- Always run tests before committing
EOF

Add global instructions

# Applies to every project you open
cat > ~/.reliant/reliant.md << 'EOF'
## Global Guidelines
- Always use meaningful variable names
- Write tests for all new features
EOF

2. Skills system

Skills are loadable instruction bundles that agents can discover and use on demand.

Skill structure

<skills-root>/<skill-name>/
├── SKILL.md            # Required — frontmatter + instructions
├── references/         # Optional — deep docs, schemas, policies
├── scripts/            # Optional — deterministic routines
├── templates/          # Optional — reusable output artifacts
└── assets/             # Optional — images, data files

Naming rules: Skill name must match its parent directory. Lowercase, letters/digits/hyphens only.

Required SKILL.md frontmatter

---
name: my-skill
description: What it does and when to use it
---

Recommended frontmatter

---
name: my-skill
description: What it does and when to use it
compatibility: reliant
metadata:
  owner: my-team
  category: tooling
---

Discovery roots (priority order)

Skills are discovered from multiple roots. Higher-priority roots shadow lower ones with the same name.

Only scaffold to Reliant-managed paths (.reliant.local/skills/, .reliant/skills/, ~/.reliant/skills/). Do not create skills in .claude/, .codex/, or .agents/ directories.

Create a project skill

mkdir -p .reliant/skills/my-helper
cat > .reliant/skills/my-helper/SKILL.md << 'EOF'
---
name: my-helper
description: Helps with our custom deployment process
compatibility: reliant
metadata:
  owner: platform-team
  category: devops
---
# My Helper
 
## When to use
- When deploying to staging or production
 
## Steps
1. Run preflight checks
2. Build the artifact
3. Deploy via our CLI
EOF

Use a skill

skill load <name>       # Load a skill by name
skill search <query>    # Find skills by keyword
skill list              # List all available skills

Authoring a new skill

When the user wants to create a new skill or improve an existing one, follow this flow.

Core principles

1. Keep SKILL.md concise and high-signal — put essential workflow/instructions in SKILL.md. Move large details into supporting files (references/, scripts/, templates/, assets/).
2. Write trigger-ready descriptions — description should clearly state what the skill does and when to use it. Include likely user intents/phrases so activation is reliable.
3. Prefer deterministic helpers for repeated work — if the same transformation or command sequence repeats, scaffold a script.
4. Iterate using concrete tests — draft realistic prompts, run the skill, inspect outputs, then revise.

Step 1: Capture intent

Confirm:

• What task/workflow the skill should enable
• Typical user prompts that should trigger the skill
• Expected output format/quality bar
• Required tools, files, APIs, or constraints

Step 2: Choose scope and location

Ask whether this should live in:

• local (.reliant.local/skills/...)
• project (.reliant/skills/...)
• global (~/.reliant/skills/...)

Step 3: Design structure (progressive disclosure)

Start with SKILL.md (required). Optionally add:

• references/ for deep docs/policies/schemas
• scripts/ for deterministic routines
• templates/ or assets/ for reusable output artifacts

Step 4: Author SKILL.md

Required frontmatter: name, description. Recommended: compatibility: reliant, metadata (owner/category).

Body should include:

• When to use
• Inputs needed
• Step-by-step procedure
• Output expectations
• References to supporting files (with when/why to read)

Starter template:

---
name: <skill-name>
description: <what it does + when to use it>
compatibility: reliant
metadata:
  owner: <team-or-user>
---
# <Skill Title>
 
## When to use
-...
 
## Inputs
-...
 
## Steps
1....
2....
 
## Output expectations
-...
 
## References
-See `references/...` when ...

Step 5: Validate and test

1. Create 2–3 realistic prompts users would actually type.
2. Invoke the skill (skill load <skill-name>).
3. Compare output quality against expectations.
4. Refine description/body/supporting files.
5. Re-run prompts and confirm improvement.

Updating an existing skill

When asked to improve an existing skill:

1. Read current SKILL.md and supporting files.
2. Identify likely failure points: weak triggering description, ambiguous steps, missing edge-case guidance, bloated SKILL.md that should be split.
3. Propose targeted edits.
4. Re-test using realistic prompts.
5. Summarize what changed and why.

Quality checks before finishing

• Path is Reliant-managed and correct scope was used.
• Skill name is normalized, stable, and unambiguous.
• Description is specific about both capability and triggering context.
• Instructions are concise, imperative, and actionable.
• Supporting files are referenced only when useful.
• At least one invocation test was suggested (or run, if requested).

3. MCP server configuration

MCP (Model Context Protocol) servers extend agent capabilities with external tools.

Config file locations

Servers are merged across scopes. Higher-priority scopes override servers with the same name.

JSON format

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "@some/mcp-server"],
      "env": { "API_KEY": "..." },
      "type": "stdio",
      "enabled": true
    }
  }
}

Server types

Add an MCP server (stdio)

mkdir -p .reliant
cat > .reliant/mcp.json << 'EOF'
{
  "mcpServers": {
    "my-tool": {
      "command": "npx",
      "args": ["-y", "@company/mcp-tool"],
      "env": {
        "API_KEY": "sk-..."
      }
    }
  }
}
EOF

Add an MCP server (SSE/HTTP)

{
  "mcpServers": {
    "remote-tool": {
      "type": "sse",
      "url": "https://mcp.example.com/sse",
      "env": { "TOKEN": "..." }
    }
  }
}

Add a language server or anything else that indexes a code tree

A server whose answers come from an INDEXED TREE — a language server, a semantic code-search server — resolves which tree it serves once, when its process starts. Declare dirScoped so each project gets its own process:

{
  "mcpServers": {
    "gopls": {
      "command": "gopls",
      "args": ["mcp"],
      "dirScoped": true
    }
  }
}

Without it, every project shares ONE process, and the second project silently receives answers about the first project's code — confident matches from the wrong repository rather than no matches. Measured with a Go language server registered globally.

dirScoped is opt-in because sharing is correct and cheaper for the stateless majority: github, linear, sentry and friends are scoped by a token and an API endpoint, not by a directory, so per-project processes would buy nothing. Dir-scoped servers are started lazily and reaped when idle, so a project you are not working in costs nothing.

Say what a project must contain before the server is worth starting

A tree indexer pays its whole cost — the walk, the open files, the resident index — before it can discover it has nothing to do. Add requiresFiles so it is never started where it has nothing to index:

{
  "mcpServers": {
    "gopls": {
      "command": "gopls",
      "args": ["mcp"],
      "dirScoped": true,
      "requiresFiles": ["go.mod", "go.work"]
    }
  }
}

Without it, opening a Unity/C# project with zero .go files still started a Go language server, which indexed a 9.9 GB checkout and reached 28,467 open file descriptors and 1.9 GB resident. One per project, and seventeen projects exhaust macOS's system-wide file table — for every process on the machine.

• Entries are globs and ANY match satisfies the server, so a server covering

several ecosystems lists the marker of each (["*.csproj", "*.sln"]).

• A pattern with no / matches by base name at any depth, so go.mod also

covers a monorepo's services/api/go.mod. A pattern containing / is matched against the project-relative path (services/*/go.mod).

• Omit it and there is no precondition: the server starts for every project,

exactly as before.

• The check is a bounded, gitignore-aware scan, not a full walk. In a very large

tree the scan can hit its bound before reaching a deeply-buried marker, and the server is then not started; keep the marker near the root, or declare nothing.

Reliant also caps how many per-project processes all dir-scoped servers hold at once. Past the cap the least recently used one is reaped and respawns on its next tool call, so visiting many projects is fine — running an unbounded number of indexers at once is not.

Two ways to tell a server WHICH tree, depending on how it expects to be told:

{
  "mcpServers": {
    "reads-its-cwd":  { "command": "gopls", "args": ["mcp"], "dirScoped": true },
    "takes-a-flag":   { "command": "some-lsp-bridge",
                        "args": ["--workspace", "${projectPath}"],
                        "dirScoped": true },
    "pinned-to-one-tree": { "command": "gopls", "args": ["mcp"],
                            "dir": "$HOME/src/monorepo" }
  }
}