opencode-plugin-team-agreements 0.1.0 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +48 -0
- package/dist/index.d.ts +15 -28
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +36 -226
- package/dist/index.js.map +1 -1
- package/dist/index.test.js +233 -53
- package/dist/index.test.js.map +1 -1
- package/dist/utils.d.ts +58 -0
- package/dist/utils.d.ts.map +1 -0
- package/dist/utils.js +572 -0
- package/dist/utils.js.map +1 -0
- package/package.json +4 -2
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
## [0.2.0](https://github.com/jwilger/opencode-plugin-team-agreements/compare/opencode-plugin-team-agreements-v0.1.4...opencode-plugin-team-agreements-v0.2.0) (2026-01-23)
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
### ⚠ BREAKING CHANGES
|
|
7
|
+
|
|
8
|
+
* Team agreements are now stored in AGENTS.md (or CLAUDE.md as fallback) in the project root instead of docs/TEAM_AGREEMENTS.md
|
|
9
|
+
|
|
10
|
+
### Features
|
|
11
|
+
|
|
12
|
+
* Use AGENTS.md for team agreements instead of docs/TEAM_AGREEMENTS.md ([#15](https://github.com/jwilger/opencode-plugin-team-agreements/issues/15)) ([00365ab](https://github.com/jwilger/opencode-plugin-team-agreements/commit/00365ab4d17f0cd4e22c2731f12fd6875d5b01e1))
|
|
13
|
+
|
|
14
|
+
|
|
15
|
+
### Bug Fixes
|
|
16
|
+
|
|
17
|
+
* Only export plugin function to prevent OpenCode crash ([#13](https://github.com/jwilger/opencode-plugin-team-agreements/issues/13)) ([d4f5930](https://github.com/jwilger/opencode-plugin-team-agreements/commit/d4f5930e0620d490b3fae635275130309f1fcfc0))
|
|
18
|
+
|
|
19
|
+
## [0.1.4](https://github.com/jwilger/opencode-plugin-team-agreements/compare/opencode-plugin-team-agreements-v0.1.3...opencode-plugin-team-agreements-v0.1.4) (2026-01-23)
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
### Bug Fixes
|
|
23
|
+
|
|
24
|
+
* **ci:** Configure npm trusted publishing correctly ([#11](https://github.com/jwilger/opencode-plugin-team-agreements/issues/11)) ([bbddb8a](https://github.com/jwilger/opencode-plugin-team-agreements/commit/bbddb8aac6a10afd917668dba3750cd5464f941b))
|
|
25
|
+
|
|
26
|
+
## [0.1.3](https://github.com/jwilger/opencode-plugin-team-agreements/compare/opencode-plugin-team-agreements-v0.1.2...opencode-plugin-team-agreements-v0.1.3) (2026-01-23)
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
### Bug Fixes
|
|
30
|
+
|
|
31
|
+
* **ci:** Remove registry-url to allow pure OIDC npm publishing ([#8](https://github.com/jwilger/opencode-plugin-team-agreements/issues/8)) ([5e0ec78](https://github.com/jwilger/opencode-plugin-team-agreements/commit/5e0ec78dbc4b92bf7e03089c83e81761b12870aa))
|
|
32
|
+
* **ci:** Use GitHub App for release-please to enable signed commits ([#10](https://github.com/jwilger/opencode-plugin-team-agreements/issues/10)) ([281200a](https://github.com/jwilger/opencode-plugin-team-agreements/commit/281200a90d694d4b72b819dced74b405f93bfff5))
|
|
33
|
+
|
|
34
|
+
## [0.1.2](https://github.com/jwilger/opencode-plugin-team-agreements/compare/opencode-plugin-team-agreements-v0.1.1...opencode-plugin-team-agreements-v0.1.2) (2026-01-23)
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
### Bug Fixes
|
|
38
|
+
|
|
39
|
+
* **ci:** Remove NPM_TOKEN to allow OIDC auth ([ef64c15](https://github.com/jwilger/opencode-plugin-team-agreements/commit/ef64c1561f43b76107b8285a2c922b45332ee635))
|
|
40
|
+
* **ci:** Use PAT for release-please to trigger CI on release PRs ([#6](https://github.com/jwilger/opencode-plugin-team-agreements/issues/6)) ([4800212](https://github.com/jwilger/opencode-plugin-team-agreements/commit/48002121148635f4221ea455dc9088f3d9daf01c))
|
|
41
|
+
* Test isolation and add lefthook pre-commit hooks ([#5](https://github.com/jwilger/opencode-plugin-team-agreements/issues/5)) ([543a641](https://github.com/jwilger/opencode-plugin-team-agreements/commit/543a641605e7542e0d95bea9fe870fb6ace3985e))
|
|
42
|
+
|
|
43
|
+
## [0.1.1](https://github.com/jwilger/opencode-plugin-team-agreements/compare/opencode-plugin-team-agreements-v0.1.0...opencode-plugin-team-agreements-v0.1.1) (2026-01-23)
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
### Features
|
|
47
|
+
|
|
48
|
+
* Offer to set up automatic enforcement for team agreements ([#2](https://github.com/jwilger/opencode-plugin-team-agreements/issues/2)) ([2af3d4e](https://github.com/jwilger/opencode-plugin-team-agreements/commit/2af3d4e147d0acf9df3fb6eda04c05ea5dba5b26))
|
package/dist/index.d.ts
CHANGED
|
@@ -1,36 +1,23 @@
|
|
|
1
|
-
import { type Plugin } from "@opencode-ai/plugin";
|
|
2
|
-
declare const PLUGIN_REPO = "jwilger/opencode-plugin-team-agreements";
|
|
3
|
-
declare const COMMAND_TEMPLATE = "You are helping establish or review team agreements for this project. Team agreements define how humans and LLM agents collaborate on the codebase.\n\nUser's request: $ARGUMENTS\n\n## Instructions\n\n1. First, check if team agreements already exist at `docs/TEAM_AGREEMENTS.md`\n\n2. If agreements exist, present the user with options:\n - **Review**: Display the current agreements\n - **Amend**: Modify a specific section \n - **Start Over**: Begin fresh (with confirmation)\n\n3. If no agreements exist (or starting over), guide the user through establishing agreements one topic at a time. Start with these core topics:\n\n### Core Topics\n\n#### a. Storage Location\nAsk where team agreements should be stored. Suggest defaults:\n- Main file: `docs/TEAM_AGREEMENTS.md`\n- Supporting details: `docs/team_agreements/*.md`\n\n#### b. Programming Languages\n- What programming language(s) will be used in this project?\n- What is each language used for? (e.g., TypeScript for frontend, Rust for backend)\n- Are there specific versions or language-specific style guides to follow?\n\n#### c. Code Quality Standards\n- What does \"great code\" look like for this team?\n- How should we prioritize: readability vs. performance vs. simplicity?\n- Are there required patterns or anti-patterns to follow/avoid?\n- What about error handling conventions?\n- Naming conventions for files, functions, variables, types?\n\n#### d. Commit Message Conventions\n- What format should commit messages follow? (Conventional Commits, custom, freeform)\n- Are there required elements? (ticket numbers, scope, breaking change indicators)\n- Any rules on length, tense, capitalization?\n- Should commits be atomic (one logical change per commit)?\n\n#### e. Integration Workflow\n- Trunk-based development or feature branches?\n- Pull request requirements? (reviews, approvals, CI checks)\n- Who can merge to main/trunk?\n- What CI checks must pass before integration?\n- Any branch naming conventions?\n\n#### f. Testing Requirements\n- What testing is required before code is considered \"done\"?\n- Are there coverage thresholds?\n- What types of tests? (unit, integration, e2e, property-based)\n- When should tests be written? (TDD, after implementation, etc.)\n\n#### g. Amendment Process\n- How can these agreements be changed?\n- Who has authority to propose/approve changes?\n- What's the review/approval process for amendments?\n- How should changes be communicated to the team?\n\n4. For each topic:\n - Ask ONE question at a time\n - Discuss trade-offs when relevant\n - Confirm understanding before moving on\n - Record the team's decision clearly\n\n5. **After the core topics**, ask:\n \"Are there any additional topics you'd like to establish agreements for?\"\n \n Suggest potential additional topics if helpful:\n - **Architecture decisions** - How to document and track ADRs\n - **Dependency management** - How to evaluate and approve new dependencies\n - **Documentation standards** - What must be documented, where, in what format\n - **LLM autonomy boundaries** - What can LLMs do without asking? What requires human approval?\n - **Session handoff protocols** - How to summarize work for the next session/agent\n - **Code review process** - What reviewers should look for, turnaround expectations\n - **Planning and work breakdown** - How to break down work into tasks\n - **Information sharing** - How to share context across sessions and team members\n \n Continue asking about each additional topic the user wants to cover.\n \n After discussing additional topics, ask: \"Would you like to suggest any of these additional topics\n (or others you thought of) to be included as standard topics in the team-agreements plugin?\n I can file a GitHub issue for you if you'd like.\"\n \n If the user wants to suggest a topic, use the `suggest_team_agreement_topic` tool to file an issue.\n\n6. After ALL topics (core + additional) are covered:\n - Generate `docs/TEAM_AGREEMENTS.md` with all agreements organized by topic\n - If any topic needs detailed documentation, create supporting files in `docs/team_agreements/`\n - Update `opencode.json` to include `docs/TEAM_AGREEMENTS.md` in the `instructions` array\n - Summarize what was established\n\n## Output Format\n\nWhen generating the TEAM_AGREEMENTS.md file, use this structure:\n\n```markdown\n# Team Agreements\n\nThis document defines how our team (humans and LLM agents) collaborates on this codebase.\n\n## Table of Contents\n[Generate based on topics covered]\n\n## 1. Storage Location\n[Agreements about where documentation lives]\n\n## 2. Programming Languages\n[Agreements about languages and their usage]\n\n## 3. Code Quality Standards\n[Agreements about what makes good code]\n\n## 4. Commit Message Conventions\n[Agreements about commit message format]\n\n## 5. Integration Workflow\n[Agreements about how code gets integrated]\n\n## 6. Testing Requirements\n[Agreements about testing]\n\n## 7. Amendment Process\n[Agreements about changing these agreements]\n\n## Additional Topics\n[Any additional topics the team added]\n\n---\n*Last updated: [date]*\n*To amend these agreements, [process from amendment section]*\n```\n\n## Important\n\n- Be conversational and collaborative\n- ONE question at a time - don't overwhelm\n- Respect the user's expertise and preferences\n- If the user provides a specific request in their message, address that first\n- The core topics are a starting point, not an exhaustive list\n- Capture the \"why\" behind decisions, not just the \"what\"";
|
|
4
|
-
/**
|
|
5
|
-
* Check if a file exists at the given path.
|
|
6
|
-
*/
|
|
7
|
-
export declare function fileExists(path: string): Promise<boolean>;
|
|
8
|
-
/**
|
|
9
|
-
* Check if the gh CLI is installed and authenticated.
|
|
10
|
-
*/
|
|
11
|
-
export declare function isGhAvailable(): Promise<boolean>;
|
|
12
1
|
/**
|
|
13
|
-
*
|
|
14
|
-
*
|
|
2
|
+
* OpenCode Team Agreements Plugin
|
|
3
|
+
*
|
|
4
|
+
* Helps teams establish and maintain shared agreements for human-LLM collaboration.
|
|
5
|
+
*
|
|
6
|
+
* IMPORTANT: Only the plugin function should be exported from this module.
|
|
7
|
+
* OpenCode's plugin loader iterates through all exports and tries to call each
|
|
8
|
+
* one as a plugin function. Exporting non-function values (like strings or objects)
|
|
9
|
+
* will cause a crash.
|
|
10
|
+
*
|
|
11
|
+
* @packageDocumentation
|
|
15
12
|
*/
|
|
16
|
-
|
|
17
|
-
/**
|
|
18
|
-
* Format suggested questions as a markdown list.
|
|
19
|
-
*/
|
|
20
|
-
export declare function formatQuestionsAsMarkdown(questions: string[]): string;
|
|
21
|
-
/**
|
|
22
|
-
* Build the issue body for a topic suggestion.
|
|
23
|
-
*/
|
|
24
|
-
export declare function buildTopicIssueBody(args: {
|
|
25
|
-
topic_name: string;
|
|
26
|
-
description: string;
|
|
27
|
-
suggested_questions: string[];
|
|
28
|
-
example_agreement?: string;
|
|
29
|
-
}): string;
|
|
30
|
-
export { COMMAND_TEMPLATE, PLUGIN_REPO };
|
|
13
|
+
import { type Plugin } from "@opencode-ai/plugin";
|
|
31
14
|
/**
|
|
32
15
|
* TeamAgreementsPlugin - Helps teams establish and maintain shared agreements
|
|
33
16
|
* for human-LLM collaboration on a codebase.
|
|
17
|
+
*
|
|
18
|
+
* Team agreements are stored in AGENTS.md (or CLAUDE.md as fallback) in the
|
|
19
|
+
* project root. These files are automatically loaded by OpenCode and Claude Code,
|
|
20
|
+
* so no config injection is needed.
|
|
34
21
|
*/
|
|
35
22
|
export declare const TeamAgreementsPlugin: Plugin;
|
|
36
23
|
export default TeamAgreementsPlugin;
|
package/dist/index.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,MAAM,EAAQ,MAAM,qBAAqB,CAAA;
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,OAAO,EAAE,KAAK,MAAM,EAAQ,MAAM,qBAAqB,CAAA;AAavD;;;;;;;GAOG;AACH,eAAO,MAAM,oBAAoB,EAAE,MAwGlC,CAAA;AAED,eAAe,oBAAoB,CAAA"}
|
package/dist/index.js
CHANGED
|
@@ -1,228 +1,32 @@
|
|
|
1
|
-
import { tool } from "@opencode-ai/plugin";
|
|
2
|
-
import { readFile, access } from "fs/promises";
|
|
3
|
-
import { join } from "path";
|
|
4
|
-
import { exec } from "child_process";
|
|
5
|
-
import { promisify } from "util";
|
|
6
|
-
const execAsync = promisify(exec);
|
|
7
|
-
const PLUGIN_REPO = "jwilger/opencode-plugin-team-agreements";
|
|
8
|
-
const COMMAND_TEMPLATE = `You are helping establish or review team agreements for this project. Team agreements define how humans and LLM agents collaborate on the codebase.
|
|
9
|
-
|
|
10
|
-
User's request: $ARGUMENTS
|
|
11
|
-
|
|
12
|
-
## Instructions
|
|
13
|
-
|
|
14
|
-
1. First, check if team agreements already exist at \`docs/TEAM_AGREEMENTS.md\`
|
|
15
|
-
|
|
16
|
-
2. If agreements exist, present the user with options:
|
|
17
|
-
- **Review**: Display the current agreements
|
|
18
|
-
- **Amend**: Modify a specific section
|
|
19
|
-
- **Start Over**: Begin fresh (with confirmation)
|
|
20
|
-
|
|
21
|
-
3. If no agreements exist (or starting over), guide the user through establishing agreements one topic at a time. Start with these core topics:
|
|
22
|
-
|
|
23
|
-
### Core Topics
|
|
24
|
-
|
|
25
|
-
#### a. Storage Location
|
|
26
|
-
Ask where team agreements should be stored. Suggest defaults:
|
|
27
|
-
- Main file: \`docs/TEAM_AGREEMENTS.md\`
|
|
28
|
-
- Supporting details: \`docs/team_agreements/*.md\`
|
|
29
|
-
|
|
30
|
-
#### b. Programming Languages
|
|
31
|
-
- What programming language(s) will be used in this project?
|
|
32
|
-
- What is each language used for? (e.g., TypeScript for frontend, Rust for backend)
|
|
33
|
-
- Are there specific versions or language-specific style guides to follow?
|
|
34
|
-
|
|
35
|
-
#### c. Code Quality Standards
|
|
36
|
-
- What does "great code" look like for this team?
|
|
37
|
-
- How should we prioritize: readability vs. performance vs. simplicity?
|
|
38
|
-
- Are there required patterns or anti-patterns to follow/avoid?
|
|
39
|
-
- What about error handling conventions?
|
|
40
|
-
- Naming conventions for files, functions, variables, types?
|
|
41
|
-
|
|
42
|
-
#### d. Commit Message Conventions
|
|
43
|
-
- What format should commit messages follow? (Conventional Commits, custom, freeform)
|
|
44
|
-
- Are there required elements? (ticket numbers, scope, breaking change indicators)
|
|
45
|
-
- Any rules on length, tense, capitalization?
|
|
46
|
-
- Should commits be atomic (one logical change per commit)?
|
|
47
|
-
|
|
48
|
-
#### e. Integration Workflow
|
|
49
|
-
- Trunk-based development or feature branches?
|
|
50
|
-
- Pull request requirements? (reviews, approvals, CI checks)
|
|
51
|
-
- Who can merge to main/trunk?
|
|
52
|
-
- What CI checks must pass before integration?
|
|
53
|
-
- Any branch naming conventions?
|
|
54
|
-
|
|
55
|
-
#### f. Testing Requirements
|
|
56
|
-
- What testing is required before code is considered "done"?
|
|
57
|
-
- Are there coverage thresholds?
|
|
58
|
-
- What types of tests? (unit, integration, e2e, property-based)
|
|
59
|
-
- When should tests be written? (TDD, after implementation, etc.)
|
|
60
|
-
|
|
61
|
-
#### g. Amendment Process
|
|
62
|
-
- How can these agreements be changed?
|
|
63
|
-
- Who has authority to propose/approve changes?
|
|
64
|
-
- What's the review/approval process for amendments?
|
|
65
|
-
- How should changes be communicated to the team?
|
|
66
|
-
|
|
67
|
-
4. For each topic:
|
|
68
|
-
- Ask ONE question at a time
|
|
69
|
-
- Discuss trade-offs when relevant
|
|
70
|
-
- Confirm understanding before moving on
|
|
71
|
-
- Record the team's decision clearly
|
|
72
|
-
|
|
73
|
-
5. **After the core topics**, ask:
|
|
74
|
-
"Are there any additional topics you'd like to establish agreements for?"
|
|
75
|
-
|
|
76
|
-
Suggest potential additional topics if helpful:
|
|
77
|
-
- **Architecture decisions** - How to document and track ADRs
|
|
78
|
-
- **Dependency management** - How to evaluate and approve new dependencies
|
|
79
|
-
- **Documentation standards** - What must be documented, where, in what format
|
|
80
|
-
- **LLM autonomy boundaries** - What can LLMs do without asking? What requires human approval?
|
|
81
|
-
- **Session handoff protocols** - How to summarize work for the next session/agent
|
|
82
|
-
- **Code review process** - What reviewers should look for, turnaround expectations
|
|
83
|
-
- **Planning and work breakdown** - How to break down work into tasks
|
|
84
|
-
- **Information sharing** - How to share context across sessions and team members
|
|
85
|
-
|
|
86
|
-
Continue asking about each additional topic the user wants to cover.
|
|
87
|
-
|
|
88
|
-
After discussing additional topics, ask: "Would you like to suggest any of these additional topics
|
|
89
|
-
(or others you thought of) to be included as standard topics in the team-agreements plugin?
|
|
90
|
-
I can file a GitHub issue for you if you'd like."
|
|
91
|
-
|
|
92
|
-
If the user wants to suggest a topic, use the \`suggest_team_agreement_topic\` tool to file an issue.
|
|
93
|
-
|
|
94
|
-
6. After ALL topics (core + additional) are covered:
|
|
95
|
-
- Generate \`docs/TEAM_AGREEMENTS.md\` with all agreements organized by topic
|
|
96
|
-
- If any topic needs detailed documentation, create supporting files in \`docs/team_agreements/\`
|
|
97
|
-
- Update \`opencode.json\` to include \`docs/TEAM_AGREEMENTS.md\` in the \`instructions\` array
|
|
98
|
-
- Summarize what was established
|
|
99
|
-
|
|
100
|
-
## Output Format
|
|
101
|
-
|
|
102
|
-
When generating the TEAM_AGREEMENTS.md file, use this structure:
|
|
103
|
-
|
|
104
|
-
\`\`\`markdown
|
|
105
|
-
# Team Agreements
|
|
106
|
-
|
|
107
|
-
This document defines how our team (humans and LLM agents) collaborates on this codebase.
|
|
108
|
-
|
|
109
|
-
## Table of Contents
|
|
110
|
-
[Generate based on topics covered]
|
|
111
|
-
|
|
112
|
-
## 1. Storage Location
|
|
113
|
-
[Agreements about where documentation lives]
|
|
114
|
-
|
|
115
|
-
## 2. Programming Languages
|
|
116
|
-
[Agreements about languages and their usage]
|
|
117
|
-
|
|
118
|
-
## 3. Code Quality Standards
|
|
119
|
-
[Agreements about what makes good code]
|
|
120
|
-
|
|
121
|
-
## 4. Commit Message Conventions
|
|
122
|
-
[Agreements about commit message format]
|
|
123
|
-
|
|
124
|
-
## 5. Integration Workflow
|
|
125
|
-
[Agreements about how code gets integrated]
|
|
126
|
-
|
|
127
|
-
## 6. Testing Requirements
|
|
128
|
-
[Agreements about testing]
|
|
129
|
-
|
|
130
|
-
## 7. Amendment Process
|
|
131
|
-
[Agreements about changing these agreements]
|
|
132
|
-
|
|
133
|
-
## Additional Topics
|
|
134
|
-
[Any additional topics the team added]
|
|
135
|
-
|
|
136
|
-
---
|
|
137
|
-
*Last updated: [date]*
|
|
138
|
-
*To amend these agreements, [process from amendment section]*
|
|
139
|
-
\`\`\`
|
|
140
|
-
|
|
141
|
-
## Important
|
|
142
|
-
|
|
143
|
-
- Be conversational and collaborative
|
|
144
|
-
- ONE question at a time - don't overwhelm
|
|
145
|
-
- Respect the user's expertise and preferences
|
|
146
|
-
- If the user provides a specific request in their message, address that first
|
|
147
|
-
- The core topics are a starting point, not an exhaustive list
|
|
148
|
-
- Capture the "why" behind decisions, not just the "what"`;
|
|
149
|
-
/**
|
|
150
|
-
* Check if a file exists at the given path.
|
|
151
|
-
*/
|
|
152
|
-
export async function fileExists(path) {
|
|
153
|
-
try {
|
|
154
|
-
await access(path);
|
|
155
|
-
return true;
|
|
156
|
-
}
|
|
157
|
-
catch {
|
|
158
|
-
return false;
|
|
159
|
-
}
|
|
160
|
-
}
|
|
161
|
-
/**
|
|
162
|
-
* Check if the gh CLI is installed and authenticated.
|
|
163
|
-
*/
|
|
164
|
-
export async function isGhAvailable() {
|
|
165
|
-
try {
|
|
166
|
-
await execAsync("gh auth status");
|
|
167
|
-
return true;
|
|
168
|
-
}
|
|
169
|
-
catch {
|
|
170
|
-
return false;
|
|
171
|
-
}
|
|
172
|
-
}
|
|
173
|
-
/**
|
|
174
|
-
* Load team agreements from the project directory.
|
|
175
|
-
* Returns the content if found, null otherwise.
|
|
176
|
-
*/
|
|
177
|
-
export async function loadTeamAgreements(directory) {
|
|
178
|
-
const defaultPath = join(directory, "docs", "TEAM_AGREEMENTS.md");
|
|
179
|
-
try {
|
|
180
|
-
const content = await readFile(defaultPath, "utf-8");
|
|
181
|
-
return `## Team Agreements\n\nThe following team agreements are in effect for this project:\n\n${content}`;
|
|
182
|
-
}
|
|
183
|
-
catch {
|
|
184
|
-
return null;
|
|
185
|
-
}
|
|
186
|
-
}
|
|
187
1
|
/**
|
|
188
|
-
*
|
|
2
|
+
* OpenCode Team Agreements Plugin
|
|
3
|
+
*
|
|
4
|
+
* Helps teams establish and maintain shared agreements for human-LLM collaboration.
|
|
5
|
+
*
|
|
6
|
+
* IMPORTANT: Only the plugin function should be exported from this module.
|
|
7
|
+
* OpenCode's plugin loader iterates through all exports and tries to call each
|
|
8
|
+
* one as a plugin function. Exporting non-function values (like strings or objects)
|
|
9
|
+
* will cause a crash.
|
|
10
|
+
*
|
|
11
|
+
* @packageDocumentation
|
|
189
12
|
*/
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
}
|
|
193
|
-
/**
|
|
194
|
-
* Build the issue body for a topic suggestion.
|
|
195
|
-
*/
|
|
196
|
-
export function buildTopicIssueBody(args) {
|
|
197
|
-
const questionsFormatted = formatQuestionsAsMarkdown(args.suggested_questions);
|
|
198
|
-
return `## Topic Name
|
|
199
|
-
${args.topic_name}
|
|
200
|
-
|
|
201
|
-
## Description
|
|
202
|
-
${args.description}
|
|
203
|
-
|
|
204
|
-
## Suggested Questions
|
|
205
|
-
${questionsFormatted}
|
|
206
|
-
|
|
207
|
-
## Example Agreement
|
|
208
|
-
${args.example_agreement || "_No example provided_"}
|
|
209
|
-
|
|
210
|
-
## Additional Context
|
|
211
|
-
_This issue was automatically created via the team-agreements plugin._`;
|
|
212
|
-
}
|
|
213
|
-
// Export constants for testing
|
|
214
|
-
export { COMMAND_TEMPLATE, PLUGIN_REPO };
|
|
13
|
+
import { tool } from "@opencode-ai/plugin";
|
|
14
|
+
import { COMMAND_TEMPLATE, PLUGIN_REPO, isGhAvailable, loadTeamAgreements, buildTopicIssueBody, detectEnforcementMechanisms, formatEnforcementResults, execAsync, } from "./utils.js";
|
|
215
15
|
/**
|
|
216
16
|
* TeamAgreementsPlugin - Helps teams establish and maintain shared agreements
|
|
217
17
|
* for human-LLM collaboration on a codebase.
|
|
18
|
+
*
|
|
19
|
+
* Team agreements are stored in AGENTS.md (or CLAUDE.md as fallback) in the
|
|
20
|
+
* project root. These files are automatically loaded by OpenCode and Claude Code,
|
|
21
|
+
* so no config injection is needed.
|
|
218
22
|
*/
|
|
219
23
|
export const TeamAgreementsPlugin = async (ctx) => {
|
|
220
24
|
const { directory } = ctx;
|
|
221
|
-
const agreementsPath = "docs/TEAM_AGREEMENTS.md";
|
|
222
|
-
const fullAgreementsPath = join(directory, agreementsPath);
|
|
223
25
|
return {
|
|
224
26
|
/**
|
|
225
|
-
*
|
|
27
|
+
* Register the /team-agreements command.
|
|
28
|
+
* Note: We no longer inject AGENTS.md into instructions because OpenCode
|
|
29
|
+
* automatically loads it from the project root.
|
|
226
30
|
*/
|
|
227
31
|
config: async (config) => {
|
|
228
32
|
// Add the /team-agreements command
|
|
@@ -233,21 +37,27 @@ export const TeamAgreementsPlugin = async (ctx) => {
|
|
|
233
37
|
description: "Establish or review team agreements for human-LLM collaboration",
|
|
234
38
|
template: COMMAND_TEMPLATE,
|
|
235
39
|
};
|
|
236
|
-
// If agreements file exists, ensure it's in instructions
|
|
237
|
-
if (await fileExists(fullAgreementsPath)) {
|
|
238
|
-
if (!config.instructions) {
|
|
239
|
-
config.instructions = [];
|
|
240
|
-
}
|
|
241
|
-
const instructions = config.instructions;
|
|
242
|
-
if (!instructions.includes(agreementsPath)) {
|
|
243
|
-
instructions.unshift(agreementsPath); // Add at beginning for priority
|
|
244
|
-
}
|
|
245
|
-
}
|
|
246
40
|
},
|
|
247
41
|
/**
|
|
248
|
-
*
|
|
42
|
+
* Tools for team agreements management
|
|
249
43
|
*/
|
|
250
44
|
tool: {
|
|
45
|
+
/**
|
|
46
|
+
* Detect existing enforcement mechanisms in the project
|
|
47
|
+
*/
|
|
48
|
+
detect_enforcement_mechanisms: tool({
|
|
49
|
+
description: "Detect existing enforcement mechanisms in the project (pre-commit hooks, CI workflows, " +
|
|
50
|
+
"linters, formatters, etc.). Use this before offering to set up enforcement for team agreements " +
|
|
51
|
+
"to understand what's already in place and avoid duplicating or conflicting with existing tooling.",
|
|
52
|
+
args: {},
|
|
53
|
+
async execute() {
|
|
54
|
+
const mechanisms = await detectEnforcementMechanisms(directory);
|
|
55
|
+
return formatEnforcementResults(mechanisms);
|
|
56
|
+
},
|
|
57
|
+
}),
|
|
58
|
+
/**
|
|
59
|
+
* Suggest a new topic for the team-agreements plugin
|
|
60
|
+
*/
|
|
251
61
|
suggest_team_agreement_topic: tool({
|
|
252
62
|
description: "Suggest a new topic to be added to the team-agreements plugin. " +
|
|
253
63
|
"This will file a GitHub issue on the plugin repository. " +
|
package/dist/index.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAe,IAAI,EAAE,MAAM,qBAAqB,CAAA;
|
|
1
|
+
{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,OAAO,EAAe,IAAI,EAAE,MAAM,qBAAqB,CAAA;AAEvD,OAAO,EACL,gBAAgB,EAChB,WAAW,EACX,aAAa,EACb,kBAAkB,EAClB,mBAAmB,EACnB,2BAA2B,EAC3B,wBAAwB,EACxB,SAAS,GACV,MAAM,YAAY,CAAA;AAEnB;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,oBAAoB,GAAW,KAAK,EAAE,GAAG,EAAE,EAAE;IACxD,MAAM,EAAE,SAAS,EAAE,GAAG,GAAG,CAAA;IAEzB,OAAO;QACL;;;;WAIG;QACH,MAAM,EAAE,KAAK,EAAE,MAAM,EAAE,EAAE;YACvB,mCAAmC;YACnC,IAAI,CAAC,MAAM,CAAC,OAAO,EAAE,CAAC;gBACnB,MAAc,CAAC,OAAO,GAAG,EAAE,CAAA;YAC9B,CAAC;YACA,MAAc,CAAC,OAAO,CAAC,iBAAiB,CAAC,GAAG;gBAC3C,WAAW,EAAE,iEAAiE;gBAC9E,QAAQ,EAAE,gBAAgB;aAC3B,CAAA;QACH,CAAC;QAED;;WAEG;QACH,IAAI,EAAE;YACJ;;eAEG;YACH,6BAA6B,EAAE,IAAI,CAAC;gBAClC,WAAW,EACT,yFAAyF;oBACzF,iGAAiG;oBACjG,mGAAmG;gBACrG,IAAI,EAAE,EAAE;gBACR,KAAK,CAAC,OAAO;oBACX,MAAM,UAAU,GAAG,MAAM,2BAA2B,CAAC,SAAS,CAAC,CAAA;oBAC/D,OAAO,wBAAwB,CAAC,UAAU,CAAC,CAAA;gBAC7C,CAAC;aACF,CAAC;YAEF;;eAEG;YACH,4BAA4B,EAAE,IAAI,CAAC;gBACjC,WAAW,EACT,iEAAiE;oBACjE,0DAA0D;oBAC1D,wDAAwD;gBAC1D,IAAI,EAAE;oBACJ,UAAU,EAAE,IAAI,CAAC,MAAM;yBACpB,MAAM,EAAE;yBACR,QAAQ,CAAC,mDAAmD,CAAC;oBAChE,WAAW,EAAE,IAAI,CAAC,MAAM;yBACrB,MAAM,EAAE;yBACR,QAAQ,CACP,kFAAkF,CACnF;oBACH,mBAAmB,EAAE,IAAI,CAAC,MAAM;yBAC7B,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC;yBAC3B,QAAQ,CACP,oFAAoF,CACrF;oBACH,iBAAiB,EAAE,IAAI,CAAC,MAAM;yBAC3B,MAAM,EAAE;yBACR,QAAQ,EAAE;yBACV,QAAQ,CAAC,0EAA0E,CAAC;iBACxF;gBACD,KAAK,CAAC,OAAO,CAAC,IAAI;oBAChB,2BAA2B;oBAC3B,IAAI,CAAC,CAAC,MAAM,aAAa,EAAE,CAAC,EAAE,CAAC;wBAC7B,OAAO,CACL,oDAAoD;4BACpD,yEAAyE;4BACzE,gCAAgC;4BAChC,sBAAsB,WAAW,0CAA0C,CAC5E,CAAA;oBACH,CAAC;oBAED,MAAM,IAAI,GAAG,mBAAmB,CAAC,IAAI,CAAC,CAAA;oBAEtC,IAAI,CAAC;wBACH,MAAM,KAAK,GAAG,WAAW,IAAI,CAAC,UAAU,EAAE,CAAA;wBAC1C,MAAM,EAAE,MAAM,EAAE,GAAG,MAAM,SAAS,CAChC,2BAA2B,WAAW,cAAc,KAAK,CAAC,OAAO,CAAC,IAAI,EAAE,KAAK,CAAC,aAAa,IAAI,CAAC,OAAO,CAAC,IAAI,EAAE,KAAK,CAAC,CAAC,OAAO,CAAC,KAAK,EAAE,KAAK,CAAC,0CAA0C,CACrL,CAAA;wBACD,OAAO,+BAA+B,MAAM,CAAC,IAAI,EAAE,EAAE,CAAA;oBACvD,CAAC;oBAAC,OAAO,KAAK,EAAE,CAAC;wBACf,OAAO,2BAA2B,KAAK,sDAAsD,WAAW,0CAA0C,CAAA;oBACpJ,CAAC;gBACH,CAAC;aACF,CAAC;SACH;QAED;;;;WAIG;QACH,iCAAiC,EAAE,KAAK,EAAE,MAAM,EAAE,MAAM,EAAE,EAAE;YAC1D,MAAM,UAAU,GAAG,MAAM,kBAAkB,CAAC,SAAS,CAAC,CAAA;YACtD,IAAI,UAAU,EAAE,CAAC;gBACf,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC,UAAU,CAAC,CAAA;YACjC,CAAC;QACH,CAAC;KACF,CAAA;AACH,CAAC,CAAA;AAED,eAAe,oBAAoB,CAAA"}
|