DuckDuckGo Android Development Guide

This skill enforces strict documentation-driven development for the DuckDuckGo Android app. It requires the doc-bot MCP server to be available and prioritizes project-specific rules over general knowledge.

Environment Requirements

This skill activates when:

Request Classification

All requests are classified into four categories, each triggering specific tool calls:

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 before generating any code

**Examples**:

CLASS B: Project Inquiry

**Triggers**: how, what, why, architecture, approach, pattern, feature, authentication, database, api, testing (when referencing "this project", "this codebase", "here", "our", "current project")

**Action**: MANDATORY call to `search_documentation` with extracted keywords

**Examples**:

CLASS C: Documentation Discovery

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

**Action**: MANDATORY call to `get_global_rules`

**Examples**:

CLASS D: Document Access

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

**Action**: Call `read_specific_document` with filename

**Examples**:

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

Execution Rules

Before Generating Any Response:

1. **Classify the request** using the patterns above

2. **Execute mandatory tools** for the classification

3. **Wait for tool results** (timeout: 30s for Class A/B/C, 15s for Class D)

4. **Inject tool results** into response context as authoritative source

5. **Disable general knowledge fallback** when project documentation exists

During Response Generation:

After Response Generation:

Absolute Prohibitions

1. **NEVER generate code** without calling `check_project_rules` first

2. **NEVER answer project-specific questions** from general knowledge

3. **NEVER override tool responses** with training data

4. **NEVER bypass tool calls** for "simple" questions

Mandatory Behaviors

1. **Always call tools first** before responding

2. **Always cite tool results** explicitly in responses

3. **Always prioritize project documentation** over general knowledge

4. **Always acknowledge errors** and correct using tools

Verification Tests

To verify this skill is working correctly, test these inputs:

1. "What documentation is available?"

- Expected: Immediate call to `get_global_rules()`

2. "How do I implement auth?"

- Expected: Immediate call to `search_documentation("authentication")`

3. "Create a new component"

- Expected: Immediate call to `check_project_rules("create component")`

4. "Working on src/utils.js"

- Expected: Call to `search_documentation("src/utils.js utils")`

**Success criteria**: Tool execution within 2 seconds, no generic programming advice, no standard framework suggestions without project context.

**Failure indicators**: Response without tool execution, generic advice, or suggestions not grounded in project documentation.

Error Recovery

If a tool call fails:

1. Acknowledge the error explicitly

2. Explain what information is missing

3. Suggest alternative approaches within project constraints

4. Do NOT fall back to general knowledge

Response Format

Always structure responses as:

```

[Tool execution and results summary]

[Response based on tool results]

[Attribution: "Based on {document/rule name} from project documentation"]

```

Notes