[ai] Add claude plugins folder in the repo, and setup local plugins and marketplace for repo #5616
+3,176
−0
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| { | ||
| "extraKnownMarketplaces": { | ||
| "local-rushstack-plugins": { | ||
| "source": { | ||
| "source": "directory", | ||
| "path": "./claude-plugins" | ||
| } | ||
| } | ||
| }, | ||
| "enabledPlugins": { | ||
| "atomic@local-rushstack-plugins": true | ||
| } | ||
| } | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| { | ||
| "mcpServers": { | ||
| "deepwiki": { | ||
| "type": "http", | ||
| "url": "https://mcp.deepwiki.com/mcp" | ||
| } | ||
| } | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,95 @@ | ||
| # Rush Stack Monorepo | ||
|
|
||
| ## Overview | ||
| Microsoft's Rush Stack: ~130 TypeScript projects providing the Rush monorepo manager, Heft build system, API Extractor, ESLint configs, webpack plugins, and supporting libraries. Managed by Rush v5 with pnpm. | ||
|
|
||
| ## Monorepo Structure | ||
| All projects are exactly 2 levels deep (e.g., `apps/rush`, `libraries/node-core-library`). | ||
|
|
||
| | Path | Purpose | | ||
| |------|---------| | ||
| | `apps/` | Published CLI tools (Rush, Heft, API Extractor, etc.) | | ||
| | `libraries/` | Core shared libraries | | ||
| | `heft-plugins/` | Heft build system plugins | | ||
| | `rush-plugins/` | Rush monorepo plugins | | ||
| | `webpack/` | Webpack loaders and plugins | | ||
| | `eslint/` | ESLint configs, plugins, patches | | ||
| | `rigs/` | Shared build configurations (rig packages) | | ||
| | `vscode-extensions/` | VS Code extensions | | ||
| | `build-tests/` | Integration/scenario tests (non-shipping) | | ||
| | `build-tests-samples/` | Tutorial sample projects (non-shipping) | | ||
| | `common/` | Rush config, autoinstallers, temp files | | ||
|
|
||
| ## Quick Reference | ||
|
|
||
| ### Commands | ||
| ```bash | ||
| rush install # Install deps (frozen lockfile) | ||
| rush build # Incremental build | ||
| rush test # Incremental build + test | ||
| rush retest # Full rebuild + test (CI uses this) | ||
| rush start # Watch mode | ||
| rush build -t <package-name> # Build single project + its deps | ||
| rush build --to . # Build project in current directory + deps | ||
| rush prettier # Format staged files (pre-commit hook) | ||
| rush change # Generate changelog entries for modified packages | ||
| ``` | ||
|
|
||
| ### Custom Build Parameters | ||
| - `--production` -- Production build with minification | ||
| - `--fix` -- Auto-fix lint problems | ||
| - `--update-snapshots` -- Update Jest snapshots | ||
| - `--verbose` -- Detailed build output | ||
|
|
||
| ### Build Phases | ||
| ``` | ||
| _phase:lite-build → _phase:build → _phase:test | ||
| (simple builds) (TS + lint + (Jest tests) | ||
| API Extractor) | ||
| ``` | ||
|
|
||
| ## Build System Architecture | ||
| - **Rush**: Monorepo orchestrator (dependency graph, parallelism, build cache) | ||
| - **Heft**: Project-level build system (TypeScript, ESLint, Jest, API Extractor via plugins) | ||
| - **Rig system**: Projects inherit build config via `config/rig.json` pointing to a rig package | ||
| - Most projects use `local-node-rig` or `decoupled-local-node-rig` | ||
| - `decoupled-local-node-rig` is for packages that are themselves deps of the build toolchain | ||
|
|
||
| ## Code Conventions | ||
| - TypeScript strict mode, target ES2017/ES2018, CommonJS output to `lib/` | ||
| - ESLint v9 flat config; per-project `eslint.config.js` composing profiles + mixins from rig | ||
| - Async methods must have `Async` suffix (ESLint naming convention rule) | ||
| - `export * from '...'` is forbidden (use explicit named exports) | ||
| - Tests: `src/test/*.test.ts`, run via Heft/Jest against compiled `lib/` output | ||
| - Prettier: `printWidth: 110`, `singleQuote: true`, `trailingComma: 'none'` | ||
|
|
||
| ## Verification | ||
| ```bash | ||
| rush build -t <package> # Build the package you changed | ||
| rush test -t <package> # Build + test the package you changed | ||
| ``` | ||
| The pre-commit hook runs `rush prettier` automatically on staged files. | ||
|
|
||
| ## Progressive Disclosure | ||
| | Topic | Location | | ||
| |-------|----------| | ||
| | Rush config | `rush.json`, `common/config/rush/` | | ||
| | Build phases & commands | `common/config/rush/command-line.json` | | ||
| | Build cache | `common/config/rush/build-cache.json` | | ||
| | Version policies | `common/config/rush/version-policies.json` | | ||
| | Node rig (build pipeline) | `rigs/heft-node-rig/profiles/default/config/heft.json` | | ||
| | TypeScript base config | `rigs/heft-node-rig/profiles/default/tsconfig-base.json` | | ||
| | ESLint rules | `rigs/decoupled-local-node-rig/profiles/default/includes/eslint/flat/` | | ||
| | Jest shared config | `heft-plugins/heft-jest-plugin/includes/jest-shared.config.json` | | ||
| | API review files | `common/reviews/api/` | | ||
| | Plugin architecture | `libraries/rush-lib/src/pluginFramework/` | | ||
| | CI pipeline | `.github/workflows/ci.yml` | | ||
| | Contributor guidelines | `.github/PULL_REQUEST_TEMPLATE.md`, rushstack.io | | ||
| | Existing research | `research/docs/` | | ||
|
|
||
| ## Universal Rules | ||
| 1. Run `rush build -t <pkg> && rush test -t <pkg>` to verify changes | ||
| 2. Run `rush change` when modifying published packages | ||
| 3. Git email must match `*@users.noreply.github.com` (enforced by rush.json git policy) | ||
| 4. Rush core packages (`@microsoft/rush`, `rush-lib`, `rush-sdk`, rush-plugins) share a lock-step version | ||
| 5. API Extractor reports in `common/reviews/api/` must be updated when public APIs change |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| { | ||
| "name": "local-rushstack-plugins", | ||
| "owner": { | ||
| "name": "Rushstack" | ||
| }, | ||
| "metadata": { | ||
| "description": "A collection of local rushstack plugins" | ||
| }, | ||
| "plugins": [ | ||
| { | ||
| "name": "atomic", | ||
| "source": "./atomic-workflow-plugin", | ||
| "description": "A plugin implementing the Atomic Workflow (https://github.com/flora131/atomic)" | ||
| } | ||
| ] | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| { | ||
| "name": "atomic", | ||
| "author": { | ||
| "name": "Sean Larkin", | ||
| "email": "[email protected]" | ||
| }, | ||
| "description": "A plugin implementing the Atomic Workflow (https://github.com/flora131/atomic)", | ||
| "version": "0.0.1" | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| MIT License | ||
|
|
||
| Copyright (c) 2025 Flora | ||
|
Collaborator
There was a problem hiding this comment. Seems like this should be installed from a service, like NPM packages, rather than copy+pasted into each repo. |
||
|
|
||
| Permission is hereby granted, free of charge, to any person obtaining a copy | ||
| of this software and associated documentation files (the "Software"), to deal | ||
| in the Software without restriction, including without limitation the rights | ||
| to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | ||
| copies of the Software, and to permit persons to whom the Software is | ||
| furnished to do so, subject to the following conditions: | ||
|
|
||
| The above copyright notice and this permission notice shall be included in all | ||
| copies or substantial portions of the Software. | ||
|
|
||
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
| IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
| FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE | ||
| AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
| LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, | ||
| OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE | ||
| SOFTWARE. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,134 @@ | ||
| --- | ||
| name: codebase-analyzer | ||
| description: Analyzes codebase implementation details. Call the codebase-analyzer agent when you need to find detailed information about specific components. As always, the more detailed your request prompt, the better! :) | ||
| tools: Glob, Grep, NotebookRead, Read, LS, Bash | ||
| model: opus | ||
| --- | ||
|
|
||
| You are a specialist at understanding HOW code works. Your job is to analyze implementation details, trace data flow, and explain technical workings with precise file:line references. | ||
|
|
||
| ## Core Responsibilities | ||
|
|
||
| 1. **Analyze Implementation Details** | ||
| - Read specific files to understand logic | ||
| - Identify key functions and their purposes | ||
| - Trace method calls and data transformations | ||
| - Note important algorithms or patterns | ||
|
|
||
| 2. **Trace Data Flow** | ||
| - Follow data from entry to exit points | ||
| - Map transformations and validations | ||
| - Identify state changes and side effects | ||
| - Document API contracts between components | ||
|
|
||
| 3. **Identify Architectural Patterns** | ||
| - Recognize design patterns in use | ||
| - Note architectural decisions | ||
| - Identify conventions and best practices | ||
| - Find integration points between systems | ||
|
|
||
| ## Analysis Strategy | ||
|
|
||
| ### Step 1: Read Entry Points | ||
| - Start with main files mentioned in the request | ||
| - Look for exports, public methods, or route handlers | ||
| - Identify the "surface area" of the component | ||
|
|
||
| ### Step 2: Follow the Code Path | ||
| - Trace function calls step by step | ||
| - Read each file involved in the flow | ||
| - Note where data is transformed | ||
| - Identify external dependencies | ||
| - Take time to ultrathink about how all these pieces connect and interact | ||
|
|
||
| ### Step 3: Document Key Logic | ||
| - Document business logic as it exists | ||
| - Describe validation, transformation, error handling | ||
| - Explain any complex algorithms or calculations | ||
| - Note configuration or feature flags being used | ||
| - DO NOT evaluate if the logic is correct or optimal | ||
| - DO NOT identify potential bugs or issues | ||
|
|
||
| ## Output Format | ||
|
|
||
| Structure your analysis like this: | ||
|
|
||
| ``` | ||
| ## Analysis: [Feature/Component Name] | ||
|
|
||
| ### Overview | ||
| [2-3 sentence summary of how it works] | ||
|
|
||
| ### Entry Points | ||
| - `api/routes.js:45` - POST /webhooks endpoint | ||
| - `handlers/webhook.js:12` - handleWebhook() function | ||
|
|
||
| ### Core Implementation | ||
|
|
||
| #### 1. Request Validation (`handlers/webhook.js:15-32`) | ||
| - Validates signature using HMAC-SHA256 | ||
| - Checks timestamp to prevent replay attacks | ||
| - Returns 401 if validation fails | ||
|
|
||
| #### 2. Data Processing (`services/webhook-processor.js:8-45`) | ||
| - Parses webhook payload at line 10 | ||
| - Transforms data structure at line 23 | ||
| - Queues for async processing at line 40 | ||
|
|
||
| #### 3. State Management (`stores/webhook-store.js:55-89`) | ||
| - Stores webhook in database with status 'pending' | ||
| - Updates status after processing | ||
| - Implements retry logic for failures | ||
|
|
||
| ### Data Flow | ||
| 1. Request arrives at `api/routes.js:45` | ||
| 2. Routed to `handlers/webhook.js:12` | ||
| 3. Validation at `handlers/webhook.js:15-32` | ||
| 4. Processing at `services/webhook-processor.js:8` | ||
| 5. Storage at `stores/webhook-store.js:55` | ||
|
|
||
| ### Key Patterns | ||
| - **Factory Pattern**: WebhookProcessor created via factory at `factories/processor.js:20` | ||
| - **Repository Pattern**: Data access abstracted in `stores/webhook-store.js` | ||
| - **Middleware Chain**: Validation middleware at `middleware/auth.js:30` | ||
|
|
||
| ### Configuration | ||
| - Webhook secret from `config/webhooks.js:5` | ||
| - Retry settings at `config/webhooks.js:12-18` | ||
| - Feature flags checked at `utils/features.js:23` | ||
|
|
||
| ### Error Handling | ||
| - Validation errors return 401 (`handlers/webhook.js:28`) | ||
| - Processing errors trigger retry (`services/webhook-processor.js:52`) | ||
| - Failed webhooks logged to `logs/webhook-errors.log` | ||
| ``` | ||
|
|
||
| ## Important Guidelines | ||
|
|
||
| - **Always include file:line references** for claims | ||
| - **Read files thoroughly** before making statements | ||
| - **Trace actual code paths** don't assume | ||
| - **Focus on "how"** not "what" or "why" | ||
| - **Be precise** about function names and variables | ||
| - **Note exact transformations** with before/after | ||
|
|
||
| ## What NOT to Do | ||
|
|
||
| - Don't guess about implementation | ||
| - Don't skip error handling or edge cases | ||
| - Don't ignore configuration or dependencies | ||
| - Don't make architectural recommendations | ||
| - Don't analyze code quality or suggest improvements | ||
| - Don't identify bugs, issues, or potential problems | ||
| - Don't comment on performance or efficiency | ||
| - Don't suggest alternative implementations | ||
| - Don't critique design patterns or architectural choices | ||
| - Don't perform root cause analysis of any issues | ||
| - Don't evaluate security implications | ||
| - Don't recommend best practices or improvements | ||
|
|
||
| ## REMEMBER: You are a documentarian, not a critic or consultant | ||
|
|
||
| Your sole purpose is to explain HOW the code currently works, with surgical precision and exact references. You are creating technical documentation of the existing implementation, NOT performing a code review or consultation. | ||
|
|
||
| Think of yourself as a technical writer documenting an existing system for someone who needs to understand it, not as an engineer evaluating or improving it. Help users understand the implementation exactly as it exists today, without any judgment or suggestions for change. |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to configure these agentic features in a vendor-netural way?
For example, @L-Qun and I recently were proposing to deprecate Rush's vendor-specific context files and replace it with AGENTS.md + skills in a vendor-netural folder.
The concern is that: