DuckDuckGo Android Development

This skill enforces project-specific rules and documentation for the DuckDuckGo Android app. It ensures all code generation and project inquiries are validated against established documentation and standards.

Prerequisites

This skill activates when:

When active, project documentation becomes the authoritative source, overriding general knowledge.

Request Classification

The skill automatically classifies all requests into four categories and takes mandatory actions:

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

**Blocking:** Cannot proceed without tool response (30s timeout)

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

**Blocking:** Cannot proceed without tool response (30s timeout)

CLASS C: Documentation Discovery

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

**Action:** MUST call `get_global_rules`

**Blocking:** Cannot proceed without tool response (30s timeout)

CLASS D: Document Access

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

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

**Blocking:** Non-blocking (15s timeout)

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

Instructions

1. Pre-Response Validation

Before generating any response:

1. Classify the user's request using the classification matrix above

2. If the request is not unrelated to the project, execute the mandatory tool for that classification

3. If the tool returns an error, provide an error recovery response

4. If the tool succeeds, inject the tool result into your response context

5. Set the tool result as the authoritative source

6. Disable general knowledge fallback

2. Response Generation

While generating your response:

3. Post-Response Validation

After generating your response:

4. Failure Detection

If you generate a response without executing required tools:

Absolute Prohibitions

Mandatory Behaviors

Example Interactions

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

**Action:** Immediately call `get_global_rules()`

**User:** "How do I implement authentication?"

**Action:** Immediately call `search_documentation("authentication")`

**User:** "Create a new component for user profiles"

**Action:** Immediately call `check_project_rules("create user profile component")`

**User:** "I'm working on src/utils.js and need to add validation"

**Action:** Immediately call `search_documentation("src/utils.js validation")`

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

**Failure Indicators:** Any response without tool execution, generic programming advice, standard framework suggestions without project context.

Important Notes