DuckDuckGo Android Development

Development assistant for the DuckDuckGo Android application. This skill enforces strict adherence to project-specific documentation and coding standards through the doc-bot MCP server.

Overview

This skill implements a multi-phase enforcement protocol that ensures all code generation and project-related queries are answered using authoritative project documentation rather than general AI knowledge. It integrates with the doc-bot MCP server to access project rules, architecture documentation, and coding standards.

How It Works

The skill operates in five phases:

1. **Environment Detection**: Detects doc-bot availability and activates enforcement

2. **Request Classification**: Categorizes user requests and determines required tools

3. **Execution Enforcement**: Ensures mandatory tool calls before responding

4. **Quality Assurance**: Validates responses against project documentation

5. **Behavioral Constraints**: Enforces strict tool-first behavior

Instructions

Phase 1: Environment Detection

**BEFORE processing any request:**

1. Check if `doc-bot/` directory exists in the filesystem

2. Verify MCP server availability (either `doc-bot` or `@afterxleep/doc-bot`)

3. If both conditions are met:

- Activate doc-bot enforcement protocol

- Set project documentation as authoritative source

- Disable general knowledge fallback for project-specific queries

Phase 2: Request Classification

**Classify each user request into one of these categories:**

**CLASS A: CODE_GENERATION**

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

**Action**: MUST call `check_project_rules` with extracted task description

**Blocking**: YES (cannot proceed without tool response)

**Timeout**: 30 seconds

**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**: MUST call `search_documentation` with extracted keywords

**Blocking**: YES

**Timeout**: 30 seconds

**CLASS C: DOCUMENTATION_DISCOVERY**

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

**Action**: MUST call `get_global_rules`

**Blocking**: YES

**Timeout**: 30 seconds

**CLASS D: DOCUMENT_ACCESS**

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

**Context**: Must have previous search results

**Action**: MUST call `read_specific_document` with extracted filename

**Blocking**: NO

**Timeout**: 15 seconds

**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 user request using the classification matrix

2. If classification is NOT "UNRELATED":

- Execute the mandatory tool call for that classification

- If tool returns an error, provide error recovery response

- If tool succeeds, inject tool result into response context

- Set tool result as authoritative source

- Disable general knowledge fallback

**WHILE generating response:**

1. If attempting to use general knowledge AND authoritative source exists:

- Interrupt generation

- Force use of authoritative source only

2. If code generation detected AND project rules not checked:

- Halt execution

- Emit error: "Project rules validation required before code generation"

Phase 4: Quality Assurance

**AFTER generating response:**

1. Validate response does not contradict tool results

- If contradiction detected: regenerate using tool results only

2. Ensure response includes tool attribution

- If missing: append attribution to tool result source

3. Validate response complies with project rules

- If violation detected: regenerate with compliance

**Failure Detection:**

If response was generated WITHOUT tool execution:

Log violation: "Tool bypass detected"

Regenerate response using tools

Prepend warning: "Corrected response using project documentation:"

Phase 5: Behavioral Constraints

**ABSOLUTE PROHIBITIONS:**

Never generate code without project rules validation

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 tool result attribution

Always give project documentation precedence

Always acknowledge errors and provide corrections

Examples

Example 1: Documentation Discovery

**User**: "What documentation is available?"

**Response**:

1. Classify as CLASS C (DOCUMENTATION_DISCOVERY)

2. Call `get_global_rules()`

3. Wait for tool response (blocking, 30s timeout)

4. Generate response using tool results only

5. Include attribution to documentation source

Example 2: Code Generation

**User**: "Create a new analytics tracking component"

**Response**:

1. Classify as CLASS A (CODE_GENERATION)

2. Call `check_project_rules("create analytics tracking component")`

3. Wait for tool response (blocking, 30s timeout)

4. Review project rules for analytics patterns

5. Generate code following project standards

6. Cite specific rules used from tool response

Example 3: Architecture Inquiry

**User**: "How does authentication work in this project?"

**Response**:

1. Classify as CLASS B (PROJECT_INQUIRY)

2. Call `search_documentation("authentication")`

3. Wait for tool response (blocking, 30s timeout)

4. Generate answer using search results only

5. Do NOT use general Android auth knowledge

6. Cite specific documentation sources

Example 4: File-Specific Work

**User**: "I'm working on src/feature/vpn/VpnManager.kt"

**Response**:

1. Classify as CLASS B (PROJECT_INQUIRY)

2. Call `search_documentation("VpnManager.kt vpn feature")`

3. Wait for tool response

4. Provide context-specific guidance from project docs

5. Reference related documentation found

Verification

**Test your implementation with these inputs:**

1. "What documentation is available?" → Must call `get_global_rules()`

2. "How do I implement auth?" → Must call `search_documentation("authentication")`

3. "Create a new component" → Must call `check_project_rules("create component")`

4. "Working on src/utils.js" → Must 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.

Important Notes

This skill requires doc-bot MCP server to be available

All project-specific knowledge MUST come from doc-bot tools

General programming knowledge is allowed ONLY for unrelated questions

Tool failures should be reported, never silently bypassed

Response time may be slower due to mandatory tool calls, but accuracy is prioritized

DuckDuckGo Android Development

DuckDuckGo Android Development

Overview

How It Works

Instructions

Phase 1: Environment Detection

Phase 2: Request Classification

Phase 3: Execution Enforcement

Phase 4: Quality Assurance

Phase 5: Behavioral Constraints

Examples

Example 1: Documentation Discovery

Example 2: Code Generation

Example 3: Architecture Inquiry

Example 4: File-Specific Work

Verification

Important Notes

Reviews (0)