Files
claude-task-master/.changeset
Joe Danziger 95c299df64 Unify and streamline profile system architecture (#853)
* move claude rules and commands to assets/claude

* update claude profile to copy assets/claude to .claude

* fix formatting

* feat(profiles): Implement unified profile system

- Convert Claude and Codex profiles to use createProfile() factory
- Remove simple vs complex profile distinction in rule transformer
- Unify convertAllRulesToProfileRules() to handle all profiles consistently
- Fix mcpConfigPath construction in base-profile.js for null mcpConfigName
- Update terminology from 'simpleProfiles' to 'assetOnlyProfiles' throughout
- Ensure Claude .claude directory copying works in both CLI and MCP contexts
- All profiles now follow same execution flow with proper lifecycle functions

Changes:
- src/profiles/claude.js: Convert to createProfile() factory pattern
- src/profiles/codex.js: Convert to createProfile() factory pattern
- src/utils/rule-transformer.js: Unified profile handling logic
- src/utils/profiles.js: Remove simple profile categorization
- src/profiles/base-profile.js: Fix mcpConfigPath construction
- scripts/modules/commands.js: Update variable naming
- tests/: Update all tests for unified system and terminology

Fixes Claude profile asset copying issue in MCP context.
All tests passing (617 passed, 11 skipped).

* re-checkin claude files

* fix formatting

* chore: clean up test Claude rules files

* chore: add changeset for unified profile system

* add claude files back

* add changeset

* restore proper gitignore

* remove claude agents file from root

* remove incorrect doc

* simplify profiles and update tests

* update changeset

* update changeset

* remove profile specific code

* streamline profiles with defaults and update tests

* update changeset

* add newline at end of gitignore

* restore changes

* streamline profiles with defaults; update tests and add vscode test

* update rule profile tests

* update wording for clearer profile management

* refactor and clarify terminology

* use original projectRoot var name

* revert param desc

* use updated claude assets from neno

* add "YOUR_" before api key here

* streamline codex profile

* add gemini profile

* update gemini profile

* update tests

* relocate function

* update rules interactive setup Gemini desc

* remove duplicative code

* add comma
2025-07-09 13:22:11 +02:00
..
2025-03-29 09:29:50 +01:00
2025-03-28 20:38:53 +01:00

Changesets

This folder has been automatically generated by @changesets/cli, a build tool that works with multi-package repos or single-package repos to help version and publish code. Full documentation is available in the Changesets repository.

What are Changesets?

Changesets are a way to track changes to packages in your repository. Each changeset:

  • Describes the changes you've made
  • Specifies the type of version bump needed (patch, minor, or major)
  • Connects these changes with release notes
  • Automates the versioning and publishing process

How to Use Changesets in Task Master

2. Making Changes

  1. Create a new branch for your changes
  2. Make your code changes
  3. Write tests and ensure all tests pass

3. Creating a Changeset

After making changes, create a changeset by running:

npx changeset

This will:

  • Walk you through a CLI to describe your changes
  • Ask you to select impact level (patch, minor, major)
  • Create a markdown file in the .changeset directory

4. Impact Level Guidelines

When choosing the impact level for your changes:

  • Patch: Bug fixes and minor changes that don't affect how users interact with the system
    • Example: Fixing a typo in output text, optimizing code without changing behavior
  • Minor: New features or enhancements that don't break existing functionality
    • Example: Adding a new flag to an existing command, adding new task metadata fields
  • Major: Breaking changes that require users to update their usage
    • Example: Renaming a command, changing the format of the tasks.json file

5. Writing Good Changeset Descriptions

Your changeset description should:

  • Be written for end-users, not developers
  • Clearly explain what changed and why
  • Include any migration steps or backward compatibility notes
  • Reference related issues or pull requests with #issue-number

Examples:

# Good

Added new `--research` flag to the `expand` command that uses Perplexity AI
to provide research-backed task expansions. Requires PERPLEXITY_API_KEY
environment variable.

# Not Good

Fixed stuff and added new flag

6. Committing Your Changes

Commit both your code changes and the generated changeset file:

git add .
git commit -m "Add feature X with changeset"
git push

7. Pull Request Process

  1. Open a pull request
  2. Ensure CI passes
  3. Await code review
  4. Once approved and merged, your changeset will be used during the next release

Release Process (for Maintainers)

When it's time to make a release:

  1. Ensure all desired changesets are merged
  2. Run npx changeset version to update package versions and changelog
  3. Review and commit the changes
  4. Run npm publish to publish to npm

This can be automated through Github Actions

Common Issues and Solutions

  • Merge Conflicts in Changeset Files: Resolve just like any other merge conflict
  • Multiple Changes in One PR: Create multiple changesets if changes affect different areas
  • Accidentally Committed Without Changeset: Create the changeset after the fact and commit it separately

Additional Resources