Two files, one repository
gitpod-io/gitpod ships 2 formats across 2 indexed files. The question worth asking is whether the second one says anything the first does not.
CompareAGENTS.md ↔ Cline rules
| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 3 | 10 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 1 | 4 | 0% |
What each file covers
Sections
0 shared · 3 only in A · 10 only in B- − Gitpod repository guidance
- − Task-specific context
- − Working conventions
- + Cline's Memory Bank
- + Memory Bank Structure
- + Core Files (Required)
- + Per-component documentation
- + Additional Context
- + Core Workflows
- + Plan Mode
- + Act Mode
- + Documentation Updates
- + Memory Management
Commands
neither file has anySection tags
0 shared · 1 only in A · 4 only in B- − code-style
- + architecture
- + ui
- + performance
- + docs
Line diff
gitpod-io/gitpod · AGENTS.md
@@ −1 @@
1# Gitpod repository guidance
2
3Gitpod is a multi-language monorepo for a Kubernetes-based development
4environment platform. Keep changes focused: identify the component or workflow
5you are changing and read its local documentation before editing it.
6
7## Task-specific context
8
9- For CVE remediation and daily vulnerability scan work, read
10 `cve-mitigation/SKILL.md` and `cve-mitigation/references/ci-scanning.md`.
11- For changes to the development image or tools installed in it, read
12 `dev/image/README.md`.
13- Consult component-specific documentation only when working in that component.
14 Do not read or update the entire `memory-bank/` for every task.
15
16## Working conventions
17
18- Preserve unrelated changes already present in the worktree.
19- `.github/workflows/build.yml` and `.github/workflows/branch-build.yml` mirror
20 many build steps. Changes to shared build behavior normally belong in both.
21- Run the smallest relevant test suite for the code you changed.
22- Run `pre-commit run --files <changed files>` before submitting a change.
23
gitpod-io/gitpod · .clinerules/memory-bank.md
@@ +1 @@
1# Cline's Memory Bank
2
3I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
4
5## Memory Bank Structure
6
7The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
8
9```mermaid
10flowchart TD
11 PB[projectbrief.md] --> PC[productContext.md]
12 PB --> SP[systemPatterns.md]
13 PB --> TC[techContext.md]
14
15 PC --> AC[activeContext.md]
16 SP --> AC
17 TC --> AC
18
19 AC --> P[progress.md]
20```
21
22### Core Files (Required)
231. `projectbrief.md`
24 - Foundation document that shapes all other files
25 - Created at project start if it doesn't exist
26 - Defines core requirements and goals
27 - Source of truth for project scope
28
292. `productContext.md`
30 - Why this project exists
31 - Problems it solves
32 - How it should work
33 - User experience goals
34
353. `activeContext.md`
36 - Current work focus
37 - Recent changes
38 - Next steps
39 - Active decisions and considerations
40 - Important patterns and preferences
41 - Learnings and project insights
42
434. `systemPatterns.md`
44 - System architecture
45 - Key technical decisions
46 - Design patterns in use
47 - Component relationships
48 - Critical implementation paths
49
505. `techContext.md`
51 - Technologies used
52 - Development setup
53 - Technical constraints
54 - Dependencies
55 - Tool usage patterns
56
576. `progress.md`
58 - What works
59 - What's left to build
60 - Current status
61 - Known issues
62 - Evolution of project decisions
63
64### Per-component documentation
65The `memory-bank/components` directory contains detailed documentation about each component in this project. With regards to maintaining and updating it, treat it just like any other part of the memory-bank.
66
67### Additional Context
68Create additional files/folders within memory-bank/ when they help organize:
69- Complex feature documentation
70- Integration specifications
71- API documentation
72- Testing strategies
73- Deployment procedures
74
75## Core Workflows
76
77### Plan Mode
78```mermaid
79flowchart TD
80 Start[Start] --> ReadFiles[Read Memory Bank]
81 ReadFiles --> CheckFiles{Files Complete?}
82
83 CheckFiles -->|No| Plan[Create Plan]
84 Plan --> Document[Document in Chat]
85
86 CheckFiles -->|Yes| Verify[Verify Context]
87 Verify --> Strategy[Develop Strategy]
88 Strategy --> Present[Present Approach]
89```
90
91### Act Mode
92```mermaid
93flowchart TD
94 Start[Start] --> Context[Check Memory Bank]
95 Context --> Update[Update Documentation]
96 Update --> Execute[Execute Task]
97 Execute --> Document[Document Changes]
98```
99
100## Documentation Updates
101
102Memory Bank updates occur when:
1031. Discovering new project patterns
1042. After implementing significant changes
1053. When user requests with **update memory bank** (MUST review ALL files)
1064. When context needs clarification
107
108```mermaid
109flowchart TD
110 Start[Update Process]
111
112 subgraph Process
113 P1[Review ALL Files]
114 P2[Document Current State]
115 P3[Clarify Next Steps]
116 P4[Document Insights & Patterns]
117
118 P1 --> P2 --> P3 --> P4
119 end
120
121 Start --> Process
122```
123
124Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.
125
126## Memory Management
127- Be mindful of space in memory bank files
128- Deleting irrelevant memories is a good thing
129- Follow short-term vs. long-term memory strategy:
130 - Short-term memory (activeContext.md, progress.md): Detailed, recent, specific
131 - Long-term memory (systemPatterns.md, techContext.md, projectbrief.md): Compressed, patterns, principles
132- Apply this strategy on every interaction with the memory bank
133- Use **compress memory bank** trigger to perform a compression run
134
135When compressing memory bank files:
1361. Focus on patterns over instances
1372. Use tables and summaries instead of exhaustive lists
1383. Keep only the most relevant and recent information in short-term memory
1394. Distill important insights into long-term memory
1405. Delete outdated or redundant information
141
142REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
143
@@ −1 +1 @@
1−# Gitpod repository guidance
1+# Cline's Memory Bank
22
3−Gitpod is a multi-language monorepo for a Kubernetes-based development
4−environment platform. Keep changes focused: identify the component or workflow
5−you are changing and read its local documentation before editing it.
3+I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
64
7−## Task-specific context
5+## Memory Bank Structure
86
9−- For CVE remediation and daily vulnerability scan work, read
10− `cve-mitigation/SKILL.md` and `cve-mitigation/references/ci-scanning.md`.
11−- For changes to the development image or tools installed in it, read
12− `dev/image/README.md`.
13−- Consult component-specific documentation only when working in that component.
14− Do not read or update the entire `memory-bank/` for every task.
7+The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
158
16−## Working conventions
9+```mermaid
10+flowchart TD
11+ PB[projectbrief.md] --> PC[productContext.md]
12+ PB --> SP[systemPatterns.md]
13+ PB --> TC[techContext.md]
1714
18−- Preserve unrelated changes already present in the worktree.
19−- `.github/workflows/build.yml` and `.github/workflows/branch-build.yml` mirror
20− many build steps. Changes to shared build behavior normally belong in both.
21−- Run the smallest relevant test suite for the code you changed.
22−- Run `pre-commit run --files <changed files>` before submitting a change.
15+ PC --> AC[activeContext.md]
16+ SP --> AC
17+ TC --> AC
18+
19+ AC --> P[progress.md]
20+```
21+
22+### Core Files (Required)
23+1. `projectbrief.md`
24+ - Foundation document that shapes all other files
25+ - Created at project start if it doesn't exist
26+ - Defines core requirements and goals
27+ - Source of truth for project scope
28+
29+2. `productContext.md`
30+ - Why this project exists
31+ - Problems it solves
32+ - How it should work
33+ - User experience goals
34+
35+3. `activeContext.md`
36+ - Current work focus
37+ - Recent changes
38+ - Next steps
39+ - Active decisions and considerations
40+ - Important patterns and preferences
41+ - Learnings and project insights
42+
43+4. `systemPatterns.md`
44+ - System architecture
45+ - Key technical decisions
46+ - Design patterns in use
47+ - Component relationships
48+ - Critical implementation paths
49+
50+5. `techContext.md`
51+ - Technologies used
52+ - Development setup
53+ - Technical constraints
54+ - Dependencies
55+ - Tool usage patterns
56+
57+6. `progress.md`
58+ - What works
59+ - What's left to build
60+ - Current status
61+ - Known issues
62+ - Evolution of project decisions
63+
64+### Per-component documentation
65+The `memory-bank/components` directory contains detailed documentation about each component in this project. With regards to maintaining and updating it, treat it just like any other part of the memory-bank.
66+
67+### Additional Context
68+Create additional files/folders within memory-bank/ when they help organize:
69+- Complex feature documentation
70+- Integration specifications
71+- API documentation
72+- Testing strategies
73+- Deployment procedures
74+
75+## Core Workflows
76+
77+### Plan Mode
78+```mermaid
79+flowchart TD
80+ Start[Start] --> ReadFiles[Read Memory Bank]
81+ ReadFiles --> CheckFiles{Files Complete?}
82+
83+ CheckFiles -->|No| Plan[Create Plan]
84+ Plan --> Document[Document in Chat]
85+
86+ CheckFiles -->|Yes| Verify[Verify Context]
87+ Verify --> Strategy[Develop Strategy]
88+ Strategy --> Present[Present Approach]
89+```
90+
91+### Act Mode
92+```mermaid
93+flowchart TD
94+ Start[Start] --> Context[Check Memory Bank]
95+ Context --> Update[Update Documentation]
96+ Update --> Execute[Execute Task]
97+ Execute --> Document[Document Changes]
98+```
99+
100+## Documentation Updates
101+
102+Memory Bank updates occur when:
103+1. Discovering new project patterns
104+2. After implementing significant changes
105+3. When user requests with **update memory bank** (MUST review ALL files)
106+4. When context needs clarification
107+
108+```mermaid
109+flowchart TD
110+ Start[Update Process]
111+
112+ subgraph Process
113+ P1[Review ALL Files]
114+ P2[Document Current State]
115+ P3[Clarify Next Steps]
116+ P4[Document Insights & Patterns]
117+
118+ P1 --> P2 --> P3 --> P4
119+ end
120+
121+ Start --> Process
122+```
123+
124+Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.
125+
126+## Memory Management
127+- Be mindful of space in memory bank files
128+- Deleting irrelevant memories is a good thing
129+- Follow short-term vs. long-term memory strategy:
130+ - Short-term memory (activeContext.md, progress.md): Detailed, recent, specific
131+ - Long-term memory (systemPatterns.md, techContext.md, projectbrief.md): Compressed, patterns, principles
132+- Apply this strategy on every interaction with the memory bank
133+- Use **compress memory bank** trigger to perform a compression run
134+
135+When compressing memory bank files:
136+1. Focus on patterns over instances
137+2. Use tables and summaries instead of exhaustive lists
138+3. Keep only the most relevant and recent information in short-term memory
139+4. Distill important insights into long-term memory
140+5. Delete outdated or redundant information
141+
142+REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
23143
