From 53215a2ef700560f25338ab238ca989142f1b5f0 Mon Sep 17 00:00:00 2001 From: ZJustin117 Date: Thu, 28 May 2026 20:23:51 +0800 Subject: [PATCH] feat: add TDD opencode workflow --- .opencode/opencode.json | 25 +++++ .opencode/skills/tdd-development/SKILL.md | 93 +++++++++++++++++++ .../skills/tdd-development/agents/openai.yaml | 4 + 3 files changed, 122 insertions(+) create mode 100644 .opencode/opencode.json create mode 100644 .opencode/skills/tdd-development/SKILL.md create mode 100644 .opencode/skills/tdd-development/agents/openai.yaml diff --git a/.opencode/opencode.json b/.opencode/opencode.json new file mode 100644 index 00000000..af8535a7 --- /dev/null +++ b/.opencode/opencode.json @@ -0,0 +1,25 @@ +{ + "$schema": "https://opencode.ai/config.json", + "command": { + "tdd": { + "description": "Develop a requested change using a strict TDD red-green-refactor loop.", + "template": "Use $tdd-development in Full TDD mode for the requested change. First identify the smallest behavior to test, add or update the minimal failing test, run the smallest relevant Gradle test command to confirm Red, implement the smallest production change, rerun the same test to confirm Green, then refactor only if useful and rerun verification. Prefer module-scoped commands such as ./gradlew :app:testDebugUnitTest or ./gradlew :module:test. Report Red, Green, Refactor, commands run, and any skipped verification." + }, + "tdd-red": { + "description": "Add the smallest failing test for a requested behavior.", + "template": "Use $tdd-development in Red-only mode. Locate the smallest relevant test surface, add or update one behavior-focused test for the requested change, run the narrowest relevant Gradle test command to confirm it fails for the expected reason, then stop and report the failing test, command, and failure evidence. Do not implement production behavior unless a pre-existing test seam requires a minimal compile fix." + }, + "tdd-green": { + "description": "Make the existing failing test pass with the smallest implementation.", + "template": "Use $tdd-development in Green-only mode. Start from the existing failing test or the failure described by the user, implement the smallest production change that makes it pass, rerun the same focused test command, and report the implementation files changed plus verification results. Avoid unrelated refactors." + }, + "tdd-refactor": { + "description": "Refactor under passing tests and rerun verification.", + "template": "Use $tdd-development in Refactor-only mode. Confirm the relevant tests are passing or identify the existing passing command, make only behavior-preserving cleanup, rerun the focused test command afterward, and report what changed and how behavior was protected. Do not add unrelated features or fixes." + }, + "tdd-review": { + "description": "Review whether a change follows effective TDD practice.", + "template": "Use $tdd-development in Review mode. Inspect the current change or requested files for meaningful behavior tests, Red/Green evidence, minimal implementation scope, brittle assertions, missing edge cases, and verification gaps. Return findings first with file and line references when available. Do not modify files unless explicitly asked." + } + } +} diff --git a/.opencode/skills/tdd-development/SKILL.md b/.opencode/skills/tdd-development/SKILL.md new file mode 100644 index 00000000..e56f37fb --- /dev/null +++ b/.opencode/skills/tdd-development/SKILL.md @@ -0,0 +1,93 @@ +--- +name: tdd-development +description: Guide test-driven development for code changes by enforcing a red-green-refactor loop, minimal behavior tests, focused implementation, and relevant verification commands. Use when asked to implement, fix, refactor, or review code using TDD. +--- + +# TDD Development + +## Quick Start + +1. Define the smallest observable behavior that proves the requested change. +2. Add or update the minimal failing test before changing production code. +3. Run the smallest relevant test command and confirm the failure is expected. +4. Implement the smallest production change that makes the test pass. +5. Rerun the same test, then refactor only when it improves clarity without changing behavior. +6. Finish with the relevant regression command and report Red, Green, Refactor, and verification results. + +## Workflow + +1. Clarify the behavior. +- Restate the requested behavior, bug, or refactor target in testable terms. +- Identify the smallest unit or integration boundary that can prove it. +- Search for nearby tests and existing test style before creating a new test file. +- If requirements are ambiguous, ask one focused question before writing tests. + +2. Red: write the failing test. +- Add the smallest test that fails for the right reason. +- Prefer behavior assertions over implementation details. +- Cover important edge cases only when they are part of the requested behavior or likely regression surface. +- Do not edit production code during the Red step unless needed to expose a test seam that already exists in the design. + +3. Verify Red. +- Run the narrowest relevant test command. +- Confirm the test fails because the behavior is missing or broken. +- If the test cannot run locally, state the blocker and use the closest static or build verification available. +- If the test passes unexpectedly, stop and reassess whether the behavior already exists or the test is insufficient. + +4. Green: implement minimally. +- Make the smallest production change that satisfies the failing test. +- Keep the change local to the behavior under test. +- Avoid opportunistic cleanup, broad rewrites, new abstractions, or unrelated fixes. +- Preserve existing architecture and style. + +5. Verify Green. +- Rerun the exact Red command first. +- If it passes, run the next relevant regression command when practical. +- If it fails for a different reason, diagnose and keep the loop focused. + +6. Refactor safely. +- Refactor only when the passing test protects the behavior and the cleanup is worthwhile. +- Keep refactors small and behavior-preserving. +- Rerun the relevant tests after refactoring. +- Do not combine unrelated refactors with the TDD change. + +7. Report clearly. +- State the Red test added or changed. +- State the Green implementation change. +- State any Refactor step or say none was needed. +- List commands run and their results. +- Call out skipped verification, environmental blockers, and residual risks. + +## Project Test Commands + +- Android app unit tests: `./gradlew :app:testDebugUnitTest` +- Android app local tests: `./gradlew :app:test` +- JVM module tests: `./gradlew :boot-bridge:test`, `./gradlew :patches:gdx-patch:test`, `./gradlew :workshop-core:test`, or the matching module task. +- Mod module tests: `./gradlew :mods:amethyst-runtime-compat:test` or `./gradlew :mods:ram-saver:test` when available. +- Broader regression: `./gradlew test` or `./gradlew check` when the change spans modules and runtime cost is acceptable. +- Instrumented or UI behavior: prefer a local unit test first; use `connectedAndroidTest` only when a device or emulator is available and the behavior requires it. + +## Command-Specific Modes + +- Full TDD mode: complete Clarify, Red, Verify Red, Green, Verify Green, optional Refactor, and final report. +- Red-only mode: stop after adding the failing test and confirming the expected failure. +- Green-only mode: start from an existing failing test, implement minimally, and verify the test passes. +- Refactor-only mode: require passing tests first, refactor narrowly, then rerun relevant tests. +- Review mode: inspect whether an existing change has meaningful tests, whether tests assert behavior, and whether implementation scope is minimal. + +## Anti-Patterns To Avoid + +- Writing production code before a failing test when the request explicitly asks for TDD. +- Adding broad snapshot or brittle implementation-detail tests as the primary proof. +- Skipping the Red verification and claiming TDD based only on a final passing test. +- Expanding the task into unrelated cleanup or architecture changes. +- Silencing or weakening tests to reach Green. +- Treating unrun tests as passed. + +## Response Rules + +- Be explicit about the current phase: Red, Green, Refactor, or verification. +- Cite file paths for tests and production changes. +- Include exact commands run. +- If a command fails, summarize the relevant failure and next action. +- Keep the final summary concise and focused on behavior, tests, and verification. diff --git a/.opencode/skills/tdd-development/agents/openai.yaml b/.opencode/skills/tdd-development/agents/openai.yaml new file mode 100644 index 00000000..935070a5 --- /dev/null +++ b/.opencode/skills/tdd-development/agents/openai.yaml @@ -0,0 +1,4 @@ +interface: + display_name: "TDD Development" + short_description: "Develop code with a red-green-refactor loop" + default_prompt: "Use $tdd-development to implement the requested change with strict TDD: write a failing behavior test first, verify Red, implement minimally, verify Green, refactor only when useful, and report commands run."