Menu
Test-driven development with red-green-refactor loop. Use when building a new feature or fixing a bug with TDD, or when asked for test-first development.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Bridge the ComfyUI anime image pipeline into the chat SSE stream so image generation renders inline in the chat bubble. Use when: changing how image-generation events reach the chat UI, editing the force_image_bridge gate or the SSE forwarder in stream.py, touching cancel / GPU-leak handling (GeneratorExit → request_cancel → /free), the error_class taxonomy, the Phase 1b thinking-block nesting, or the Phase 3 WS live-preview; debugging why an image turn stalls, double-renders, leaks VRAM, or shows the wrong error; or running the PR4 verification harness. This subsystem deliberately spans services/chatbot/ AND app/image_pipeline/.
Choose which repository skill to activate for a given task. Use when: starting any chatbot, MCP, config, or docs task to determine the best skill or skill combination; reviewing whether the right skills were applied; or deciding whether to combine multiple skills for a cross-cutting change.
Repository maintenance and coding-agent instructions for AI-Assistant.
Reason about the impact of chatbot/core changes on GitHub workflows, tests, security scans, and CI behavior. Use when: adding or changing routes, tools, providers, or dependencies; reviewing a PR that might affect CI; debugging CI failures after a chatbot change; checking whether a code change needs a workflow or docs update; or auditing workflow assumptions after startup or env changes.
Map changed files to the smallest sufficient verification set. Use when: deciding which tests to run after a code change, explaining why a test scope is enough, or choosing between unit tests, integration tests, and manual checks.
Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: "Index this repo", "Reanalyze the codebase", "Generate a wiki"
| name | tdd |
| description | Test-driven development with red-green-refactor loop. Use when building a new feature or fixing a bug with TDD, or when asked for test-first development. |
Vertical slices via tracer bullets. One test → one implementation → repeat.
Tests verify behavior through public interfaces, not implementation details.
If renaming an internal function breaks your test, the test was testing implementation, not behavior.
Do NOT write all tests first, then all code.
WRONG: RED: test1, test2, test3, test4 → GREEN: impl1, impl2, impl3, impl4
RIGHT: RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
For chatbot tasks — seam selection guide:
| What to test | Correct seam |
|---|---|
| Tool function | core/tools.py function directly |
| Route returns right JSON | pytest with Flask test client |
| SSE stream fields | routes/stream.py integration test |
| Provider routing | core/chatbot.py or chatbot_v2.py unit test |
| DB read/write | database/repositories/ with test DB |
Run existing tests first: cd services/chatbot && pytest tests/ -v
Write ONE test confirming ONE behavior:
RED: Write test for first behavior → fails
GREEN: Write minimal code to pass → passes
For each remaining behavior:
RED: Write next test → fails
GREEN: Minimal code to pass → passes
Rules:
pytest tests/<file> -vOnly after ALL tests pass:
Never refactor while RED.
[ ] Test describes behavior, not implementation
[ ] Test uses public interface only
[ ] Test would survive internal refactor
[ ] Code is minimal for this test
[ ] No speculative features added
[ ] Tests pass: pytest tests/ -v