DuckDuckGo Android Project Standards

This skill enforces strict documentation-driven development for the DuckDuckGo Android project. It ensures all code generation and project-specific responses are validated against project documentation through the doc-bot MCP server.

Purpose

Maintains consistency with DuckDuckGo Android project standards by:

Preventing code generation without project rules validation

Ensuring project-specific answers come from documentation, not general knowledge

Enforcing mandatory documentation checks for all development tasks

Providing authoritative, project-specific guidance

Instructions

Phase 1: Environment Detection

**CRITICAL**: Before processing any request, verify the doc-bot MCP server is available:

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

2. Confirm MCP server `doc-bot` or `@afterxleep/doc-bot` is accessible

3. If both conditions are met:

- Activate documentation enforcement protocol

- Disable general knowledge responses for project-specific queries

- Set project documentation as the sole authoritative source

Phase 2: Request Classification

Classify every user request into one of these categories and execute the corresponding mandatory tool call:

#### CLASS A: CODE_GENERATION

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

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

**Blocking**: Cannot generate any code without tool response

**Timeout**: 30 seconds

**Example**: "Create a new view model" → `check_project_rules("create view model")`

#### CLASS B: PROJECT_INQUIRY

**Triggers**: how, what, why, architecture, approach, pattern, feature, authentication, database, api, testing (in project context)

**Required Action**: MUST call `search_documentation` with extracted keywords

**Blocking**: Cannot answer without documentation search

**Timeout**: 30 seconds

**Example**: "How does authentication work in this project?" → `search_documentation("authentication")`

#### CLASS C: DOCUMENTATION_DISCOVERY

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

**Required Action**: MUST call `get_global_rules`

**Blocking**: Cannot list documentation without tool call

**Timeout**: 30 seconds

**Example**: "What documentation is available?" → `get_global_rules()`

#### CLASS D: DOCUMENT_ACCESS

**Triggers**: read, show, get content, full document, complete, entire (when search results are present)

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

**Blocking**: Non-blocking (can provide partial response)

**Timeout**: 15 seconds

**Example**: "Show me the full architecture doc" → `read_specific_document("architecture.md")`

**File-Specific Queries**: For questions about specific files (e.g., "working on src/utils.js"), use `search_documentation` with the file name and context keywords instead of a separate tool.

Phase 3: Execution Enforcement

**Pre-Response Validation**:

1. Classify the user request using Phase 2 rules

2. If classification is not "UNRELATED":

- Execute mandatory tool call BEFORE generating any response

- 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 for project-specific content

**Response Constraint Engine**:

While generating response:

- If attempting to use general knowledge when authoritative source exists: STOP and force use of tool result

- If code generation detected without project rules check: HALT and require validation

- Never override tool responses with training data

Phase 4: Quality Assurance

**Response Validation**:

1. After generating response:

- Verify response doesn't contradict tool result

- If contradiction found: regenerate response using only tool result

- Ensure tool attribution is present

- Validate compliance with project rules from tool result

**Failure Detection & Recovery**:

If response generated without required tool execution:

- Log violation internally

- Regenerate response with mandatory tool calls

- Prepend warning: "Corrected response using project documentation:"

Phase 5: Behavioral Constraints

**ABSOLUTE PROHIBITIONS**:

❌ Code generation without `check_project_rules` validation

❌ Project-specific answers from general knowledge

❌ Overriding tool responses with training data

❌ Bypassing tool calls for "simple" questions

❌ Making assumptions about project architecture without documentation search

**MANDATORY BEHAVIORS**:

✅ Tool-first response generation (always call tools before responding)

✅ Explicit attribution of tool results in responses

✅ Project documentation takes precedence over general knowledge

✅ Acknowledge errors and correct with documentation

✅ Surface documentation gaps to user when tools return incomplete results

Examples

Example 1: Code Generation Request

**User**: "Create a new repository class for user data"

**Required Flow**:

1. Classify as CLASS A: CODE_GENERATION

2. Call `check_project_rules("create repository class user data")`

3. Wait for tool response (blocking)

4. Generate code following rules from tool response

5. Attribute: "Based on project standards from [doc-bot source]"

Example 2: Project Architecture Inquiry

**User**: "How is dependency injection handled here?"

**Required Flow**:

1. Classify as CLASS B: PROJECT_INQUIRY

2. Call `search_documentation("dependency injection")`

3. Wait for tool response (blocking)

4. Provide answer using only documentation results

5. If no results: "I couldn't find specific documentation on dependency injection. Available docs: [list from get_global_rules]"

Example 3: Documentation Discovery

**User**: "What documentation exists for this project?"

**Required Flow**:

1. Classify as CLASS C: DOCUMENTATION_DISCOVERY

2. Call `get_global_rules()`

3. Wait for tool response (blocking)

4. List available documentation with summaries

5. Suggest relevant docs based on current conversation context

Example 4: File-Specific Query

**User**: "I'm working on src/data/UserRepository.kt, what patterns should I follow?"

**Required Flow**:

1. Classify as CLASS B: PROJECT_INQUIRY

2. Call `search_documentation("src/data/UserRepository.kt repository patterns")`

3. Wait for tool response (blocking)

4. Provide guidance from documentation results

5. If file-specific rules found, highlight them

Verification Protocol

**Test these inputs to verify correct behavior**:

| Input | Expected Tool Call | Timeout |

|-------|-------------------|---------|

| "What documentation is available?" | `get_global_rules()` | 30s |

| "How do I implement auth?" | `search_documentation("authentication")` | 30s |

| "Create a new component" | `check_project_rules("create component")` | 30s |

| "Working on src/utils.js" | `search_documentation("src/utils.js utils")` | 30s |

**Expected Behavior**:

Tool execution within 2 seconds of request

No responses containing general Android/Kotlin advice without tool validation

Clear attribution of documentation sources

Error messages when tools are unavailable

**Failure Indicators** (these should NEVER happen):

Any response without tool execution for classified requests

Generic programming advice for project-specific questions

Standard Android framework suggestions without project context validation

Code generation before `check_project_rules` completion

Constraints

Requires doc-bot MCP server to be installed and accessible

Only activates when `doc-bot/` directory exists in project

30-second timeout for blocking tool calls (user should be notified if exceeded)

Cannot function properly without MCP server connection

All project-specific responses must be traceable to documentation sources

DuckDuckGo Android Project Standards

DuckDuckGo Android Project Standards

Purpose

Instructions

Phase 1: Environment Detection

Phase 2: Request Classification

Phase 3: Execution Enforcement

Phase 4: Quality Assurance

Phase 5: Behavioral Constraints

Examples

Example 1: Code Generation Request

Example 2: Project Architecture Inquiry

Example 3: Documentation Discovery

Example 4: File-Specific Query

Verification Protocol

Constraints

Reviews (0)