AgentSkillsCN

dci-dogfooding

当 DCI 群集的代码发生变更,且需要通过实时系统进行验证时使用——通过 API 调用与 CLI 命令,在运行中的群集中测试新功能、端点与行为表现

SKILL.md
--- frontmatter
name: dci-dogfooding
description: Use when code changes have been made to the DCI swarm and need to be verified through the live system — exercises new features, endpoints, and behaviors via API calls and CLI commands against the running swarm

DCI Dogfooding

Overview

Verify code changes to the DCI swarm by exercising them through the live system. You test through the API and CLI, never by reading source code or running unit tests. The running swarm is the source of truth.

Core principle: If you didn't exercise it through the live API, you didn't verify it.

When to Use

  • After implementing backend/frontend changes to the DCI swarm
  • After fixing bugs in the swarm
  • When the user says "dogfood this" or "verify through the swarm"
  • Before committing changes, to catch runtime issues unit tests miss

When NOT to use:

  • For unit test verification (use pytest directly)
  • For TypeScript type checking (use tsc)
  • For code review (use code-review skill)

Prerequisites

The backend must be running at localhost:8000. Check with:

bash
curl -s http://localhost:8000/api/v1/corps | head -c 100

If not running: ./dci forward-march or ./dci ten-hut.

The Process

1. Identify What Changed

List the features/endpoints that were added or modified. For each, determine the API call that exercises it.

2. Exercise Each Change via API

For every changed feature, make the actual API call and verify the response:

bash
# Example: testing a new query parameter
curl -s http://localhost:8000/api/v1/corps | jq '.[] | .corps_type'

# Example: testing a rejection case
curl -s -X POST http://localhost:8000/api/v1/seasons/test/corps \
  -H "Content-Type: application/json" \
  -d '{"corps_id": "system-corps-id"}'
# Expect: 400

Do NOT:

  • Assume it works because the code looks right
  • Skip error cases (test rejections, not just happy paths)
  • Only test via the UI (Playwright clicks don't prove the API works)

3. Run Integration Flows

If the change touches a workflow (e.g., competition → auto-critique), run the full flow:

bash
# Create a test season
curl -X POST http://localhost:8000/api/v1/seasons -d '...'

# Register corps
curl -X POST http://localhost:8000/api/v1/seasons/<id>/corps -d '...'

# Run competition
curl -X POST http://localhost:8000/api/v1/seasons/<id>/competitions/<comp>/run

# Check results
curl http://localhost:8000/api/v1/seasons/<id>/competitions/<comp>/standings

4. Report Findings

For each feature tested:

  • PASS: API returned expected response
  • FAIL: Unexpected error or wrong behavior (include the error)
  • FIXED: Found and fixed a bug during dogfooding (describe what was wrong)

5. Fix and Re-verify

If bugs are found:

  1. Fix the code
  2. Re-exercise the same API call
  3. Confirm the fix works through the live system

Common Mistakes

MistakeFix
Only clicking through Playwright UIMake direct API calls with curl
Testing only happy pathsTest error cases, rejections, edge cases
Assuming code correctness from reading itExercise it live — runtime bugs are invisible in source
Skipping multi-step workflowsIf feature spans multiple endpoints, test the full flow
Not checking response bodiesRead the actual JSON, don't just check status codes