| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 9 | 6 | 1 | 56% |
| Commands | 0 | 1 | 0 | 0% |
| Section tags | 5 | 2 | 0 | 71% |
What each file covers
Sections
9 shared · 6 only in A · 1 only in B- − AGENTS.md — Agent Skill Routing for ORGII
- − Touching background work or retained state
- − Pull request contract
- − Problem
- − Solution
- − Potential risks
- + CLAUDE.md — Agent Skill Routing for ORGII
- Skill Routing Table
- Default Delivery Flow
- Touching `*.tsx` files (UI work)
- React performance-focused work
- Touching Rust / backend / type-level / cross-layer code
- When multiple methodologies apply
- What This File Does NOT Do
- Audit Report Conventions
- When You're Unsure
Commands
0 shared · 1 only in A · 0 only in B- − gh pr view
Section tags
5 shared · 2 only in A · 0 only in B- − git-pr
- − api
- code-style
- types
- ui
- performance
- agent-behaviour
Line diff
org2AI/ORG2 · AGENTS.md
@@ −1 @@
1# AGENTS.md — Agent Skill Routing for ORGII
2
3This file orients Codex / orgii agents working in this repo. It tells you **which audit / methodology skill to invoke** for which kind of task, and what to deliver before declaring work done.
4
5> Cursor IDE users: live UI-feature delivery rules live in `.cursor/rules/ui-feature-workflow.mdc`. This file does **not** replace those — it's about skill routing for AI agents, not unit-test gates.
6
@@ −17 @@
17| React performance, re-renders, async waterfalls, bundle size, heavy dependencies, virtualization, high-frequency events | `react-best-practices` | For performance-focused React implementation/review; not for routine styling, copy, or single-file bug fixes without a performance concern |
18| Both architecture and React performance change together | Run both, keep findings categorized | Apply `architecture-audit` to ownership/boundaries and `react-best-practices` to measured React runtime concerns |
19| E2E test surface (Playwright / WebDriver), test stability | `e2e-testing` | When adding or repairing rendered E2E specs |
20| Polling, timers, caches, subscriptions, workers, streaming, sync, scans, pagination, multi-instance lifecycle | `org2-performance-guard` | Before delivering any change that can consume CPU/RAM/I/O while active, idle, hidden, or across repeated open/close cycles |
21
22Skills live at:
23
@@ −26 @@
26- `.orgii/skills/architecture-audit/SKILL.md` (workspace copy, if present)
27- `.orgii/skills/react-best-practices/SKILL.md` (workspace; ORGII overlay for Vercel's React guidance)
28- `.orgii/skills/e2e-testing/SKILL.md` (workspace)
29- `.orgii/skills/org2-performance-guard/SKILL.md` (workspace)
30
31If the skill block isn't already prefetched in your context, read its `SKILL.md` before acting on it.
32
@@ −53 @@
53### When multiple methodologies apply
54
55Run every applicable skill. Keep architecture, React performance, and UI-consistency findings clearly categorized. Only skills that define an audit-report format require a report; `react-best-practices` is implementation/review guidance and does not create a report by default.
56
57### Touching background work or retained state
58
59Run `org2-performance-guard` whenever a change adds or modifies polling, timers, retries, subscriptions, workers, streaming hot paths, caches, scans, sync loops, pagination, or multi-instance state. Apply its lifecycle matrix and rejection rules even when performance is not the feature's headline. State the performance verdict and concrete verification in the delivery message.
60
61### Pull request contract
62
63Every pull request created or updated by an agent MUST follow these rules.
64
65#### Single responsibility
66
67- One PR solves one problem or delivers one feature. Do not combine multiple
68 features, unrelated bug fixes, opportunistic refactors, cleanup, formatting,
69 or documentation changes in the same PR.
70- Supporting tests and documentation belong in the same PR only when they
71 directly verify or explain that PR's single change.
72- If requested work contains independent changes, split them into separate
73 branches/worktrees and separate PRs.
74- If a new unrelated request arrives after a PR has been opened, do not append
75 it to the existing branch. Create a separate PR.
76- Before handoff, compare the branch against its base and confirm every changed
77 file maps directly to the PR's stated problem or solution.
78
79#### Description format
80
81The PR description MUST begin with these top-level sections in this exact
82order:
83
84```markdown
85## Problem
86
87<What is wrong, who or what is affected, and the root cause.>
88
89## Solution
90
91<What changed, the resulting invariant or behavior, and why this approach was chosen.>
92
93## Potential risks
94
95<Concrete regressions, compatibility concerns, unverified paths, or operational tradeoffs.>
96```
97
98- Do not replace these sections with `Summary`, `Overview`, or `Test plan`.
99- Do not leave a required section blank. If no material risk remains, state
100 that explicitly and explain why.
101- Additional sections such as `Audit`, `Verification`, screenshots, or rollout
102 notes may follow the three required sections.
103- Before handing off a PR, read back the published description (for example
104 with `gh pr view`) and verify the section names and order.
105
106#### Base and diff integrity
107
108- Start from the intended target branch. Before handoff, fetch its latest state
109 and check whether the PR needs to be updated or conflicts resolved.
110- After resolving conflicts or incorporating target-branch changes, rerun the
111 checks affected by that integration.
112- Keep the published description synchronized with the final diff. Remove
113 claims about approaches, files, or behavior that are no longer present.
114- Avoid unrelated merge commits and generated churn. Do not rewrite published
115 history after review begins unless necessary; if history must change, use the
116 safest available method and tell reviewers what changed.
117
118#### Verification evidence
119
120- List the exact commands and meaningful manual checks that actually ran,
121 together with their outcomes.
122- State which relevant checks were not run and why. Do not write unsupported
123 claims such as "all tests pass" or infer runtime/performance improvement from
124 typecheck or code shape alone.
125- Verification must be proportional to risk and cover the changed behavior at
126 its owning boundary, not only a helper or selector.
127
128#### Risk, compatibility, and rollback
129
130- `Potential risks` must name concrete compatibility, data, concurrency,
131 lifecycle, platform, rollout, and unverified-path concerns that apply. Do not
132 use a generic "no risk" statement to avoid analysis.
133- Dependency or lockfile changes, database/schema migrations, configuration or
134 persistence format changes, and public API/IPC/wire changes must state why
135 they are necessary, how compatibility is handled, and how to roll back or
136 recover.
137- Destructive or difficult-to-reverse behavior requires an explicit rollback
138 or recovery plan before the PR is ready for review.
139
140#### UI and security evidence
141
142- User-visible UI changes should include screenshots or recordings appropriate
143 to the change, including relevant themes, viewport constraints, and
144 loading/empty/error states. If visual evidence is not useful, say why.
145- Before handoff, inspect the diff for secrets, tokens, personal paths, private
146 configuration, debug logs, build artifacts, caches, and unrelated formatting
147 changes. None may be included.
148
149#### Draft, ready, and review lifecycle
150
151- Keep the PR in Draft while material design choices, known blockers, required
152 migrations, or risk-proportionate verification remain incomplete.
153- Mark the PR ready only when its acceptance criteria are met and the
154 description reflects the current implementation.
155- If scope, behavior, or the chosen solution changes materially after review
156 begins, update the description and notify reviewers instead of silently
157 changing direction.
158
159---
160
org2AI/ORG2 · CLAUDE.md
@@ +1 @@
1# CLAUDE.md — Agent Skill Routing for ORGII
2
3This file orients Claude / orgii agents working in this repo. It tells you **which audit / methodology skill to invoke** for which kind of task, and what to deliver before declaring work done.
4
5> Cursor IDE users: live UI-feature delivery rules live in `.cursor/rules/ui-feature-workflow.mdc`. This file does **not** replace those — it's about skill routing for AI agents, not unit-test gates.
6
@@ +17 @@
17| React performance, re-renders, async waterfalls, bundle size, heavy dependencies, virtualization, high-frequency events | `react-best-practices` | For performance-focused React implementation/review; not for routine styling, copy, or single-file bug fixes without a performance concern |
18| Both architecture and React performance change together | Run both, keep findings categorized | Apply `architecture-audit` to ownership/boundaries and `react-best-practices` to measured React runtime concerns |
19| E2E test surface (Playwright / WebDriver), test stability | `e2e-testing` | When adding or repairing rendered E2E specs |
20| Cloud sync / session sharing / collab correctness (share, push/retract, fork, replay, comments, continuation) | `dual-instance-verification` | Before declaring any sharing/sync change "verified"; when a sharing bug escaped earlier testing |
21
22Skills live at:
23
@@ +26 @@
26- `.orgii/skills/architecture-audit/SKILL.md` (workspace copy, if present)
27- `.orgii/skills/react-best-practices/SKILL.md` (workspace; ORGII overlay for Vercel's React guidance)
28- `.orgii/skills/e2e-testing/SKILL.md` (workspace)
29- `.orgii/skills/dual-instance-verification/SKILL.md` (workspace; 双机实测 protocol for cloud sync / sharing)
30
31If the skill block isn't already prefetched in your context, read its `SKILL.md` before acting on it.
32
@@ +53 @@
53### When multiple methodologies apply
54
55Run every applicable skill. Keep architecture, React performance, and UI-consistency findings clearly categorized. Only skills that define an audit-report format require a report; `react-best-practices` is implementation/review guidance and does not create a report by default.
56
57---
58
@@ −1 +1 @@
1−# AGENTS.md — Agent Skill Routing for ORGII
1+# CLAUDE.md — Agent Skill Routing for ORGII
22
3−This file orients Codex / orgii agents working in this repo. It tells you **which audit / methodology skill to invoke** for which kind of task, and what to deliver before declaring work done.
3+This file orients Claude / orgii agents working in this repo. It tells you **which audit / methodology skill to invoke** for which kind of task, and what to deliver before declaring work done.
44
55 > Cursor IDE users: live UI-feature delivery rules live in `.cursor/rules/ui-feature-workflow.mdc`. This file does **not** replace those — it's about skill routing for AI agents, not unit-test gates.
66
@@ −17 +17 @@
1717 | React performance, re-renders, async waterfalls, bundle size, heavy dependencies, virtualization, high-frequency events | `react-best-practices` | For performance-focused React implementation/review; not for routine styling, copy, or single-file bug fixes without a performance concern |
1818 | Both architecture and React performance change together | Run both, keep findings categorized | Apply `architecture-audit` to ownership/boundaries and `react-best-practices` to measured React runtime concerns |
1919 | E2E test surface (Playwright / WebDriver), test stability | `e2e-testing` | When adding or repairing rendered E2E specs |
20−| Polling, timers, caches, subscriptions, workers, streaming, sync, scans, pagination, multi-instance lifecycle | `org2-performance-guard` | Before delivering any change that can consume CPU/RAM/I/O while active, idle, hidden, or across repeated open/close cycles |
20+| Cloud sync / session sharing / collab correctness (share, push/retract, fork, replay, comments, continuation) | `dual-instance-verification` | Before declaring any sharing/sync change "verified"; when a sharing bug escaped earlier testing |
2121
2222 Skills live at:
2323
@@ −26 +26 @@
2626 - `.orgii/skills/architecture-audit/SKILL.md` (workspace copy, if present)
2727 - `.orgii/skills/react-best-practices/SKILL.md` (workspace; ORGII overlay for Vercel's React guidance)
2828 - `.orgii/skills/e2e-testing/SKILL.md` (workspace)
29−- `.orgii/skills/org2-performance-guard/SKILL.md` (workspace)
29+- `.orgii/skills/dual-instance-verification/SKILL.md` (workspace; 双机实测 protocol for cloud sync / sharing)
3030
3131 If the skill block isn't already prefetched in your context, read its `SKILL.md` before acting on it.
3232
@@ −53 +53 @@
5353 ### When multiple methodologies apply
5454
5555 Run every applicable skill. Keep architecture, React performance, and UI-consistency findings clearly categorized. Only skills that define an audit-report format require a report; `react-best-practices` is implementation/review guidance and does not create a report by default.
56−
57−### Touching background work or retained state
58−
59−Run `org2-performance-guard` whenever a change adds or modifies polling, timers, retries, subscriptions, workers, streaming hot paths, caches, scans, sync loops, pagination, or multi-instance state. Apply its lifecycle matrix and rejection rules even when performance is not the feature's headline. State the performance verdict and concrete verification in the delivery message.
60−
61−### Pull request contract
62−
63−Every pull request created or updated by an agent MUST follow these rules.
64−
65−#### Single responsibility
66−
67−- One PR solves one problem or delivers one feature. Do not combine multiple
68− features, unrelated bug fixes, opportunistic refactors, cleanup, formatting,
69− or documentation changes in the same PR.
70−- Supporting tests and documentation belong in the same PR only when they
71− directly verify or explain that PR's single change.
72−- If requested work contains independent changes, split them into separate
73− branches/worktrees and separate PRs.
74−- If a new unrelated request arrives after a PR has been opened, do not append
75− it to the existing branch. Create a separate PR.
76−- Before handoff, compare the branch against its base and confirm every changed
77− file maps directly to the PR's stated problem or solution.
78−
79−#### Description format
80−
81−The PR description MUST begin with these top-level sections in this exact
82−order:
83−
84−```markdown
85−## Problem
86−
87−<What is wrong, who or what is affected, and the root cause.>
88−
89−## Solution
90−
91−<What changed, the resulting invariant or behavior, and why this approach was chosen.>
92−
93−## Potential risks
94−
95−<Concrete regressions, compatibility concerns, unverified paths, or operational tradeoffs.>
96−```
97−
98−- Do not replace these sections with `Summary`, `Overview`, or `Test plan`.
99−- Do not leave a required section blank. If no material risk remains, state
100− that explicitly and explain why.
101−- Additional sections such as `Audit`, `Verification`, screenshots, or rollout
102− notes may follow the three required sections.
103−- Before handing off a PR, read back the published description (for example
104− with `gh pr view`) and verify the section names and order.
105−
106−#### Base and diff integrity
107−
108−- Start from the intended target branch. Before handoff, fetch its latest state
109− and check whether the PR needs to be updated or conflicts resolved.
110−- After resolving conflicts or incorporating target-branch changes, rerun the
111− checks affected by that integration.
112−- Keep the published description synchronized with the final diff. Remove
113− claims about approaches, files, or behavior that are no longer present.
114−- Avoid unrelated merge commits and generated churn. Do not rewrite published
115− history after review begins unless necessary; if history must change, use the
116− safest available method and tell reviewers what changed.
117−
118−#### Verification evidence
119−
120−- List the exact commands and meaningful manual checks that actually ran,
121− together with their outcomes.
122−- State which relevant checks were not run and why. Do not write unsupported
123− claims such as "all tests pass" or infer runtime/performance improvement from
124− typecheck or code shape alone.
125−- Verification must be proportional to risk and cover the changed behavior at
126− its owning boundary, not only a helper or selector.
127−
128−#### Risk, compatibility, and rollback
129−
130−- `Potential risks` must name concrete compatibility, data, concurrency,
131− lifecycle, platform, rollout, and unverified-path concerns that apply. Do not
132− use a generic "no risk" statement to avoid analysis.
133−- Dependency or lockfile changes, database/schema migrations, configuration or
134− persistence format changes, and public API/IPC/wire changes must state why
135− they are necessary, how compatibility is handled, and how to roll back or
136− recover.
137−- Destructive or difficult-to-reverse behavior requires an explicit rollback
138− or recovery plan before the PR is ready for review.
139−
140−#### UI and security evidence
141−
142−- User-visible UI changes should include screenshots or recordings appropriate
143− to the change, including relevant themes, viewport constraints, and
144− loading/empty/error states. If visual evidence is not useful, say why.
145−- Before handoff, inspect the diff for secrets, tokens, personal paths, private
146− configuration, debug logs, build artifacts, caches, and unrelated formatting
147− changes. None may be included.
148−
149−#### Draft, ready, and review lifecycle
150−
151−- Keep the PR in Draft while material design choices, known blockers, required
152− migrations, or risk-proportionate verification remain incomplete.
153−- Mark the PR ready only when its acceptance criteria are met and the
154− description reflects the current implementation.
155−- If scope, behavior, or the chosen solution changes materially after review
156− begins, update the description and notify reviewers instead of silently
157− changing direction.
15856
15957 ---
16058
