Enforces doc-bot MCP server usage for project-specific queries, code generation, and documentation access in the DuckDuckGo Android app. Ensures all responses derive from project documentation rather than general knowledge.
This skill enforces strict documentation-first workflows for the DuckDuckGo Android app using the doc-bot MCP server. All code generation and project-specific questions must be validated against project documentation before generating responses.
Before responding to any request, verify the environment:
1. Check if `doc-bot/` directory exists in the filesystem
2. Verify MCP server availability: `doc-bot` or `@afterxleep/doc-bot`
3. If both conditions are met, activate enforcement protocol:
- Set project documentation as authoritative source
- Disable general knowledge fallback for project-specific queries
Classify every incoming request into one of these categories:
**Triggers**: write, create, implement, build, add, code, function, class, component, method, develop, generate, make, refactor, modify, update, fix, debug
**Required Action**:
**Example**: "Create a new authentication component" → Must call `check_project_rules("create authentication component")` before generating any code.
**Triggers**: how, what, why, architecture, approach, pattern, feature, authentication, database, api, testing
**Context Pattern**: this project, this codebase, here, our, current project
**Required Action**:
**Example**: "How does authentication work in this project?" → Must call `search_documentation("authentication")` before answering.
**Triggers**: documentation, available, capabilities, help, rules, standards, what exists, docs, guide
**Required Action**:
**Example**: "What documentation is available?" → Must call `get_global_rules()` immediately.
**Triggers**: read, show, get content, full document, complete, entire
**Required Action**:
**Example**: "Show the full architecture document" → Must call `read_specific_document("architecture.md")`.
**Note**: For file-specific queries like "working on src/utils.js", use `search_documentation("src/utils.js utils")` with the file name and context keywords.
Before generating any response:
1. Classify the user request
2. If classification is not "UNRELATED":
- Execute the mandatory tool call
- If tool returns error, generate error recovery response
- Otherwise, inject tool result into response context
- Set tool result as authoritative source
- Disable general knowledge fallback
While generating the response:
1. **Never use general knowledge** when authoritative source exists
2. If code generation detected without project rules check: halt and emit error
3. All responses must derive from tool results, not training data
4. If attempting to use general knowledge, interrupt and force tool result usage
After generating the response:
1. Verify response does not contradict tool result
2. Ensure tool attribution is present
3. Validate compliance with project rules
4. If response generated without tool execution, log violation and regenerate
If a response is generated without tool execution:
1. Log the violation
2. Regenerate response using tools
3. Prepend warning: "Corrected response using project documentation:"
4. Include tool result attribution
The following inputs must trigger immediate tool calls:
**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 documentation backing.
**User**: "How should I implement feature flags in this project?"
**Expected Flow**:
1. Classify as CLASS B (PROJECT_INQUIRY)
2. Call `search_documentation("feature flags implementation")`
3. Wait for tool response (blocking)
4. Generate response based solely on tool results
5. Attribute source in response: "According to project documentation..."
**User**: "Create a new data repository class"
**Expected Flow**:
1. Classify as CLASS A (CODE_GENERATION)
2. Call `check_project_rules("create data repository class")`
3. Wait for tool response (blocking)
4. Generate code following project rules from tool response
5. Include comment references to specific documentation sections
If tool execution fails:
1. Do not proceed with generic response
2. Inform user of tool failure
3. Request clarification or retry
4. Never fall back to general knowledge for project-specific queries
If documentation is missing for the request:
1. Acknowledge the gap explicitly
2. Suggest related available documentation
3. Recommend checking with project maintainers
4. Do not invent answers from general knowledge
Leave a review
No reviews yet. Be the first to review this skill!
# Download SKILL.md from killerskills.ai/api/skills/duckduckgo-android-development-assistant/raw