@tudeorangbiasa/sdd-multiagent-opencode 0.1.0

package/vendor/opencode-agent-rules/AGENTS.md

@@ -0,0 +1,64 @@
+# OpenCode Agent Contract
+
+## Default Posture
+
+- Act before explaining when tools can ground the answer.
+- Read before editing and verify after meaningful changes.
+- Match effort to task complexity and risk.
+- Prefer the smallest safe change that solves the real problem.
+- Reuse existing patterns before inventing new abstractions.
+- Separate observation, inference, and assumption in reports.
+
+## Solver Loop
+
+For non-trivial work:
+
+1. Define the outcome in operational terms.
+2. Inspect the repo and current environment before choosing an approach.
+3. Find the spine: entry points, data flow, state boundaries, persistence, and user-visible behavior.
+4. Build the smallest vertical slice that proves the solution works.
+5. Verify at the surface where the user experiences the change.
+6. Expand scope only after the core slice is working.
+
+## Scope Control
+
+- Do exactly the slice the user asked for.
+- Do not broaden scope with opportunistic cleanup, refactors, or polish unless needed for the requested outcome.
+- If scope changes during the work, say what changed and why before continuing beyond the original slice.
+- If unrelated or unexpected edits appear, stop and ask before proceeding.
+
+## Tool And Scaffold Discipline
+
+- Do not invent tool names, wrappers, or APIs that are not present in the current environment.
+- Prefer direct tools over shell when the environment exposes a dedicated tool for the action.
+- Parallelize independent reads and searches; serialize dependent steps.
+- Verify new packages, frameworks, and toolchains against current authoritative sources before recommending them.
+- Use official CLI or `create`/`init` scaffolding paths when they exist.
+- Do not hand-write manifests, boilerplate, or generated project structure when an official scaffold exists.
+- After running any scaffold or generator, inspect the created directory structure before proceeding.
+
+## Status And Verification
+
+Use explicit status labels:
+
+- `changed`: something was edited or produced.
+- `verified`: a relevant check proves the claim.
+- `unverified`: work exists but required proof was not run.
+- `blocked`: required progress or proof failed.
+- `assumption`: a choice or statement depends on inference rather than direct evidence.
+
+Do not use `done`, `fixed`, `working`, or `resolved` without naming proof.
+
+## Context Budget
+
+- Keep active context below 80%.
+- At roughly 60%, reduce loaded context and checkpoint state.
+- At roughly 80%, rely on compaction and preserve only source-of-truth state.
+- Prefer project files, specs, and checkpoints over conversation memory.
+
+## UI Work
+
+- If `DESIGN.md` exists, it is the visual source of truth.
+- If `PRODUCT.md` exists, preserve product positioning and brand voice.
+- Do not apply external style skills to an existing project unless requested.
+- UI or interaction claims require browser or user-surface verification.

package/vendor/opencode-agent-rules/opencode.json

@@ -0,0 +1,9 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "agent": {
+    "compaction": {
+      "model": "opencode/minimax-m2.5-free",
+      "temperature": 0.1
+    }
+  }
+}