DuckDuckGo Test Automation

This skill enforces documentation-driven development for the testDuckDuckGo project using GitHub Copilot. It ensures all code generation and project-specific answers come from the doc-bot MCP server rather than general AI knowledge.

How It Works

The skill implements a five-phase enforcement protocol:

1. **Environment Detection** - Activates when doc-bot MCP server is available

2. **Request Classification** - Categorizes user requests into four classes requiring different tool responses

3. **Execution Enforcement** - Forces tool execution before generating responses

4. **Quality Assurance** - Validates responses match tool outputs

5. **Behavioral Constraints** - Defines absolute prohibitions and mandatory behaviors

Instructions

Phase 1: Environment Detection

When the filesystem contains `doc-bot/` directory AND the `doc-bot` or `@afterxleep/doc-bot` MCP server is available:

Activate documentation enforcement protocol

Set project documentation as authoritative source

Disable general knowledge fallback

Phase 2: Request Classification

Classify every user request using these patterns:

**CLASS A: CODE_GENERATION**

Triggers: "write", "create", "implement", "build", "add", "code", "function", "class", "component", "method", "develop", "generate", "make", "refactor", "modify", "update", "fix", "debug"

Action: MANDATORY call to `check_project_rules` with task description

Must block until tool responds (30s timeout)

**CLASS B: PROJECT_INQUIRY**

Triggers: "how", "what", "why", "architecture", "approach", "pattern", "feature", "authentication", "database", "api", "testing"

Context: "this project", "this codebase", "here", "our", "current project"

Action: MANDATORY call to `search_documentation` with extracted keywords

Must block until tool responds (30s timeout)

**CLASS C: DOCUMENTATION_DISCOVERY**

Triggers: "documentation", "available", "capabilities", "help", "rules", "standards", "what exists", "docs", "guide"

Action: MANDATORY call to `get_global_rules`

Must block until tool responds (30s timeout)

**CLASS D: DOCUMENT_ACCESS**

Triggers: "read", "show", "get content", "full document", "complete", "entire"

Context: Previous search results present

Action: Call `read_specific_document` with filename

Non-blocking (15s timeout)

**Note**: For file-specific queries (e.g., "working on src/utils.js"), use `search_documentation` with the file name and context keywords.

Phase 3: Execution Enforcement

Before generating ANY response:

1. Classify the request using Phase 2 patterns

2. If classification is not "UNRELATED":

- Execute the mandatory tool call

- If tool returns error: provide error recovery response

- If tool succeeds: inject result into response context

3. Set tool result as authoritative source

4. Disable general knowledge fallback

While generating response:

If attempting to use general knowledge when tool result exists: INTERRUPT and force use of tool result

If code generation detected without project rules check: HALT and emit error

Phase 4: Quality Assurance

After generating response:

If response contradicts tool result: regenerate using only tool data

If response lacks attribution: append tool source reference

Validate response complies with project rules

If tool execution was bypassed:

Log violation

Regenerate with proper tool calls

Prepend warning: "Corrected response using project documentation:"

Phase 5: Behavioral Constraints

**ABSOLUTE PROHIBITIONS:**

Never generate code without validating project rules first

Never answer project-specific questions from general knowledge

Never override tool responses with training data

Never bypass tool calls for "simple" questions

**MANDATORY BEHAVIORS:**

Always use tool-first response generation

Always provide explicit attribution to tool results

Always prioritize project documentation over general knowledge

Always acknowledge and correct errors

Verification

Test the skill with these inputs (tool must be called immediately):

"What documentation is available?" → should call `get_global_rules()`

"How do I implement auth?" → should call `search_documentation("authentication")`

"Create a new component" → should call `check_project_rules("create component")`

"Working on src/utils.js" → should call `search_documentation("src/utils.js utils")`

Expected behavior: Tool execution within 2 seconds, no general knowledge responses.

Failure indicators: Any response without tool execution, generic programming advice, standard framework suggestions.

Usage Example

```

User: "I need to add a new test for the search feature"

Copilot:

1. Classifies as CODE_GENERATION (contains "add" + "test")

2. Calls check_project_rules("add test for search feature")

3. Receives project testing standards from doc-bot

4. Generates code following documented patterns

5. Attributes response to project documentation

```

Notes

This skill requires the doc-bot MCP server to be installed and configured

Tool calls must complete before response generation

All project-specific answers must come from tool results, not AI training data

General knowledge fallback is disabled when project documentation exists

DuckDuckGo Test Automation

DuckDuckGo Test Automation

How It Works

Instructions

Phase 1: Environment Detection

Phase 2: Request Classification

Phase 3: Execution Enforcement

Phase 4: Quality Assurance

Phase 5: Behavioral Constraints

Verification

Usage Example

Notes

Reviews (0)