[FEATURE] Swap Claude.md per task to perform better and more fine tuned context engineering.

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

Currently Claude Code support a single claude.md file. But it has restrictions as it fills context quickly and has to be kept as small as possible. Many times, due to lack of information about the project the model has to "dig" information. How some architecture is done, how some setting is configured in the local computer, some specific path, etc. This consumes lots of tokens and time. For some tasks it would be convenient to have a more tailored or fine-tuned claude.md tailored to the specific task. Currently the only solution is to close claude code and swap the claude.md tailored to your goal. This is time consuming and far from convenient 'hack'.

Proposed Solution

It is a very simple modification to claude code to just add selectable claude.md tailored to your goal that you could select on the interface. Example claude-refactoring.md claude-testexecution.md claude-architecture-design.md, claude-run-e2etests-java-php.md, claude-database-engineering.md. In this way perform context engineering specific and finetuned to be more effective for the task. Other options could be a per task Skills, and also MCP configuration per task, the whole pack. The idea could be improved over time with more features. But just swapping the claude.md is quick and easy to add but very useful start. Just some brainstorming options.

Alternative Solutions

Swapping claude.md and mcp configuration by hand or using script (closing and reopening claude code). Very time consuming by hand, slow and error prone. Another option is to keep a superlight claude.md and include in context specific document for your task, but then why have claude.md in the first place? Also it does not includes MCP configuration that could be very effective for some tasks but only pollutes the context for others. The idea is to eventually have a full context engineered for your task (would start with number 1) instead of per project.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

• If I want to refactor database I would put claude.md with information about database architecture, how to start database server, credentials, etc. Keeping a small but effective context.

• If I want to perform some refactoring I would put claude.md with application architecture and constrains. Where are code analyzers and parameters to use. Again small and effective for the task.

• If I want to create tests, I tell it where the tests folder is, constrains about tests. For instance, to use dependency injection with fake clock, fake filesystem or registry to increase testability. What kind of test coverage analysis tool I am using and execution parameters. Sometimes claude have created fake clock twice in the same codebase just because it did not found in exploration the one already implemented. Later had to coalesce. Would have being solve if it had those specifications in context and would have saved exploration.

Additional Context

_No response_