Feature request: User-defined chat-level Skill/Plugin/Rules Profiles

[glebfox]

What variant of Codex are you using?

App

What feature would you like to see?

Summary

Codex should support user-defined skill/plugin/rules profiles that can be selected per chat, similar to how users select a model or other session settings.

A profile would represent the intended mode of work, for example:

• Features
• Small Fixes
• Code Review
• Docs Writing
• CI Debugging

Each profile would define which skills, plugins and rules are available in that chat, and how they are allowed to activate.

Motivation

Today, skills are either available or unavailable globally/session-wide. This makes it difficult to use powerful workflow skills without them becoming intrusive in smaller tasks.

For example, a large-feature workflow may benefit from planning, brainstorming, TDD, verification, and parallel-agent skills. But the same skills can add too much ceremony for a tiny bug fix or a quick conceptual question.

Conversely, some domain-specific skills are useful only on demand. Users may want them installed and discoverable, but not automatically invoked unless explicitly requested.

This creates friction: users have to keep changing settings, editing instructions, or uninstalling/reinstalling skills depending on the type of work they are doing.

Proposed behavior

Add first-class, user-defined profiles for skills and plugins.

Each profile should allow configuring skills/plugins with activation modes such as:

• off: unavailable in this profile
• manual: available only when explicitly requested by the user
• auto: may activate automatically when relevant
• required: must run for specific lifecycle moments, such as verification before completion

Example:

name: Features
description: Large feature development
skills:
  superpowers:brainstorming: auto
  superpowers:writing-plans: auto
  superpowers:test-driven-development: auto
  superpowers:verification-before-completion: required
plugins:
  GitHub: auto
  Browser: auto

name: Small Fixes
description: Compact code changes and low-ceremony fixes
skills:
  karpathy-guidelines: auto
  superpowers:brainstorming: manual
  superpowers:test-driven-development: manual
  superpowers:writing-plans: off
  superpowers:verification-before-completion: required
plugins:
  GitHub: manual
  Browser: manual
rules:
  When tests are added after the implementation, verify they are not false positives

UX

Profiles should be selectable at the chat/session level, next to model and other chat settings.

Users should be able to:

• create custom profiles
• choose a profile for the current chat
• set a default profile
• override a project default when needed
• see the effective skill/plugin policy for the active chat
• temporarily invoke a manual skill by name

Sharing

Profiles should be shareable in two ways:

1. Simple file/folder sharing, similar to copying skills into the appropriate local directory.
2. Marketplace-style distribution, similar to plugins, where users can install community or vendor-provided workflow profiles.

Marketplace profiles would be useful as workflow recipes, not just individual tools. For example:

• "Large Feature Workflow"
• "Minimal Patch Workflow"
• "Frontend QA Workflow"

Why this matters

The key distinction is between a tool being installed and a tool being appropriate for the current task.

Skill/plugin profiles would let users keep powerful skills available without forcing them into every conversation. This would make Codex more adaptable across different work styles: deep feature development, small fixes, reviews, documentation, debugging, and domain-specific development.

Relationship to existing profile/agent ideas

This is related to role/agent presets and skill scoping (#17545), but the requested UX is specifically chat-level and purpose-based.

The goal is not only to start Codex as a different agent, but to let users choose the intended working mode for the current chat.

Additional information

No response

[etraut-openai]

This isn't quite what you're asking for, but there's a capability already implemented that might address some or all of your needs. You have the ability to mark a skill as "not available for implicit invocation". This keeps its description out of the context unless you explicitly invoke it. For more details, refer to this documentation.