baram2584/Agentic-AI-Template
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

modify template

Browse Source
This commit is contained in:
김경종
2026-06-10 17:12:23 +09:00
parent 2d59191df2
commit df3cc3e890
186 changed files with 24935 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/cache/local-personal/claude-md-management/1.0.0/.codex-plugin/plugin.json
Vendored
+44
View File
@@ -0,0 +1,44 @@
{
"name": "claude-md-management",
"version": "1.0.0",
"description": "Audit and improve Claude/Codex project instruction files such as CLAUDE.md and AGENTS.md.",
"author": {
"name": "Anthropic",
"email": "support@anthropic.com",
"url": "https://github.com/anthropics"
},
"homepage": "https://github.com/anthropics/claude-plugins-official/tree/main/plugins/claude-md-management",
"repository": "https://github.com/anthropics/claude-plugins-official/tree/main/plugins/claude-md-management",
"license": "Apache-2.0",
"keywords": [
"claude-md",
"agents-md",
"project-instructions",
"memory",
"maintenance"
],
"skills": "./skills/",
"interface": {
"displayName": "CLAUDE.md Management",
"shortDescription": "Audit and revise project instruction files",
"longDescription": "A Codex-compatible port of Anthropic's CLAUDE.md Management plugin. It helps audit and improve CLAUDE.md and AGENTS.md files, then capture useful session learnings as concise project instructions.",
"developerName": "Anthropic",
"category": "Productivity",
"capabilities": [
"Read",
"Write"
],
"websiteURL": "https://github.com/anthropics/claude-plugins-official/tree/main/plugins/claude-md-management",
"privacyPolicyURL": "https://www.anthropic.com/legal/privacy",
"termsOfServiceURL": "https://www.anthropic.com/legal/consumer-terms",
"defaultPrompt": [
"Audit my AGENTS.md and CLAUDE.md files",
"Revise project instructions from this session"
],
"brandColor": "#D97706",
"screenshots": [
"./assets/claude-md-improver-example.png",
"./assets/revise-claude-md-example.png"
]
}
}
plugins/cache/local-personal/claude-md-management/1.0.0/LICENSE
Vendored
+202
View File
@@ -0,0 +1,202 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
plugins/cache/local-personal/claude-md-management/1.0.0/README.md
Vendored
+31
View File
@@ -0,0 +1,31 @@
# CLAUDE.md Management for Codex
Codex-compatible port of Anthropic's CLAUDE.md Management plugin.
This plugin helps maintain project instruction files:
- `AGENTS.md` for Codex project instructions
- `CLAUDE.md` for Claude Code project context
- `.agents.local.md` and `.claude.local.md` for local-only notes when a project uses them
## Skills
| Skill | Purpose |
| --- | --- |
| `claude-md-improver` | Audit instruction files against the current codebase, report quality gaps, and propose targeted updates. |
| `revise-claude-md` | Capture durable session learnings into the right instruction file after user approval. |
## Example Prompts
```text
Use claude-md-management to audit my AGENTS.md and CLAUDE.md files.
```
```text
Use revise-claude-md to capture useful learnings from this session.
```
## Source
Adapted from Anthropic's official Claude plugin:
https://github.com/anthropics/claude-plugins-official/tree/main/plugins/claude-md-management
plugins/cache/local-personal/claude-md-management/1.0.0/assets/claude-md-improver-example.png
Vendored
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 507 KiB

plugins/cache/local-personal/claude-md-management/1.0.0/assets/revise-claude-md-example.png
Vendored
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 542 KiB

plugins/cache/local-personal/claude-md-management/1.0.0/skills/claude-md-improver/SKILL.md
Vendored
+151
View File
@@ -0,0 +1,151 @@
---
name: claude-md-improver
description: Audit and improve project instruction files such as AGENTS.md, CLAUDE.md, .agents.local.md, and .claude.local.md. Use when the user asks to check, audit, update, improve, or fix project memory or instruction files.
---
# Project Instruction Improver
Audit, evaluate, and improve project instruction files so future Codex or Claude sessions have concise, current, actionable project context.
This skill can write to instruction files only after presenting a quality report and getting user approval.
## Workflow
### Phase 1: Discovery
Find project instruction files in the repository. Prefer `rg --files`; on Windows, use PowerShell-native commands if needed.
```powershell
rg --files | rg '(^|/)(AGENTS\.md|CLAUDE\.md|\.agents\.local\.md|\.claude\.local\.md)$'
```
File types and locations:
| Type | Location | Purpose |
| --- | --- | --- |
| Codex project root | `./AGENTS.md` | Primary Codex project instructions, usually checked into git |
| Claude project root | `./CLAUDE.md` | Primary Claude Code project context, usually checked into git |
| Local Codex override | `./.agents.local.md` | Personal/local Codex notes, normally gitignored |
| Local Claude override | `./.claude.local.md` | Personal/local Claude notes, normally gitignored |
| Global Codex defaults | `~/.codex/AGENTS.md` | User-wide Codex defaults |
| Global Claude defaults | `~/.claude/CLAUDE.md` | User-wide Claude defaults |
| Nested/package files | `**/AGENTS.md` or `**/CLAUDE.md` | Module-level context in monorepos |
When both `AGENTS.md` and `CLAUDE.md` exist, keep tool-specific rules in the matching file and avoid duplicating generic content unless the user asks for parity.
### Phase 2: Quality Assessment
For each instruction file, evaluate it against [references/quality-criteria.md](references/quality-criteria.md).
Quick checklist:
| Criterion | Weight | Check |
| --- | --- | --- |
| Commands/workflows documented | High | Are build/test/lint/deploy commands present and executable? |
| Architecture clarity | High | Can an agent understand the codebase structure? |
| Non-obvious patterns | Medium | Are gotchas and project-specific quirks documented? |
| Conciseness | Medium | Does every line earn its prompt cost? |
| Currency | High | Does it reflect the current codebase state? |
| Actionability | High | Are instructions concrete, not vague? |
Quality scores:
- A (90-100): Comprehensive, current, actionable
- B (70-89): Good coverage, minor gaps
- C (50-69): Basic info, missing key sections
- D (30-49): Sparse or outdated
- F (0-29): Missing or severely outdated
### Phase 3: Quality Report
Always output the quality report before making updates.
```markdown
## Project Instruction Quality Report
### Summary
- Files found: X
- Average score: X/100
- Files needing update: X
### File-by-File Assessment
#### 1. ./AGENTS.md
**Score: XX/100 (Grade: X)**
| Criterion | Score | Notes |
| --- | --- | --- |
| Commands/workflows | X/20 | ... |
| Architecture clarity | X/20 | ... |
| Non-obvious patterns | X/15 | ... |
| Conciseness | X/15 | ... |
| Currency | X/15 | ... |
| Actionability | X/15 | ... |
**Issues:**
- ...
**Recommended additions:**
- ...
```
### Phase 4: Targeted Updates
After the report, ask for confirmation before editing.
Update guidelines:
1. Propose targeted additions only:
- Commands or workflows discovered during analysis
- Gotchas or non-obvious patterns found in code
- Package relationships that were unclear
- Testing approaches that work
- Environment or configuration quirks
2. Keep changes minimal:
- Do not restate obvious code structure
- Do not add generic best practices
- Do not preserve one-off fixes unlikely to recur
- Prefer one-line notes over long explanations
3. Show diffs:
- File to update
- Exact addition or replacement
- One-line reason this helps future sessions
Diff format:
````markdown
### Update: ./AGENTS.md
**Why:** The build command was missing.
```diff
+ ## Commands
+ `npm run build` - Production build.
```
````
### Phase 5: Apply Updates
After user approval, edit only the approved instruction files. Preserve existing structure and formatting, and do not change unrelated project files.
## Templates
Use [references/templates.md](references/templates.md) as a source of section patterns, adapting `CLAUDE.md` examples to `AGENTS.md` when working in Codex projects.
## Common Issues to Flag
1. Stale commands that no longer work
2. Missing dependencies or setup steps
3. Outdated architecture or deleted paths
4. Missing environment variables or config notes
5. Broken test commands
6. Undocumented gotchas or recurring workflow mistakes
## User Tips
When presenting recommendations, remind users:
- Keep instruction files concise; they become model context.
- Commands should be copy-paste ready.
- Store shared team rules in `AGENTS.md` or `CLAUDE.md`.
- Store personal preferences in local-only files if the project uses them.
plugins/cache/local-personal/claude-md-management/1.0.0/skills/claude-md-improver/references/quality-criteria.md
Vendored
+109
View File
@@ -0,0 +1,109 @@
# CLAUDE.md Quality Criteria
## Scoring Rubric
### 1. Commands/Workflows (20 points)
**20 points**: All essential commands documented with context
- Build, test, lint, deploy commands present
- Development workflow clear
- Common operations documented
**15 points**: Most commands present, some missing context
**10 points**: Basic commands only, no workflow
**5 points**: Few commands, many missing
**0 points**: No commands documented
### 2. Architecture Clarity (20 points)
**20 points**: Clear codebase map
- Key directories explained
- Module relationships documented
- Entry points identified
- Data flow described where relevant
**15 points**: Good structure overview, minor gaps
**10 points**: Basic directory listing only
**5 points**: Vague or incomplete
**0 points**: No architecture info
### 3. Non-Obvious Patterns (15 points)
**15 points**: Gotchas and quirks captured
- Known issues documented
- Workarounds explained
- Edge cases noted
- "Why we do it this way" for unusual patterns
**10 points**: Some patterns documented
**5 points**: Minimal pattern documentation
**0 points**: No patterns or gotchas
### 4. Conciseness (15 points)
**15 points**: Dense, valuable content
- No filler or obvious info
- Each line adds value
- No redundancy with code comments
**10 points**: Mostly concise, some padding
**5 points**: Verbose in places
**0 points**: Mostly filler or restates obvious code
### 5. Currency (15 points)
**15 points**: Reflects current codebase
- Commands work as documented
- File references accurate
- Tech stack current
**10 points**: Mostly current, minor staleness
**5 points**: Several outdated references
**0 points**: Severely outdated
### 6. Actionability (15 points)
**15 points**: Instructions are executable
- Commands can be copy-pasted
- Steps are concrete
- Paths are real
**10 points**: Mostly actionable
**5 points**: Some vague instructions
**0 points**: Vague or theoretical
## Assessment Process
1. Read the CLAUDE.md file completely
2. Cross-reference with actual codebase:
- Run documented commands (mentally or actually)
- Check if referenced files exist
- Verify architecture descriptions
3. Score each criterion
4. Calculate total and assign grade
5. List specific issues found
6. Propose concrete improvements
## Red Flags
- Commands that would fail (wrong paths, missing deps)
- References to deleted files/folders
- Outdated tech versions
- Copy-paste from templates without customization
- Generic advice not specific to the project
- "TODO" items never completed
- Duplicate info across multiple CLAUDE.md files
plugins/cache/local-personal/claude-md-management/1.0.0/skills/claude-md-improver/references/templates.md
Vendored
+253
View File
@@ -0,0 +1,253 @@
# CLAUDE.md Templates
## Key Principles
- **Concise**: Dense, human-readable content; one line per concept when possible
- **Actionable**: Commands should be copy-paste ready
- **Project-specific**: Document patterns unique to this project, not generic advice
- **Current**: All info should reflect actual codebase state
---
## Recommended Sections
Use only the sections relevant to the project. Not all sections are needed.
### Commands
Document the essential commands for working with the project.
```markdown
## Commands
| Command | Description |
|---------|-------------|
| `<install command>` | Install dependencies |
| `<dev command>` | Start development server |
| `<build command>` | Production build |
| `<test command>` | Run tests |
| `<lint command>` | Lint/format code |
```
### Architecture
Describe the project structure so Claude understands where things live.
```markdown
## Architecture
```
<root>/
<dir>/ # <purpose>
<dir>/ # <purpose>
<dir>/ # <purpose>
```
```
### Key Files
List important files that Claude should know about.
```markdown
## Key Files
- `<path>` - <purpose>
- `<path>` - <purpose>
```
### Code Style
Document project-specific coding conventions.
```markdown
## Code Style
- <convention>
- <convention>
- <preference over alternative>
```
### Environment
Document required environment variables and setup.
```markdown
## Environment
Required:
- `<VAR_NAME>` - <purpose>
- `<VAR_NAME>` - <purpose>
Setup:
- <setup step>
```
### Testing
Document testing approach and commands.
```markdown
## Testing
- `<test command>` - <what it tests>
- <testing convention or pattern>
```
### Gotchas
Document non-obvious patterns, quirks, and warnings.
```markdown
## Gotchas
- <non-obvious thing that causes issues>
- <ordering dependency or prerequisite>
- <common mistake to avoid>
```
### Workflow
Document development workflow patterns.
```markdown
## Workflow
- <when to do X>
- <preferred approach for Y>
```
---
## Template: Project Root (Minimal)
```markdown
# <Project Name>
<One-line description>
## Commands
| Command | Description |
|---------|-------------|
| `<command>` | <description> |
## Architecture
```
<structure>
```
## Gotchas
- <gotcha>
```
---
## Template: Project Root (Comprehensive)
```markdown
# <Project Name>
<One-line description>
## Commands
| Command | Description |
|---------|-------------|
| `<command>` | <description> |
## Architecture
```
<structure with descriptions>
```
## Key Files
- `<path>` - <purpose>
## Code Style
- <convention>
## Environment
- `<VAR>` - <purpose>
## Testing
- `<command>` - <scope>
## Gotchas
- <gotcha>
```
---
## Template: Package/Module
For packages within a monorepo or distinct modules.
```markdown
# <Package Name>
<Purpose of this package>
## Usage
```
<import/usage example>
```
## Key Exports
- `<export>` - <purpose>
## Dependencies
- `<dependency>` - <why needed>
## Notes
- <important note>
```
---
## Template: Monorepo Root
```markdown
# <Monorepo Name>
<Description>
## Packages
| Package | Description | Path |
|---------|-------------|------|
| `<name>` | <purpose> | `<path>` |
## Commands
| Command | Description |
|---------|-------------|
| `<command>` | <description> |
## Cross-Package Patterns
- <shared pattern>
- <generation/sync pattern>
```
---
## Update Principles
When updating any CLAUDE.md:
1. **Be specific**: Use actual file paths, real commands from this project
2. **Be current**: Verify info against the actual codebase
3. **Be brief**: One line per concept when possible
4. **Be useful**: Would this help a new Claude session understand the project?
plugins/cache/local-personal/claude-md-management/1.0.0/skills/claude-md-improver/references/update-guidelines.md
Vendored
+150
View File
@@ -0,0 +1,150 @@
# CLAUDE.md Update Guidelines
## Core Principle
Only add information that will genuinely help future Claude sessions. The context window is precious - every line must earn its place.
## What TO Add
### 1. Commands/Workflows Discovered
```markdown
## Build
`npm run build:prod` - Full production build with optimization
`npm run build:dev` - Fast dev build (no minification)
```
Why: Saves future sessions from discovering these again.
### 2. Gotchas and Non-Obvious Patterns
```markdown
## Gotchas
- Tests must run sequentially (`--runInBand`) due to shared DB state
- `yarn.lock` is authoritative; delete `node_modules` if deps mismatch
```
Why: Prevents repeating debugging sessions.
### 3. Package Relationships
```markdown
## Dependencies
The `auth` module depends on `crypto` being initialized first.
Import order matters in `src/bootstrap.ts`.
```
Why: Architecture knowledge that isn't obvious from code.
### 4. Testing Approaches That Worked
```markdown
## Testing
For API endpoints: Use `supertest` with the test helper in `tests/setup.ts`
Mocking: Factory functions in `tests/factories/` (not inline mocks)
```
Why: Establishes patterns that work.
### 5. Configuration Quirks
```markdown
## Config
- `NEXT_PUBLIC_*` vars must be set at build time, not runtime
- Redis connection requires `?family=0` suffix for IPv6
```
Why: Environment-specific knowledge.
## What NOT to Add
### 1. Obvious Code Info
Bad:
```markdown
The `UserService` class handles user operations.
```
The class name already tells us this.
### 2. Generic Best Practices
Bad:
```markdown
Always write tests for new features.
Use meaningful variable names.
```
This is universal advice, not project-specific.
### 3. One-Off Fixes
Bad:
```markdown
We fixed a bug in commit abc123 where the login button didn't work.
```
Won't recur; clutters the file.
### 4. Verbose Explanations
Bad:
```markdown
The authentication system uses JWT tokens. JWT (JSON Web Tokens) are
an open standard (RFC 7519) that defines a compact and self-contained
way for securely transmitting information between parties as a JSON
object. In our implementation, we use the HS256 algorithm which...
```
Good:
```markdown
Auth: JWT with HS256, tokens in `Authorization: Bearer <token>` header.
```
## Diff Format for Updates
For each suggested change:
### 1. Identify the File
```
File: ./CLAUDE.md
Section: Commands (new section after ## Architecture)
```
### 2. Show the Change
```diff
## Architecture
...
+## Commands
+
+| Command | Purpose |
+|---------|---------|
+| `npm run dev` | Dev server with HMR |
+| `npm run build` | Production build |
+| `npm test` | Run test suite |
```
### 3. Explain Why
> **Why this helps:** The build commands weren't documented, causing
> confusion about how to run the project. This saves future sessions
> from needing to inspect `package.json`.
## Validation Checklist
Before finalizing an update, verify:
- [ ] Each addition is project-specific
- [ ] No generic advice or obvious info
- [ ] Commands are tested and work
- [ ] File paths are accurate
- [ ] Would a new Claude session find this helpful?
- [ ] Is this the most concise way to express the info?
plugins/cache/local-personal/claude-md-management/1.0.0/skills/revise-claude-md/SKILL.md
Vendored
+72
View File
@@ -0,0 +1,72 @@
---
name: revise-claude-md
description: Capture useful learnings from the current session into AGENTS.md, CLAUDE.md, .agents.local.md, or .claude.local.md. Use when the user asks to revise project instructions, update project memory, capture session learnings, or run the Claude /revise-claude-md workflow in Codex.
---
# Revise Project Instructions
Review the current session for durable learnings about working in this codebase, then propose concise updates to the appropriate project instruction file.
## Step 1: Reflect
Identify context that would help future Codex or Claude sessions:
- Commands that were used or discovered
- Code style patterns that were followed
- Testing approaches that worked
- Environment or configuration quirks
- Recurring warnings, gotchas, or workflow constraints
Only keep information likely to recur. Do not capture one-off debugging details or generic software engineering advice.
## Step 2: Find Instruction Files
Search for relevant files:
```powershell
rg --files | rg '(^|/)(AGENTS\.md|CLAUDE\.md|\.agents\.local\.md|\.claude\.local\.md)$'
```
Choose the target file:
- `AGENTS.md`: Codex project instructions shared with the team
- `CLAUDE.md`: Claude Code project context shared with the team
- `.agents.local.md`: personal/local Codex notes, normally gitignored
- `.claude.local.md`: personal/local Claude notes, normally gitignored
When the repo has `AGENTS.md`, prefer it for Codex-specific rules. When the repo has only `CLAUDE.md`, use `CLAUDE.md` unless the user asks to create an `AGENTS.md`.
## Step 3: Draft Additions
Keep additions concise. One line per concept is usually enough.
Format:
```text
<command or pattern> - <brief description>
```
Avoid:
- Verbose explanations
- Obvious information
- One-off fixes unlikely to recur
- Duplicating an existing rule
## Step 4: Show Proposed Changes
For each proposed addition, show:
````markdown
### Update: ./AGENTS.md
**Why:** <one-line reason>
```diff
+ <the addition>
```
````
## Step 5: Apply with Approval
Ask if the user wants to apply the changes. Only edit files they approve, preserve existing structure, and keep the update focused on approved additions.