opencode-plugin-team-agreements 0.1.4 → 0.2.0

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## [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)
+
+
+### ⚠ BREAKING CHANGES
+
+* Team agreements are now stored in AGENTS.md (or CLAUDE.md as fallback) in the project root instead of docs/TEAM_AGREEMENTS.md
+
+### Features
+
+* 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))
+
+
+### Bug Fixes
+
+* 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))
+
 ## [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)
 
 

package/dist/index.d.ts

@@ -1,54 +1,23 @@
-import { type Plugin } from "@opencode-ai/plugin";
-declare const PLUGIN_REPO = "jwilger/opencode-plugin-team-agreements";
-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\n7. **After generating the agreements**, use the `detect_enforcement_mechanisms` tool to check what enforcement is already in place, then offer to set up automatic enforcement for agreements that can be enforced programmatically.\n\n   For each agreement that CAN be automatically enforced, ask the user if they'd like help setting it up. Here are the enforcement mechanisms to consider:\n\n   ### Enforcement Mechanisms\n\n   #### OpenCode Plugin Hooks\n   Ideal for: LLM behavior guidance, context injection, custom commands\n   - Can add validation in `tool.execute.before` hooks\n   - Can transform messages via `experimental.chat.messages.transform`\n   - Can inject reminders in `experimental.session.compacting`\n\n   #### Pre-commit Hooks (husky, lefthook, pre-commit)\n   Ideal for: Commit message validation, code formatting, linting, test execution\n   - **Commit messages**: Use commitlint with husky for Conventional Commits or custom formats\n   - **Code formatting**: Run prettier/eslint/biome on staged files\n   - **Tests**: Run affected tests before allowing commits\n   - **File restrictions**: Prevent commits to certain paths\n\n   #### CI Workflows (GitHub Actions, etc.)\n   Ideal for: Test coverage, build verification, security scanning, PR checks\n   - **Testing requirements**: Enforce coverage thresholds, run full test suites\n   - **Code quality**: Run linters, type checking, security audits\n   - **Build verification**: Ensure the project builds successfully\n   - **PR requirements**: Block merging until checks pass\n\n   #### GitHub Rulesets / Branch Protection\n   Ideal for: PR requirements, review policies, merge restrictions\n   - **Required reviews**: Set minimum approvals before merge\n   - **Required checks**: Specify which CI checks must pass\n   - **Branch restrictions**: Control who can push to main/protected branches\n   - **Commit signing**: Require verified commits\n\n   #### Linting Rules (.eslintrc, biome.json, etc.)\n   Ideal for: Code style, naming conventions, import organization, complexity limits\n   - **Naming conventions**: Enforce variable/function/file naming patterns\n   - **Code patterns**: Require/forbid certain coding patterns\n   - **Import organization**: Enforce import ordering and restrictions\n\n   ### Mapping Agreements to Enforcement\n\n   | Agreement Topic | Possible Enforcement |\n   |-----------------|---------------------|\n   | Commit message conventions | commitlint + husky, GitHub Actions check |\n   | Code quality standards | ESLint/Biome rules, pre-commit hooks, CI checks |\n   | Testing requirements | CI workflow with coverage thresholds, pre-commit test runs |\n   | Integration workflow | GitHub rulesets, required status checks, PR templates |\n   | Programming language standards | Language-specific linters, compiler flags |\n\n   ### When Offering Enforcement\n\n   - Only offer enforcement for agreements that can actually be automated\n   - Explain what the enforcement will do and how it works\n   - Get explicit confirmation before making changes\n   - If enforcement tooling already exists (detected by the tool), offer to update/extend it rather than replace it\n   - Document what enforcement was set up in the TEAM_AGREEMENTS.md file\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\"";
-/**
- * Check if a file exists at the given path.
- */
-export declare function fileExists(path: string): Promise<boolean>;
-/**
- * Check if the gh CLI is installed and authenticated.
- */
-export declare function isGhAvailable(): Promise<boolean>;
-/**
- * Load team agreements from the project directory.
- * Returns the content if found, null otherwise.
- */
-export declare function loadTeamAgreements(directory: string): Promise<string | null>;
-/**
- * Format suggested questions as a markdown list.
- */
-export declare function formatQuestionsAsMarkdown(questions: string[]): string;
-/**
- * Build the issue body for a topic suggestion.
- */
-export declare function buildTopicIssueBody(args: {
-    topic_name: string;
-    description: string;
-    suggested_questions: string[];
-    example_agreement?: string;
-}): string;
-/**
- * Enforcement mechanism detection result.
- */
-export interface EnforcementMechanism {
-    type: string;
-    name: string;
-    detected: boolean;
-    configFile?: string;
-    notes?: string;
-}
-/**
- * Detect existing enforcement mechanisms in the project.
- */
-export declare function detectEnforcementMechanisms(directory: string): Promise<EnforcementMechanism[]>;
 /**
- * Format enforcement detection results as markdown.
+ * OpenCode Team Agreements Plugin
+ *
+ * Helps teams establish and maintain shared agreements for human-LLM collaboration.
+ *
+ * IMPORTANT: Only the plugin function should be exported from this module.
+ * OpenCode's plugin loader iterates through all exports and tries to call each
+ * one as a plugin function. Exporting non-function values (like strings or objects)
+ * will cause a crash.
+ *
+ * @packageDocumentation
  */
-export declare function formatEnforcementResults(mechanisms: EnforcementMechanism[]): string;
-export { COMMAND_TEMPLATE, PLUGIN_REPO };
+import { type Plugin } from "@opencode-ai/plugin";
 /**
  * TeamAgreementsPlugin - Helps teams establish and maintain shared agreements
  * for human-LLM collaboration on a codebase.
+ *
+ * Team agreements are stored in AGENTS.md (or CLAUDE.md as fallback) in the
+ * project root. These files are automatically loaded by OpenCode and Claude Code,
+ * so no config injection is needed.
  */
 export declare const TeamAgreementsPlugin: Plugin;
 export default TeamAgreementsPlugin;

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,MAAM,EAAQ,MAAM,qBAAqB,CAAA;AAQvD,QAAA,MAAM,WAAW,4CAA4C,CAAA;AAE7D,QAAA,MAAM,gBAAgB,4pRAqMoC,CAAA;AAE1D;;GAEG;AACH,wBAAsB,UAAU,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC,CAO/D;AAED;;GAEG;AACH,wBAAsB,aAAa,IAAI,OAAO,CAAC,OAAO,CAAC,CAOtD;AAED;;;GAGG;AACH,wBAAsB,kBAAkB,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,GAAG,IAAI,CAAC,CASlF;AAED;;GAEG;AACH,wBAAgB,yBAAyB,CAAC,SAAS,EAAE,MAAM,EAAE,GAAG,MAAM,CAErE;AAED;;GAEG;AACH,wBAAgB,mBAAmB,CAAC,IAAI,EAAE;IACxC,UAAU,EAAE,MAAM,CAAA;IAClB,WAAW,EAAE,MAAM,CAAA;IACnB,mBAAmB,EAAE,MAAM,EAAE,CAAA;IAC7B,iBAAiB,CAAC,EAAE,MAAM,CAAA;CAC3B,GAAG,MAAM,CAiBT;AAED;;GAEG;AACH,MAAM,WAAW,oBAAoB;IACnC,IAAI,EAAE,MAAM,CAAA;IACZ,IAAI,EAAE,MAAM,CAAA;IACZ,QAAQ,EAAE,OAAO,CAAA;IACjB,UAAU,CAAC,EAAE,MAAM,CAAA;IACnB,KAAK,CAAC,EAAE,MAAM,CAAA;CACf;AAED;;GAEG;AACH,wBAAsB,2BAA2B,CAC/C,SAAS,EAAE,MAAM,GAChB,OAAO,CAAC,oBAAoB,EAAE,CAAC,CA2LjC;AAED;;GAEG;AACH,wBAAgB,wBAAwB,CAAC,UAAU,EAAE,oBAAoB,EAAE,GAAG,MAAM,CAkEnF;AAGD,OAAO,EAAE,gBAAgB,EAAE,WAAW,EAAE,CAAA;AAExC;;;GAGG;AACH,eAAO,MAAM,oBAAoB,EAAE,MAmHlC,CAAA;AAED,eAAe,oBAAoB,CAAA"}
+{"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

@@ -1,522 +1,32 @@
-import { tool } from "@opencode-ai/plugin";
-import { readFile, access } from "fs/promises";
-import { join } from "path";
-import { exec } from "child_process";
-import { promisify } from "util";
-const execAsync = promisify(exec);
-const PLUGIN_REPO = "jwilger/opencode-plugin-team-agreements";
-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.
-
-User's request: $ARGUMENTS
-
-## Instructions
-
-1. First, check if team agreements already exist at \`docs/TEAM_AGREEMENTS.md\`
-
-2. If agreements exist, present the user with options:
-   - **Review**: Display the current agreements
-   - **Amend**: Modify a specific section  
-   - **Start Over**: Begin fresh (with confirmation)
-
-3. If no agreements exist (or starting over), guide the user through establishing agreements one topic at a time. Start with these core topics:
-
-### Core Topics
-
-#### a. Storage Location
-Ask where team agreements should be stored. Suggest defaults:
-- Main file: \`docs/TEAM_AGREEMENTS.md\`
-- Supporting details: \`docs/team_agreements/*.md\`
-
-#### b. Programming Languages
-- What programming language(s) will be used in this project?
-- What is each language used for? (e.g., TypeScript for frontend, Rust for backend)
-- Are there specific versions or language-specific style guides to follow?
-
-#### c. Code Quality Standards
-- What does "great code" look like for this team?
-- How should we prioritize: readability vs. performance vs. simplicity?
-- Are there required patterns or anti-patterns to follow/avoid?
-- What about error handling conventions?
-- Naming conventions for files, functions, variables, types?
-
-#### d. Commit Message Conventions
-- What format should commit messages follow? (Conventional Commits, custom, freeform)
-- Are there required elements? (ticket numbers, scope, breaking change indicators)
-- Any rules on length, tense, capitalization?
-- Should commits be atomic (one logical change per commit)?
-
-#### e. Integration Workflow
-- Trunk-based development or feature branches?
-- Pull request requirements? (reviews, approvals, CI checks)
-- Who can merge to main/trunk?
-- What CI checks must pass before integration?
-- Any branch naming conventions?
-
-#### f. Testing Requirements
-- What testing is required before code is considered "done"?
-- Are there coverage thresholds?
-- What types of tests? (unit, integration, e2e, property-based)
-- When should tests be written? (TDD, after implementation, etc.)
-
-#### g. Amendment Process
-- How can these agreements be changed?
-- Who has authority to propose/approve changes?
-- What's the review/approval process for amendments?
-- How should changes be communicated to the team?
-
-4. For each topic:
-   - Ask ONE question at a time
-   - Discuss trade-offs when relevant
-   - Confirm understanding before moving on
-   - Record the team's decision clearly
-
-5. **After the core topics**, ask:
-   "Are there any additional topics you'd like to establish agreements for?"
-   
-   Suggest potential additional topics if helpful:
-   - **Architecture decisions** - How to document and track ADRs
-   - **Dependency management** - How to evaluate and approve new dependencies
-   - **Documentation standards** - What must be documented, where, in what format
-   - **LLM autonomy boundaries** - What can LLMs do without asking? What requires human approval?
-   - **Session handoff protocols** - How to summarize work for the next session/agent
-   - **Code review process** - What reviewers should look for, turnaround expectations
-   - **Planning and work breakdown** - How to break down work into tasks
-   - **Information sharing** - How to share context across sessions and team members
-   
-   Continue asking about each additional topic the user wants to cover.
-   
-   After discussing additional topics, ask: "Would you like to suggest any of these additional topics
-   (or others you thought of) to be included as standard topics in the team-agreements plugin?
-   I can file a GitHub issue for you if you'd like."
-   
-   If the user wants to suggest a topic, use the \`suggest_team_agreement_topic\` tool to file an issue.
-
-6. After ALL topics (core + additional) are covered:
-   - Generate \`docs/TEAM_AGREEMENTS.md\` with all agreements organized by topic
-   - If any topic needs detailed documentation, create supporting files in \`docs/team_agreements/\`
-   - Update \`opencode.json\` to include \`docs/TEAM_AGREEMENTS.md\` in the \`instructions\` array
-   - Summarize what was established
-
-7. **After generating the agreements**, use the \`detect_enforcement_mechanisms\` tool to check what enforcement is already in place, then offer to set up automatic enforcement for agreements that can be enforced programmatically.
-
-   For each agreement that CAN be automatically enforced, ask the user if they'd like help setting it up. Here are the enforcement mechanisms to consider:
-
-   ### Enforcement Mechanisms
-
-   #### OpenCode Plugin Hooks
-   Ideal for: LLM behavior guidance, context injection, custom commands
-   - Can add validation in \`tool.execute.before\` hooks
-   - Can transform messages via \`experimental.chat.messages.transform\`
-   - Can inject reminders in \`experimental.session.compacting\`
-
-   #### Pre-commit Hooks (husky, lefthook, pre-commit)
-   Ideal for: Commit message validation, code formatting, linting, test execution
-   - **Commit messages**: Use commitlint with husky for Conventional Commits or custom formats
-   - **Code formatting**: Run prettier/eslint/biome on staged files
-   - **Tests**: Run affected tests before allowing commits
-   - **File restrictions**: Prevent commits to certain paths
-
-   #### CI Workflows (GitHub Actions, etc.)
-   Ideal for: Test coverage, build verification, security scanning, PR checks
-   - **Testing requirements**: Enforce coverage thresholds, run full test suites
-   - **Code quality**: Run linters, type checking, security audits
-   - **Build verification**: Ensure the project builds successfully
-   - **PR requirements**: Block merging until checks pass
-
-   #### GitHub Rulesets / Branch Protection
-   Ideal for: PR requirements, review policies, merge restrictions
-   - **Required reviews**: Set minimum approvals before merge
-   - **Required checks**: Specify which CI checks must pass
-   - **Branch restrictions**: Control who can push to main/protected branches
-   - **Commit signing**: Require verified commits
-
-   #### Linting Rules (.eslintrc, biome.json, etc.)
-   Ideal for: Code style, naming conventions, import organization, complexity limits
-   - **Naming conventions**: Enforce variable/function/file naming patterns
-   - **Code patterns**: Require/forbid certain coding patterns
-   - **Import organization**: Enforce import ordering and restrictions
-
-   ### Mapping Agreements to Enforcement
-
-   | Agreement Topic | Possible Enforcement |
-   |-----------------|---------------------|
-   | Commit message conventions | commitlint + husky, GitHub Actions check |
-   | Code quality standards | ESLint/Biome rules, pre-commit hooks, CI checks |
-   | Testing requirements | CI workflow with coverage thresholds, pre-commit test runs |
-   | Integration workflow | GitHub rulesets, required status checks, PR templates |
-   | Programming language standards | Language-specific linters, compiler flags |
-
-   ### When Offering Enforcement
-
-   - Only offer enforcement for agreements that can actually be automated
-   - Explain what the enforcement will do and how it works
-   - Get explicit confirmation before making changes
-   - If enforcement tooling already exists (detected by the tool), offer to update/extend it rather than replace it
-   - Document what enforcement was set up in the TEAM_AGREEMENTS.md file
-
-## Output Format
-
-When generating the TEAM_AGREEMENTS.md file, use this structure:
-
-\`\`\`markdown
-# Team Agreements
-
-This document defines how our team (humans and LLM agents) collaborates on this codebase.
-
-## Table of Contents
-[Generate based on topics covered]
-
-## 1. Storage Location
-[Agreements about where documentation lives]
-
-## 2. Programming Languages
-[Agreements about languages and their usage]
-
-## 3. Code Quality Standards
-[Agreements about what makes good code]
-
-## 4. Commit Message Conventions
-[Agreements about commit message format]
-
-## 5. Integration Workflow
-[Agreements about how code gets integrated]
-
-## 6. Testing Requirements
-[Agreements about testing]
-
-## 7. Amendment Process
-[Agreements about changing these agreements]
-
-## Additional Topics
-[Any additional topics the team added]
-
----
-*Last updated: [date]*
-*To amend these agreements, [process from amendment section]*
-\`\`\`
-
-## Important
-
-- Be conversational and collaborative
-- ONE question at a time - don't overwhelm
-- Respect the user's expertise and preferences
-- If the user provides a specific request in their message, address that first
-- The core topics are a starting point, not an exhaustive list
-- Capture the "why" behind decisions, not just the "what"`;
-/**
- * Check if a file exists at the given path.
- */
-export async function fileExists(path) {
-    try {
-        await access(path);
-        return true;
-    }
-    catch {
-        return false;
-    }
-}
-/**
- * Check if the gh CLI is installed and authenticated.
- */
-export async function isGhAvailable() {
-    try {
-        await execAsync("gh auth status");
-        return true;
-    }
-    catch {
-        return false;
-    }
-}
-/**
- * Load team agreements from the project directory.
- * Returns the content if found, null otherwise.
- */
-export async function loadTeamAgreements(directory) {
-    const defaultPath = join(directory, "docs", "TEAM_AGREEMENTS.md");
-    try {
-        const content = await readFile(defaultPath, "utf-8");
-        return `## Team Agreements\n\nThe following team agreements are in effect for this project:\n\n${content}`;
-    }
-    catch {
-        return null;
-    }
-}
-/**
- * Format suggested questions as a markdown list.
- */
-export function formatQuestionsAsMarkdown(questions) {
-    return questions.map((q) => `- ${q}`).join("\n");
-}
-/**
- * Build the issue body for a topic suggestion.
- */
-export function buildTopicIssueBody(args) {
-    const questionsFormatted = formatQuestionsAsMarkdown(args.suggested_questions);
-    return `## Topic Name
-${args.topic_name}
-
-## Description
-${args.description}
-
-## Suggested Questions
-${questionsFormatted}
-
-## Example Agreement
-${args.example_agreement || "_No example provided_"}
-
-## Additional Context
-_This issue was automatically created via the team-agreements plugin._`;
-}
-/**
- * Detect existing enforcement mechanisms in the project.
- */
-export async function detectEnforcementMechanisms(directory) {
-    const mechanisms = [];
-    // Pre-commit hooks
-    const huskyPath = join(directory, ".husky");
-    const lefthookPath = join(directory, "lefthook.yml");
-    const lefthookAltPath = join(directory, ".lefthook.yml");
-    const preCommitPath = join(directory, ".pre-commit-config.yaml");
-    if (await fileExists(huskyPath)) {
-        mechanisms.push({
-            type: "pre-commit",
-            name: "husky",
-            detected: true,
-            configFile: ".husky/",
-            notes: "Git hooks manager for Node.js projects",
-        });
-    }
-    if (await fileExists(lefthookPath)) {
-        mechanisms.push({
-            type: "pre-commit",
-            name: "lefthook",
-            detected: true,
-            configFile: "lefthook.yml",
-            notes: "Fast, cross-platform git hooks manager",
-        });
-    }
-    else if (await fileExists(lefthookAltPath)) {
-        mechanisms.push({
-            type: "pre-commit",
-            name: "lefthook",
-            detected: true,
-            configFile: ".lefthook.yml",
-            notes: "Fast, cross-platform git hooks manager",
-        });
-    }
-    if (await fileExists(preCommitPath)) {
-        mechanisms.push({
-            type: "pre-commit",
-            name: "pre-commit",
-            detected: true,
-            configFile: ".pre-commit-config.yaml",
-            notes: "Python-based pre-commit framework",
-        });
-    }
-    // Commit message validation
-    const commitlintPath = join(directory, "commitlint.config.js");
-    const commitlintCjsPath = join(directory, "commitlint.config.cjs");
-    const commitlintJsonPath = join(directory, ".commitlintrc.json");
-    if ((await fileExists(commitlintPath)) ||
-        (await fileExists(commitlintCjsPath)) ||
-        (await fileExists(commitlintJsonPath))) {
-        mechanisms.push({
-            type: "commit-validation",
-            name: "commitlint",
-            detected: true,
-            configFile: (await fileExists(commitlintPath))
-                ? "commitlint.config.js"
-                : (await fileExists(commitlintCjsPath))
-                    ? "commitlint.config.cjs"
-                    : ".commitlintrc.json",
-            notes: "Lint commit messages against conventional commit format",
-        });
-    }
-    // Linters
-    const eslintPath = join(directory, ".eslintrc.json");
-    const eslintJsPath = join(directory, "eslint.config.js");
-    const eslintMjsPath = join(directory, "eslint.config.mjs");
-    const biomePath = join(directory, "biome.json");
-    const biomeJsoncPath = join(directory, "biome.jsonc");
-    if ((await fileExists(eslintPath)) ||
-        (await fileExists(eslintJsPath)) ||
-        (await fileExists(eslintMjsPath))) {
-        mechanisms.push({
-            type: "linter",
-            name: "eslint",
-            detected: true,
-            configFile: (await fileExists(eslintPath))
-                ? ".eslintrc.json"
-                : (await fileExists(eslintJsPath))
-                    ? "eslint.config.js"
-                    : "eslint.config.mjs",
-            notes: "JavaScript/TypeScript linter",
-        });
-    }
-    if ((await fileExists(biomePath)) || (await fileExists(biomeJsoncPath))) {
-        mechanisms.push({
-            type: "linter",
-            name: "biome",
-            detected: true,
-            configFile: (await fileExists(biomePath)) ? "biome.json" : "biome.jsonc",
-            notes: "Fast formatter and linter for JS/TS/JSON",
-        });
-    }
-    // CI Workflows
-    const githubWorkflowsPath = join(directory, ".github", "workflows");
-    if (await fileExists(githubWorkflowsPath)) {
-        mechanisms.push({
-            type: "ci",
-            name: "github-actions",
-            detected: true,
-            configFile: ".github/workflows/",
-            notes: "GitHub Actions CI/CD workflows",
-        });
-    }
-    const gitlabCiPath = join(directory, ".gitlab-ci.yml");
-    if (await fileExists(gitlabCiPath)) {
-        mechanisms.push({
-            type: "ci",
-            name: "gitlab-ci",
-            detected: true,
-            configFile: ".gitlab-ci.yml",
-            notes: "GitLab CI/CD pipeline",
-        });
-    }
-    const circleCiPath = join(directory, ".circleci", "config.yml");
-    if (await fileExists(circleCiPath)) {
-        mechanisms.push({
-            type: "ci",
-            name: "circleci",
-            detected: true,
-            configFile: ".circleci/config.yml",
-            notes: "CircleCI pipeline",
-        });
-    }
-    // PR Templates
-    const prTemplatePath = join(directory, ".github", "pull_request_template.md");
-    const prTemplateAltPath = join(directory, ".github", "PULL_REQUEST_TEMPLATE.md");
-    if ((await fileExists(prTemplatePath)) || (await fileExists(prTemplateAltPath))) {
-        mechanisms.push({
-            type: "pr-template",
-            name: "github-pr-template",
-            detected: true,
-            configFile: (await fileExists(prTemplatePath))
-                ? ".github/pull_request_template.md"
-                : ".github/PULL_REQUEST_TEMPLATE.md",
-            notes: "GitHub Pull Request template",
-        });
-    }
-    // OpenCode configuration
-    const opencodePath = join(directory, "opencode.json");
-    if (await fileExists(opencodePath)) {
-        mechanisms.push({
-            type: "opencode",
-            name: "opencode-config",
-            detected: true,
-            configFile: "opencode.json",
-            notes: "OpenCode configuration with hooks and plugins",
-        });
-    }
-    // Formatters
-    const prettierPath = join(directory, ".prettierrc");
-    const prettierJsonPath = join(directory, ".prettierrc.json");
-    const prettierJsPath = join(directory, "prettier.config.js");
-    if ((await fileExists(prettierPath)) ||
-        (await fileExists(prettierJsonPath)) ||
-        (await fileExists(prettierJsPath))) {
-        mechanisms.push({
-            type: "formatter",
-            name: "prettier",
-            detected: true,
-            configFile: (await fileExists(prettierPath))
-                ? ".prettierrc"
-                : (await fileExists(prettierJsonPath))
-                    ? ".prettierrc.json"
-                    : "prettier.config.js",
-            notes: "Code formatter for JS/TS/CSS/HTML/JSON/MD",
-        });
-    }
-    return mechanisms;
-}
 /**
- * Format enforcement detection results as markdown.
+ * OpenCode Team Agreements Plugin
+ *
+ * Helps teams establish and maintain shared agreements for human-LLM collaboration.
+ *
+ * IMPORTANT: Only the plugin function should be exported from this module.
+ * OpenCode's plugin loader iterates through all exports and tries to call each
+ * one as a plugin function. Exporting non-function values (like strings or objects)
+ * will cause a crash.
+ *
+ * @packageDocumentation
  */
-export function formatEnforcementResults(mechanisms) {
-    if (mechanisms.length === 0) {
-        return `## Detected Enforcement Mechanisms
-
-No existing enforcement mechanisms detected. This is a great opportunity to set up automation for your team agreements!
-
-### Available Options
-
-You can set up any of the following:
-
-**Pre-commit Hooks**
-- husky (Node.js projects)
-- lefthook (cross-platform, fast)
-- pre-commit (Python-based, language-agnostic)
-
-**Commit Message Validation**
-- commitlint (conventional commits)
-
-**Linting/Formatting**
-- ESLint (JavaScript/TypeScript)
-- Biome (JS/TS/JSON, fast)
-- Prettier (formatting)
-
-**CI/CD**
-- GitHub Actions
-- GitLab CI
-- CircleCI
-
-**GitHub Features**
-- Pull Request templates
-- Branch protection rulesets`;
-    }
-    const byType = {};
-    for (const m of mechanisms) {
-        if (!byType[m.type])
-            byType[m.type] = [];
-        byType[m.type].push(m);
-    }
-    let result = `## Detected Enforcement Mechanisms
-
-The following enforcement mechanisms are already in place:\n\n`;
-    const typeLabels = {
-        "pre-commit": "Pre-commit Hooks",
-        "commit-validation": "Commit Message Validation",
-        linter: "Linters",
-        ci: "CI/CD Pipelines",
-        "pr-template": "PR Templates",
-        opencode: "OpenCode Configuration",
-        formatter: "Formatters",
-    };
-    for (const [type, mechs] of Object.entries(byType)) {
-        result += `### ${typeLabels[type] || type}\n\n`;
-        for (const m of mechs) {
-            result += `- **${m.name}** (\`${m.configFile}\`): ${m.notes}\n`;
-        }
-        result += "\n";
-    }
-    result += `### Recommendations
-
-Based on what's already set up, consider extending or integrating with these existing tools rather than adding new ones.`;
-    return result;
-}
-// Export constants for testing
-export { COMMAND_TEMPLATE, PLUGIN_REPO };
+import { tool } from "@opencode-ai/plugin";
+import { COMMAND_TEMPLATE, PLUGIN_REPO, isGhAvailable, loadTeamAgreements, buildTopicIssueBody, detectEnforcementMechanisms, formatEnforcementResults, execAsync, } from "./utils.js";
 /**
  * TeamAgreementsPlugin - Helps teams establish and maintain shared agreements
  * for human-LLM collaboration on a codebase.
+ *
+ * Team agreements are stored in AGENTS.md (or CLAUDE.md as fallback) in the
+ * project root. These files are automatically loaded by OpenCode and Claude Code,
+ * so no config injection is needed.
  */
 export const TeamAgreementsPlugin = async (ctx) => {
     const { directory } = ctx;
-    const agreementsPath = "docs/TEAM_AGREEMENTS.md";
-    const fullAgreementsPath = join(directory, agreementsPath);
     return {
         /**
-         * Inject command definition and ensure agreements are in instructions
+         * Register the /team-agreements command.
+         * Note: We no longer inject AGENTS.md into instructions because OpenCode
+         * automatically loads it from the project root.
          */
         config: async (config) => {
             // Add the /team-agreements command
@@ -527,16 +37,6 @@ export const TeamAgreementsPlugin = async (ctx) => {
                 description: "Establish or review team agreements for human-LLM collaboration",
                 template: COMMAND_TEMPLATE,
             };
-            // If agreements file exists, ensure it's in instructions
-            if (await fileExists(fullAgreementsPath)) {
-                if (!config.instructions) {
-                    config.instructions = [];
-                }
-                const instructions = config.instructions;
-                if (!instructions.includes(agreementsPath)) {
-                    instructions.unshift(agreementsPath); // Add at beginning for priority
-                }
-            }
         },
         /**
          * Tools for team agreements management