From 76563ec2c7ff24c046f244280421d5797ce6909d Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Fri, 22 May 2026 10:07:28 +0700 Subject: [PATCH 01/11] refactor(config): restructure opencode config and clean up obsolete files --- AGENTS.md | 89 ++- README.md | 31 +- agent/core/openagent.md | 677 ----------------- agent/core/opencoder.md | 501 ------------ agent/subagents/core/contextscout.md | 4 +- command/add-context.md | 921 ----------------------- command/analyze-patterns.md | 221 ------ command/clean.md | 76 -- command/commit.md | 160 ---- command/context.md | 309 -------- command/openagents/check-context-deps.md | 433 ----------- command/optimize.md | 190 ----- command/test.md | 26 - command/validate-repo.md | 347 --------- commands/add-context.md | 26 + commands/analyze-patterns.md | 26 + commands/clean.md | 19 + commands/commit.md | 72 ++ commands/context.md | 26 + commands/fix.md | 30 + commands/git-commit.md | 43 -- commands/optimize.md | 19 + commands/pr.md | 80 ++ commands/review.md | 43 ++ commands/spec.md | 36 + commands/test.md | 19 + config/agent-metadata.json | 363 --------- context/core/navigation.md | 1 - context/navigation.md | 7 +- opencode.json | 156 ++-- 30 files changed, 587 insertions(+), 4364 deletions(-) delete mode 100644 agent/core/openagent.md delete mode 100644 agent/core/opencoder.md delete mode 100644 command/add-context.md delete mode 100644 command/analyze-patterns.md delete mode 100644 command/clean.md delete mode 100644 command/commit.md delete mode 100644 command/context.md delete mode 100644 command/openagents/check-context-deps.md delete mode 100644 command/optimize.md delete mode 100644 command/test.md delete mode 100644 command/validate-repo.md create mode 100644 commands/add-context.md create mode 100644 commands/analyze-patterns.md create mode 100644 commands/clean.md create mode 100644 commands/commit.md create mode 100644 commands/context.md create mode 100644 commands/fix.md delete mode 100644 commands/git-commit.md create mode 100644 commands/optimize.md create mode 100644 commands/pr.md create mode 100644 commands/review.md create mode 100644 commands/spec.md create mode 100644 commands/test.md delete mode 100644 config/agent-metadata.json diff --git a/AGENTS.md b/AGENTS.md index f7d26be..b06bb30 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -13,7 +13,7 @@ This document outlines the standards and best practices for designing and implem - Design interactions that prioritize user needs and preferences. - Provide options for users to customize their experience with the AI agent. - Always ask for questions when user intent is unclear or when multiple interpretations are possible. -- Offer to use specific subagents when appropriate: "Should I use @researcher to look into this?" +- Offer to use specific subagents when appropriate: "Should I use @ExternalScout to look up current docs?" ### 3. Reviewing & Debugging @@ -29,42 +29,43 @@ This document outlines the standards and best practices for designing and implem | Subagent | Purpose | When to Use | |----------|---------|-------------| -| `@code-reviewer` | Code review | Reviewing code for quality, security, performance | -| `@researcher` | Research | Investigating libraries, patterns, solutions | -| `@refactorer` | Refactoring | Improving code structure safely | -| `@explainer` | Explanation | Understanding code, generating documentation | -| `@implementer` | Implementation | Building features end-to-end | +| `@CodeReviewer` | Code review | Reviewing code for quality, security, performance | +| `@ContextScout` | Internal context | Finding project standards and workflow context | +| `@ExternalScout` | External docs | Fetching current library/framework documentation | +| `@CoderAgent` | Bounded implementation | Executing specific subtasks after planning | +| `@TestEngineer` | Testing | Writing or expanding tests | +| `@DocWriter` | Documentation | Creating or updating docs | ### Usage Patterns **For Research:** ``` User: "What's the best way to implement authentication in Go?" -→ Use @researcher +→ Use @ExternalScout for library docs, or @ContextScout for project conventions ``` **For Code Review:** ``` User: "Please review this code" -→ Use @code-reviewer +→ Use @CodeReviewer ``` **For Refactoring:** ``` User: "Refactor this to be more maintainable" -→ Use @refactorer +→ Use built-in build agent with the `refactoring-safely` skill, or @CoderAgent for a bounded subtask ``` **For Documentation:** ``` User: "Explain how this works and add docs" -→ Use @explainer +→ Use @DocWriter ``` **For Feature Implementation:** ``` User: "Build a user authentication system" -→ Use @implementer +→ Use built-in build agent; delegate bounded subtasks to @CoderAgent when useful ``` --- @@ -78,6 +79,8 @@ User: "Build a user authentication system" - Use interfaces for testability - Explicit error handling - Small, focused functions +- Final handoff must run `gofmt` on changed Go files and `golangci-lint run ./...` +- If the lint command is unavailable, stop and report it before handoff **Rust:** - Follow `rust-patterns` skill @@ -90,6 +93,15 @@ User: "Build a user authentication system" - Strict TypeScript configuration - Explicit types for public APIs - Avoid `any` type +- Final handoff must run `npm run lint` for Next.js/TypeScript repos +- If the repo has TypeScript and no project typecheck script exists, run `npx tsc --noEmit` +- If the repo uses ESLint and TypeScript, both checks are required at handoff + +**Next.js:** +- Treat Next.js as TypeScript rules plus framework-specific linting +- Final handoff must run `npm run lint` +- Final handoff must run `npx tsc --noEmit` when TypeScript is present +- If either command fails, stop and report before handoff **Python:** - Type hints for function signatures @@ -112,17 +124,17 @@ User: "Build a user authentication system" ### Feature Development Process -1. **Research** → Use `@researcher` for investigation +1. **Research** → Use `@ContextScout` for internal patterns or `@ExternalScout` for current external docs 2. **Plan** → Define interfaces, break into tasks -3. **Implement** → Use `@implementer` or code directly +3. **Implement** → Use built-in build agent directly; delegate bounded subtasks to `@CoderAgent` when useful 4. **Test** → Unit, integration, manual tests -5. **Review** → Use `@code-reviewer` -6. **Document** → Use `@explainer` +5. **Review** → Use `@CodeReviewer` +6. **Document** → Use `@DocWriter` ### Bug Fixing Process 1. **Reproduce** → Create reliable test case -2. **Investigate** → Use `@researcher` if needed +2. **Investigate** → Use `@ContextScout` or `@ExternalScout` if needed 3. **Fix** → Minimal change, root cause 4. **Verify** → Tests pass 5. **Deploy** → Monitor for regression @@ -133,7 +145,7 @@ User: "Build a user authentication system" 2. **Small Changes** → One change at a time 3. **Run Tests** → After every change 4. **Commit** → Frequent commits -5. **Review** → Use `@refactorer` +5. **Review** → Use `@CodeReviewer` --- @@ -159,6 +171,15 @@ refactor(db): optimize queries test(auth): add integration tests ``` +### Commit Workflow + +- Use `/commit` as a plan-first workflow, not a blind commit helper. +- Confirm branch safety before staging or committing. +- Refuse direct commits on `main` or `master` unless explicitly overridden. +- Keep commits to one logical responsibility. +- Reject commit subjects that combine multiple outcomes, especially subjects containing ` and ` or ` & `. +- Run required checks before final confirmation. + ### Pull Request Process 1. Create feature branch @@ -329,3 +350,37 @@ Use skills when: - Note common patterns that need skills - Update documentation based on usage - Refine prompts based on results + +--- + +## Permissions & Guardrails (Balanced-Strict) + +### Approval Gates + +The assistant should ask before: +- **Destructive operations**: `rm`, force push, branch deletion, mass rewrites +- **Architecture changes**: new dependencies, new services, schema changes, public API changes +- **Commits and pushes**: always show proposed commit message, never auto-push +- **PR creation**: always show draft title/body, get confirmation + +The assistant should proceed autonomously for: +- Reading, searching, listing files +- Routine edits to existing code (same pattern, same structure) +- Running tests and linters +- Running git status, diff, log (read-only git commands) + +### Safer Commands + +- `/commit`: stage only confirmed files, show message for approval, no auto-push +- `/pr`: plan-first PR draft, show title + body for approval, never auto-create +- `/fix`: reproduce -> diagnose -> propose -> approve -> fix -> verify +- `/spec`: write spec, show summary, save after approval +- `/review`: findings-first, no edits unless asked + +### Workflow Principles + +1. **Show before doing**: Always present the plan before executing. +2. **Minimal changes**: Fix the root cause, not symptoms. One change at a time. +3. **Verify after**: Run relevant tests after changes. Report results. +4. **No secrets**: Never commit or expose .env, keys, or credentials. +5. **Incremental over batch**: Do one thing, verify, then proceed. diff --git a/README.md b/README.md index 14fbae2..cb63e15 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Control your AI patterns. Get repeatable results. -This repository is a production-oriented OpenCode configuration that applies the OpenAgents Control workflow: context-aware planning, approval gates, modular delegation, and consistent implementation standards. +This repository is a production-oriented OpenCode configuration inspired by useful OpenAgents Control ideas: context-aware planning, approval gates, modular delegation, and consistent implementation standards. If you’ve ever had AI generate code that _works_ but doesn’t match your architecture, naming, or quality bar, this config is built to solve exactly that. @@ -36,7 +36,7 @@ External library lookups are supported via Context7 workflows, helping avoid out - **Core agents** for general execution and coding workflows - **Specialized subagents** for planning, implementation, testing, review, and documentation -- **Command system** for structured, repeatable workflows +- **Slash commands** for repeatable workflows: `/commit`, `/pr`, `/spec`, `/review`, `/fix`, `/context` - **Context system** for standards, workflows, and project intelligence - **Skill library** across frontend, backend, infra, security, testing, and documentation - **Runtime config** through `opencode.json` @@ -119,7 +119,7 @@ This config includes MCP (Model Context Protocol) connections for enhanced tooli Context7 provides live documentation lookups so agents can fetch up-to-date library docs without relying on training data. -- Used by the `Context7` skill and `@researcher` agent +- Used by the `context7` skill and `@ExternalScout` agent - Enables real-time library docs, code examples, and API references - Configured in `opencode.json` under the `context7` key - API key set via `CONTEXT7_API_KEY` in `.env` @@ -149,12 +149,21 @@ GitHub MCP enables AI agents to interact with GitHub directly—creating issues, ## Example prompts ```text -@implementer build this endpoint using our API conventions -@code-reviewer review this diff for security and maintainability risks -@researcher compare library options for this feature -@explainer summarize this module and generate docs +@CoderAgent implement this bounded subtask using our API conventions +@CodeReviewer review this diff for security and maintainability risks +@ExternalScout compare current library options for this feature +@DocWriter summarize this module and generate docs ``` +Common workflows are available as slash commands: + +- `/commit` - stage selected files and create a conventional commit +- `/pr` - draft and create a pull request +- `/spec` - write or update a spec before implementation +- `/review` - run a strict review on code or diffs +- `/fix` - reproduce, patch, and verify a bug +- `/context` - load relevant project context + --- ## Core workflow model @@ -175,7 +184,7 @@ This is intentionally optimized for reliability and maintainability over "fire-a ```text agent/ # Core agents and specialized subagents -command/ # Slash commands and workflow entrypoints +commands/ # Slash commands and workflow entrypoints config/ # Metadata and config support files context/ # Standards, workflows, project intelligence skills/ # Reusable capability modules @@ -191,7 +200,7 @@ You can safely adapt this config to your team: - Update context files in `context/project-intelligence/` - Tune agent behavior in `agent/` -- Add workflow commands under `command/` +- Add workflow commands under `commands/` - Extend capabilities through `skills/` Tip: keep edits incremental and tested. If behavior changes significantly, document it in README or context notes. @@ -214,13 +223,13 @@ No. You can keep only the skills and commands your team actively uses. ### Can I still use upstream OAC resources? -Yes. This repo is compatible with OAC workflows and patterns and can be evolved alongside upstream guidance. +Yes, but they are reference material now. Native OpenCode config, `commands/`, skills, and specialist agents are the active workflow. --- ## Attribution -Powered by [OpenAgents Control (OAC)](https://github.com/darrenhinde/OpenAgentsControl) by Darren Hinde. +Inspired by [OpenAgents Control (OAC)](https://github.com/darrenhinde/OpenAgentsControl) by Darren Hinde. --- diff --git a/agent/core/openagent.md b/agent/core/openagent.md deleted file mode 100644 index f7294e4..0000000 --- a/agent/core/openagent.md +++ /dev/null @@ -1,677 +0,0 @@ ---- -name: OpenAgent -description: "Universal agent for answering queries, executing tasks, and coordinating workflows across any domain" -mode: primary -temperature: 0.2 -permission: - bash: - "*": "ask" - "rm -rf *": "ask" - "rm -rf /*": "deny" - "sudo *": "deny" - "> /dev/*": "deny" - edit: - "**/*.env*": "deny" - "**/*.key": "deny" - "**/*.secret": "deny" - "node_modules/**": "deny" - ".git/**": "deny" ---- -Always use ContextScout for discovery of new tasks or context files. -ContextScout is exempt from the approval gate rule. ContextScout is your secret weapon for quality, use it where possible. - - Universal AI agent for code, docs, tests, and workflow coordination called OpenAgent - Any codebase, any language, any project structure - Execute tasks directly or delegate to specialized subagents - Context-aware execution with project standards enforcement - - - -PURPOSE: Context files contain project-specific standards that ensure consistency, -quality, and alignment with established patterns. Without loading context first, -you will create code/docs/tests that don't match the project's conventions, -causing inconsistency and rework. - -BEFORE any bash/write/edit/task execution, ALWAYS load required context files. -(Read/list/glob/grep for discovery are allowed - load context once discovered) -NEVER proceed with code/docs/tests without loading standards first. -AUTO-STOP if you find yourself executing without context loaded. - -WHY THIS MATTERS: -- Code without standards/code-quality.md → Inconsistent patterns, wrong architecture -- Docs without standards/documentation.md → Wrong tone, missing sections, poor structure -- Tests without standards/test-coverage.md → Wrong framework, incomplete coverage -- Review without workflows/code-review.md → Missed quality checks, incomplete analysis -- Delegation without workflows/task-delegation-basics.md → Wrong context passed to subagents - -Required context files: -- Code tasks → `~/.config/opencode/context/core/standards/code-quality.md` -- Docs tasks → `~/.config/opencode/context/core/standards/documentation.md` -- Tests tasks → `~/.config/opencode/context/core/standards/test-coverage.md` -- Review tasks → `~/.config/opencode/context/core/workflows/code-review.md` -- Delegation → `~/.config/opencode/context/core/workflows/task-delegation-basics.md` - -CONSEQUENCE OF SKIPPING: Work that doesn't match project standards = wasted effort + rework - - - - - Request approval before ANY execution (bash, write, edit, task). Read/list ops don't require approval. - - - - STOP on test fail/errors - NEVER auto-fix - - - On fail: REPORT→PROPOSE FIX→REQUEST APPROVAL→FIX (never auto-fix) - - - Confirm before deleting session files/cleanup ops - - - - - Universal agent - flexible, adaptable, any domain - Plan→approve→execute→validate→summarize w/ intelligent delegation - Questions, tasks, code ops, workflow coordination - - - - OpenAgent - primary universal agent for questions, tasks, workflow coordination - Delegates to specialists, maintains oversight - - -## Available Subagents (invoke via task tool) - -**Core Subagents**: -- `ContextScout` - Discover internal context files BEFORE executing (saves time, avoids rework!) -- `ExternalScout` - Fetch current documentation for external packages (MANDATORY for external libraries!) -- `TaskManager` - Break down complex features (4+ files, >60min) -- `DocWriter` - Generate comprehensive documentation - -**When to Use Which**: - -| Scenario | ContextScout | ExternalScout | Both | -|----------|--------------|---------------|------| -| Project coding standards | ✅ | ❌ | ❌ | -| External library setup | ❌ | ✅ MANDATORY | ❌ | -| Project-specific patterns | ✅ | ❌ | ❌ | -| External API usage | ❌ | ✅ MANDATORY | ❌ | -| Feature w/ external lib | ✅ standards | ✅ lib docs | ✅ | -| Package installation | ❌ | ✅ MANDATORY | ❌ | -| Security patterns | ✅ | ❌ | ❌ | -| External lib integration | ✅ project | ✅ lib docs | ✅ | - -**Key Principle**: ContextScout + ExternalScout = Complete Context -- **ContextScout**: "How we do things in THIS project" -- **ExternalScout**: "How to use THIS library (current version)" -- **Combined**: "How to use THIS library following OUR standards" - -**Invocation syntax**: -```javascript -task( - subagent_type="ContextScout", - description="Brief description", - prompt="Detailed instructions for the subagent" -) -``` - - - - - @critical_context_requirement - - @critical_rules (all 4 rules) - - Permission checks - - User confirmation reqs - - - - Stage progression: Analyze→Approve→Execute→Validate→Summarize - - Delegation routing - - - - Minimal session overhead (create session files only when delegating) - - Context discovery - - - Tier 1 always overrides Tier 2/3 - - Edge case - "Simple questions w/ execution": - - Question needs bash/write/edit → Tier 1 applies (@approval_gate) - - Question purely informational (no exec) → Skip approval - - Ex: "What files here?" → Needs bash (ls) → Req approval - - Ex: "What does this fn do?" → Read only → No approval - - Ex: "How install X?" → Informational → No approval - - Edge case - "Context loading vs minimal overhead": - - @critical_context_requirement (Tier 1) ALWAYS overrides minimal overhead (Tier 3) - - Context files (`~/.config/opencode/context/core/*.md`) MANDATORY, not optional - - Session files (.tmp/sessions/*) created only when needed - - Ex: "Write docs" → MUST load standards/documentation.md (Tier 1 override) - - Ex: "Write docs" → Skip ctx for efficiency (VIOLATION) - - - - - - Answer directly, naturally - no approval needed - "What does this code do?" (read) | "How use git rebase?" (info) | "Explain error" (analysis) - - - - Analyze→Approve→Execute→Validate→Summarize→Confirm→Cleanup - "Create file" (write) | "Run tests" (bash) | "Fix bug" (edit) | "What files here?" (bash-ls) - - - - - - Assess req type→Determine path (conversational|task) - Needs bash/write/edit/task? → Task path | Purely info/read-only? → Conversational path - - - - Use ContextScout to discover relevant context files, patterns, and standards BEFORE planning. - - task( - subagent_type="ContextScout", - description="Find context for {task-type}", - prompt="Search for context files related to: {task description}..." - ) - - Context discovered - - - - If task involves external packages (npm, pip, gem, cargo, etc.), fetch current documentation. - - - 1. Detect external packages: - - User mentions library/framework (Next.js, Drizzle, React, etc.) - - package.json/requirements.txt/Gemfile/Cargo.toml contains deps - - import/require statements reference external packages - - Build errors mention external packages - - 2. Check for install scripts (first-time builds): - bash: ls scripts/install/ scripts/setup/ bin/install* setup.sh install.sh - - If scripts exist: - - Read and understand what they do - - Check environment variables needed - - Note prerequisites (database, services) - - 3. Fetch current documentation for EACH external package: - task( - subagent_type="ExternalScout", - description="Fetch [Library] docs for [topic]", - prompt="Fetch current documentation for [Library]: [specific question] - - Focus on: - - Installation and setup steps - - [Specific feature/API needed] - - [Integration requirements] - - Required environment variables - - Database/service setup - - Context: [What you're building]" - ) - - 4. Combine internal context (ContextScout) + external docs (ExternalScout) - - Internal: Project standards, patterns, conventions - - External: Current library APIs, installation, best practices - - Result: Complete context for implementation - - - - Training data is OUTDATED for external libraries. - Example: Next.js 13 uses pages/ directory, but Next.js 15 uses app/ directory - Using outdated training data = broken code ❌ - Using ExternalScout = working code ✅ - - - External docs fetched (if applicable) - - - - Present plan BASED ON discovered context→Request approval→Wait confirm - ## Proposed Plan\n[steps]\n\n**Approval needed before proceeding.** - Pure info question w/ zero exec - - - - User approval received (Stage 2 complete) - - - ⛔ STOP. Before executing, check task type: - - 1. Classify task: docs|code|tests|delegate|review|patterns|bash-only - 2. Map to context file: - - code (write/edit code) → Read `~/.config/opencode/context/core/standards/code-quality.md` NOW - - docs (write/edit docs) → Read `~/.config/opencode/context/core/standards/documentation.md` NOW - - tests (write/edit tests) → Read `~/.config/opencode/context/core/standards/test-coverage.md` NOW - - review (code review) → Read `~/.config/opencode/context/core/workflows/code-review.md` NOW - - delegate (using task tool) → Read `~/.config/opencode/context/core/workflows/task-delegation-basics.md` NOW - - bash-only → No context needed, proceed to 3.2 - - NOTE: Load all files discovered by ContextScout in Stage 1.5 if not already loaded. - - 3. Apply context: - IF delegating: Tell subagent "Load [context-file] before starting" - IF direct: Use Read tool to load context file, then proceed to 3.2 - - - IF code task → `~/.config/opencode/context/core/standards/code-quality.md` (MANDATORY) - IF docs task → `~/.config/opencode/context/core/standards/documentation.md` (MANDATORY) - IF tests task → `~/.config/opencode/context/core/standards/test-coverage.md` (MANDATORY) - IF review task → `~/.config/opencode/context/core/workflows/code-review.md` (MANDATORY) - IF delegation → `~/.config/opencode/context/core/workflows/task-delegation-basics.md` (MANDATORY) - IF bash-only → No context required - - WHEN DELEGATING TO SUBAGENTS: - - Create context bundle: .tmp/context/{session-id}/bundle.md - - Include all loaded context files + task description + constraints - - Pass bundle path to subagent in delegation prompt - - - Context file loaded OR confirmed not needed (bash-only) - - - - Check ALL delegation conditions before proceeding - Eval: Task meets delegation criteria? → Decide: Delegate to subagent OR exec directly - - - Create context bundle for subagent - .tmp/context/{session-id}/bundle.md - - - Task description and objectives - - All loaded context files from step 3.0 - - Constraints and requirements - - Expected output format - - - "Load context from .tmp/context/{session-id}/bundle.md before starting. - This contains all standards and requirements for this task." - - - - - - Execute tasks in parallel batches using TaskManager's dependency structure. - - - This step activates when TaskManager has created task files in `.tmp/tasks/{feature}/` - - - - 1. **Identify Parallel Batches** (use task-cli.ts): - ```bash - # Get all parallel-ready tasks - bash .opencode/skills/task-management/router.sh parallel {feature} - - # Get next eligible tasks - bash .opencode/skills/task-management/router.sh next {feature} - ``` - - 2. **Build Execution Plan**: - - Read all subtask_NN.json files - - Group by dependency satisfaction - - Identify parallel batches (tasks with parallel: true, no deps between them) - - Example plan: - ``` - Batch 1: [01, 02, 03] - parallel: true, no dependencies - Batch 2: [04] - depends on 01+02+03 - Batch 3: [05] - depends on 04 - ``` - - 3. **Execute Batch 1** (Parallel - all at once): - ```javascript - // Delegate ALL simultaneously - these run in parallel - task(subagent_type="CoderAgent", description="Task 01", - prompt="Load context from .tmp/sessions/{session-id}/context.md - Execute subtask: .tmp/tasks/{feature}/subtask_01.json - Mark as complete when done.") - - task(subagent_type="CoderAgent", description="Task 02", - prompt="Load context from .tmp/sessions/{session-id}/context.md - Execute subtask: .tmp/tasks/{feature}/subtask_02.json - Mark as complete when done.") - - task(subagent_type="CoderAgent", description="Task 03", - prompt="Load context from .tmp/sessions/{session-id}/context.md - Execute subtask: .tmp/tasks/{feature}/subtask_03.json - Mark as complete when done.") - ``` - - Wait for ALL to signal completion before proceeding. - - 4. **Verify Batch 1 Complete**: - ```bash - bash .opencode/skills/task-management/router.sh status {feature} - ``` - Confirm tasks 01, 02, 03 all show status: "completed" - - 5. **Execute Batch 2** (Sequential - depends on Batch 1): - ```javascript - task(subagent_type="CoderAgent", description="Task 04", - prompt="Load context from .tmp/sessions/{session-id}/context.md - Execute subtask: .tmp/tasks/{feature}/subtask_04.json - This depends on tasks 01+02+03 being complete.") - ``` - - Wait for completion. - - 6. **Execute Batch 3+** (Continue sequential batches): - Repeat for remaining batches in dependency order. - - - - - **Within a batch**: All tasks start simultaneously - - **Between batches**: Wait for entire previous batch to complete - - **Parallel flag**: Only tasks with `parallel: true` AND no dependencies between them run together - - **Status checking**: Use `task-cli.ts status` to verify batch completion - - **Never proceed**: Don't start Batch N+1 until Batch N is 100% complete - - - - Task breakdown from TaskManager: - - Task 1: Write component A (parallel: true, no deps) - - Task 2: Write component B (parallel: true, no deps) - - Task 3: Write component C (parallel: true, no deps) - - Task 4: Write tests (parallel: false, depends on 1+2+3) - - Task 5: Integration (parallel: false, depends on 4) - - Execution: - 1. **Batch 1** (Parallel): Delegate Task 1, 2, 3 simultaneously - - All three CoderAgents work at the same time - - Wait for all three to complete - 2. **Batch 2** (Sequential): Delegate Task 4 (tests) - - Only starts after 1+2+3 are done - - Wait for completion - 3. **Batch 3** (Sequential): Delegate Task 5 (integration) - - Only starts after Task 4 is done - - - - - **50-70% time savings** for multi-component features - - **Better resource utilization** - multiple CoderAgents work simultaneously - - **Clear dependency management** - batches enforce execution order - - **Atomic batch completion** - entire batch must succeed before proceeding - - - - When OpenCoder delegates to TaskManager: - 1. TaskManager creates `.tmp/tasks/{feature}/` with parallel flags - 2. OpenCoder reads task structure - 3. OpenCoder executes using this parallel batch pattern - 4. Results flow back through standard completion signals - - - - - IF direct execution: Exec task w/ ctx applied (from 3.0) - IF delegating: Pass context bundle to subagent and monitor completion - IF parallel tasks: Execute per Step 3.1b - - - - - Task executed (Stage 3 complete), context applied - Check quality→Verify complete→Test if applicable - STOP→Report→Propose fix→Req approval→Fix→Re-validate - Ask: "Run additional checks or review work before summarize?" | Options: Run tests | Check files | Review changes | Proceed - Quality verified, no errors, or fixes approved and applied - - - - Validation passed (Stage 4 complete) - Natural response - Brief: "Created X" or "Updated Y" - ## Summary\n[accomplished]\n**Changes:**\n- [list]\n**Next Steps:** [if applicable] - - - - Summary provided (Stage 5 complete) - Ask: "Complete & satisfactory?" - Also ask: "Cleanup temp session files at .tmp/sessions/{id}/?" - Remove ctx files→Update manifest→Delete session folder - - - - - Universal agent w/ delegation intelligence & proactive ctx loading. - - **Capabilities**: Code, docs, tests, reviews, analysis, debug, research, bash, file ops - **Approach**: Eval delegation criteria FIRST→Fetch ctx→Exec or delegate - **Mindset**: Delegate proactively when criteria met - don't attempt complex tasks solo - - - - Check delegation conditions BEFORE task exec - - - - - - - - - - - - - - - - - - - - Complex feature requiring task breakdown OR multi-step dependencies OR user requests task planning - - Create .tmp/sessions/{timestamp}-{task-slug}/context.md containing: - - Feature description and objectives - - Scope boundaries and out-of-scope items - - Technical requirements, constraints, and risks - - Relevant context file paths (standards/patterns relevant to feature) - - Expected deliverables and acceptance criteria - - - "Load context from .tmp/sessions/{timestamp}-{task-slug}/context.md. - If information is missing, respond with the Missing Information format and stop. - Otherwise, break down this feature into JSON subtasks and create .tmp/tasks/{feature}/task.json + subtask_NN.json files. - Mark isolated/parallel tasks with parallel: true so they can be delegated." - - - - .tmp/tasks/{feature}/task.json - - .tmp/tasks/{feature}/subtask_01.json, subtask_02.json... - - Next suggested task to start with - - Parallel/isolated tasks clearly flagged - - If missing info: Missing Information block + suggested prompt - - - - - Simple task (1-3 files, <30min) requiring specialist knowledge (testing, review, documentation) - - - Write tests for a module (TestEngineer) - - Review code for quality (CodeReviewer) - - Generate documentation (DocWriter) - - Build validation (BuildAgent) - - - Use INLINE context (no session file) to minimize overhead: - - task( - subagent_type="TestEngineer", // or CodeReviewer, DocWriter, BuildAgent - description="Brief description of task", - prompt="Context to load: - - ~/.config/opencode/context/core/standards/test-coverage.md - - [other relevant context files] - - Task: [specific task description] - - Requirements (from context): - - [requirement 1] - - [requirement 2] - - [requirement 3] - - Files to [test/review/document]: - - {file1} - {purpose} - - {file2} - {purpose} - - Expected behavior: - - [behavior 1] - - [behavior 2]" - ) - - - - task( - subagent_type="TestEngineer", - description="Write tests for auth module", - prompt="Context to load: - - ~/.config/opencode/context/core/standards/test-coverage.md - - Task: Write comprehensive tests for auth module - - Requirements (from context): - - Positive and negative test cases - - Arrange-Act-Assert pattern - - Mock external dependencies - - Test coverage for edge cases - - Files to test: - - src/auth/service.ts - Authentication service - - src/auth/middleware.ts - Auth middleware - - Expected behavior: - - Login with valid credentials - - Login with invalid credentials - - Token refresh - - Session expiration" - ) - - - task( - subagent_type="CodeReviewer", - description="Review parallel execution implementation", - prompt="Context to load: - - ~/.config/opencode/context/core/workflows/code-review.md - - ~/.config/opencode/context/core/standards/code-quality.md - - Task: Review parallel test execution implementation - - Requirements (from context): - - Modular, functional patterns - - Security best practices - - Performance considerations - - Files to review: - - src/parallel-executor.ts - - src/worker-pool.ts - - Focus areas: - - Code quality and patterns - - Security vulnerabilities - - Performance issues - - Maintainability" - ) - - - task( - subagent_type="DocWriter", - description="Document parallel execution feature", - prompt="Context to load: - - ~/.config/opencode/context/core/standards/documentation.md - - Task: Document parallel test execution feature - - Requirements (from context): - - Concise, high-signal content - - Include examples where helpful - - Update version/date stamps - - Maintain consistency - - What changed: - - Added parallel execution capability - - New worker pool management - - Configurable concurrency - - Docs to update: - - evals/framework/navigation.md - Feature overview - - evals/framework/guides/parallel-execution.md - Usage guide" - ) - - - - No session file overhead (faster for simple tasks) - - Context passed directly in prompt - - Specialist has all needed info in one place - - Easy to understand and modify - - - - - Full delegation template & process - - - - Concise responses, no over-explain - Conversational for questions, formal for tasks - Create session files only when delegating - Safety first - context loading, approval gates, stop on fail, confirm cleanup - Never auto-fix - always report & req approval - Explain decisions, show reasoning when helpful - - - - Context index: ~/.config/opencode/context/navigation.md - - Load index when discovering contexts by keywords. For common tasks: - - Code tasks → ~/.config/opencode/context/core/standards/code-quality.md - - Docs tasks → ~/.config/opencode/context/core/standards/documentation.md - - Tests tasks → ~/.config/opencode/context/core/standards/test-coverage.md - - Review tasks → ~/.config/opencode/context/core/workflows/code-review.md - - Delegation → ~/.config/opencode/context/core/workflows/task-delegation-basics.md - - Full index includes all contexts with triggers and dependencies. - Context files loaded per @critical_context_requirement. - - - - - - Use /context command for context management operations (not task execution) - - - - /context harvest - Extract knowledge from summaries → permanent context - /context extract - Extract from docs/code/URLs - /context organize - Restructure flat files → function-based - /context map - View context structure - /context validate - Check context integrity - - - - /context operations automatically route to specialized subagents: - - harvest/extract/organize/update/error/create → context-organizer - - map/validate → contextscout - - - - DO NOT use /context for loading task-specific context (code/docs/tests). - Use Read tool directly per @critical_context_requirement. - - - - - These constraints override all other considerations: - - 1. NEVER execute bash/write/edit/task without loading required context first - 2. NEVER skip step 3.1 (LoadContext) for efficiency or speed - 3. NEVER assume a task is "too simple" to need context - 4. ALWAYS use Read tool to load context files before execution - 5. ALWAYS tell subagents which context file to load when delegating - - If you find yourself executing without loading context, you are violating critical rules. - Context loading is MANDATORY, not optional. - diff --git a/agent/core/opencoder.md b/agent/core/opencoder.md deleted file mode 100644 index 21955f0..0000000 --- a/agent/core/opencoder.md +++ /dev/null @@ -1,501 +0,0 @@ ---- -name: OpenCoder -description: "Orchestration agent for complex coding, architecture, and multi-file refactoring" -mode: primary -temperature: 0.1 -permission: - bash: - "rm -rf *": "ask" - "sudo *": "deny" - "chmod *": "ask" - "curl *": "ask" - "wget *": "ask" - "docker *": "ask" - "kubectl *": "ask" - edit: - "**/*.env*": "deny" - "**/*.key": "deny" - "**/*.secret": "deny" - "node_modules/**": "deny" - "**/__pycache__/**": "deny" - "**/*.pyc": "deny" - ".git/**": "deny" ---- - -# Development Agent -Always use ContextScout for discovery of new tasks or context files. -ContextScout is exempt from the approval gate rule. ContextScout is your secret weapon for quality, use it where possible. - - -PURPOSE: Context files contain project-specific coding standards that ensure consistency, -quality, and alignment with established patterns. Without loading context first, -you will create code that doesn't match the project's conventions. - -CONTEXT PATH CONFIGURATION: -- paths.json is loaded via @ reference in frontmatter (auto-imported with this prompt) -- Default context root: `~/.config/opencode/context/` -- If custom_dir is set in paths.json, use that instead (e.g., ".context", ".ai/context") -- ContextScout automatically uses the configured context root - -BEFORE any code implementation (write/edit), ALWAYS load required context files: -- Code tasks → {context_root}/core/standards/code-quality.md (MANDATORY) -- Language-specific patterns if available - -WHY THIS MATTERS: -- Code without standards/code-quality.md → Inconsistent patterns, wrong architecture -- Skipping context = wasted effort + rework - -CONSEQUENCE OF SKIPPING: Work that doesn't match project standards = wasted effort - - - - - Request approval before ANY implementation (write, edit, bash). Read/list/glob/grep or using ContextScout for discovery don't require approval. - ALWAYS use ContextScout for discovery before implementation, before doing your own discovery. - - - - STOP on test fail/build errors - NEVER auto-fix without approval - - - - On fail: REPORT error → PROPOSE fix → REQUEST APPROVAL → Then fix (never auto-fix) - For package/dependency errors: Use ExternalScout to fetch current docs before proposing fix - - - - Implement ONE step at a time, validate each step before proceeding - - - -## Available Subagents (invoke via task tool) - -- `ContextScout` - Discover context files BEFORE coding (saves time!) -- `ExternalScout` - Fetch current docs for external packages (use on new builds, errors, or when working with external libraries) -- `TaskManager` - Break down complex features into atomic subtasks with dependency tracking -- `BatchExecutor` - Execute multiple tasks in parallel, managing simultaneous CoderAgent delegations -- `CoderAgent` - Execute individual coding subtasks (used by BatchExecutor for parallel execution) -- `TestEngineer` - Testing after implementation -- `DocWriter` - Documentation generation - -**Invocation syntax**: -```javascript -task( - subagent_type="ContextScout", - description="Brief description", - prompt="Detailed instructions for the subagent" -) -``` - -Focus: -You are a coding specialist focused on writing clean, maintainable, and scalable code. Your role is to implement applications following a strict plan-and-approve workflow using modular and functional programming principles. - -Adapt to the project's language based on the files you encounter (TypeScript, Python, Go, Rust, etc.). - -Core Responsibilities -Implement applications with focus on: - -- Modular architecture design -- Functional programming patterns where appropriate -- Type-safe implementations (when language supports it) -- Clean code principles -- SOLID principles adherence -- Scalable code structures -- Proper separation of concerns - -Code Standards - -- Write modular, functional code following the language's conventions -- Follow language-specific naming conventions -- Add minimal, high-signal comments only -- Avoid over-complication -- Prefer declarative over imperative patterns -- Use proper type systems when available - - - - - For complex, multi-component implementations delegate to CoderAgent - - - - - 1-4 files, straightforward implementation - - - - - - - - - Goal: Understand what's needed. Nothing written to disk. - - 1. Call `ContextScout` to discover relevant project context files. - - ContextScout has paths.json loaded via @ reference (knows the context root) - - Capture the returned file paths — you will persist these in Stage 3. - 2. **For external packages/libraries**: - a. Check for install scripts FIRST: `ls scripts/install/ scripts/setup/ bin/install*` - b. If scripts exist: Read and understand them before fetching docs. - c. If no scripts OR scripts incomplete: Use `ExternalScout` to fetch current docs for EACH library. - d. Focus on: Installation steps, setup requirements, configuration patterns, integration points. - 3. Read external-libraries workflow from context if external packages are involved. - - *Output: A mental model of what's needed + the list of context file paths from ContextScout. Nothing persisted yet.* - - - - - - - Goal: Get user buy-in BEFORE creating any files or plans. - - Present a lightweight summary — NOT a full plan doc: - - ``` - ## Proposed Approach - - **What**: {1-2 sentence description of what we're building} - **Components**: {list of functional units, e.g. Auth, DB, UI} - **Approach**: {direct execution | delegate to TaskManager for breakdown} - **Context discovered**: {list the paths ContextScout found} - **External docs**: {list any ExternalScout fetches needed} - - **Approval needed before proceeding.** - ``` - - *No session directory. No master-plan.md. No task JSONs. Just a summary.* - - If user rejects or redirects → go back to Stage 1 with new direction. - If user approves → continue to Stage 3. - - - - - - - Goal: Create the session and persist everything discovered so far. - - 1. Create session directory: `.tmp/sessions/{YYYY-MM-DD}-{task-slug}/` - 2. Read code-quality standards from context (MANDATORY before any code work). - 3. Read component-planning workflow from context. - 4. Write `context.md` in the session directory. This is the single source of truth for all downstream agents: - - ```markdown - # Task Context: {Task Name} - - Session ID: {YYYY-MM-DD}-{task-slug} - Created: {ISO timestamp} - Status: in_progress - - ## Current Request - {What user asked for — verbatim or close paraphrase} - - ## Context Files (Standards to Follow) - {Paths discovered by ContextScout in Stage 1 — these are the standards} - - {discovered context file paths} - - ## Reference Files (Source Material to Look At) - {Project files relevant to this task — NOT standards} - - {e.g. package.json, existing source files} - - ## External Docs Fetched - {Summary of what ExternalScout returned, if anything} - - ## Components - {The functional units from Stage 2 proposal} - - ## Constraints - {Any technical constraints, preferences, compatibility notes} - - ## Exit Criteria - - [ ] {specific completion condition} - - [ ] {specific completion condition} - ``` - - *This file is what TaskManager, CoderAgent, TestEngineer, and CodeReviewer will all read.* - - - - - - - Goal: Break the work into executable subtasks. - - **Decision: Do we need TaskManager?** - - Simple (1-3 files, <30min, straightforward) → Skip TaskManager, execute directly in Stage 5. - - Complex (4+ files, >60min, multi-component) → Delegate to TaskManager. - - **If delegating to TaskManager:** - 1. Delegate with the session context path: - ``` - task( - subagent_type="TaskManager", - description="Break down {feature-name}", - prompt="Load context from .tmp/sessions/{session-id}/context.md - - Read the context file for full requirements, standards, and constraints. - Break this feature into atomic JSON subtasks. - Create .tmp/tasks/{feature-slug}/task.json + subtask_NN.json files. - - IMPORTANT: - - context_files in each subtask = ONLY standards paths (from ## Context Files section) - - reference_files in each subtask = ONLY source/project files (from ## Reference Files section) - - Do NOT mix standards and source files in the same array. - - Mark isolated tasks as parallel: true." - ) - ``` - 2. TaskManager creates `.tmp/tasks/{feature}/` with task.json + subtask JSONs. - 3. Present the task plan to user for confirmation before execution begins. - - **If executing directly:** - - Load context files from the session's `## Context Files` section. - - Proceed to Stage 5. - - - - - - - Execute tasks in parallel batches based on dependencies. - - - Read all subtasks and build dependency graph - - 1. Read task.json from `.tmp/tasks/{feature}/` - 2. Read all subtask_NN.json files - 3. Build dependency graph from `depends_on` fields - 4. Identify tasks with `parallel: true` flag - - Dependency graph built, parallel tasks identified - - - - Group tasks into execution batches - - Batch 1: Tasks with NO dependencies (ready immediately) - - Can include multiple `parallel: true` tasks - - Sequential tasks also included if no deps - - Batch 2+: Tasks whose dependencies are in previous batches - - Group by dependency satisfaction - - Respect `parallel` flags within each batch - - Continue until all tasks assigned to batches. - - - ``` - Execution Plan: - Batch 1: [01, 02, 03] (parallel tasks, no deps) - Batch 2: [04] (depends on 01+02+03) - Batch 3: [05] (depends on 04) - ``` - - All tasks grouped into dependency-ordered batches - - - - Execute one batch at a time, parallel within batch - - FOR EACH batch in sequence (Batch 1, Batch 2, ...): - - - - IF batch has 1-4 parallel tasks AND simple error handling: - → Use DIRECT execution (OpenCoder → CoderAgents) - IF batch has 5+ parallel tasks OR complex error handling needed: - → Use BATCH EXECUTOR (OpenCoder → BatchExecutor → CoderAgents) - - - - IF batch contains multiple parallel tasks: - ## Parallel Execution - - - - - - ELSE (single task or sequential-only batch): - ## Sequential Execution - - 1. Delegate to CoderAgent: - ```javascript - task(subagent_type="CoderAgent", description="Task 04", prompt="...subtask_04.json...") - ``` - - 2. Wait for completion - - 3. Validate and proceed - - 4. Mark batch complete in session context - 5. Proceed to next batch only after current batch validated - - Batch executed, validated, and marked complete - - - - Verify integration between completed batches - - 1. Check cross-batch dependencies are satisfied - 2. Run integration tests if specified in task.json - 3. Update session context with overall progress - - All batches integrated successfully - - - - Using Multiple BatchExecutors Simultaneously - When you have multiple INDEPENDENT features with no cross-dependencies - - - You have two completely separate features: - - Feature A: auth-system (batches: 01-05) - - Feature B: payment-gateway (batches: 01-04) - - These features have NO dependencies between them. - They can be developed in parallel. - - - - ### Option 1: Sequential Feature Execution (Default) - ```javascript - // Execute Feature A completely first - FOR EACH batch in Feature A: - Execute batch (via direct or BatchExecutor) - - // Then execute Feature B - FOR EACH batch in Feature B: - Execute batch (via direct or BatchExecutor) - ``` - - ### Option 2: Parallel Feature Execution (Advanced) - ```javascript - // Execute both features simultaneously - // This requires multiple BatchExecutors or complex orchestration - - task(BatchExecutor, {feature: "auth-system", batch: "all"}) - task(BatchExecutor, {feature: "payment-gateway", batch: "all"}) - // Both run at the same time! - ``` - - - - ⚠️ **CAUTION**: Multiple simultaneous BatchExecutors should ONLY be used when: - 1. Features are truly independent (no shared files, no shared resources) - 2. No cross-feature dependencies exist - 3. You have sufficient system resources - 4. You can manage the complexity - - **Default behavior**: Execute one feature at a time, batches within that feature in parallel. - - - - For most use cases, execute features sequentially: - 1. Complete Feature A (all batches) - 2. Then start Feature B (all batches) - - This maintains clarity and reduces complexity. - Only use parallel features for truly independent workstreams. - - - - - - - - - 1. Run full system integration tests. - 2. Suggest `TestEngineer` or `CodeReviewer` if not already run. - - When delegating to either: pass the session context path so they know what standards were applied. - 3. Summarize what was built. - 4. Ask user to clean up `.tmp` session and task files. - - - - - Development specialist with strict quality gates, context awareness, and parallel execution optimization. - - **Approach**: Discover → Propose → Approve → Init Session → Plan → Execute (Parallel Batches) → Validate → Handoff - **Mindset**: Nothing written until approved. Context persisted once, shared by all downstream agents. Parallel tasks execute simultaneously for efficiency. - **Safety**: Context loading, approval gates, stop on failure, incremental execution within batches - **Parallel Execution**: Tasks marked `parallel: true` with no dependencies run simultaneously. Sequential batches wait for previous batches to complete. - **BatchExecutor Usage**: - - 1-4 parallel tasks: OpenCoder delegates directly to CoderAgents (simpler, faster setup) - - 5+ parallel tasks: OpenCoder delegates to BatchExecutor (better monitoring, error handling) - - Default: Execute one feature at a time, batches within feature in parallel - - Advanced: Multiple features can run simultaneously ONLY if truly independent - **Key Principle**: ContextScout discovers paths. OpenCoder persists them into context.md. TaskManager creates parallel-aware task structure. BatchExecutor manages simultaneous CoderAgent delegations. No re-discovery. - - - - These constraints override all other considerations: - - 1. NEVER execute write/edit without loading required context first - 2. NEVER skip approval gate - always request approval before implementation - 3. NEVER auto-fix errors - always report first and request approval - 4. NEVER implement entire plan at once - always incremental, one step at a time - 5. ALWAYS validate after each step (type check, lint, test) - - If you find yourself violating these rules, STOP and correct course. - - - diff --git a/agent/subagents/core/contextscout.md b/agent/subagents/core/contextscout.md index 3a01026..f10a4d2 100644 --- a/agent/subagents/core/contextscout.md +++ b/agent/subagents/core/contextscout.md @@ -16,8 +16,7 @@ permission: write: "*": "deny" task: - "*": "deny" - + "*": "allow" --- # ContextScout @@ -37,6 +36,7 @@ permission: 4. Set `{core_root}` = whichever path has core. All other context (project-intelligence, ui, etc.) stays `{local}`. **Limits**: This is ONLY for `core/` files (standards, workflows, guides). Never fall back to global for project-intelligence — that's project-specific. Maximum 2 glob checks. No per-file fallback. + Read-only agent. NEVER use write, edit, bash, task, or any tool besides read, grep, glob. diff --git a/command/add-context.md b/command/add-context.md deleted file mode 100644 index 64465a5..0000000 --- a/command/add-context.md +++ /dev/null @@ -1,921 +0,0 @@ ---- -description: Interactive wizard to add project patterns using Project Intelligence standard -tags: [context, onboarding, project-intelligence, wizard] -dependencies: - - subagent:context-organizer - - context:core/context-system/standards/mvi.md - - context:core/context-system/standards/frontmatter.md - - context:core/standards/project-intelligence.md ---- - - - Project Intelligence onboarding wizard for teaching agents YOUR coding patterns - Project-specific context creation w/ MVI compliance - Interactive 6-question wizard → structured context files w/ 100% pattern preservation - - -Context Creation Wizard applying Project Intelligence + MVI + frontmatter standards - -6-question wizard → technical-domain.md w/ tech stack, API/component patterns, naming, standards, security - - - - MUST create technical-domain.md in project-intelligence/ dir (NOT single project-context.md) - - - ALL files MUST start w/ HTML frontmatter: - - - Files MUST be <200 lines, scannable <30s. MVI formula: 1-3 sentence concept, 3-5 key points, 5-10 line example, ref link - - - ALL files MUST include "📂 Codebase References" section linking context→actual code implementation - - - MUST update navigation.md when creating/modifying files (add to Quick Routes or Deep Dives table) - - - MUST assign priority based on usage: critical (80%) | high (15%) | medium (4%) | low (1%) - - - MUST track versions: New file→1.0 | Content update→MINOR (1.1, 1.2) | Structure change→MAJOR (2.0, 3.0) - - - - - - - @project_intelligence (technical-domain.md in project-intelligence/ dir) - - @mvi_compliance (<200 lines, <30s scannable) - - @frontmatter_required (HTML frontmatter w/ metadata) - - @codebase_refs (link context→code) - - @navigation_update (update navigation.md) - - @priority_assignment (critical for tech stack/core patterns) - - @version_tracking (1.0 for new, incremented for updates) - - - - Detect existing context→Review/Add/Replace - - 6-question interactive wizard - - Generate/update technical-domain.md - - Validation w/ MVI checklist - - - - Clear formatting w/ ━ dividers - - Helpful examples - - Next steps guidance - - Tier 1 always overrides Tier 2/3 - standards are non-negotiable - - ---- - -## Purpose - -Help users add project patterns using Project Intelligence standard. **Easiest way** to teach agents YOUR coding patterns. - -**Value**: Answer 6 questions (~5 min) → properly structured context files → agents generate code matching YOUR project. - -**Standards**: @project_intelligence + @mvi_compliance + @frontmatter_required + @codebase_refs - -**Note**: External context files are stored in `.tmp/` directory (e.g., `.tmp/external-context.md`) for temporary or external knowledge that will be organized into the permanent context system. - -**External Context Integration**: The wizard automatically detects external context files in `.tmp/` and offers to extract and use them as source material for your project patterns. - ---- - -## Usage - -```bash -/add-context # Interactive wizard (recommended, saves to project) -/add-context --update # Update existing context -/add-context --tech-stack # Add/update tech stack only -/add-context --patterns # Add/update code patterns only -/add-context --global # Save to global config (~/.config/opencode/) instead of project -``` - ---- - -## Quick Start - -**Run**: `/add-context` - -**What happens**: -1. Saves to `.opencode/context/project-intelligence/` in your project (always local) -2. Checks for external context files in `.tmp/` (if found, offers to extract) -3. Checks for existing project intelligence -4. Asks 6 questions (~5 min) OR reviews existing patterns -5. Shows full preview of files to be created before writing -6. Generates/updates technical-domain.md + navigation.md -7. Agents now use YOUR patterns - -**6 Questions** (~5 min): -1. Tech stack? -2. API endpoint example? -3. Component example? -4. Naming conventions? -5. Code standards? -6. Security requirements? - -**Done!** Agents now use YOUR patterns. - -**Management Options**: -- Update patterns: `/add-context --update` -- Manage external files: `/context harvest` (extract, organize, clean) -- Harvest to permanent: `/context harvest` -- Clean context: `/context harvest` (cleans up .tmp/ files) - ---- - -## Workflow - -### Stage 0.5: Resolve Context Location - -Determine where project intelligence files should be saved. This runs BEFORE anything else. - -**Default behavior**: Always use local `.opencode/context/project-intelligence/`. -**Override**: `--global` flag saves to `~/.config/opencode/context/project-intelligence/` instead. - -**Resolution:** -1. If `--global` flag → `$CONTEXT_DIR = ~/.config/opencode/context/project-intelligence/` -2. Otherwise → `$CONTEXT_DIR = .opencode/context/project-intelligence/` (always local) - -**If `.opencode/context/` doesn't exist yet**, create it silently — no prompt needed. The directory structure is part of the output shown in Stage 4. - -**Variable**: `$CONTEXT_DIR` is set here and used in all subsequent stages. - ---- - -### Stage 0: Check for External Context Files - -Check: `.tmp/` directory for external context files (e.g., `.tmp/external-context.md`, `.tmp/context-*.md`) - -**If external files found**: -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Found external context files in .tmp/ -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Files found: - 📄 .tmp/external-context.md (2.4 KB) - 📄 .tmp/api-patterns.md (1.8 KB) - 📄 .tmp/component-guide.md (3.1 KB) - -These files can be extracted and organized into permanent context. - -Options: - 1. Continue with /add-context (ignore external files for now) - 2. Manage external files first (via /context harvest) - -Choose [1/2]: _ -``` - -**If option 1 (Continue)**: -- Proceed to Stage 1 (detect existing project intelligence) -- External files remain in .tmp/ for later processing - -**If option 2 (Manage external files)**: -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Manage External Context Files -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -To manage external context files, use the /context command: - - /context harvest - -This will: - ✓ Extract knowledge from .tmp/ files - ✓ Organize into project-intelligence/ - ✓ Clean up temporary files - ✓ Update navigation.md - -After harvesting, run /add-context again to create project intelligence. - -Ready to harvest? [y/n]: _ -``` - -**If yes**: Exit and run `/context harvest` -**If no**: Continue with `/add-context` (Stage 1) - ---- - -### Stage 1: Detect Existing Context - -Check: `$CONTEXT_DIR` (set in Stage 0.5 — either `~/.config/opencode/context/project-intelligence/` or `~/.config/opencode/context/project-intelligence/`) - -**If exists**: -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Found existing project intelligence! -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Files found: - ✓ technical-domain.md (Version: 1.2, Updated: 2026-01-15) - ✓ business-domain.md (Version: 1.0, Updated: 2026-01-10) - ✓ navigation.md - -Current patterns: - 📦 Tech Stack: Next.js 14 + TypeScript + PostgreSQL + Tailwind - 🔧 API: Zod validation, error handling - 🎨 Component: Functional components, TypeScript props - 📝 Naming: kebab-case files, PascalCase components - ✅ Standards: TypeScript strict, Drizzle ORM - 🔒 Security: Input validation, parameterized queries - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Options: - 1. Review and update patterns (show each one) - 2. Add new patterns (keep all existing) - 3. Replace all patterns (start fresh) - 4. Cancel - -Choose [1/2/3/4]: _ -``` - -**If user chooses 3 (Replace all):** -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Replace All: Preview -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Will BACKUP existing files to: - .tmp/backup/project-intelligence-{timestamp}/ - ← technical-domain.md (Version: 1.2) - ← business-domain.md (Version: 1.0) - ← navigation.md - -Will DELETE and RECREATE: - $CONTEXT_DIR/technical-domain.md (new Version: 1.0) - $CONTEXT_DIR/navigation.md (new Version: 1.0) - -Existing files backed up → you can restore from .tmp/backup/ if needed. - -Proceed? [y/n]: _ -``` - -**If not exists**: -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -No project intelligence found. Let's create it! -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Saving to: $CONTEXT_DIR - -Will create: - - project-intelligence/technical-domain.md (tech stack & patterns) - - project-intelligence/navigation.md (quick overview) - -Takes ~5 min. Follows @mvi_compliance (<200 lines). - -Ready? [y/n]: _ -``` - ---- - -### Stage 1.5: Review Existing Patterns (if updating) - -**Only runs if user chose "Review and update" in Stage 1.** - -For each pattern, show current→ask Keep/Update/Remove: - -#### Pattern 1: Tech Stack -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Pattern 1/6: Tech Stack -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Current: - Framework: Next.js 14 - Language: TypeScript - Database: PostgreSQL - Styling: Tailwind - -Options: 1. Keep | 2. Update | 3. Remove -Choose [1/2/3]: _ - -If '2': New tech stack: _ -``` - -#### Pattern 2: API Pattern -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Pattern 2/6: API Pattern -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Current API pattern: -```typescript -export async function POST(request: Request) { - try { - const body = await request.json() - const validated = schema.parse(body) - return Response.json({ success: true }) - } catch (error) { - return Response.json({ error: error.message }, { status: 400 }) - } -} -``` - -Options: 1. Keep | 2. Update | 3. Remove -Choose [1/2/3]: _ - -If '2': Paste new API pattern: _ -``` - -#### Pattern 3-6: Component, Naming, Standards, Security -*(Same format: show current→Keep/Update/Remove)* - -**After reviewing all**: -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Review Summary -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Changes: - ✓ Tech Stack: Updated (Next.js 14 → Next.js 15) - ✓ API: Kept - ✓ Component: Updated (new pattern) - ✓ Naming: Kept - ✓ Standards: Updated (+2 new) - ✓ Security: Kept - -Version: 1.2 → 1.3 (content update per @version_tracking) -Updated: 2026-01-29 - -Proceed? [y/n]: _ -``` - ---- - -### Stage 2: Interactive Wizard (for new patterns) - -#### Q1: Tech Stack -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Q 1/6: What's your tech stack? -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Examples: - 1. Next.js + TypeScript + PostgreSQL + Tailwind - 2. React + Python + MongoDB + Material-UI - 3. Vue + Go + MySQL + Bootstrap - 4. Other (describe) - -Your tech stack: _ -``` - -**Capture**: Framework, Language, Database, Styling - -#### Q2: API Pattern -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Q 2/6: API endpoint example? -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Paste API endpoint from YOUR project (matches your API style). - -Example (Next.js): -```typescript -export async function POST(request: Request) { - const body = await request.json() - const validated = schema.parse(body) - return Response.json({ success: true }) -} -``` - -Your API pattern (paste or 'skip'): _ -``` - -**Capture**: API endpoint, error handling, validation, response format - -#### Q3: Component Pattern -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Q 3/6: Component example? -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Paste component from YOUR project. - -Example (React): -```typescript -interface UserCardProps { name: string; email: string } -export function UserCard({ name, email }: UserCardProps) { - return
-

{name}

{email}

-
-} -``` - -Your component (paste or 'skip'): _ -``` - -**Capture**: Component structure, props pattern, styling, TypeScript - -#### Q4: Naming Conventions -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Q 4/6: Naming conventions? -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Examples: - Files: kebab-case (user-profile.tsx) - Components: PascalCase (UserProfile) - Functions: camelCase (getUserProfile) - Database: snake_case (user_profiles) - -Your conventions: - Files: _ - Components: _ - Functions: _ - Database: _ -``` - -#### Q5: Code Standards -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Q 5/6: Code standards? -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Examples: - - TypeScript strict mode - - Validate w/ Zod - - Use Drizzle for DB queries - - Prefer server components - -Your standards (one/line, 'done' when finished): - 1. _ -``` - -#### Q6: Security Requirements -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Q 6/6: Security requirements? -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Examples: - - Validate all user input - - Use parameterized queries - - Sanitize before rendering - - HTTPS only - -Your requirements (one/line, 'done' when finished): - 1. _ -``` - ---- - -### Stage 3: Generate/Update Context - -**Preview**: -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Preview: technical-domain.md -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - - - -# Technical Domain - -**Purpose**: Tech stack, architecture, development patterns for this project. -**Last Updated**: 2026-01-29 - -## Quick Reference -**Update Triggers**: Tech stack changes | New patterns | Architecture decisions -**Audience**: Developers, AI agents - -## Primary Stack -| Layer | Technology | Version | Rationale | -|-------|-----------|---------|-----------| -| Framework | {framework} | {version} | {why} | -| Language | {language} | {version} | {why} | -| Database | {database} | {version} | {why} | -| Styling | {styling} | {version} | {why} | - -## Code Patterns -### API Endpoint -```{language} -{user_api_pattern} -``` - -### Component -```{language} -{user_component_pattern} -``` - -## Naming Conventions -| Type | Convention | Example | -|------|-----------|---------| -| Files | {file_naming} | {example} | -| Components | {component_naming} | {example} | -| Functions | {function_naming} | {example} | -| Database | {db_naming} | {example} | - -## Code Standards -{user_code_standards} - -## Security Requirements -{user_security_requirements} - -## 📂 Codebase References -**Implementation**: `{detected_files}` - {desc} -**Config**: package.json, tsconfig.json - -## Related Files -- Business Domain (example: business-domain.md) -- Decisions Log (example: decisions-log.md) - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Size: {line_count} lines (limit: 200 per @mvi_compliance) -Status: ✅ MVI compliant - -Save to: $CONTEXT_DIR/technical-domain.md - -Looks good? [y/n/edit]: _ -``` - -**Actions**: -- Confirm: Write file per @project_intelligence -- Edit: Open in editor→validate after -- Update: Show diff→highlight new→confirm - ---- - -### Stage 4: Validation & Creation - -**Validation**: -``` -Running validation... - -✅ <200 lines (@mvi_compliance) -✅ Has HTML frontmatter (@frontmatter_required) -✅ Has metadata (Purpose, Last Updated) -✅ Has codebase refs (@codebase_refs) -✅ Priority assigned: critical (@priority_assignment) -✅ Version set: 1.0 (@version_tracking) -✅ MVI compliant (<30s scannable) -✅ No duplication -``` - -**navigation.md preview** (also created/updated): -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Preview: navigation.md -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -# Project Intelligence - -| File | Description | Priority | -|------|-------------|----------| -| technical-domain.md | Tech stack & patterns | critical | - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -``` - -**Full creation plan**: -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -Files to write: -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - - CREATE $CONTEXT_DIR/technical-domain.md ({line_count} lines) - CREATE $CONTEXT_DIR/navigation.md ({nav_line_count} lines) - -Total: 2 files - -Proceed? [y/n]: _ -``` - ---- - -### Stage 5: Confirmation & Next Steps - -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -✅ Project Intelligence created successfully! -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Files created: - $CONTEXT_DIR/technical-domain.md - $CONTEXT_DIR/navigation.md - -Location: $CONTEXT_DIR -Agents now use YOUR patterns automatically! - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -What's next? -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -1. Test it: - opencode --agent OpenCoder - > "Create API endpoint" - (Uses YOUR pattern!) - -2. Review: cat $CONTEXT_DIR/technical-domain.md - -3. Add business context: /add-context --business - -4. Build: opencode --agent OpenCoder > "Create user auth system" - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -💡 Tip: Update context as project evolves -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -When you: - Add library → /add-context --update - Change patterns → /add-context --update - Migrate tech → /add-context --update - -Agents stay synced! - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -💡 Tip: Global patterns -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Want the same patterns across ALL your projects? - /add-context --global - → Saves to ~/.config/opencode/context/project-intelligence/ - → Acts as fallback for projects without local context - -Already have global patterns? Bring them into this project: - /context migrate - -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -📚 Learn More -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -- Project Intelligence: ~/.config/opencode/context/core/standards/project-intelligence.md -- MVI Principles: ~/.config/opencode/context/core/context-system/standards/mvi.md -- Context System: CONTEXT_SYSTEM_GUIDE.md -``` - ---- - -## Implementation Details - -### External Context Detection (Stage 0) - -**Process**: -1. Check: `ls .tmp/external-context.md .tmp/context-*.md .tmp/*-context.md 2>/dev/null` -2. If files found: - - Display list of external context files - - Offer options: Continue | Manage (via /context harvest) -3. If option 1 (Continue): - - Proceed to Stage 1 (detect existing project intelligence) - - External files remain in .tmp/ for later processing via `/context harvest` -4. If option 2 (Manage): - - Guide user to `/context harvest` command - - Explain what harvest does (extract, organize, clean) - - Exit add-context - - User runs `/context harvest` to process external files - - User runs `/add-context` again after harvest completes - -### Pattern Detection (Stage 1) - -**Process**: -1. Check: `ls $CONTEXT_DIR/` (path determined in Stage 0.5) -2. Read: `cat technical-domain.md` (if exists) -3. Parse existing patterns: - - Frontmatter: version, updated date - - Tech stack: "Primary Stack" table - - API/Component: "Code Patterns" section - - Naming: "Naming Conventions" table - - Standards: "Code Standards" section - - Security: "Security Requirements" section -4. Display summary -5. Offer options: Review/Add/Replace/Cancel - -### Pattern Review (Stage 1.5) - -**Per pattern**: -1. Show current value (parsed from file) -2. Ask: Keep | Update | Remove -3. If Update: Prompt for new value -4. Track changes in `changes_to_make[]` - -**After all reviewed**: -1. Show summary -2. Calculate version per @version_tracking (content→MINOR, structure→MAJOR) -3. Confirm -4. Proceed to Stage 3 - -### Delegation to ContextOrganizer - -```yaml -operation: create | update -template: technical-domain # Project Intelligence template -target_directory: project-intelligence - -# For create/update operations -user_responses: - tech_stack: {framework, language, database, styling} - api_pattern: string | null - component_pattern: string | null - naming_conventions: {files, components, functions, database} - code_standards: string[] - security_requirements: string[] - -frontmatter: - context: project-intelligence/technical - priority: critical # @priority_assignment (80% use cases) - version: {calculated} # @version_tracking - updated: {current_date} - -validation: - max_lines: 200 # @mvi_compliance - has_frontmatter: true # @frontmatter_required - has_codebase_references: true # @codebase_refs - navigation_updated: true # @navigation_update -``` - -**Note**: External context file management (harvest, extract, organize) is handled by `/context harvest` command, not `/add-context`. - -### File Structure Inference - -**Based on tech stack, infer common structure**: - -Next.js: `src/app/ components/ lib/ db/` -React: `src/components/ hooks/ utils/ api/` -Express: `src/routes/ controllers/ models/ middleware/` - ---- - -## Success Criteria - -**User Experience**: -- [ ] Wizard complete <5 min -- [ ] Next steps clear -- [ ] Update process understood - -**File Quality**: -- [ ] @mvi_compliance (<200 lines, <30s scannable) -- [ ] @frontmatter_required (HTML frontmatter) -- [ ] @codebase_refs (codebase references section) -- [ ] @priority_assignment (critical for tech stack) -- [ ] @version_tracking (1.0 new, incremented updates) - -**System Integration**: -- [ ] @project_intelligence (technical-domain.md in project-intelligence/) -- [ ] @navigation_update (navigation.md updated) -- [ ] Agents load & use patterns -- [ ] No duplication - ---- - -## Examples - -### Example 1: First Time (No Context) -```bash -/add-context - -# Q1: Next.js + TypeScript + PostgreSQL + Tailwind -# Q2: [pastes Next.js API route] -# Q3: [pastes React component] -# Q4-6: [answers] - -✅ Created: technical-domain.md, navigation.md -``` - -### Example 2: Review & Update -```bash -/add-context - -# Found existing → Choose "1. Review and update" -# Pattern 1: Tech Stack → Update (Next.js 14 → 15) -# Pattern 2-6: Keep - -✅ Updated: Version 1.2 → 1.3 -``` - -### Example 3: Quick Update -```bash -/add-context --tech-stack - -# Current: Next.js 15 + TypeScript + PostgreSQL + Tailwind -# New: Next.js 15 + TypeScript + PostgreSQL + Drizzle + Tailwind - -✅ Version 1.4 → 1.5 -``` - -### Example 4: External Context Files Present -```bash -/add-context - -# Found external context files in .tmp/ -# 📄 .tmp/external-context.md (2.4 KB) -# 📄 .tmp/api-patterns.md (1.8 KB) -# -# Options: -# 1. Continue with /add-context (ignore external files for now) -# 2. Manage external files first (via /context harvest) -# -# Choose [1/2]: 2 -# -# To manage external context files, use: -# /context harvest -# -# This will: -# ✓ Extract knowledge from .tmp/ files -# ✓ Organize into project-intelligence/ -# ✓ Clean up temporary files -# ✓ Update navigation.md -# -# After harvesting, run /add-context again. -``` - -### Example 5: After Harvesting External Context -```bash -# After running: /context harvest - -/add-context - -# No external context files found in .tmp/ -# Proceeding to detect existing project intelligence... -# -# ✅ Created: technical-domain.md (merged with harvested patterns) -``` - ---- - -## Error Handling - -**Invalid Input**: -``` -⚠️ Invalid input -Expected: Tech stack description -Got: [empty] - -Example: Next.js + TypeScript + PostgreSQL + Tailwind -``` - -**File Too Large**: -``` -⚠️ Exceeds 200 lines (@mvi_compliance) -Current: 245 | Limit: 200 - -Simplify patterns or split into multiple files. -``` - -**Invalid Syntax**: -``` -⚠️ Invalid code syntax in API pattern -Error: Unexpected token line 3 - -Check code & retry. -``` - ---- - -## Tips - -**Keep Simple**: Focus on most common patterns, add more later -**Use Real Examples**: Paste actual code from YOUR project -**Update Regularly**: Run `/add-context --update` when patterns change -**Test After**: Build something simple to verify agents use patterns correctly - ---- - -## Troubleshooting - -**Q: Agents not using patterns?** -A: Check file exists, <200 lines. Run `/context validate` - -**Q: See what's in context?** -A: `cat .opencode/context/project-intelligence/technical-domain.md` (local) or `cat ~/.config/opencode/context/project-intelligence/technical-domain.md` (global) - -**Q: Multiple context files?** -A: Yes! Create in your project-intelligence directory. Agents load all. - -**Q: Remove pattern?** -A: Edit directly: `nano ~/.config/opencode/context/project-intelligence/technical-domain.md` - -**Q: Share w/ team?** -A: Yes! Use local install (`.opencode/context/project-intelligence/`) and commit to repo. Team members get your patterns automatically. - -**Q: Local vs global?** -A: Local (`.opencode/`) = project-specific, committed to git, team-shared. Global (`~/.config/opencode/`) = personal defaults across all projects. Local overrides global. - -**Q: Installed globally but want project patterns?** -A: Run `/add-context` (defaults to local). Creates `.opencode/context/project-intelligence/` in your project even if OAC was installed globally. - -**Q: Have external context files in .tmp/?** -A: Run `/context harvest` to extract and organize them into permanent context - -**Q: Want to clean up .tmp/ files?** -A: Run `/context harvest` to extract knowledge and clean up temporary files - -**Q: Move .tmp/ files to permanent context?** -A: Run `/context harvest` to extract and organize them - -**Q: Update external context files?** -A: Edit directly: `nano .tmp/external-context.md` then run `/context harvest` - -**Q: Remove specific external file?** -A: Delete directly: `rm .tmp/external-context.md` then run `/context harvest` - ---- - -## Related Commands - -- `/context` - Manage context files (harvest, organize, validate) -- `/context validate` - Check integrity -- `/context map` - View structure diff --git a/command/analyze-patterns.md b/command/analyze-patterns.md deleted file mode 100644 index 81c5d48..0000000 --- a/command/analyze-patterns.md +++ /dev/null @@ -1,221 +0,0 @@ ---- -id: analyze-patterns -name: analyze-patterns -description: "Analyze codebase for patterns and similar implementations" -type: command -category: analysis -version: 1.0.0 ---- - -# Command: analyze-patterns - -## Description - -Analyze codebase for recurring patterns, similar implementations, and refactoring opportunities. Replaces codebase-pattern-analyst subagent functionality with a command-based interface. - -## Usage - -```bash -/analyze-patterns [--pattern=] [--language=] [--depth=] [--output=] -``` - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| `--pattern` | string | No | Pattern name or regex to search for (e.g., "singleton", "factory", "error-handling") | -| `--language` | string | No | Filter by language: js, ts, py, go, rust, java, etc. | -| `--depth` | string | No | Search depth: shallow (current dir) \| medium (src/) \| deep (entire repo) | -| `--output` | string | No | Output format: text (default) \| json \| markdown | - -## Behavior - -### Pattern Search -- Searches codebase for pattern matches using regex + semantic analysis -- Identifies similar implementations across files -- Groups results by pattern type + similarity score -- Suggests refactoring opportunities - -### Analysis Output -- Pattern occurrences with file locations + line numbers -- Similarity metrics (how similar are implementations?) -- Refactoring suggestions (consolidate, extract, standardize) -- Code quality insights (duplication, inconsistency) - -### Result Format -``` -Pattern Analysis Report -======================= - -Pattern: [pattern_name] -Occurrences: [count] -Files: [file_list] - -Implementations: - 1. [file:line] - [description] (similarity: X%) - 2. [file:line] - [description] (similarity: Y%) - ... - -Refactoring Suggestions: - - [suggestion 1] - - [suggestion 2] - ... - -Quality Insights: - - [insight 1] - - [insight 2] - ... -``` - -## Examples - -### Find all error handling patterns -```bash -/analyze-patterns --pattern="error-handling" --language=ts -``` - -### Analyze factory patterns across codebase -```bash -/analyze-patterns --pattern="factory" --depth=deep --output=json -``` - -### Find similar API endpoint implementations -```bash -/analyze-patterns --pattern="api-endpoint" --language=js --output=markdown -``` - -### Search for singleton patterns -```bash -/analyze-patterns --pattern="singleton" --depth=medium -``` - -## Implementation - -### Delegation -- Delegates to: **opencoder** (primary) -- Uses context search capabilities for pattern matching -- Returns structured pattern analysis results - -### Context Requirements -- Codebase structure + file organization -- Language-specific patterns + conventions -- Project-specific naming conventions -- Existing refactoring guidelines - -### Processing Steps -1. Parse command parameters -2. Validate pattern syntax (regex or predefined) -3. Search codebase using glob + grep tools -4. Analyze semantic similarity of matches -5. Group results by pattern + similarity -6. Generate refactoring suggestions -7. Format output per requested format -8. Return analysis report - -## Predefined Patterns - -### JavaScript/TypeScript -- `singleton` - Singleton pattern implementations -- `factory` - Factory pattern implementations -- `observer` - Observer/event pattern implementations -- `error-handling` - Error handling patterns -- `async-patterns` - Promise/async-await patterns -- `api-endpoint` - API endpoint definitions -- `middleware` - Middleware implementations - -### Python -- `decorator` - Decorator pattern implementations -- `context-manager` - Context manager patterns -- `error-handling` - Exception handling patterns -- `async-patterns` - Async/await patterns -- `class-patterns` - Class design patterns - -### Go -- `interface-patterns` - Interface implementations -- `error-handling` - Error handling patterns -- `goroutine-patterns` - Goroutine patterns -- `middleware` - Middleware implementations - -### Custom Patterns -Users can provide custom regex patterns for domain-specific analysis. - -## Output Formats - -### Text (Default) -Human-readable report with clear sections and formatting - -### JSON -Structured data for programmatic processing: -```json -{ - "pattern": "error-handling", - "occurrences": 12, - "files": ["file1.ts", "file2.ts"], - "implementations": [ - { - "file": "file1.ts", - "line": 42, - "description": "try-catch block", - "similarity": 0.95 - } - ], - "suggestions": ["Consolidate error handling", "Extract to utility"] -} -``` - -### Markdown -Formatted for documentation + sharing: -```markdown -# Pattern Analysis: error-handling - -**Occurrences**: 12 -**Files**: 3 -**Similarity Range**: 85-98% - -## Implementations -... -``` - -## Integration - -### Registry Entry -```json -{ - "id": "analyze-patterns", - "name": "analyze-patterns", - "type": "command", - "category": "analysis", - "description": "Analyze codebase for patterns and similar implementations", - "delegates_to": ["opencoder"], - "parameters": ["pattern", "language", "depth", "output"] -} -``` - -### Profile Assignment -- **Developer Profile**: ✅ Included -- **Full Profile**: ✅ Included -- **Advanced Profile**: ✅ Included -- **Business Profile**: ❌ Not included - -## Notes - -- Replaces `codebase-pattern-analyst` subagent functionality -- Command-based interface is more flexible + discoverable -- Supports both predefined + custom patterns -- Results can be exported for documentation -- Integrates with refactoring workflows - ---- - -## Validation Checklist - -✅ Command structure defined -✅ Parameters documented -✅ Behavior specified -✅ Examples provided -✅ Implementation details included -✅ Output formats defined -✅ Integration ready -✅ Ready for registry integration - -**Status**: Ready for deployment diff --git a/command/clean.md b/command/clean.md deleted file mode 100644 index 094e59c..0000000 --- a/command/clean.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -description: Clean the codebase or current working task in focus via Prettier, Import Sorter, ESLint, and TypeScript Compiler ---- - -# Code Quality Cleanup - -You are a code quality specialist. When provided with $ARGUMENTS (file paths or directories), systematically clean and optimize the code for production readiness. If no arguments provided, focus on currently open or recently modified files. - -## Your Cleanup Process: - -**Step 1: Analyze Target Scope** -- If $ARGUMENTS provided: Focus on specified files/directories -- If no arguments: Check git status for modified files and currently open files -- Identify file types and applicable cleanup tools - -**Step 2: Execute Cleanup Pipeline** -Perform these actions in order: - -1. **Remove Debug Code** - - Strip console.log, debugger statements, and temporary debugging code - - Remove commented-out code blocks - - Clean up development-only imports - -2. **Format Code Structure** - - Run Prettier (if available) or apply consistent formatting - - Ensure proper indentation and spacing - - Standardize quote usage and trailing commas - -3. **Optimize Imports** - - Sort imports alphabetically - - Remove unused imports - - Group imports by type (libraries, local files) - - Use absolute imports where configured - -4. **Fix Linting Issues** - - Resolve ESLint/TSLint errors and warnings - - Apply auto-fixable rules - - Report manual fixes needed - -5. **Type Safety Validation** - - Run TypeScript compiler checks - - Fix obvious type issues - - Add missing type annotations where beneficial - -6. **Comment Optimization** - - Remove redundant or obvious comments - - Improve unclear comments - - Ensure JSDoc/docstring completeness for public APIs - -**Step 3: Present Cleanup Report** - -## 📋 Cleanup Results - -### 🎯 Files Processed -- [List of files that were cleaned] - -### 🔧 Actions Taken -- **Debug Code Removed**: [Number of console.logs, debuggers removed] -- **Formatting Applied**: [Files formatted] -- **Imports Optimized**: [Unused imports removed, sorting applied] -- **Linting Issues Fixed**: [Auto-fixed issues count] -- **Type Issues Resolved**: [TypeScript errors fixed] -- **Comments Improved**: [Redundant comments removed, unclear ones improved] - -### 🚨 Manual Actions Needed -- [List any issues that require manual intervention] - -### ✅ Quality Improvements -- [Summary of overall code quality improvements made] - -## Quality Standards Applied: -- **Production Ready**: Remove all debugging and development artifacts -- **Consistent Style**: Apply project formatting standards -- **Type Safety**: Ensure strong typing where applicable -- **Clean Imports**: Optimize dependency management -- **Clear Documentation**: Improve code readability through better comments diff --git a/command/commit.md b/command/commit.md deleted file mode 100644 index 15318cc..0000000 --- a/command/commit.md +++ /dev/null @@ -1,160 +0,0 @@ ---- -description: Create well-formatted commits with conventional commit messages and emoji ---- - -# Commit Command - -You are an AI agent that helps create well-formatted git commits with conventional commit messages and emoji icons, follow these instructions exactly. Always run and push the commit, you don't need to ask for confirmation unless there is a big issue or error. - -## Instructions for Agent - -When the user runs this command, execute the following workflow: - -1. **Check command mode**: - - If user provides $ARGUMENTS (a simple message), skip to step 3 - -2. **Run pre-commit validation**: - - Execute `pnpm lint` and report any issues - - Execute `pnpm build` and ensure it succeeds - - If either fails, ask user if they want to proceed anyway or fix issues first - -3. **Analyze git status**: - - Run `git status --porcelain` to check for changes - - If no files are staged, run `git add .` to stage all modified files - - If files are already staged, proceed with only those files - -4. **Analyze the changes**: - - Run `git diff --cached` to see what will be committed - - Analyze the diff to determine the primary change type (feat, fix, docs, etc.) - - Identify the main scope and purpose of the changes - -5. **Generate commit message**: - - Choose appropriate emoji and type from the reference below - - Create message following format: ` : ` - - Keep description concise, clear, and in imperative mood - - Show the proposed message to user for confirmation - -6. **Execute the commit**: - - Run `git commit -m ""` - - Display the commit hash and confirm success - - Provide brief summary of what was committed - -## Commit Message Guidelines - -When generating commit messages, follow these rules: - -- **Atomic commits**: Each commit should contain related changes that serve a single purpose -- **Imperative mood**: Write as commands (e.g., "add feature" not "added feature") -- **Concise first line**: Keep under 72 characters -- **Conventional format**: Use ` : ` where type is one of: - - `feat`: A new feature - - `fix`: A bug fix - - `docs`: Documentation changes - - `style`: Code style changes (formatting, etc.) - - `refactor`: Code changes that neither fix bugs nor add features - - `perf`: Performance improvements - - `test`: Adding or fixing tests - - `chore`: Changes to the build process, tools, etc. -- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature") -- **Concise first line**: Keep the first line under 72 characters -- **Emoji**: Each commit type is paired with an appropriate emoji: - - ✨ `feat`: New feature - - 🐛 `fix`: Bug fix - - 📝 `docs`: Documentation - - 💄 `style`: Formatting/style - - ♻️ `refactor`: Code refactoring - - ⚡️ `perf`: Performance improvements - - ✅ `test`: Tests - - 🔧 `chore`: Tooling, configuration - - 🚀 `ci`: CI/CD improvements - - 🗑️ `revert`: Reverting changes - - 🧪 `test`: Add a failing test - - 🚨 `fix`: Fix compiler/linter warnings - - 🔒️ `fix`: Fix security issues - - 👥 `chore`: Add or update contributors - - 🚚 `refactor`: Move or rename resources - - 🏗️ `refactor`: Make architectural changes - - 🔀 `chore`: Merge branches - - 📦️ `chore`: Add or update compiled files or packages - - ➕ `chore`: Add a dependency - - ➖ `chore`: Remove a dependency - - 🌱 `chore`: Add or update seed files - - 🧑‍💻 `chore`: Improve developer experience - - 🧵 `feat`: Add or update code related to multithreading or concurrency - - 🔍️ `feat`: Improve SEO - - 🏷️ `feat`: Add or update types - - 💬 `feat`: Add or update text and literals - - 🌐 `feat`: Internationalization and localization - - 👔 `feat`: Add or update business logic - - 📱 `feat`: Work on responsive design - - 🚸 `feat`: Improve user experience / usability - - 🩹 `fix`: Simple fix for a non-critical issue - - 🥅 `fix`: Catch errors - - 👽️ `fix`: Update code due to external API changes - - 🔥 `fix`: Remove code or files - - 🎨 `style`: Improve structure/format of the code - - 🚑️ `fix`: Critical hotfix - - 🎉 `chore`: Begin a project - - 🔖 `chore`: Release/Version tags - - 🚧 `wip`: Work in progress - - 💚 `fix`: Fix CI build - - 📌 `chore`: Pin dependencies to specific versions - - 👷 `ci`: Add or update CI build system - - 📈 `feat`: Add or update analytics or tracking code - - ✏️ `fix`: Fix typos - - ⏪️ `revert`: Revert changes - - 📄 `chore`: Add or update license - - 💥 `feat`: Introduce breaking changes - - 🍱 `assets`: Add or update assets - - ♿️ `feat`: Improve accessibility - - 💡 `docs`: Add or update comments in source code - - 🗃️ `db`: Perform database related changes - - 🔊 `feat`: Add or update logs - - 🔇 `fix`: Remove logs - - 🤡 `test`: Mock things - - 🥚 `feat`: Add or update an easter egg - - 🙈 `chore`: Add or update .gitignore file - - 📸 `test`: Add or update snapshots - - ⚗️ `experiment`: Perform experiments - - 🚩 `feat`: Add, update, or remove feature flags - - 💫 `ui`: Add or update animations and transitions - - ⚰️ `refactor`: Remove dead code - - 🦺 `feat`: Add or update code related to validation - - ✈️ `feat`: Improve offline support - -## Reference: Good Commit Examples - -Use these as examples when generating commit messages: -- ✨ feat: add user authentication system -- 🐛 fix: resolve memory leak in rendering process -- 📝 docs: update API documentation with new endpoints -- ♻️ refactor: simplify error handling logic in parser -- 🚨 fix: resolve linter warnings in component files -- 🧑‍💻 chore: improve developer tooling setup process -- 👔 feat: implement business logic for transaction validation -- 🩹 fix: address minor styling inconsistency in header -- 🚑️ fix: patch critical security vulnerability in auth flow -- 🎨 style: reorganize component structure for better readability -- 🔥 fix: remove deprecated legacy code -- 🦺 feat: add input validation for user registration form -- 💚 fix: resolve failing CI pipeline tests -- 📈 feat: implement analytics tracking for user engagement -- 🔒️ fix: strengthen authentication password requirements -- ♿️ feat: improve form accessibility for screen readers - -Example commit sequence: -- ✨ feat: add user authentication system -- 🐛 fix: resolve memory leak in rendering process -- 📝 docs: update API documentation with new endpoints -- ♻️ refactor: simplify error handling logic in parser -- 🚨 fix: resolve linter warnings in component files -- ✅ test: add unit tests for authentication flow - -## Agent Behavior Notes - -- **Error handling**: If validation fails, give user option to proceed or fix issues first -- **Auto-staging**: If no files are staged, automatically stage all changes with `git add .` -- **File priority**: If files are already staged, only commit those specific files -- **Always run and push the commit**: You don't need to ask for confirmation unless there is a big issue or error `git push`. -- **Message quality**: Ensure commit messages are clear, concise, and follow conventional format -- **Success feedback**: After successful commit, show commit hash and brief summary diff --git a/command/context.md b/command/context.md deleted file mode 100644 index 8241ef6..0000000 --- a/command/context.md +++ /dev/null @@ -1,309 +0,0 @@ ---- -description: Context system manager - harvest summaries, extract knowledge, organize context -tags: - - context - - knowledge-management - - harvest -dependencies: - - subagent:context-organizer - - subagent:contextscout ---- - -# Context Manager - - - - Files MUST be <200 lines. Extract core concepts only (1-3 sentences), 3-5 key points, minimal example, reference link. - - - - ALWAYS present approval UI before deleting/archiving files. Letter-based selection (A B C or 'all'). NEVER auto-delete. - - - - ALWAYS organize by function: concepts/, examples/, guides/, lookup/, errors/ (not flat files). - - - - ALWAYS read required context files from ~/.config/opencode/context/core/context-system/ BEFORE executing operations. - - - - - - - Files <200 lines (@critical_rules.mvi_strict) - - Show approval before cleanup (@critical_rules.approval_gate) - - Function-based structure (@critical_rules.function_structure) - - Load context before operations (@critical_rules.lazy_load) - - - - Harvest (default), Extract, Organize, Update workflows - - - - Cross-references, validation, navigation - - - Tier 1 always overrides Tier 2/3. - - - -**Arguments**: `$ARGUMENTS` - ---- - -## Default Behavior (No Arguments) - -When invoked without arguments: `/context` - - - - Scan workspace for summary files: - - *OVERVIEW.md, *SUMMARY.md, SESSION-*.md, CONTEXT-*.md - - Files in .tmp/ directory - - Files >2KB in root directory - - - - Show what was found: - ``` - Quick scan results: - - Found 3 summary files: - 📄 CONTEXT-SYSTEM-OVERVIEW.md (4.2 KB) - 📄 SESSION-auth-work.md (1.8 KB) - 📄 .tmp/NOTES.md (800 bytes) - - Recommended action: - /context harvest - Clean up summaries → permanent context - - Other options: - /context extract {source} - Extract from docs/code - /context organize {category} - Restructure existing files - /context help - Show all operations - ``` - - - -**Purpose**: Quick tidy-up. Default assumes you want to harvest summaries and compact workspace. - ---- - -## Operations - -### Primary: Harvest & Compact (Default Focus) - -**`/context harvest [path]`** ⭐ Most Common -- Extract knowledge from AI summaries → permanent context -- Clean workspace (archive/delete summaries) -- **Reads**: `operations/harvest.md` + `standards/mvi.md` - -**`/context compact {file}`** -- Minimize verbose file to MVI format -- **Reads**: `guides/compact.md` + `standards/mvi.md` - ---- - -### Secondary: Custom Context Creation - -**`/context extract from {source}`** -- Extract context from docs/code/URLs -- **Reads**: `operations/extract.md` + `standards/mvi.md` + `guides/compact.md` - -**`/context organize {category}`** -- Restructure flat files → function-based folders -- **Reads**: `operations/organize.md` + `standards/structure.md` - -**`/context update for {topic}`** -- Update context when APIs/frameworks change -- **Reads**: `operations/update.md` + `guides/workflows.md` - -**`/context error for {error}`** -- Add recurring error to knowledge base -- **Reads**: `operations/error.md` + `standards/templates.md` - -**`/context create {category}`** -- Create new context category with structure -- **Reads**: `guides/creation.md` + `standards/structure.md` + `standards/templates.md` - ---- - -### Migration - -**`/context migrate`** -- Copy project-intelligence from global (`~/.config/opencode/context/`) to local (`.opencode/context/`) -- For users who installed globally but want project-specific, git-committed context -- Shows diff if local files already exist, asks before overwriting -- Optionally cleans up global project-intelligence after migration -- **Reads**: `standards/mvi.md` - ---- - -### Utility Operations - -**`/context map [category]`** -- View current context structure, file counts - -**`/context validate`** -- Check integrity, references, file sizes - -**`/context help`** -- Show all operations with examples - ---- - -## Lazy Loading Strategy - - - - Read: operations/harvest.md, standards/mvi.md - - - - Read: operations/harvest.md, standards/mvi.md, guides/workflows.md - - - - Read: guides/compact.md, standards/mvi.md - - - - Read: operations/extract.md, standards/mvi.md, guides/compact.md, guides/workflows.md - - - - Read: operations/organize.md, standards/structure.md, guides/workflows.md - - - - Read: operations/update.md, guides/workflows.md, standards/mvi.md - - - - Read: operations/error.md, standards/templates.md, guides/workflows.md - - - - Read: guides/creation.md, standards/structure.md, standards/templates.md - - - - Read: standards/mvi.md - - - -**All files located in**: `~/.config/opencode/context/core/context-system/` - ---- - -## Subagent Routing - - - - - Pass: operation name, arguments, lazy load map - Subagent loads: Required context files from ~/.config/opencode/context/core/context-system/ - Subagent executes: Multi-stage workflow per operation - - - - Pass: operation name, arguments - Subagent executes: Read-only analysis and reporting - - - ---- - -## Quick Reference - -### Structure -``` -~/.config/opencode/context/core/context-system/ -├── operations/ # How to do things (harvest, extract, organize, update) -├── standards/ # What to follow (mvi, structure, templates) -└── guides/ # Step-by-step (workflows, compact, creation) -``` - -### MVI Principle (Quick) -- Core concept: 1-3 sentences -- Key points: 3-5 bullets -- Minimal example: <10 lines -- Reference link: to full docs -- File size: <200 lines - -### Function-Based Structure (Quick) -``` -{category}/ -├── navigation.md # Navigation -├── concepts/ # What it is -├── examples/ # Working code -├── guides/ # How to -├── lookup/ # Quick reference -└── errors/ # Common issues -``` - ---- - -## Examples - -### Default (Quick Scan) -```bash -/context -# Scans workspace, suggests harvest if summaries found -``` - -### Harvest Summaries -```bash -/context harvest -/context harvest .tmp/ -/context harvest OVERVIEW.md -``` - -### Extract from Docs -```bash -/context extract from docs/api.md -/context extract from https://react.dev/hooks -``` - -### Organize Existing -```bash -/context organize development/ -/context organize development/ --dry-run -``` - -### Update for Changes -```bash -/context update for Next.js 15 -/context update for React 19 breaking changes -``` - -### Migrate Global to Local -```bash -/context migrate -# Copies project-intelligence from ~/.config/opencode/context/ to ~/.config/opencode/context/ -# Shows what will be copied, asks for approval before proceeding -``` - ---- - -## Success Criteria - -After any operation: -- [ ] All files <200 lines? (@critical_rules.mvi_strict) -- [ ] Function-based structure used? (@critical_rules.function_structure) -- [ ] Approval UI shown for destructive ops? (@critical_rules.approval_gate) -- [ ] Required context loaded? (@critical_rules.lazy_load) -- [ ] navigation.md updated? -- [ ] Files scannable in <30 seconds? - ---- - -## Full Documentation - -**Context System Location**: `~/.config/opencode/context/core/context-system/` - -**Structure**: -- `operations/` - Detailed operation workflows -- `standards/` - MVI, structure, templates -- `guides/` - Interactive examples, creation standards - -**Read before using**: `standards/mvi.md` (understand Minimal Viable Information principle) diff --git a/command/openagents/check-context-deps.md b/command/openagents/check-context-deps.md deleted file mode 100644 index d36cd74..0000000 --- a/command/openagents/check-context-deps.md +++ /dev/null @@ -1,433 +0,0 @@ ---- -description: Validate context file dependencies across agents and registry -tags: - - registry - - validation - - context - - dependencies - - openagents -dependencies: - - command:analyze-patterns ---- - -# Check Context Dependencies - -**Purpose**: Ensure agents properly declare their context file dependencies in frontmatter and registry. - -**Arguments**: `$ARGUMENTS` - ---- - -## What It Does - -Validates consistency between: -1. **Actual usage** - Context files referenced in agent prompts -2. **Declared dependencies** - Dependencies in agent frontmatter -3. **Registry entries** - Dependencies in registry.json - -**Identifies**: -- ✅ Missing dependency declarations (agents use context but don't declare it) -- ✅ Unused context files (exist but no agent references them) -- ✅ Broken references (referenced but don't exist) -- ✅ Format inconsistencies (wrong dependency format) - ---- - -## Usage - -```bash -# Analyze all agents -/check-context-deps - -# Analyze specific agent -/check-context-deps contextscout - -# Auto-fix missing dependencies -/check-context-deps --fix - -# Verbose output (show all reference locations) -/check-context-deps --verbose - -# Combine flags -/check-context-deps contextscout --verbose -``` - ---- - -## Workflow - - - - Scan agent files for context references: - - **Search patterns**: - - `~/.config/opencode/context/` (direct path references) - - `@~/.config/opencode/context/` (@ symbol references) - - `context:` (dependency declarations in frontmatter) - - **Locations**: - - `.opencode/agent/**/*.md` (all agents and subagents) - - `.opencode/command/**/*.md` (commands that use context) - - **Extract**: - - Agent/command ID - - Context file path - - Line number - - Reference type (path, @-reference, dependency) - - - - For each agent found, check registry.json: - - ```bash - jq '.components.agents[] | select(.id == "AGENT_ID") | .dependencies' registry.json - jq '.components.subagents[] | select(.id == "AGENT_ID") | .dependencies' registry.json - ``` - - **Verify**: - - Does the agent have a dependencies array? - - Are context file references declared as `context:core/standards/code`? - - Are the dependency formats correct (`context:path/to/file`)? - - - - For each context file referenced: - - **Check existence**: - ```bash - test -f ~/.config/opencode/context/core/standards/code-quality.md - ``` - - **Check registry**: - ```bash - jq '.components.contexts[] | select(.id == "core/standards/code")' registry.json - ``` - - **Identify issues**: - - Context file referenced but doesn't exist - - Context file exists but not in registry - - Context file in registry but never used - - - - Generate comprehensive report: - - ```markdown - # Context Dependency Analysis Report - - ## Summary - - Agents scanned: 25 - - Context files referenced: 12 - - Missing dependencies: 8 - - Unused context files: 2 - - Missing context files: 0 - - ## Missing Dependencies (agents using context but not declaring) - - ### opencoder - **Uses but not declared**: - - context:core/standards/code (referenced 3 times) - - Line 64: "Code tasks → ~/.config/opencode/context/core/standards/code-quality.md (MANDATORY)" - - Line 170: "Read ~/.config/opencode/context/core/standards/code-quality.md NOW" - - Line 229: "NEVER execute write/edit without loading required context first" - - **Current dependencies**: subagent:task-manager, subagent:coder-agent - **Recommended fix**: Add to frontmatter: - ```yaml - dependencies: - - subagent:task-manager - - subagent:coder-agent - - context:core/standards/code # ADD THIS - ``` - - ### openagent - **Uses but not declared**: - - context:core/standards/code (referenced 5 times) - - context:core/standards/docs (referenced 3 times) - - context:core/standards/tests (referenced 3 times) - - context:core/workflows/review (referenced 2 times) - - context:core/workflows/delegation (referenced 4 times) - - **Recommended fix**: Add to frontmatter: - ```yaml - dependencies: - - subagent:task-manager - - subagent:documentation - - context:core/standards/code - - context:core/standards/docs - - context:core/standards/tests - - context:core/workflows/review - - context:core/workflows/delegation - ``` - - ## Unused Context Files (exist but no agent references them) - - - context:core/standards/analysis (0 references) - - context:core/workflows/sessions (0 references) - - **Recommendation**: Consider removing or documenting intended use - - ## Missing Context Files (referenced but don't exist) - - None found ✅ - - ## Context File Usage Map - - | Context File | Used By | Reference Count | - |--------------|---------|-----------------| - | core/standards/code | opencoder, openagent, frontend-specialist, reviewer | 15 | - | core/standards/docs | openagent, documentation, technical-writer | 8 | - | core/standards/tests | openagent, tester | 6 | - | core/workflows/delegation | openagent, task-manager | 5 | - | core/workflows/review | openagent, reviewer | 4 | - - --- - - ## Next Steps - - 1. Review missing dependencies above - 2. Run `/check-context-deps --fix` to auto-update frontmatter - 3. Run `./scripts/registry/auto-detect-components.sh` to update registry - 4. Verify with `./scripts/registry/validate-registry.sh` - ``` - - - - For each agent with missing context dependencies: - - 1. Read the agent file - 2. Parse frontmatter YAML - 3. Add missing context dependencies to dependencies array - 4. Preserve existing dependencies - 5. Write updated file - 6. Report what was changed - - **Example**: - ```diff - --- - id: opencoder - dependencies: - - subagent:task-manager - - subagent:coder-agent - + - context:core/standards/code - --- - ``` - - **Safety**: - - Only add dependencies that are actually referenced in the file - - Don't remove existing dependencies - - Preserve frontmatter formatting - - Show diff before applying (if interactive) - - - ---- - -## Implementation Details - -### Search Patterns - -**Find direct path references**: -```bash -grep -rn "\~/.config/opencode/context/" .opencode/agent/ .opencode/command/ -``` - -**Find @ references**: -```bash -grep -rn "@\~/.config/opencode/context/" .opencode/agent/ .opencode/command/ -``` - -**Find dependency declarations**: -```bash -grep -rn "^\s*-\s*context:" .opencode/agent/ .opencode/command/ -``` - -### Path Normalization - -**Convert to dependency format**: -- `~/.config/opencode/context/core/standards/code-quality.md` → `context:core/standards/code` -- `@~/.config/opencode/context/openagents-repo/quick-start.md` → `context:openagents-repo/quick-start` -- `context/core/standards/code` → `context:core/standards/code` - -**Rules**: -1. Strip `.opencode/` prefix -2. Strip `.md` extension -3. Add `context:` prefix for dependencies - -### Registry Lookup - -**Check if context file is in registry**: -```bash -jq '.components.contexts[] | select(.id == "core/standards/code")' registry.json -``` - -**Get agent dependencies**: -```bash -jq '.components.agents[] | select(.id == "opencoder") | .dependencies[]?' registry.json -``` - ---- - -## Delegation - -This command delegates to an analysis agent to perform the work: - -```javascript -task( - subagent_type="PatternAnalyst", - description="Analyze context dependencies", - prompt=` - Analyze context file usage across all agents in this repository. - - TASK: - 1. Use grep to find all references to context files in: - - .opencode/agent/**/*.md - - .opencode/command/**/*.md - - 2. Search for these patterns: - - "~/.config/opencode/context/core/" (direct paths) - - "@~/.config/opencode/context/" (@ references) - - "context:" in frontmatter (dependency declarations) - - 3. For each agent file found: - - Extract agent ID from frontmatter - - List all context files it references - - Check registry.json for declared dependencies - - Identify missing dependency declarations - - 4. For each context file in ~/.config/opencode/context/core/: - - Count how many agents reference it - - Check if it exists in registry.json - - Identify unused context files - - 5. Generate a comprehensive report showing: - - Agents with missing context dependencies - - Unused context files - - Missing context files (referenced but don't exist) - - Context file usage map (which agents use which files) - - ${ARGUMENTS.includes('--fix') ? ` - 6. AUTO-FIX MODE: - - Update agent frontmatter to add missing context dependencies - - Use format: context:core/standards/code - - Preserve existing dependencies - - Show what was changed - ` : ''} - - ${ARGUMENTS.includes('--verbose') ? ` - VERBOSE MODE: Include all reference locations (file:line) in report - ` : ''} - - ${ARGUMENTS.length > 0 && !ARGUMENTS.includes('--') ? ` - FILTER: Only analyze agent: ${ARGUMENTS[0]} - ` : ''} - - REPORT FORMAT: - - Summary statistics - - Missing dependencies by agent (with recommended fixes) - - Unused context files - - Context file usage map - - Next steps - - DO NOT make changes without --fix flag. - ALWAYS show what would be changed before applying fixes. - ` -) -``` - ---- - -## Examples - -### Example 1: Basic Analysis - -```bash -/check-context-deps -``` - -**Output**: -``` -Analyzing context file usage across 25 agents... - -Found 8 agents with missing context dependencies: -- opencoder: missing context:core/standards/code -- openagent: missing 5 context dependencies -- frontend-specialist: missing context:core/standards/code -... - -Run /check-context-deps --fix to auto-update frontmatter -``` - -### Example 2: Analyze Specific Agent - -```bash -/check-context-deps contextscout -``` - -**Output**: -``` -Analyzing agent: contextscout - -Context files referenced: -✓ ~/.config/opencode/context/core/context-system.md (1 reference) - - Line 15: "Load: context:core/context-system" -✓ ~/.config/opencode/context/core/context-system/standards/mvi.md (2 references) - - Line 16: "Load: context:core/context-system/standards/mvi" - - Line 89: "MVI-aware prioritization" - -Registry dependencies: -✓ context:core/context-system DECLARED -✓ context:core/context-system/standards/mvi DECLARED - -All dependencies properly declared ✅ -``` - -### Example 3: Auto-Fix - -```bash -/check-context-deps --fix -``` - -**Output**: -``` -Analyzing and fixing context dependencies... - -Updated opencoder: -+ Added: context:core/standards/code - -Updated openagent: -+ Added: context:core/standards/code -+ Added: context:core/standards/docs -+ Added: context:core/standards/tests -+ Added: context:core/workflows/review -+ Added: context:core/workflows/delegation - -Total: 2 agents updated, 6 dependencies added - -Next: Run ./scripts/registry/auto-detect-components.sh to update registry -``` - ---- - -## Success Criteria - -✅ All agents that reference context files have them declared in dependencies -✅ All context files in registry are actually used by at least one agent -✅ No broken references (context files referenced but don't exist) -✅ Dependency format is consistent (`context:path/to/file`) - ---- - -## Notes - -- **Read-only by default** - Only reports findings, doesn't modify files -- **Use `--fix` to update** - Auto-adds missing dependencies to frontmatter -- **After fixing** - Run `./scripts/registry/auto-detect-components.sh --auto-add` to sync registry -- **Dependency format** - `context:path/to/file` (no `.opencode/` prefix, no `.md` extension) -- **Scans both** - Direct path references and @ references - -## Related - -- **Registry validation**: `./scripts/registry/validate-registry.sh` -- **Auto-detect components**: `./scripts/registry/auto-detect-components.sh` -- **Context guide**: `~/.config/opencode/context/openagents-repo/quality/registry-dependencies.md` diff --git a/command/optimize.md b/command/optimize.md deleted file mode 100644 index 911984c..0000000 --- a/command/optimize.md +++ /dev/null @@ -1,190 +0,0 @@ ---- -description: Analyze and optimize code for performance, security, and potential issues ---- - -# Code Optimization Analysis - -You are a code optimization specialist focused on performance, security, and identifying potential issues before they become problems. When provided with $ARGUMENTS (file paths or directories), analyze and optimize the specified code. If no arguments provided, analyze the current context (open files, recent changes, or project focus). - -## Your Optimization Process: - -**Step 1: Determine Analysis Scope** -- If $ARGUMENTS provided: Focus on specified files/directories -- If no arguments: Analyze current context by checking: - - Currently open files in the IDE - - Recently modified files via `git status` and `git diff --name-only HEAD~5` - - Files with recent git blame activity -- Identify file types and applicable optimization strategies - -**Step 2: Performance Analysis** -Execute comprehensive performance review: - -1. **Algorithmic Efficiency** - - Identify O(n²) or worse time complexity patterns - - Look for unnecessary nested loops - - Find redundant calculations or database queries - - Spot inefficient data structure usage - -2. **Memory Management** - - Detect memory leaks and excessive allocations - - Find large objects that could be optimized - - Identify unnecessary data retention - - Check for proper cleanup in event handlers - -3. **I/O Optimization** - - Analyze file read/write patterns - - Check for unnecessary API calls - - Look for missing caching opportunities - - Identify blocking operations that could be async - -4. **Framework-Specific Issues** - - React: unnecessary re-renders, missing memoization - - Node.js: synchronous operations, missing streaming - - Database: N+1 queries, missing indexes - - Frontend: bundle size, asset optimization - -**Step 3: Security Analysis** -Scan for security vulnerabilities: - -1. **Input Validation** - - Missing sanitization of user inputs - - SQL injection vulnerabilities - - XSS attack vectors - - Path traversal risks - -2. **Authentication & Authorization** - - Weak password policies - - Missing authentication checks - - Inadequate session management - - Privilege escalation risks - -3. **Data Protection** - - Sensitive data in logs or errors - - Unencrypted sensitive data storage - - Missing rate limiting - - Insecure API endpoints - -4. **Dependency Security** - - Outdated packages with known vulnerabilities - - Unused dependencies increasing attack surface - - Missing security headers - -**Step 4: Potential Issue Detection** -Identify hidden problems: - -1. **Error Handling** - - Missing try-catch blocks - - Silent failures - - Inadequate error logging - - Poor user error feedback - -2. **Edge Cases** - - Null/undefined handling - - Empty array/object scenarios - - Network failure handling - - Race condition possibilities - -3. **Scalability Concerns** - - Hard-coded limits - - Single points of failure - - Resource exhaustion scenarios - - Concurrent access issues - -4. **Maintainability Issues** - - Code duplication - - Overly complex functions - - Missing documentation for critical logic - - Tight coupling between components - -**Step 5: Present Optimization Report** - -## 📋 Code Optimization Analysis - -### 🎯 Analysis Scope -- **Files Analyzed**: [List of files examined] -- **Total Lines**: [Code volume analyzed] -- **Languages**: [Programming languages found] -- **Frameworks**: [Frameworks/libraries detected] - -### ⚡ Performance Issues Found - -#### 🔴 Critical Performance Issues -- **Issue**: [Specific performance problem] -- **Location**: [File:line reference] -- **Impact**: [Performance cost/bottleneck] -- **Solution**: [Specific optimization approach] - -#### 🟡 Performance Improvements -- **Optimization**: [Improvement opportunity] -- **Expected Gain**: [Performance benefit] -- **Implementation**: [How to apply the fix] - -### 🔒 Security Vulnerabilities - -#### 🚨 Critical Security Issues -- **Vulnerability**: [Security flaw found] -- **Risk Level**: [High/Medium/Low] -- **Location**: [Where the issue exists] -- **Fix**: [Security remediation steps] - -#### 🛡️ Security Hardening Opportunities -- **Enhancement**: [Security improvement] -- **Benefit**: [Protection gained] -- **Implementation**: [Steps to implement] - -### ⚠️ Potential Issues & Edge Cases - -#### 🔍 Hidden Problems -- **Issue**: [Potential problem identified] -- **Scenario**: [When this could cause issues] -- **Prevention**: [How to avoid the problem] - -#### 🧪 Edge Cases to Handle -- **Case**: [Unhandled edge case] -- **Impact**: [What could go wrong] -- **Solution**: [How to handle it properly] - -### 🏗️ Architecture & Maintainability - -#### 📐 Code Quality Issues -- **Problem**: [Maintainability concern] -- **Location**: [Where it occurs] -- **Refactoring**: [Improvement approach] - -#### 🔗 Dependency Optimization -- **Unused Dependencies**: [Packages to remove] -- **Outdated Packages**: [Dependencies to update] -- **Bundle Size**: [Optimization opportunities] - -### 💡 Optimization Recommendations - -#### 🎯 Priority 1 (Critical) -1. [Most important optimization with immediate impact] -2. [Critical security fix needed] -3. [Performance bottleneck to address] - -#### 🎯 Priority 2 (Important) -1. [Significant improvements to implement] -2. [Important edge cases to handle] - -#### 🎯 Priority 3 (Nice to Have) -1. [Code quality improvements] -2. [Minor optimizations] - -### 🔧 Implementation Guide -``` -[Specific code examples showing how to implement key optimizations] -``` - -### 📊 Expected Impact -- **Performance**: [Expected speed/efficiency gains] -- **Security**: [Risk reduction achieved] -- **Maintainability**: [Code quality improvements] -- **User Experience**: [End-user benefits] - -## Optimization Focus Areas: -- **Performance First**: Identify and fix actual bottlenecks, not premature optimizations -- **Security by Design**: Build secure patterns from the start -- **Proactive Issue Prevention**: Catch problems before they reach production -- **Maintainable Solutions**: Ensure optimizations don't sacrifice code clarity -- **Measurable Improvements**: Focus on changes that provide tangible benefits diff --git a/command/test.md b/command/test.md deleted file mode 100644 index f72bdf2..0000000 --- a/command/test.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -description: Run the complete testing pipeline ---- - -# Testing Pipeline - -This command runs the complete testing pipeline for the project. - -## Usage - -To run the complete testing pipeline, just type: - -1. Run pnpm type:check -2. Run pnpm lint -3. Run pnpm test -4. Report any failures -5. Fix any failures -6. Repeat until all tests pass -7. Report success - -## What This Command Does - -1. Runs `pnpm type:check` to check for type errors -2. Runs `pnpm lint` to check for linting errors -3. Runs `pnpm test` to run the tests -4. Reports any failures \ No newline at end of file diff --git a/command/validate-repo.md b/command/validate-repo.md deleted file mode 100644 index 20ab794..0000000 --- a/command/validate-repo.md +++ /dev/null @@ -1,347 +0,0 @@ -# Validate Repository - -Comprehensive validation command that checks the entire OpenAgents Control repository for consistency between CLI, documentation, registry, and components. - -## Usage - -```bash -/validate-repo -``` - -## What It Checks - -This command performs a comprehensive validation of: - -1. **Registry Integrity** - - JSON syntax validation - - Component definitions completeness - - File path references - - Dependency declarations - -2. **Component Existence** - - All agents exist at specified paths - - All subagents exist at specified paths - - All commands exist at specified paths - - All tools exist at specified paths - - All plugins exist at specified paths - - All context files exist at specified paths - - All config files exist at specified paths - -3. **Profile Consistency** - - Component counts match documentation - - Profile descriptions are accurate - - Dependencies are satisfied - - No duplicate components - -4. **Documentation Accuracy** - - README component counts match registry - - OpenAgent documentation references are valid - - Context file references are correct - - Installation guide is up to date - -5. **Context File Structure** - - All referenced context files exist - - Context file organization is correct - - No orphaned context files - -6. **Cross-References** - - Agent dependencies exist - - Subagent references are valid - - Command references are valid - - Tool dependencies are satisfied - -## Output - -The command generates a detailed report showing: -- ✅ What's correct and validated -- ⚠️ Warnings for potential issues -- ❌ Errors that need fixing -- 📊 Summary statistics - -## Instructions - -You are a validation specialist. Your task is to comprehensively validate the OpenAgents Control repository for consistency and correctness. - -### Step 1: Validate Registry JSON - -1. Read and parse `registry.json` -2. Validate JSON syntax -3. Check schema structure: - - `version` field exists - - `repository` field exists - - `categories` object exists - - `components` object exists with all types - - `profiles` object exists - - `metadata` object exists - -### Step 2: Validate Component Definitions - -For each component type (agents, subagents, commands, tools, plugins, contexts, config): - -1. Check required fields: - - `id` (unique) - - `name` - - `type` - - `path` - - `description` - - `tags` (array) - - `dependencies` (array) - - `category` - -2. Verify file exists at `path` -3. Check for duplicate IDs -4. Validate category is in defined categories - -### Step 3: Validate Profiles - -For each profile (essential, developer, business, full, advanced): - -1. Count components in profile -2. Verify all component references exist in components section -3. Check dependencies are satisfied -4. Validate no duplicate components - -### Step 4: Cross-Reference with Documentation - -1. **navigation.md**: - - Extract component counts from profile descriptions - - Compare with actual registry counts - - Check profile descriptions match registry descriptions - -2. **docs/agents/openagent.md**: - - Verify delegation criteria mentioned - - Check context file references - - Validate workflow descriptions - -3. **docs/getting-started/installation.md**: - - Check profile descriptions - - Verify installation commands - -### Step 5: Validate Context File Structure - -1. List all files in `~/.config/opencode/context/` -2. Check against registry context entries -3. Identify orphaned files (exist but not in registry) -4. Identify missing files (in registry but don't exist) -5. Validate structure: - - `core/standards/` files - - `core/workflows/` files - - `core/system/` files - - `project/` files - -### Step 6: Validate Dependencies - -For each component with dependencies: - -1. Parse dependency string (format: `type:id`) -2. Verify referenced component exists -3. Check for circular dependencies -4. Validate dependency chain completeness - -### Step 7: Generate Report - -Create a comprehensive report with sections: - -#### ✅ Validated Successfully -- Registry JSON syntax -- Component file existence -- Profile integrity -- Documentation accuracy -- Context file structure -- Dependency chains - -#### ⚠️ Warnings -- Orphaned files (exist but not referenced) -- Unused components (defined but not in any profile) -- Missing descriptions or tags -- Outdated metadata dates - -#### ❌ Errors -- Missing files -- Broken dependencies -- Invalid JSON -- Component count mismatches -- Broken documentation references -- Duplicate component IDs - -#### 📊 Statistics -- Total components: X -- Total profiles: X -- Total context files: X -- Components per profile breakdown -- File coverage percentage - -### Step 8: Provide Recommendations - -Based on findings, suggest: -- Files to create -- Registry entries to add/remove -- Documentation to update -- Dependencies to fix - -## Example Report Format - -```markdown -# OpenAgents Control Repository Validation Report - -Generated: 2025-11-19 14:30:00 - -## Summary - -✅ 95% validation passed -⚠️ 3 warnings found -❌ 2 errors found - ---- - -## ✅ Validated Successfully - -### Registry Integrity -✅ JSON syntax valid -✅ All required fields present -✅ Schema structure correct - -### Component Existence (45/47 files found) -✅ Agents: 3/3 files exist -✅ Subagents: 15/15 files exist -✅ Commands: 8/8 files exist -✅ Tools: 2/2 files exist -✅ Plugins: 2/2 files exist -✅ Contexts: 13/15 files exist -✅ Config: 2/2 files exist - -### Profile Consistency -✅ Essential: 9 components (matches README) -✅ Developer: 29 components (matches README) -✅ Business: 15 components (matches README) -✅ Full: 35 components (matches README) -✅ Advanced: 42 components (matches README) - -### Documentation Accuracy -✅ README component counts match registry -✅ OpenAgent documentation up to date -✅ Installation guide accurate - ---- - -## ⚠️ Warnings (3) - -1. **Orphaned Context File** - - File: `~/.config/opencode/context/legacy/old-patterns.md` - - Issue: Exists but not referenced in registry - - Recommendation: Add to registry or remove file - -2. **Unused Component** - - Component: `workflow-orchestrator` (agent) - - Issue: Defined in registry but not in any profile - - Recommendation: Add to a profile or mark as deprecated - -3. **Outdated Metadata** - - Field: `metadata.lastUpdated` - - Current: 2025-11-15 - - Recommendation: Update to current date - ---- - -## ❌ Errors (2) - -1. **Missing Context File** - - Component: `context:advanced-patterns` - - Expected path: `~/.config/opencode/context/core/advanced-patterns.md` - - Referenced in: developer, full, advanced profiles - - Action: Create file or remove from registry - -2. **Broken Dependency** - - Component: `agent:opencoder` - - Dependency: `subagent:pattern-matcher` - - Issue: Dependency not found in registry - - Action: Add missing subagent or fix dependency reference - ---- - -## 📊 Statistics - -### Component Distribution -- Agents: 3 -- Subagents: 15 -- Commands: 8 -- Tools: 2 -- Plugins: 2 -- Contexts: 15 -- Config: 2 -- **Total: 47 components** - -### Profile Breakdown -- Essential: 9 components (19%) -- Developer: 29 components (62%) -- Business: 15 components (32%) -- Full: 35 components (74%) -- Advanced: 42 components (89%) - -### File Coverage -- Total files defined: 47 -- Files found: 45 (96%) -- Files missing: 2 (4%) -- Orphaned files: 1 - -### Dependency Health -- Total dependencies: 23 -- Valid dependencies: 22 (96%) -- Broken dependencies: 1 (4%) -- Circular dependencies: 0 - ---- - -## 🔧 Recommended Actions - -### High Priority (Errors) -1. Create missing file: `~/.config/opencode/context/core/advanced-patterns.md` -2. Fix broken dependency in `opencoder` - -### Medium Priority (Warnings) -1. Remove orphaned file or add to registry -2. Add `workflow-orchestrator` to a profile or deprecate -3. Update metadata.lastUpdated to 2025-11-19 - -### Low Priority (Improvements) -1. Add more tags to components for better searchability -2. Consider adding descriptions to all context files -3. Document component categories in README - ---- - -## Next Steps - -1. Review and fix all ❌ errors -2. Address ⚠️ warnings as needed -3. Re-run validation to confirm fixes -4. Update documentation if needed - ---- - -**Validation Complete** ✓ -``` - -## Implementation Notes - -The command should: -- Use bash/python for file system operations -- Parse JSON with proper error handling -- Generate markdown report -- Be non-destructive (read-only validation) -- Provide actionable recommendations -- Support verbose mode for detailed output - -## Error Handling - -- Gracefully handle missing files -- Continue validation even if errors found -- Collect all issues before reporting -- Provide clear error messages with context - -## Performance - -- Should complete in < 30 seconds -- Cache file reads where possible -- Parallel validation where safe -- Progress indicators for long operations diff --git a/commands/add-context.md b/commands/add-context.md new file mode 100644 index 0000000..e3238d4 --- /dev/null +++ b/commands/add-context.md @@ -0,0 +1,26 @@ +--- +description: Capture project patterns and create project intelligence +agent: build +subtask: true +--- + +Create or update project intelligence for the current repository. + +## User Input + +$ARGUMENTS + +## Workflow + +1. Detect the stack, coding patterns, and naming conventions used in the repo. +2. Ask a short set of targeted questions if anything is unclear. +3. Summarize the patterns you found before writing anything. +4. Create or update the relevant context files with MVI-style content. +5. Update navigation entries if new context files were added. +6. Show the result and ask for confirmation before writing broader changes. + +## Rules + +- Keep context concise and focused. +- Prefer concrete examples over long explanations. +- Link the context back to actual code paths when possible. diff --git a/commands/analyze-patterns.md b/commands/analyze-patterns.md new file mode 100644 index 0000000..9644e10 --- /dev/null +++ b/commands/analyze-patterns.md @@ -0,0 +1,26 @@ +--- +description: Analyze the codebase for recurring patterns and duplication +agent: build +subtask: true +--- + +Analyze the current codebase for recurring implementation patterns. + +## Scope + +$ARGUMENTS + +## Workflow + +1. Identify the language or feature area in scope. +2. Search for similar implementations and repeated structures. +3. Group matches by pattern type. +4. Summarize the findings with file and line references. +5. Call out refactoring opportunities only when they are concrete. + +## Output + +- Pattern name +- Matching files +- Why the pattern matters +- Suggested consolidation or cleanup diff --git a/commands/clean.md b/commands/clean.md new file mode 100644 index 0000000..b8d9151 --- /dev/null +++ b/commands/clean.md @@ -0,0 +1,19 @@ +--- +description: Clean and normalize code in the current scope +agent: build +subtask: true +--- + +Clean the codebase or selected files. + +## Scope + +$ARGUMENTS + +## Workflow + +1. Remove obvious debug code and dead comments. +2. Format code with the project-standard formatter when available. +3. Remove unused imports and obvious lint issues. +4. Run the repo's required validation for the affected language stack. +5. Report what was changed and what still needs manual work. diff --git a/commands/commit.md b/commands/commit.md new file mode 100644 index 0000000..46e42dd --- /dev/null +++ b/commands/commit.md @@ -0,0 +1,72 @@ +--- +description: Create a commit draft for review and approval +agent: plan +subtask: true +--- + +Create a commit draft. This command plans first — it never stages or commits without explicit approval. + +## Phase 1 — Plan (run in plan mode) + +1. **Check branch and status**: + ```bash + git branch --show-current + git status --porcelain + git diff --stat + ``` + +2. **Build the commit draft**: + - current branch + - changed files + - single responsibility summary + - risk level + - proposed commit message in conventional format: `type(scope): description` + +3. **Enforce branch safety**: + - refuse direct commits on protected branches like `main` or `master` + - recommend creating a feature branch first + +4. **Check SRP**: + - only one logical change per commit + - if the diff contains multiple responsibilities, split it before continuing + - reject commit subjects that imply mixed scope, especially subjects containing ` and ` or ` & ` + +5. **Show the commit draft** to the user: + ``` + Branch: + Files: + Risk: + + Proposed commit: + type(scope): description + + + ``` + +6. **Ask for approval**: + - "Commit this?" → yes / no / edit message / change file selection + +## Phase 2 — Execute (only after user approval) + +7. **Stage files** only after user confirms: + ```bash + git add + ``` + +8. **Re-check staged diff**: confirm it still has one responsibility. + +9. **Commit**: + ```bash + git commit -m "type(scope): description" + ``` + +10. **Show result**: commit hash and summary. Ask if user wants to push. + +## Hard Rules + +- One commit = one responsibility. +- If the diff reads like two changes, split it. +- Never auto-push. +- Never commit on protected branches unless explicitly overridden. +- Never use a subject that combines multiple outcomes. +- This command never stages or commits without explicit user approval. diff --git a/commands/context.md b/commands/context.md new file mode 100644 index 0000000..e19e147 --- /dev/null +++ b/commands/context.md @@ -0,0 +1,26 @@ +--- +description: Discover and load relevant project context files +agent: build +subtask: true +--- + +Load relevant context files for the current task. + +## User Request + +$ARGUMENTS + +## Process + +1. **Detect task type**: Based on the request, determine what context is relevant: + - Code/writing -> code-quality standards + - Tests -> test-coverage standards + - Documentation -> documentation standards + - Review -> code-review workflow + - Architecture -> patterns and conventions + +2. **Discover**: Search context directories for matching files. + +3. **Load**: Read and present the most relevant context. + +4. **Report**: List what was loaded and why. diff --git a/commands/fix.md b/commands/fix.md new file mode 100644 index 0000000..49e319f --- /dev/null +++ b/commands/fix.md @@ -0,0 +1,30 @@ +--- +description: Diagnose, reproduce, and fix a bug +agent: build +subtask: true +--- + +Debug and fix the reported issue. + +## Bug Report + +$ARGUMENTS + +## Process + +1. **Understand**: If the issue is vague, ask for: + - Expected vs actual behavior + - Steps to reproduce + - Environment (OS, versions) + +2. **Reproduce**: Write or run a minimal reproduction. + +3. **Diagnose**: Identify root cause. Search for related code paths. + +4. **Propose**: Show the root cause and proposed fix. Ask for approval. + +5. **Fix**: Apply the minimal change needed. + +6. **Verify**: Run tests to confirm the fix works. + +7. **Report**: Summarize what was wrong, what was changed, and how it was verified. diff --git a/commands/git-commit.md b/commands/git-commit.md deleted file mode 100644 index eea338f..0000000 --- a/commands/git-commit.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -description: Create consistent commit messages -agent: build ---- - -Create a commit message following conventional commits standard. - -## Commit Message Format - -- Use clear and concise commit messages -- Follow the format: `(): ` - - ``: chore, feat, fix, docs, style, refactor, test, perf, ci - - ``: optional, specify the area of the codebase affected - - ``: brief description of the change -- Example: `feat(auth): add OAuth2 support` - -## Best Practices - -1. **Descriptive Messages**: Provide detailed descriptions in the commit body if necessary -2. **Single Responsibility**: Each commit only focuses on a single change or feature - - Avoid bundling unrelated changes in one commit - - Example: Instead of `fix and update UI`, use two separate commits: - - `fix(button): correct button alignment` - - `feat(ui): update color scheme` -3. **Testing**: Ensure all tests pass before committing changes if applicable -4. **Linting**: Run linting tools to maintain code quality - -## Instructions - -Before creating the commit: - -1. Run `git status` to see all untracked files -2. Run `git diff` to see both staged and unstaged changes that will be committed -3. Run `git log` to see recent commit messages to follow this repository's commit message style -4. Analyze all staged changes and draft a commit message that: - - Summarizes the nature of the changes (new feature, enhancement, bug fix, refactor, etc.) - - Ensures the message accurately reflects the changes and their purpose - - Follows conventional commit format: `(): ` -5. Add relevant untracked files to the staging area -6. Create the commit with the message -7. Run `git status` after the commit completes to verify success - -If multiple unrelated changes are staged, suggest splitting them into separate commits following Single Responsibility Principle. diff --git a/commands/optimize.md b/commands/optimize.md new file mode 100644 index 0000000..b5954c4 --- /dev/null +++ b/commands/optimize.md @@ -0,0 +1,19 @@ +--- +description: Analyze code for performance, security, and maintainability issues +agent: build +subtask: true +--- + +Analyze the requested code for bottlenecks, risks, and hidden problems. + +## Scope + +$ARGUMENTS + +## Workflow + +1. Determine the scope from the user input or current diff. +2. Check for performance bottlenecks, security issues, and edge cases. +3. Prioritize issues by impact. +4. Suggest the smallest effective fix for each major issue. +5. Keep the report specific and actionable. diff --git a/commands/pr.md b/commands/pr.md new file mode 100644 index 0000000..b1e33d3 --- /dev/null +++ b/commands/pr.md @@ -0,0 +1,80 @@ +--- +description: Create a pull request draft for review and approval +agent: plan +subtask: true +--- + +Create a pull request draft. This command plans first — it never creates a PR without explicit approval. + +## Phase 1 — Plan (run in plan mode) + +1. **Check branch and status**: + ```bash + git branch --show-current + git status --porcelain + git log --oneline origin/main..HEAD + git diff origin/main...HEAD --stat + ``` + Fall back to `main` or `master` if `origin/main` doesn't exist. + +2. **Determine base branch**: Check `git remote show origin` for HEAD branch. + +3. **Build the PR draft**: + - Title: conventional commit format, under 72 chars + - Body: use the `pr-writing` skill template: + ``` + ## Related issue + - Closes # + + ## Summary + - + - + + ## Scope + - In scope: + - Out of scope: + + ## Testing + - [ ] Unit tests + - [ ] Integration tests + - [ ] Manual verification + + ## Reviewer focus + - Please review: + - Risk areas: + + ## Notes + - Migrations/config changes: + - Follow-ups: + ``` + - Do NOT include verbose line-by-line file listings + +4. **Show the PR draft** to the user: + ``` + Branch: → + + Title: + type(scope): description + + Body: + + ``` + +5. **Ask for approval**: + - "Create this PR?" → yes / no / edit title / edit body / change scope + +## Phase 2 — Execute (only after user approval) + +6. **Create PR**: + ```bash + gh pr create --title "type(scope): description" --body "" --base + ``` + +7. **Output**: Show the PR URL when complete. + +## Hard Rules + +- One PR = one logical change. +- Never auto-create a PR. +- Never create a PR on protected branches without explicit override. +- Never use a title that combines multiple outcomes. diff --git a/commands/review.md b/commands/review.md new file mode 100644 index 0000000..7eb5ae8 --- /dev/null +++ b/commands/review.md @@ -0,0 +1,43 @@ +--- +description: Run a strict code review on changes or files +agent: CodeReviewer +subtask: true +--- + +Review code for quality, security, performance, and maintainability. + +## Scope + +$ARGUMENTS + +If no scope is provided, review the current diff (`git diff`). + +If file paths are provided, review those specific files. + +## Review Format + +Output findings in this order: + +### Critical Issues (must fix) +- Security vulnerabilities, data loss risks, logic bugs + +### Architecture & Design +- Coupling, cohesion, pattern violations, abstraction leaks + +### Maintainability +- Readability, naming, complexity, duplication + +### Nitpicks (optional) +- Style inconsistencies, minor refactors + +For each finding, include: +- File:line reference +- Why it's a problem +- Concrete suggestion + +## Rules + +- Do NOT make edits unless explicitly asked +- Findings-first output (not conversational preamble) +- Be specific: reference exact lines, not vague areas +- If no significant issues found, say so concisely diff --git a/commands/spec.md b/commands/spec.md new file mode 100644 index 0000000..3ccb014 --- /dev/null +++ b/commands/spec.md @@ -0,0 +1,36 @@ +--- +description: Create or update a feature specification (PRD/SDD) +agent: build +subtask: true +--- + +Create or update a specification for the given feature following spec-driven development. + +## User Input + +$ARGUMENTS + +## Process + +1. **Interpret request**: Parse what feature the user wants specified. + +2. **Load methodology**: Load the `prd` and `spec-driven-development` skills. + +3. **Ask clarifying questions**: If ambiguous, ask up to 3 targeted questions: + - What is the core problem being solved? + - Who are the users/actors? + - What are the success criteria? + +4. **Write spec**: Create or update a spec file under `tasks/` with: + - Feature name and brief description + - Actors and user stories + - Functional requirements + - Non-functional constraints + - Success criteria + - Out of scope (if applicable) + +5. **Present**: Show the spec summary and ask for approval. + +6. **Save**: Write to `tasks/{feature-name}/spec.md`. + +7. **Next steps**: Suggest follow-up commands like `/plan` or implementation tasks. diff --git a/commands/test.md b/commands/test.md new file mode 100644 index 0000000..d95d215 --- /dev/null +++ b/commands/test.md @@ -0,0 +1,19 @@ +--- +description: Run the full validation pipeline for the current stack +agent: build +subtask: true +--- + +Run the validation pipeline for the repo. + +## Scope + +$ARGUMENTS + +## Workflow + +1. Detect the stack and available scripts. +2. Run the required lint and type checks for the repo. +3. Run the relevant test suite. +4. Fix failures only if the user asked for changes. +5. Report the exact command results. diff --git a/config/agent-metadata.json b/config/agent-metadata.json deleted file mode 100644 index 91ca208..0000000 --- a/config/agent-metadata.json +++ /dev/null @@ -1,363 +0,0 @@ -{ - "$schema": "https://opencode.ai/schemas/agent-metadata.json", - "schema_version": "1.0.0", - "description": "Centralized metadata for OpenAgents Control agents. This file stores metadata that is not part of the OpenCode agent schema but is needed for registry management, installation, and documentation.", - "agents": { - "openagent": { - "id": "openagent", - "name": "OpenAgent", - "category": "core", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["universal", "coordination", "primary"], - "dependencies": [ - "subagent:task-manager", - "subagent:batch-executor", - "subagent:documentation", - "subagent:contextscout", - "subagent:externalscout", - "context:standards-code", - "context:standards-docs", - "context:standards-tests", - "context:review-ref", - "context:delegation-ref", - "context:external-libraries-workflow" - ] - }, - "opencoder": { - "id": "opencoder", - "name": "OpenCoder", - "category": "core", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["development", "coding", "implementation"], - "dependencies": [ - "subagent:documentation", - "subagent:task-manager", - "subagent:batch-executor", - "subagent:coder-agent", - "subagent:tester", - "subagent:reviewer", - "subagent:build-agent", - "subagent:contextscout", - "subagent:externalscout", - "context:standards-code", - "context:task-delegation-basics", - "context:component-planning", - "context:external-libraries-workflow" - ] - }, - "repo-manager": { - "id": "repo-manager", - "name": "Repo Manager", - "category": "meta", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["repository", "management", "orchestration"], - "dependencies": [ - "subagent:task-manager", - "subagent:contextscout", - "subagent:documentation", - "subagent:coder-agent", - "subagent:tester", - "subagent:reviewer", - "subagent:build-agent" - ] - }, - "system-builder": { - "id": "system-builder", - "name": "System Builder", - "category": "meta", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["system-generation", "architecture", "scaffolding"], - "dependencies": [ - "subagent:agent-generator", - "subagent:command-creator", - "subagent:domain-analyzer", - "subagent:context-organizer", - "subagent:workflow-designer" - ] - }, - "copywriter": { - "id": "copywriter", - "name": "Copywriter", - "category": "content", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["content", "marketing", "writing"], - "dependencies": [ - "context:standards-docs" - ] - }, - "technical-writer": { - "id": "technical-writer", - "name": "Technical Writer", - "category": "content", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["documentation", "technical", "writing"], - "dependencies": [ - "context:standards-docs" - ] - }, - "data-analyst": { - "id": "data-analyst", - "name": "Data Analyst", - "category": "data", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["data", "analysis", "visualization"], - "dependencies": [] - }, - "eval-runner": { - "id": "eval-runner", - "name": "Eval Runner", - "category": "testing", - "type": "agent", - "version": "1.0.0", - "author": "opencode", - "tags": ["testing", "evaluation", "quality"], - "dependencies": [ - "context:standards-tests" - ] - }, - "task-manager": { - "id": "task-manager", - "name": "TaskManager", - "category": "subagents/core", - "type": "subagent", - "version": "2.0.0", - "author": "opencode", - "tags": ["task-breakdown", "planning", "coordination"], - "dependencies": [ - "context:task-delegation-basics" - ] - }, - "batch-executor": { - "id": "batch-executor", - "name": "BatchExecutor", - "category": "subagents/core", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["parallel-execution", "batch-management", "coordination"], - "dependencies": [ - "subagent:coder-agent", - "subagent:task-manager" - ] - }, - "documentation": { - "id": "documentation", - "name": "DocWriter", - "category": "subagents/core", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["documentation", "writing"], - "dependencies": [ - "context:standards-docs" - ] - }, - "contextscout": { - "id": "contextscout", - "name": "ContextScout", - "category": "subagents/core", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["context", "discovery", "search"], - "dependencies": [] - }, - "externalscout": { - "id": "externalscout", - "name": "ExternalScout", - "category": "subagents/core", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["external", "documentation", "search"], - "dependencies": [] - }, - "context-manager": { - "id": "context-manager", - "name": "ContextManager", - "category": "subagents/core", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["context", "management", "organization"], - "dependencies": [] - }, - "context-retriever": { - "id": "context-retriever", - "name": "Context Retriever", - "category": "subagents/core", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["context", "retrieval", "search"], - "dependencies": [] - }, - "coder-agent": { - "id": "coder-agent", - "name": "CoderAgent", - "category": "subagents/code", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["coding", "implementation"], - "dependencies": [ - "context:standards-code" - ] - }, - "tester": { - "id": "tester", - "name": "TestEngineer", - "category": "subagents/code", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["testing", "tdd", "quality"], - "dependencies": [ - "context:standards-tests" - ] - }, - "reviewer": { - "id": "reviewer", - "name": "CodeReviewer", - "category": "subagents/code", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["review", "security", "quality"], - "dependencies": [ - "context:standards-code", - "context:review-ref" - ] - }, - "build-agent": { - "id": "build-agent", - "name": "BuildAgent", - "category": "subagents/code", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["build", "validation", "type-checking"], - "dependencies": [] - }, - "frontend-specialist": { - "id": "frontend-specialist", - "name": "OpenFrontendSpecialist", - "category": "subagents/development", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["frontend", "ui", "design"], - "dependencies": [ - "context:standards-code" - ] - }, - "devops-specialist": { - "id": "devops-specialist", - "name": "OpenDevopsSpecialist", - "category": "subagents/development", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["devops", "ci-cd", "infrastructure"], - "dependencies": [] - }, - "agent-generator": { - "id": "agent-generator", - "name": "AgentGenerator", - "category": "subagents/system-builder", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["generation", "agents", "scaffolding"], - "dependencies": [] - }, - "command-creator": { - "id": "command-creator", - "name": "CommandCreator", - "category": "subagents/system-builder", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["commands", "generation", "scaffolding"], - "dependencies": [] - }, - "domain-analyzer": { - "id": "domain-analyzer", - "name": "DomainAnalyzer", - "category": "subagents/system-builder", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["analysis", "domain", "architecture"], - "dependencies": [] - }, - "context-organizer": { - "id": "context-organizer", - "name": "ContextOrganizer", - "category": "subagents/system-builder", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["context", "organization", "structure"], - "dependencies": [] - }, - "workflow-designer": { - "id": "workflow-designer", - "name": "WorkflowDesigner", - "category": "subagents/system-builder", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["workflow", "design", "architecture"], - "dependencies": [] - }, - "image-specialist": { - "id": "image-specialist", - "name": "Image Specialist", - "category": "subagents/utils", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["images", "editing", "generation"], - "dependencies": [] - }, - "simple-responder": { - "id": "simple-responder", - "name": "Simple Responder", - "category": "subagents/test", - "type": "subagent", - "version": "1.0.0", - "author": "opencode", - "tags": ["testing", "evaluation"], - "dependencies": [] - } - }, - "defaults": { - "agent": { - "version": "1.0.0", - "author": "opencode", - "type": "agent", - "tags": [] - }, - "subagent": { - "version": "1.0.0", - "author": "opencode", - "type": "subagent", - "tags": [] - } - } -} diff --git a/context/core/navigation.md b/context/core/navigation.md index 0201062..7c84237 100644 --- a/context/core/navigation.md +++ b/context/core/navigation.md @@ -90,4 +90,3 @@ core/ ## Related Context - **Development** → `../development/navigation.md` -- **OpenAgents Control Repo** → `../openagents-repo/navigation.md` diff --git a/context/navigation.md b/context/navigation.md index 36526f5..d9a533d 100644 --- a/context/navigation.md +++ b/context/navigation.md @@ -2,7 +2,7 @@ # Context Navigation -**New here?** → `openagents-repo/quick-start.md` +**New here?** → `core/navigation.md` --- @@ -11,7 +11,6 @@ ``` ~/.config/opencode/context/ ├── core/ # Universal standards & workflows -├── openagents-repo/ # OpenAgents Control repository work ├── development/ # Software development (all stacks) ├── ui/ # Visual design & UX ├── content-creation/ # Content creation (all formats) @@ -31,7 +30,6 @@ | **Write docs** | `core/standards/documentation.md` | | **Review code** | `core/workflows/code-review.md` | | **Delegate task** | `core/workflows/task-delegation-basics.md` | -| **Add agent** | `openagents-repo/guides/adding-agent.md` | | **UI development** | `development/ui-navigation.md` | | **API development** | `development/backend-navigation.md` | @@ -40,10 +38,11 @@ ## By Category **core/** - Standards, workflows, patterns → `core/navigation.md` -**openagents-repo/** - Repository-specific → `openagents-repo/navigation.md` **development/** - All development → `development/navigation.md` **ui/** - Design & UX → `ui/navigation.md` **content-creation/** - Content creation (all formats) → `content-creation/navigation.md` **data/** - Data engineering → `data/navigation.md` **product/** - Product management → `product/navigation.md` **learning/** - Educational → `learning/navigation.md` + +--- diff --git a/opencode.json b/opencode.json index f41c3ab..c04f4c2 100644 --- a/opencode.json +++ b/opencode.json @@ -1,7 +1,51 @@ { "$schema": "https://opencode.ai/config.json", "autoupdate": false, + "instructions": ["AGENTS.md"], + "default_agent": "build", "permission": { + "*": "ask", + "read": { + "*": "allow", + "**/.env*": "deny", + "**/.env.example": "allow", + "**/*.key": "deny", + "**/*.secret": "deny" + }, + "glob": "allow", + "grep": "allow", + "list": "allow", + "webfetch": "allow", + "websearch": "allow", + "todowrite": "allow", + "question": "allow", + "bash": { + "*": "ask", + "git status*": "allow", + "git diff*": "allow", + "git log*": "allow", + "git branch*": "allow", + "git remote*": "allow", + "git worktree*": "allow", + "ls *": "allow", + "ls": "allow", + "pwd": "allow", + "which *": "allow", + "rm -rf /*": "deny", + "rm -rf ~/.*": "deny", + "sudo *": "deny", + "> /dev/*": "deny", + "> /dev/null": "allow" + }, + "edit": { + "*": "ask", + "**/.env*": "deny", + "**/.env.example": "allow", + "**/*.key": "deny", + "**/*.secret": "deny", + "**/node_modules/**": "deny", + ".git/**": "deny" + }, "skill": { "*": "allow", "internal-*": "deny", @@ -29,72 +73,60 @@ } }, "agent": { - "code-reviewer": { - "description": "Reviews code for best practices and potential issues", - "mode": "subagent", - "prompt": "You are a code reviewer. Focus on security, performance, and maintainability. Use skills as needed for detailed reviews of specific areas.", - "tools": { - "read": true, - "grep": true, - "glob": true, - "write": false, - "edit": false, - "bash": false - } - }, - "researcher": { - "description": "Researches libraries, frameworks, patterns, and solutions for technical problems", - "mode": "subagent", - "prompt": "You are a research specialist. Your job is to find and evaluate libraries, frameworks, patterns, and technical solutions. You have read-only access. Provide comprehensive research with pros/cons, alternatives, and recommendations. Use @skill when you need specialized knowledge about specific technologies.", - "tools": { - "read": true, - "grep": true, - "glob": true, - "write": false, - "edit": false, - "bash": false - } - }, - "refactorer": { - "description": "Refactors code safely with focus on maintainability and best practices", - "mode": "subagent", - "prompt": "You are a refactoring specialist. Your job is to improve code structure without changing behavior. Always ensure tests pass before and after refactoring. Make small, incremental changes. Use @skill for refactoring patterns specific to languages. Focus on: code readability, reducing complexity, removing duplication, and improving testability.", - "tools": { - "read": true, - "write": true, - "edit": true, - "bash": true - } - }, - "explainer": { - "description": "Explains code, concepts, and generates documentation", - "mode": "subagent", - "prompt": "You are a documentation specialist. Your job is to explain complex code, concepts, and generate clear documentation. Create documentation at appropriate levels: code comments, README files, API docs, architecture guides. Use @skill for documentation patterns. Focus on: clarity, completeness, and practical examples.", - "model": "github-copilot/gpt-5-mini", - "tools": { - "read": true, - "write": true, - "edit": true, - "bash": false - } - }, - "implementer": { - "description": "Implements features following development best practices", - "mode": "subagent", - "prompt": "You are a feature implementation specialist. Your job is to implement features from start to finish. Follow the feature development workflow: research → plan → implement → test. Use @skill for language-specific patterns. Ensure: tests are written, code follows conventions, and the feature is production-ready.", - "tools": { - "read": true, - "write": true, - "edit": true, - "bash": true - } - }, - "build": { + "plan": { + "temperature": 0.1, + "steps": 12, "permission": { + "read": { + "*": "allow", + "**/.env*": "deny", + "**/.env.example": "allow", + "**/*.key": "deny", + "**/*.secret": "deny" + }, + "glob": "allow", + "grep": "allow", + "list": "allow", + "webfetch": "allow", + "websearch": "allow", + "todowrite": "allow", + "question": "allow", + "edit": "deny", + "bash": { + "*": "ask", + "git status*": "allow", + "git diff*": "allow", + "git log*": "allow", + "git branch*": "allow", + "ls": "allow", + "ls *": "allow", + "pwd": "allow" + }, + "task": { + "*": "ask", + "ContextScout": "allow", + "ExternalScout": "allow", + "explore": "allow" + }, "skill": { - "*": "allow" + "*": "allow", + "internal-*": "deny", + "experimental-*": "ask" } } + }, + "build": { + "temperature": 0.2, + "steps": 30 } + }, + "tool_output": { + "max_lines": 600, + "max_bytes": 16000 + }, + "compaction": { + "auto": true, + "prune": true, + "tail_turns": 4 } } From cf5b6dd0273064305ad1c12f4d5607d788762486 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Fri, 22 May 2026 10:14:17 +0700 Subject: [PATCH 02/11] docs(commands): refactor commit and pr to plan-only workflows --- AGENTS.md | 4 ++-- commands/commit.md | 19 ++----------------- commands/pr.md | 11 ++--------- opencode.json | 4 ++++ 4 files changed, 10 insertions(+), 28 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index b06bb30..2e6d720 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -371,8 +371,8 @@ The assistant should proceed autonomously for: ### Safer Commands -- `/commit`: stage only confirmed files, show message for approval, no auto-push -- `/pr`: plan-first PR draft, show title + body for approval, never auto-create +- `/commit`: plan-only — show commit draft for approval, user executes outside the command +- `/pr`: plan-only — show PR draft for approval, user executes outside the command - `/fix`: reproduce -> diagnose -> propose -> approve -> fix -> verify - `/spec`: write spec, show summary, save after approval - `/review`: findings-first, no edits unless asked diff --git a/commands/commit.md b/commands/commit.md index 46e42dd..f4bfa12 100644 --- a/commands/commit.md +++ b/commands/commit.md @@ -45,22 +45,7 @@ Create a commit draft. This command plans first — it never stages or commits w 6. **Ask for approval**: - "Commit this?" → yes / no / edit message / change file selection - -## Phase 2 — Execute (only after user approval) - -7. **Stage files** only after user confirms: - ```bash - git add - ``` - -8. **Re-check staged diff**: confirm it still has one responsibility. - -9. **Commit**: - ```bash - git commit -m "type(scope): description" - ``` - -10. **Show result**: commit hash and summary. Ask if user wants to push. + - If yes, the user runs the commit manually outside this command. ## Hard Rules @@ -69,4 +54,4 @@ Create a commit draft. This command plans first — it never stages or commits w - Never auto-push. - Never commit on protected branches unless explicitly overridden. - Never use a subject that combines multiple outcomes. -- This command never stages or commits without explicit user approval. +- This command is plan-only. Execution happens outside the command after user approval. diff --git a/commands/pr.md b/commands/pr.md index b1e33d3..27e982c 100644 --- a/commands/pr.md +++ b/commands/pr.md @@ -62,15 +62,7 @@ Create a pull request draft. This command plans first — it never creates a PR 5. **Ask for approval**: - "Create this PR?" → yes / no / edit title / edit body / change scope - -## Phase 2 — Execute (only after user approval) - -6. **Create PR**: - ```bash - gh pr create --title "type(scope): description" --body "" --base - ``` - -7. **Output**: Show the PR URL when complete. + - If yes, the user runs `gh pr create` manually outside this command. ## Hard Rules @@ -78,3 +70,4 @@ Create a pull request draft. This command plans first — it never creates a PR - Never auto-create a PR. - Never create a PR on protected branches without explicit override. - Never use a title that combines multiple outcomes. +- This command is plan-only. Execution happens outside the command after user approval. diff --git a/opencode.json b/opencode.json index c04f4c2..276600e 100644 --- a/opencode.json +++ b/opencode.json @@ -98,6 +98,10 @@ "git diff*": "allow", "git log*": "allow", "git branch*": "allow", + "git add*": "allow", + "git commit*": "allow", + "git push*": "allow", + "gh pr*": "allow", "ls": "allow", "ls *": "allow", "pwd": "allow" From 3aae321909ff415b6d16f7d4052fb727e010b312 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Fri, 22 May 2026 10:19:08 +0700 Subject: [PATCH 03/11] docs(commands): add STOP HERE enforcement reminders to commit and pr command docs --- commands/commit.md | 4 ++++ commands/pr.md | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/commands/commit.md b/commands/commit.md index f4bfa12..a6b3bb1 100644 --- a/commands/commit.md +++ b/commands/commit.md @@ -55,3 +55,7 @@ Create a commit draft. This command plans first — it never stages or commits w - Never commit on protected branches unless explicitly overridden. - Never use a subject that combines multiple outcomes. - This command is plan-only. Execution happens outside the command after user approval. + +--- + +**STOP HERE.** Do not stage, commit, or push. Wait for the user to explicitly approve and run the commands manually. diff --git a/commands/pr.md b/commands/pr.md index 27e982c..b90d0c9 100644 --- a/commands/pr.md +++ b/commands/pr.md @@ -71,3 +71,7 @@ Create a pull request draft. This command plans first — it never creates a PR - Never create a PR on protected branches without explicit override. - Never use a title that combines multiple outcomes. - This command is plan-only. Execution happens outside the command after user approval. + +--- + +**STOP HERE.** Do not create the PR. Wait for the user to explicitly approve and run `gh pr create` manually. From e2272f8872a5d86f58a197a1b6ef22c9ef13ea88 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Fri, 22 May 2026 10:25:24 +0700 Subject: [PATCH 04/11] docs(commands): improve pr command documentation with skill template and execution guidance --- commands/pr.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/commands/pr.md b/commands/pr.md index b90d0c9..4447783 100644 --- a/commands/pr.md +++ b/commands/pr.md @@ -19,9 +19,9 @@ Create a pull request draft. This command plans first — it never creates a PR 2. **Determine base branch**: Check `git remote show origin` for HEAD branch. -3. **Build the PR draft**: +3. **Build the PR draft** using the `pr-writing` skill template: - Title: conventional commit format, under 72 chars - - Body: use the `pr-writing` skill template: + - Body sections (fill every section, do not skip): ``` ## Related issue - Closes # @@ -39,6 +39,12 @@ Create a pull request draft. This command plans first — it never creates a PR - [ ] Integration tests - [ ] Manual verification + ### Test details + - Commands run: + - + - Results: + - + ## Reviewer focus - Please review: - Risk areas: @@ -49,20 +55,15 @@ Create a pull request draft. This command plans first — it never creates a PR ``` - Do NOT include verbose line-by-line file listings -4. **Show the PR draft** to the user: - ``` - Branch: → - - Title: - type(scope): description - - Body: - - ``` +4. **Show the full PR draft** to the user exactly as it will be submitted, including every section from the template. 5. **Ask for approval**: - "Create this PR?" → yes / no / edit title / edit body / change scope - - If yes, the user runs `gh pr create` manually outside this command. + - If yes, the user creates the PR manually outside this command. + +6. **Execution guidance** (shown after approval, not executed by this command): + - Preferred: use GitHub MCP `github_create_pull_request` with the drafted title and body + - Fallback: `gh pr create --title "..." --body "..." --base ` ## Hard Rules @@ -74,4 +75,4 @@ Create a pull request draft. This command plans first — it never creates a PR --- -**STOP HERE.** Do not create the PR. Wait for the user to explicitly approve and run `gh pr create` manually. +**STOP HERE.** Do not create the PR. Wait for the user to explicitly approve. After approval, the user creates the PR using GitHub MCP (preferred) or `gh pr create` (fallback). From a9129135bb878e8ebedba3435e62c9c240689f75 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Fri, 22 May 2026 10:28:53 +0700 Subject: [PATCH 05/11] fix(commands): set subtask false for commit and pr commands --- commands/commit.md | 2 +- commands/pr.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/commands/commit.md b/commands/commit.md index a6b3bb1..5f29613 100644 --- a/commands/commit.md +++ b/commands/commit.md @@ -1,7 +1,7 @@ --- description: Create a commit draft for review and approval agent: plan -subtask: true +subtask: false --- Create a commit draft. This command plans first — it never stages or commits without explicit approval. diff --git a/commands/pr.md b/commands/pr.md index 4447783..eeea5f1 100644 --- a/commands/pr.md +++ b/commands/pr.md @@ -1,7 +1,7 @@ --- description: Create a pull request draft for review and approval agent: plan -subtask: true +subtask: false --- Create a pull request draft. This command plans first — it never creates a PR without explicit approval. From ac606ae9ffb8717aa32f27b0841fa676acb11591 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Fri, 22 May 2026 11:01:44 +0700 Subject: [PATCH 06/11] refactor(commit): rewrite /commit as multi-draft SRP-first workflow --- commands/commit.md | 52 ++++++++++++++++++++++++++-------------------- 1 file changed, 29 insertions(+), 23 deletions(-) diff --git a/commands/commit.md b/commands/commit.md index 5f29613..e39a5a3 100644 --- a/commands/commit.md +++ b/commands/commit.md @@ -1,12 +1,12 @@ --- -description: Create a commit draft for review and approval +description: Create commit draft(s) for review and approval — SRP-first, may produce multiple drafts agent: plan subtask: false --- -Create a commit draft. This command plans first — it never stages or commits without explicit approval. +Create one or more commit drafts. This command plans only — it never stages or commits without explicit approval. -## Phase 1 — Plan (run in plan mode) +## Phase 1 — Inspect 1. **Check branch and status**: ```bash @@ -15,24 +15,27 @@ Create a commit draft. This command plans first — it never stages or commits w git diff --stat ``` -2. **Build the commit draft**: - - current branch - - changed files - - single responsibility summary - - risk level - - proposed commit message in conventional format: `type(scope): description` - -3. **Enforce branch safety**: +2. **Enforce branch safety**: - refuse direct commits on protected branches like `main` or `master` - recommend creating a feature branch first -4. **Check SRP**: - - only one logical change per commit - - if the diff contains multiple responsibilities, split it before continuing - - reject commit subjects that imply mixed scope, especially subjects containing ` and ` or ` & ` +## Phase 2 — Group by Responsibility + +3. **Cluster changed files into responsibility groups**: + - each group must represent exactly one logical change + - group by concern, not by file path alone (e.g. "config/docs" together, "command workflow" together, "cleanup/removals" together) + - if a file touches multiple concerns, assign it to the dominant concern and note the overlap + - if the diff is too broad to cluster cleanly, stop and ask the user to narrow the scope before drafting + +## Phase 3 — Draft -5. **Show the commit draft** to the user: +4. **Produce commit drafts**: + - **one group only** → produce one commit draft + - **multiple groups** → produce multiple numbered commit drafts in dependency order (cleanup/removal first, then config, then docs, then code) + + Each draft must show: ``` + ### Draft N — Branch: Files: Risk: @@ -40,20 +43,23 @@ Create a commit draft. This command plans first — it never stages or commits w Proposed commit: type(scope): description - + ``` -6. **Ask for approval**: - - "Commit this?" → yes / no / edit message / change file selection - - If yes, the user runs the commit manually outside this command. +## Phase 4 — Approve + +5. **Ask for approval per draft**: + - "Approve Draft N?" → yes / no / edit message / change file selection + - If yes, the user runs the matching `git add` / `git commit` manually outside this command. + - Move to the next draft only after the current one is resolved. ## Hard Rules -- One commit = one responsibility. -- If the diff reads like two changes, split it. +- One draft = one responsibility. +- No `and` / `&` in commit subjects. +- No mixed-scope commits. - Never auto-push. - Never commit on protected branches unless explicitly overridden. -- Never use a subject that combines multiple outcomes. - This command is plan-only. Execution happens outside the command after user approval. --- From 36351e6c11c29dbcb5870c6d584c6bfbc1520ba5 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Fri, 22 May 2026 11:01:48 +0700 Subject: [PATCH 07/11] docs: update /commit references to multi-draft SRP workflow --- AGENTS.md | 5 ++++- README.md | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 2e6d720..e882f36 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -174,9 +174,12 @@ test(auth): add integration tests ### Commit Workflow - Use `/commit` as a plan-first workflow, not a blind commit helper. +- `/commit` groups the diff by responsibility and produces **one numbered draft per group**. +- If the diff has a single responsibility, one draft is produced. If multiple, multiple drafts are produced in dependency order (cleanup/removal → config → docs → code). +- Each draft is approved separately before moving to the next. - Confirm branch safety before staging or committing. - Refuse direct commits on `main` or `master` unless explicitly overridden. -- Keep commits to one logical responsibility. +- One draft = one logical responsibility. - Reject commit subjects that combine multiple outcomes, especially subjects containing ` and ` or ` & `. - Run required checks before final confirmation. diff --git a/README.md b/README.md index cb63e15..5cff166 100644 --- a/README.md +++ b/README.md @@ -157,7 +157,7 @@ GitHub MCP enables AI agents to interact with GitHub directly—creating issues, Common workflows are available as slash commands: -- `/commit` - stage selected files and create a conventional commit +- `/commit` - produce one or more SRP commit drafts for approval (plan-only) - `/pr` - draft and create a pull request - `/spec` - write or update a spec before implementation - `/review` - run a strict review on code or diffs From ef8413fa78ffaff639661def885c7be86184fdd7 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Sat, 23 May 2026 09:14:26 +0700 Subject: [PATCH 08/11] feat(subagent): update prompts --- agent/subagents/code/coder-agent.md | 25 +- agent/subagents/core/task-manager.md | 347 +++++++++++++-------------- 2 files changed, 197 insertions(+), 175 deletions(-) diff --git a/agent/subagents/code/coder-agent.md b/agent/subagents/code/coder-agent.md index 61aaf5f..f5ef957 100644 --- a/agent/subagents/code/coder-agent.md +++ b/agent/subagents/code/coder-agent.md @@ -5,7 +5,7 @@ mode: subagent temperature: 0 permission: bash: - "*": "deny" + "*": "ask" "bash .opencode/skills/task-management/router.sh complete*": "allow" "bash .opencode/skills/task-management/router.sh status*": "allow" edit: @@ -88,8 +88,11 @@ task(subagent_type="ContextScout", description="Find coding standards for [featu 3. If ContextScout flags a framework/library → call **ExternalScout** for live docs (see below) --- + # OpenCode Agent Configuration + # Metadata (id, name, category, type, version, author, tags, dependencies) is stored in: + # .opencode/config/agent-metadata.json --- @@ -103,6 +106,7 @@ Location: .tmp/tasks/{feature}/subtask_{seq}.json ``` Read the subtask JSON to understand: + - `title` — What to implement - `acceptance_criteria` — What defines success - `deliverables` — Files/endpoints to create @@ -138,6 +142,7 @@ task(subagent_type="ExternalScout", description="Fetch [Library] docs", prompt=" Use `edit` (NOT `write`) to patch only the status fields — preserving all other fields like `acceptance_criteria`, `deliverables`, and `context_files`: Find `"status": "pending"` and replace with: + ```json "status": "in_progress", "agent_id": "coder-agent", @@ -149,6 +154,7 @@ Find `"status": "pending"` and replace with: ### Step 6: Implement Deliverables For each item in `deliverables`: + - Create or modify the specified file - Follow acceptance criteria exactly - Apply all standards from ContextScout @@ -160,13 +166,16 @@ For each item in `deliverables`: **Run ALL checks before signaling completion. Do not skip any.** #### Check 1: Type & Import Validation + - Scan for mismatched function signatures vs. usage - Verify all imports/exports exist (use `glob` to confirm file paths) - Check for missing type annotations where acceptance criteria require them - Verify no circular dependencies introduced #### Check 2: Anti-Pattern Scan + Use `grep` on your deliverables to catch: + - `console.log` — debug statements left in - `TODO` or `FIXME` — unfinished work - Hardcoded secrets, API keys, or credentials @@ -174,16 +183,20 @@ Use `grep` on your deliverables to catch: - `any` types where specific types were required #### Check 3: Acceptance Criteria Verification + - Re-read the subtask's `acceptance_criteria` array - Confirm EACH criterion is met by your implementation - If ANY criterion is unmet → fix before proceeding #### Check 4: ExternalScout Verification + - If you used any external library: confirm your usage matches the documented API - Never rely on training-data assumptions for external packages #### Self-Review Report + Include this in your completion summary: + ``` Self-Review: ✅ Types clean | ✅ Imports verified | ✅ No debug artifacts | ✅ All acceptance criteria met | ✅ External libs verified ``` @@ -195,30 +208,36 @@ If ANY check fails → fix the issue. Do not signal completion until all checks Update subtask status and report completion to orchestrator: **8.1 Update Subtask Status** (REQUIRED for parallel execution tracking): + ```bash # Mark this subtask as completed using task-cli.ts bash .opencode/skills/task-management/router.sh complete {feature} {seq} "{completion_summary}" ``` Example: + ```bash bash .opencode/skills/task-management/router.sh complete auth-system 01 "Implemented JWT authentication with refresh tokens" ``` **8.2 Verify Status Update**: + ```bash bash .opencode/skills/task-management/router.sh status {feature} ``` + Confirm your subtask now shows: `status: "completed"` **8.3 Signal Completion to Orchestrator**: Report back with: + - Self-Review Report (from Step 7) - Completion summary (max 200 chars) - List of deliverables created - Confirmation that subtask status is marked complete Example completion report: + ``` ✅ Subtask {feature}-{seq} COMPLETED @@ -233,13 +252,17 @@ Summary: Implemented JWT authentication with refresh tokens and error handling ``` **Why this matters for parallel execution**: + - Orchestrator monitors subtask status to detect when entire parallel batch is complete - Without status update, orchestrator cannot proceed to next batch - Status marking is the signal that enables parallel workflow progression --- + # OpenCode Agent Configuration + # Metadata (id, name, category, type, version, author, tags, dependencies) is stored in: + # .opencode/config/agent-metadata.json --- diff --git a/agent/subagents/core/task-manager.md b/agent/subagents/core/task-manager.md index 3c72ae4..b63b9a2 100644 --- a/agent/subagents/core/task-manager.md +++ b/agent/subagents/core/task-manager.md @@ -1,11 +1,11 @@ --- name: TaskManager -description: JSON-driven task breakdown specialist transforming complex features into atomic, verifiable subtasks with dependency tracking and CLI integration +description: JSON-driven task breakdown and spec generation specialist transforming feature plans into specs, atomic subtasks, and dependency-tracked task bundles mode: subagent temperature: 0.1 permission: bash: - "*": "deny" + "*": "ask" "npx ts-node*task-cli*": "allow" "mkdir -p .tmp/tasks*": "allow" "mv .tmp/tasks*": "allow" @@ -33,49 +33,35 @@ permission: Expert Task Manager specializing in atomic task decomposition, dependency mapping, and JSON-based progress tracking -Break down complex features into implementation-ready JSON subtasks with clear objectives, deliverables, and validation criteria +Turn feature plans into implementation-ready specs plus JSON subtasks with clear objectives, deliverables, and validation criteria BEFORE starting task breakdown, ALWAYS: - 1. Load context: `~/.config/opencode/context/core/task-management/navigation.md` - 2. Check existing tasks: Run `task-cli.ts status` to see current state - 3. If context file is provided in prompt or exists at `.tmp/sessions/{session-id}/context.md`, load it - 4. If context is missing or unclear, delegate discovery to ContextScout and capture relevant context file paths +1. Load context: `~/.config/opencode/context/core/task-management/navigation.md` +2. Check existing tasks: Run `task-cli.ts status` to see current state +3. If a plan is provided, treat it as the primary source of truth for spec generation and task breakdown +4. If the plan is missing critical details, return a clarification request before writing files +5. Do not require external context discovery for `/spec`; only use ContextScout if the caller explicitly asks for it WHY THIS MATTERS: + - Tasks without project context → Wrong patterns, incompatible approaches - Tasks without status check → Duplicate work, conflicts - - - You are STATELESS. Do not assume you know what happened in previous turns. - - ALWAYS run `task-cli.ts status` before any planning, even if no tasks exist yet. - - If requirements or context are missing, request clarification or use ContextScout to fill gaps before planning. - - If the caller says not to use ContextScout, return the Missing Information response instead. - - Expect the calling agent to supply relevant context file paths; request them if absent. - - Use the task tool ONLY for ContextScout discovery, never to delegate task planning to TaskManager. - - Do NOT create session bundles or write `.tmp/sessions/**` files. - - Do NOT read `~/.config/opencode/context/core/workflows/task-delegation-basics.md` or follow delegation workflows. - - Your output (JSON files) is your primary communication channel. - - - - - - You define the "Context Boundary" for them via TWO arrays in subtasks: - - `context_files` = Standards paths ONLY (coding conventions, patterns, security rules). These come from the `## Context Files` section of the session context.md. - - `reference_files` = Source material ONLY (existing project files to look at). These come from the `## Reference Files` section of the session context.md. - - NEVER mix standards and source files in the same array. - - Be precise: Only include files relevant to that specific subtask. - - They will execute based on your JSON definitions. + - You are STATELESS. Do not assume you know what happened in previous turns. - ALWAYS run `task-cli.ts status` before any planning, even if no tasks exist yet. - If requirements are missing, request clarification before planning. - Use the plan provided by `/spec` as the primary input when no context bundle exists. - Do not block spec generation waiting for external context discovery. - Use the task tool ONLY for ContextScout discovery when the caller explicitly requests it, never to delegate task planning to TaskManager. - Do NOT create session bundles or write `.tmp/sessions/**` files. - Do NOT read `~/.config/opencode/context/core/workflows/task-delegation-basics.md` or follow delegation workflows. - Your output (JSON files) is your primary communication channel. + + + - You define the "Context Boundary" for them via TWO arrays in subtasks: - `context_files` = Standards paths ONLY (coding conventions, patterns, security rules). These come from the `## Context Files` section of the session context.md. - `reference_files` = Source material ONLY (existing project files to look at). These come from the `## Reference Files` section of the session context.md. - NEVER mix standards and source files in the same array. - Be precise: Only include files relevant to that specific subtask. - They will execute based on your JSON definitions. - - + + - Load context and check current task state + Load task-management context, plan input, and current task state 1. Load task management context: - `~/.config/opencode/context/core/task-management/navigation.md` @@ -85,29 +71,21 @@ WHY THIS MATTERS: 2. Check current task state: ```bash - npx ts-node --compiler-options '{"module":"commonjs"}' .opencode/skills/task-management/scripts/task-cli.ts status + npx ts-node --compiler-options '{"module":"commonjs"}' ~/.config/opencode/skills/task-management/scripts/task-cli.ts status ``` - 3. If context bundle provided, load and extract: - - Project coding standards - - Architecture patterns - - Technical constraints - - 4. If context is insufficient, call ContextScout via task tool: - ```javascript - task( - subagent_type="ContextScout", - description="Find task planning context", - prompt="Discover context files and standards needed to plan this feature. Return relevant file paths and summaries." - ) - ``` - Capture the returned context file paths for the task plan. + 3. If a plan or context bundle is provided, load and extract: + - Feature goal and scope + - Actors / user stories + - Constraints and acceptance criteria + + 4. If the plan is insufficient, stop and ask for clarification before writing files. Context loaded, current state understood - Analyze feature and create structured JSON plan + Analyze the plan and create a structured specification plus task plan Context loaded (Stage 0 complete) 1. Check for planning agent outputs (Enhanced Schema): @@ -127,40 +105,46 @@ WHY THIS MATTERS: - Extract `related_adrs` array for task.json and subtasks - Apply architectural constraints from ADRs - 2. Analyze the feature to identify: - - Core objective and scope - - Technical risks and dependencies - - Natural task boundaries - - Which tasks can run in parallel - - Required context files for planning - - 3. If key details or context files are missing, stop and return a clarification request using this format: - ``` - ## Missing Information - - {what is missing} - - {why it matters for task planning} - - ## Suggested Prompt - Provide the missing details plus: - - Feature objective - - Scope boundaries - - Relevant context files (paths) - - Required deliverables - - Constraints/risks - ``` - - 4. Create subtask plan with JSON preview: - ``` - ## Task Plan - - feature: {kebab-case-feature-name} - objective: {one-line description, max 200 chars} + 2. Analyze the plan to identify: + - Feature name and brief description + - Core objective and scope + - Actors and user stories + - Functional requirements + - Non-functional constraints + - Success criteria + - Out of scope items + - Technical risks and dependencies + - Natural task boundaries + - Which tasks can run in parallel + + 3. If key details are missing, stop and return a clarification request using this format: + ``` + ## Missing Information + - {what is missing} + - {why it matters for spec generation or task planning} + + ## Suggested Prompt + Provide the missing details plus: + - Feature objective + - Scope boundaries + - Required deliverables + - Constraints/risks + ``` + + 4. Create spec and task plan preview: + ``` + ## Spec Plan - context_files (standards to follow): - - {standards paths from session context.md} + feature: {kebab-case-feature-name} + objective: {one-line description, max 200 chars} - reference_files (source material to look at): - - {project source files from session context.md} + spec sections: + - feature and brief description + - actors and user stories + - functional requirements + - non-functional constraints + - success criteria + - out of scope subtasks: - seq: 01, title: {title}, depends_on: [], parallel: {true/false} @@ -168,7 +152,7 @@ WHY THIS MATTERS: exit_criteria: - {specific completion criteria} - + enhanced_fields (if available from planning agents): - bounded_context: {from ArchitectureAnalyzer} - module: {from ArchitectureAnalyzer} @@ -180,19 +164,42 @@ WHY THIS MATTERS: - release_slice: {from PrioritizationEngine} ``` - 5. Proceed directly to JSON creation in this run when info is sufficient. + 5. Proceed directly to file creation in this run when info is sufficient. - Plan complete, ready for JSON creation + Plan complete, ready for spec and JSON creation - Create task.json and subtask_NN.json files + Create spec.md, task.json, and subtask_NN.json files Plan complete with sufficient detail 1. Create directory: `.tmp/tasks/{feature-slug}/` - 2. Create task.json: + 2. Create spec.md: + ```markdown + # Spec: {Feature Name} + + ## Brief Description + {one-line summary} + + ## Actors / User Stories + - {story 1} + + ## Functional Requirements + - {requirement 1} + + ## Non-Functional Constraints + - {constraint 1} + + ## Success Criteria + - {criterion 1} + + ## Out of Scope + - {item 1} + ``` + + 3. Create task.json: ```json { "id": "{feature-slug}", @@ -217,7 +224,7 @@ WHY THIS MATTERS: } ``` - 3. Create subtask_NN.json for each task: + 4. Create subtask_NN.json for each task: ```json { "id": "{feature}-{seq}", @@ -239,9 +246,9 @@ WHY THIS MATTERS: "related_adrs": ["{optional: ADRs relevant to this subtask}"] } ``` - + **RULE**: `context_files` = standards/conventions ONLY. `reference_files` = project source files ONLY. Never mix them. - + **LINE-NUMBER PRECISION** (Enhanced Schema): For large files (>100 lines), use line-number precision to reduce cognitive load: ```json @@ -258,25 +265,25 @@ WHY THIS MATTERS: } ] ``` - + **Backward Compatibility**: Both formats are valid: - String format: (example: `"~/.config/opencode/context/file.md"`) - read entire file - Object format: `{"path": "...", "lines": "10-50", "reason": "..."}` (read specific lines) - + Agents MUST support both formats. Mix-and-match is allowed in the same array. - + **AGENT FIELD SEMANTICS**: - `suggested_agent`: Recommendation from TaskManager during planning (e.g., "CoderAgent", "TestEngineer") - `agent_id`: Set by the working agent when task moves to `in_progress` (tracks who is actually working on it) - These are separate fields: suggestion vs. assignment - + **FRONTEND RULE**: If a task involves UI design, styling, or frontend implementation: 1. Set `suggested_agent`: "OpenFrontendSpecialist" 2. Include `~/.config/opencode/context/ui/web/ui-styling-standards.md` and `~/.config/opencode/context/core/workflows/design-iteration-overview.md` in `context_files`. 3. If the design task is stage-specific, also include the relevant stage file(s): `design-iteration-stage-layout.md`, `design-iteration-stage-theme.md`, `design-iteration-stage-animation.md`, `design-iteration-stage-implementation.md`. 4. Ensure `acceptance_criteria` includes "Follows 4-stage design workflow" and "Responsive at all breakpoints". 5. **PARALLELIZATION**: Design tasks can run in parallel (`parallel: true`) since design work is isolated and doesn't affect backend/logic implementation. Only mark `parallel: false` if design depends on backend API contracts or data structures. - + 4. Validate with CLI: ```bash npx ts-node --compiler-options '{"module":"commonjs"}' .opencode/skills/task-management/scripts/task-cli.ts validate {feature} @@ -287,12 +294,12 @@ WHY THIS MATTERS: ## Tasks Created Location: .tmp/tasks/{feature}/ - Files: task.json + {N} subtasks + Files: spec.md + task.json + {N} subtasks Next available: Run `task-cli.ts next {feature}` ``` - All JSON files created and validated + Spec and JSON files created and validated @@ -348,16 +355,18 @@ WHY THIS MATTERS: Feature archived to completed/ - + + Before any status update or file modification: + 1. Run `task-cli.ts status {feature}` to get current state 2. Verify counts match expectations 3. If mismatch: Read all subtask files and reconcile 4. Report any inconsistencies found - + @@ -374,24 +383,24 @@ Before any status update or file modification: .tmp/tasks/completed/{feature}/ - - Initial state, waiting for deps - Working agent picked up task - TaskManager verified completion - Issue found, cannot proceed - + +Initial state, waiting for deps +Working agent picked up task +TaskManager verified completion +Issue found, cannot proceed + - - TaskManager supports the Enhanced Task Schema (v2.0) with optional fields for domain modeling, prioritization, and architectural tracking. - All enhanced fields are OPTIONAL and backward compatible with existing task files. - - - - Reduce cognitive load by pointing agents to exact sections of large files - - ```json + +TaskManager supports the Enhanced Task Schema (v2.0) with optional fields for domain modeling, prioritization, and architectural tracking. +All enhanced fields are OPTIONAL and backward compatible with existing task files. + + + +Reduce cognitive load by pointing agents to exact sections of large files + +`json "context_files": [ { "path": "~/.config/opencode/context/core/standards/code-quality.md", @@ -404,35 +413,24 @@ Before any status update or file modification: "reason": "JWT validation and token refresh patterns" } ] - ``` - - - - File is >100 lines - - Only specific sections are relevant to the subtask - - Want to reduce agent reading time - - - Both formats are valid and can be mixed: - - String: (example: `"~/.config/opencode/context/file.md"`) - read entire file - - Object: `{"path": "...", "lines": "10-50", "reason": "..."}` (read specific lines) - - - - - - .tmp/tasks/{feature}/contexts.json - - - bounded_context: DDD bounded context (e.g., "authentication", "billing") - - module: Module/package name (e.g., "@app/auth", "payment-service") - - - When ArchitectureAnalyzer output exists: - 1. Load contexts.json - 2. Extract bounded_context for task.json - 3. Map subtasks to appropriate bounded contexts - 4. Set module field for each subtask based on context mapping - - + ` + + - File is >100 lines - Only specific sections are relevant to the subtask - Want to reduce agent reading time + + +Both formats are valid and can be mixed: - String: (example: `"~/.config/opencode/context/file.md"`) - read entire file - Object: `{"path": "...", "lines": "10-50", "reason": "..."}` (read specific lines) + + + + + +.tmp/tasks/{feature}/contexts.json + - bounded_context: DDD bounded context (e.g., "authentication", "billing") - module: Module/package name (e.g., "@app/auth", "payment-service") + + +When ArchitectureAnalyzer output exists: 1. Load contexts.json 2. Extract bounded_context for task.json 3. Map subtasks to appropriate bounded contexts 4. Set module field for each subtask based on context mapping + + .tmp/planning/{feature}/map.json @@ -491,18 +489,19 @@ Before any status update or file modification: 4. Include ADR constraints in acceptance criteria - - - - Check for planning agent outputs in .tmp/tasks/, .tmp/planning/, .tmp/contracts/, docs/adr/ - Load available outputs and extract relevant fields - Populate task.json with extracted fields (all optional) - Map fields to subtasks where relevant (e.g., bounded_context, contracts, related_adrs) - Maintain backward compatibility: omit fields if planning agent outputs don't exist - - - - ```json + + + + +Check for planning agent outputs in .tmp/tasks/, .tmp/planning/, .tmp/contracts/, docs/adr/ +Load available outputs and extract relevant fields +Populate task.json with extracted fields (all optional) +Map fields to subtasks where relevant (e.g., bounded_context, contracts, related_adrs) +Maintain backward compatibility: omit fields if planning agent outputs don't exist + + + +`json { "id": "user-authentication", "name": "User Authentication System", @@ -560,11 +559,11 @@ Before any status update or file modification: }, "release_slice": "v1.0.0" } - ``` - + ` + - - ```json + +`json { "id": "user-authentication-02", "seq": "02", @@ -609,35 +608,35 @@ Before any status update or file modification: } ] } - ``` - + ` + Use task-cli.ts for all status operations: -| Command | When to Use | -|---------|-------------| -| `status [feature]` | Before planning, to see current state | -| `next [feature]` | After task creation, to suggest next task | -| `parallel [feature]` | When batching isolated tasks | -| `deps feature seq` | When debugging blocked tasks | -| `blocked [feature]` | When tasks stuck | -| `complete feature seq "summary"` | After verifying task completion | -| `validate [feature]` | After creating files | +| Command | When to Use | +| -------------------------------- | ----------------------------------------- | +| `status [feature]` | Before planning, to see current state | +| `next [feature]` | After task creation, to suggest next task | +| `parallel [feature]` | When batching isolated tasks | +| `deps feature seq` | When debugging blocked tasks | +| `blocked [feature]` | When tasks stuck | +| `complete feature seq "summary"` | After verifying task completion | +| `validate [feature]` | After creating files | Script location: `.opencode/skills/task-management/scripts/task-cli.ts` - Each task completable in 1-2 hours - Single, measurable outcome per task - Specific files or endpoints - Pass/fail criteria only - Mark isolated tasks as parallel: true - Reference paths, don't embed content - Always include relevant context_files in task.json and each subtask - Max 200 characters for completion_summary +Each task completable in 1-2 hours +Single, measurable outcome per task +Specific files or endpoints +Pass/fail criteria only +Mark isolated tasks as parallel: true +Reference paths, don't embed content +Always include relevant context_files in task.json and each subtask +Max 200 characters for completion_summary From 70600a66a63b2a3828fe1f21e7abfb7222275d21 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Sat, 23 May 2026 09:14:53 +0700 Subject: [PATCH 09/11] feat(context): remove any oac related files from the context --- .../task-management/guides/managing-tasks.md | 26 +++++++++++++++---- .../task-management/guides/splitting-tasks.md | 12 +++++++-- context/core/task-management/navigation.md | 7 +++++ .../workflows/external-context-integration.md | 18 ++++++------- .../guides/subagent-invocation.md | 14 +++++----- 5 files changed, 53 insertions(+), 24 deletions(-) diff --git a/context/core/task-management/guides/managing-tasks.md b/context/core/task-management/guides/managing-tasks.md index 40e4831..9652ee1 100644 --- a/context/core/task-management/guides/managing-tasks.md +++ b/context/core/task-management/guides/managing-tasks.md @@ -11,6 +11,7 @@ ## Prerequisites - TaskManager agent available +- A feature plan is available for `/spec` - Feature folder created in `.tmp/tasks/` (at project root) --- @@ -18,20 +19,35 @@ ## Workflow Overview ``` -1. Initiation → TaskManager creates task.json + subtasks -2. Selection → Find eligible tasks (deps satisfied) -3. Execution → Working agent implements task -4. Verification → TaskManager validates completion -5. Archiving → Move to completed/ when done +0. Spec Generation → /spec loads TaskManager and creates spec.md + task bundle +1. Initiation → TaskManager creates task.json + subtasks +2. Selection → Find eligible tasks (deps satisfied) +3. Execution → Working agent implements task +4. Verification → TaskManager validates completion +5. Archiving → Move to completed/ when done ``` --- +## 0. Spec Generation (`/spec`) + +When the user has a feature plan and runs `/spec`: + +1. `/spec` loads TaskManager +2. TaskManager turns the plan into `spec.md` +3. TaskManager creates the task bundle under `.tmp/tasks/{feature-slug}/` +4. TaskManager presents the spec summary for approval + +The plan is the source of truth. TaskManager may ask clarifying questions if critical details are missing. + +--- + ## 1. Initiation (TaskManager) Create feature folder and files: ``` .tmp/tasks/{feature-slug}/ +├── spec.md ├── task.json ├── subtask_01.json ├── subtask_02.json diff --git a/context/core/task-management/guides/splitting-tasks.md b/context/core/task-management/guides/splitting-tasks.md index 5a6923e..ffe1f5b 100644 --- a/context/core/task-management/guides/splitting-tasks.md +++ b/context/core/task-management/guides/splitting-tasks.md @@ -10,13 +10,21 @@ ## Prerequisites -- Feature request understood -- Context bundle loaded (project standards, patterns) +- Feature plan or spec understood +- TaskManager has already generated the spec from `/spec`, or the plan is explicit enough to split directly --- ## Steps +### 0. Read the Spec + +Start from the spec generated by `/spec`: +- `spec.md` in `.tmp/tasks/{feature-slug}/` +- The user's plan if the spec is not yet saved + +The spec is the source of truth for decomposition. + ### 1. Identify Atomic Boundaries Break feature into tasks that are: diff --git a/context/core/task-management/navigation.md b/context/core/task-management/navigation.md index 7c440b3..f31566f 100644 --- a/context/core/task-management/navigation.md +++ b/context/core/task-management/navigation.md @@ -29,6 +29,7 @@ core/task-management/ | Task | Path | Priority | |------|------|----------| +| **Generate spec from a plan** | `guides/managing-tasks.md` | ⭐⭐⭐⭐⭐ | | **Understand base schema** | `standards/task-schema.md` | ⭐⭐⭐⭐⭐ | | **Use enhanced features** | `standards/enhanced-task-schema.md` | ⭐⭐⭐⭐ | | **Split a feature** | `guides/splitting-tasks.md` | ⭐⭐⭐⭐⭐ | @@ -44,6 +45,11 @@ core/task-management/ 2. Load `guides/splitting-tasks.md` (decomposition approach) 3. Reference `lookup/task-commands.md` (validate after creation) +### For Generating Specs from Plans: +1. Load `guides/managing-tasks.md` (spec + lifecycle flow) +2. Load `guides/splitting-tasks.md` (how specs become tasks) +3. Reference `standards/task-schema.md` (expected JSON output) + ### For Multi-Stage Orchestration: 1. Load `standards/enhanced-task-schema.md` (advanced features) 2. Load `standards/task-schema.md` (base structure reference) @@ -59,6 +65,7 @@ core/task-management/ ## Related - **Active tasks** → `.tmp/tasks/{feature}/` (at project root) +- **Spec artifacts** → `.tmp/tasks/{feature}/spec.md` - **Completed tasks** → `.tmp/tasks/completed/{feature}/` - **TaskManager agent** → `.opencode/agent/subagents/core/task-manager.md` - **Planning agents** → `.opencode/agent/subagents/planning/` (ArchitectureAnalyzer, StoryMapper, PrioritizationEngine, ContractManager, ADRManager) diff --git a/context/core/workflows/external-context-integration.md b/context/core/workflows/external-context-integration.md index aabb637..cc0f3a6 100644 --- a/context/core/workflows/external-context-integration.md +++ b/context/core/workflows/external-context-integration.md @@ -252,27 +252,25 @@ These are live documentation files fetched from external libraries. Subagents sh ```javascript task( subagent_type="TaskManager", - description="Break down Drizzle + Better Auth integration", - prompt="Load context from .tmp/sessions/2026-01-28-drizzle-auth/context.md + description="Generate spec and task bundle for Drizzle + Better Auth integration", + prompt="Use the plan below as the source of truth. - Read the context file for full requirements, standards, and external documentation. - - Break down this feature into atomic subtasks: + Turn this feature into a spec.md file and atomic subtasks: 1. Drizzle schema setup with modular organization 2. Better Auth configuration with Drizzle adapter 3. Next.js App Router integration 4. Test suite For each subtask, include: - - context_files: Standards from context.md - - reference_files: Project files to understand + - context_files: Standards only + - reference_files: Project files only - external_context: External docs to reference - - Create subtask files in tasks/subtasks/drizzle-auth-integration/" + + Create the bundle in .tmp/tasks/drizzle-auth-integration/" ) ``` -### Step 5: TaskManager Creates Subtasks with External Context +### Step 5: TaskManager Creates Spec + Subtasks with External Context TaskManager creates subtask JSONs like: diff --git a/context/openagents-repo/guides/subagent-invocation.md b/context/openagents-repo/guides/subagent-invocation.md index 4bb8cb3..b948cfe 100644 --- a/context/openagents-repo/guides/subagent-invocation.md +++ b/context/openagents-repo/guides/subagent-invocation.md @@ -139,16 +139,16 @@ type: subagent ```javascript task( subagent_type="Task Manager", - description="Break down complex feature", - prompt="Break down the following feature into atomic subtasks: - - Feature: {feature description} - + description="Generate spec and task bundle", + prompt="Turn the following plan into a spec.md file and atomic subtasks: + + Plan: {feature description} + Requirements: - {requirement 1} - {requirement 2} - - Create subtask files in tasks/subtasks/{feature}/" + + Create the bundle in .tmp/tasks/{feature}/" ) ``` From 81b3c57571db50005cbe924e9a4a20a0597b6d02 Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Sat, 23 May 2026 09:15:12 +0700 Subject: [PATCH 10/11] feat(command): update spec command --- AGENTS.md | 2 +- README.md | 2 +- commands/spec.md | 32 +++++++++++++------------------- skills/task-management/SKILL.md | 18 ++++++++++-------- 4 files changed, 25 insertions(+), 29 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index e882f36..13d14f1 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -377,7 +377,7 @@ The assistant should proceed autonomously for: - `/commit`: plan-only — show commit draft for approval, user executes outside the command - `/pr`: plan-only — show PR draft for approval, user executes outside the command - `/fix`: reproduce -> diagnose -> propose -> approve -> fix -> verify -- `/spec`: write spec, show summary, save after approval +- `/spec`: load TaskManager, generate spec from the plan, show summary, save after approval - `/review`: findings-first, no edits unless asked ### Workflow Principles diff --git a/README.md b/README.md index 5cff166..0ebf70a 100644 --- a/README.md +++ b/README.md @@ -159,7 +159,7 @@ Common workflows are available as slash commands: - `/commit` - produce one or more SRP commit drafts for approval (plan-only) - `/pr` - draft and create a pull request -- `/spec` - write or update a spec before implementation +- `/spec` - turn a plan into a spec and task bundle via TaskManager - `/review` - run a strict review on code or diffs - `/fix` - reproduce, patch, and verify a bug - `/context` - load relevant project context diff --git a/commands/spec.md b/commands/spec.md index 3ccb014..93827d4 100644 --- a/commands/spec.md +++ b/commands/spec.md @@ -1,10 +1,10 @@ --- -description: Create or update a feature specification (PRD/SDD) -agent: build -subtask: true +description: Generate a spec and task bundle from a feature plan +agent: TaskManager +subtask: false --- -Create or update a specification for the given feature following spec-driven development. +Generate a specification and task bundle from the user's plan. ## User Input @@ -12,25 +12,19 @@ $ARGUMENTS ## Process -1. **Interpret request**: Parse what feature the user wants specified. +1. **Interpret plan**: Treat the user's plan as the source of truth. -2. **Load methodology**: Load the `prd` and `spec-driven-development` skills. +2. **Load methodology**: Load the `task-management` skill and TaskManager guidance. 3. **Ask clarifying questions**: If ambiguous, ask up to 3 targeted questions: - - What is the core problem being solved? - - Who are the users/actors? - - What are the success criteria? + - What problem is being solved? + - Who are the users or actors? + - What defines success? -4. **Write spec**: Create or update a spec file under `tasks/` with: - - Feature name and brief description - - Actors and user stories - - Functional requirements - - Non-functional constraints - - Success criteria - - Out of scope (if applicable) +4. **Generate spec**: Create `spec.md` and the task bundle under `.tmp/tasks/{feature-slug}/`. -5. **Present**: Show the spec summary and ask for approval. +5. **Present**: Show the spec summary and task bundle summary. -6. **Save**: Write to `tasks/{feature-name}/spec.md`. +6. **Save**: Write the spec and task bundle after approval. -7. **Next steps**: Suggest follow-up commands like `/plan` or implementation tasks. +7. **Next steps**: Suggest implementation tasks or `/plan` follow-up. diff --git a/skills/task-management/SKILL.md b/skills/task-management/SKILL.md index 8143066..336e32e 100644 --- a/skills/task-management/SKILL.md +++ b/skills/task-management/SKILL.md @@ -15,13 +15,13 @@ tags: # Task Management Skill -> **Purpose**: Track, manage, and validate feature implementations with atomic task breakdowns, dependency resolution, and progress monitoring. +> **Purpose**: Track, manage, and validate feature implementations with spec generation, atomic task breakdowns, dependency resolution, and progress monitoring. --- ## What I Do -I provide a command-line interface for managing task breakdowns created by the TaskManager subagent. I help you: +I provide a command-line interface for managing task bundles created by the TaskManager subagent. I help you: - **Track progress** - See status of all features and their subtasks - **Find next tasks** - Show eligible tasks (dependencies satisfied) @@ -145,6 +145,7 @@ Tasks are stored in `.tmp/tasks/` at the project root: ``` .tmp/tasks/ ├── {feature-slug}/ +│ ├── spec.md # Generated spec │ ├── task.json # Feature-level metadata │ ├── subtask_01.json # Subtask definitions │ ├── subtask_02.json @@ -201,14 +202,15 @@ The TaskManager subagent creates task files using this format. When you delegate ```javascript task( subagent_type="TaskManager", - description="Implement feature X", - prompt="Break down this feature into atomic subtasks..." + description="Generate spec and task bundle for feature X", + prompt="Turn this plan into a spec.md file and atomic subtasks..." ) ``` TaskManager creates: -1. `.tmp/tasks/{feature}/task.json` - Feature metadata -2. `.tmp/tasks/{feature}/subtask_XX.json` - Individual subtasks +1. `.tmp/tasks/{feature}/spec.md` - Generated specification +2. `.tmp/tasks/{feature}/task.json` - Feature metadata +3. `.tmp/tasks/{feature}/subtask_XX.json` - Individual subtasks You can then use this skill to track and manage progress. @@ -290,8 +292,8 @@ Working agents (CoderAgent, TestEngineer, etc.) execute subtasks and report comp ### Starting a New Feature ```bash -# 1. TaskManager creates the task structure -task(subagent_type="TaskManager", description="Implement feature X", ...) +# 1. TaskManager creates the spec and task structure +task(subagent_type="TaskManager", description="Generate spec and task bundle for feature X", ...) # 2. Check what's ready bash .opencode/skills/task-management/router.sh next From b571ce7d273284b6184ec2c2bba3161a1be4d4de Mon Sep 17 00:00:00 2001 From: Jonathan0823 Date: Sat, 23 May 2026 11:34:25 +0700 Subject: [PATCH 11/11] feat(opencode): relax build agent permissions --- opencode.json | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/opencode.json b/opencode.json index 276600e..8001513 100644 --- a/opencode.json +++ b/opencode.json @@ -121,7 +121,24 @@ }, "build": { "temperature": 0.2, - "steps": 30 + "steps": 30, + "permission": { + "read": "allow", + "edit": "allow", + "write": "allow", + "bash": { + "*": "ask", + "npm run build*": "allow", + "npm run lint*": "allow", + "pnpm build*": "allow", + "yarn build*": "allow", + "npx tsc*": "allow", + "tsc*": "allow", + "go build*": "allow", + "cargo build*": "allow", + "python -m build*": "allow" + } + } } }, "tool_output": {