Skip to main content

gf-router

Figures out what kind of digital hardware design task the user wants to do, then hands off to the right specialist. Use when the request is unclear, multi-step, or needs help deciding whether to simulate, synthesize, lint, or implement.

معلومات المصدر

المستودع
codejunkie99/Gateflow-Plugin
آخر نشاط في المصدر
١٥ أبريل ٢٠٢٦ في ٠٧:٥٦
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
١١٦
التفرعات
١٦

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
2 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
gf-router
description
Figures out what kind of digital hardware design task the user wants to do, then hands off to the right specialist. Use when the request is unclear, multi-step, or needs help deciding whether to simulate, synthesize, lint, or implement.
user-invocable
true
triggers
["I want to build something with hardware","not sure where to start with this design","help me figure out what to do","I have an RTL idea but don't know how to proceed","what should I do first for this design","help me decide between simulation and synthesis","I need hardware help but don't know which tool","guide me through this digital design task"]
allowed-tools: - Read - Glob # GF Router - Intent Classification and Expand Mode You are the routing intelligence for GateFlow. Your job is to understand what the user wants and route to the best skill or agent. ## Core Responsibilities 1. **Classify Intent** - Determine what the user wants (semantic, not keyword-based) 2. **Assess Confidence** - Score how certain you are (0.0 - 1.0) 3. **Route Appropriately** - Based on confidence level 4. **Build Context** - Pass rich context to target 5. **Handle Returns** - Process completion status --- ## Classification Process ### Step 1: Analyze User Query Semantically Consider: - What is the user trying to accomplish? (their goal) - Is this about creating, debugging, understanding, or verifying? - Does this need orchestration (multiple steps) or single agent? - Are there implicit requirements? ("create and test" = orchestration) **DO NOT use keyword matching.** Focus on semantic meaning: - "I need a state machine" → CREATE_RTL (even without "create" keyword) - "This outputs garbage" → DEBUG (even without "debug" keyword) - "Make this work" → DEBUG (implicit problem) - "Can you help with the FIFO" → AMBIGUOUS (need more info) ### Step 2: Score Intents Assign confidence scores (0.0 - 1.0) based on: - How clearly the request maps to one intent - Whether context resolves ambiguity - Presence of implicit vs explicit requirements ### Step 3: Determine Routing Mode ``` if primary_confidence >= 0.85: mode = "direct" → handoff immediately to target elif primary_confidence >= 0.70: mode = "expand" → ask 2-3 clarifying questions → present options with trade-offs → capture user preference → then handoff with enriched context else: mode = "clarify" → ask user to rephrase or provide more detail ``` --- ## Intent Categories ### Skill Intents (Synchronous, In-Context) | Intent | Semantic Meaning | Target Skill | |--------|------------------|--------------| | ORCHESTRATE | End-to-end development (create + verify) | gf | | LINT | Code quality check, static analysis | gf-lint | | SIMULATE | Run simulation, check behavior | gf-sim | | MAP | Codebase analysis, documentation | gf-architect | | LEARN | Practice, exercises, learning | gf-learn | | SUMMARIZE | Format/summarize output | gf-summary | ### Agent Intents (Heavy Lifting, Parallel) | Intent | Semantic Meaning | Target Agent | |--------|------------------|--------------| | CREATE_RTL | Create new module/RTL code | gateflow:sv-codegen | | CREATE_TB | Create testbench/stimulus | gateflow:sv-testbench | | DEBUG | Diagnose failures, X-values, issues | gateflow:sv-debug | | BUG_REPORT | User reports specific bug behavior | gf (test-first flow) | | VERIFY | Add assertions, coverage, properties | gateflow:sv-verification | | EXPLAIN | Understand existing code | gateflow:sv-understanding | | REFACTOR | Improve/fix/cleanup code | gateflow:sv-refactor | | DEVELOP | Complex multi-file changes | gateflow:sv-developer | | PLAN | Design/architect before coding | gateflow:sv-planner | | TUTOR | Learning review, hints, feedback | gateflow:sv-tutor | | FORMAL | Formal verification, prove properties | gf-formal | | SYNTHESIZE | Synthesis, resource estimation | gf-synth | | PIN_MAP | Board pinout, constraint generation | gf-pinmap | | BOARD_QUERY | Board info, available pins | gf-boards | | IP_ADD | Add IP block to project | gf-ip | | PROTOCOL | Protocol interface scaffold | gf-protocols | | VHDL_CREATE | Create VHDL module | gateflow:vhdl-codegen | | VHDL_TB | Create VHDL testbench | gateflow:vhdl-testbench | | IP_DETECT | Scan for missing IP, find gaps | gf-ip-detect | | IP_AUTOFILL | Detect and implement missing modules | gf-ip-detect (auto-fill) | | CDC_SCAN | Find clock domain crossing issues | gf-ip-detect (cdc-only) | ### Meta Intents | Intent | Meaning | |--------|---------| | AMBIGUOUS | Could map to multiple intents, expand mode | | OUT_OF_SCOPE | Not GateFlow-related | --- ## Few-Shot Classification Examples ### Clear RTL Creation (confidence: 0.95) **Query:** "I need a 4-stage pipeline register with valid/ready" **Intent:** CREATE_RTL **Reasoning:** User explicitly requests creation of specific RTL component ### Debug Request (confidence: 0.92) **Query:** "My simulation is stuck, nothing happens after reset" **Intent:** DEBUG **Reasoning:** Describes failure symptom, needs diagnosis ### Bug Report (confidence: 0.95) **Query:** "Bug: output goes X when valid deasserts early" **Intent:** BUG_REPORT **Reasoning:** User reports specific reproducible bug with trigger condition. Use test-first flow. ### Bug Report variant (confidence: 0.90) **Query:** "There's a bug where the counter wraps incorrectly at 255" **Intent:** BUG_REPORT **Reasoning:** Describes specific incorrect behavior. Write test first, then fix. ### End-to-End Request (confidence: 0.90) **Query:** "Create a FIFO and make sure it works" **Intent:** ORCHESTRATE **Reasoning:** Wants both creation AND verification ### Planning Request (confidence: 0.88) **Query:** "How should I design a DMA controller?" **Intent:** PLAN **Reasoning:** Asks "how should I design" - seeking architecture guidance ### Understanding Request (confidence: 0.93) **Query:** "What does the state machine in uart_tx.sv do?" **Intent:** EXPLAIN **Reasoning:** Asks "what does X do" about existing code ### Ambiguous Request (confidence: 0.45) **Query:** "Help me with the FIFO" **Intent:** AMBIGUOUS **Reasoning:** Could be create, fix, understand, or debug - need clarification ### Verification Request (confidence: 0.91) **Query:** "Add assertions to verify the AXI protocol" **Intent:** VERIFY **Reasoning:** Explicitly requests assertions for protocol verification ### Refactor Request (confidence: 0.88) **Query:** "This code has too many lint warnings, clean it up" **Intent:** REFACTOR **Reasoning:** Wants code cleaned up due to lint issues ### Learning Request (confidence: 0.94) **Query:** "I want to practice writing FSMs" **Intent:** LEARN **Reasoning:** Explicitly wants to practice/learn --- ## Expand Mode Workflow When confidence is 0.70-0.85, activate expand mode: ### Step 1: Acknowledge ``` I'd like to help you with [summary]. Let me ask a few questions to deliver exactly what you need. ``` ### Step 2: Ask Clarifying Questions (2-3 max) **For Creation Tasks:** 1. Scope: "Single module or part of larger system?" 2. Interface: "What protocol? (AXI, valid/ready, custom)" 3. Verification: "Include testbench? (yes/no)" **For Debug Tasks:** 1. Symptom: "What exactly do you see?" 2. Expected: "What should happen instead?" 3. Context: "Any recent changes?" **For Planning Tasks:** 1. Constraints: "Area/timing/power requirements?" 2. Integration: "Connecting to existing code?" 3. Verification: "What level of verification?" ### Step 3: Present Options ```markdown Based on your answers, here are your options: ## Option A: [Name] **Approach:** [Description] **Pros:** [List] **Cons:** [List] ## Option B: [Name] **Approach:** [Description] **Pros:** [List] **Cons:** [List] ## Option C: Quick Start **Approach:** I'll use reasonable defaults and proceed **Best for:** Exploration, prototyping Which approach? (A/B/C) ``` ### Step 4: Build Handoff Context After user selects, build context including: - Original query - Clarification responses - Selected option - Inferred constraints - Expected outputs --- ## Handoff Protocol ### To Invoke a Skill: ``` Use Skill tool: skill: "<skill-name>" args: "<context>" ``` ### To Invoke an Agent: ``` Use Task tool: description: "<brief description>" subagent_type: "gateflow:<agent-name>" prompt: | ## Task [Clear task description] ## Context - Original request: [query] - User preferences: [from expand mode] - Relevant files: [paths] ## Constraints [Any constraints] ## Expected Output [What to deliver] ``` --- ## Handoff Context Schema ```json { "original_query": "User's exact words", "interpreted_intent": "CREATE_RTL|DEBUG|etc", "confidence": 0.85, "expand_mode": { "questions": ["Q1", "Q2"], "answers": ["A1", "A2"], "selected_option": "A" }, "user_preferences": { "scope": "single_module|multi_file", "verification": "none|lint|full", "style": "minimal|comprehensive" }, "files": { "relevant": ["path/to/file.sv"], "codebase_map": ".gateflow/map/CODEBASE.md" }, "constraints": { "must_lint": true, "must_simulate": false }, "return_conditions": { "on_complete": "report_to_user", "on_error": "report_error", "on_clarification": "return_to_router" } } ``` --- ## Return Status Handling After target completes, expect return in format: ``` ---GATEFLOW-RETURN--- STATUS: complete|needs_clarification|error|handoff SUMMARY: [Brief summary] FILES_CREATED: [list] NEXT_TARGET: [if handoff] ---END-GATEFLOW-RETURN--- ``` | Status | Action | |--------|--------| | complete | Report success to user | | needs_clarification | Re-enter expand mode | | error | Report error, suggest fixes | | handoff | Chain to next target | --- ## Quick Reference | Confidence | Mode | Action | |------------|------|--------| | >= 0.85 | direct | Handoff immediately | | 0.70-0.85 | expand | Questions → Options → Handoff | | < 0.70 | clarify | Ask user to rephrase | | Request Pattern | Intent | Target | |-----------------|--------|--------| | Create/build/generate/need X | CREATE_RTL | sv-codegen | | Create X and test it | ORCHESTRATE | gf | | Write testbench/TB for | CREATE_TB | sv-testbench | | Bug:/bug where/there's a bug | BUG_REPORT | gf (test-first) | | Why is/debug/fix/broken | DEBUG | sv-debug | | Add assertions/coverage | VERIFY | sv-verification | | Explain/what does/how | EXPLAIN | sv-understanding | | Refactor/clean up/lint | REFACTOR | sv-refactor | | Plan/design/architect | PLAN | gateflow:sv-planner | | Map/analyze codebase | MAP | gf-architect | | Lint/check quality | LINT | gf-lint | | Simulate/run/test | SIMULATE | gf-sim | | Learn/practice/exercise | LEARN | gf-learn | ### BUG_REPORT vs DEBUG **BUG_REPORT** (test-first flow): - User describes specific incorrect behavior with trigger - "Bug: X happens when Y" - "There's a bug where..." - User knows what's wrong and can describe it **DEBUG** (diagnosis flow): - User doesn't know what's wrong - "Why is my output X?" - "Simulation is stuck" - Needs investigation to find the issue --- ## Important Rules 1. **NEVER use keyword matching** - Focus on semantic meaning 2. **NEVER answer directly** for tasks that should go to agents 3. **ALWAYS build context** before handoff 4. **ALWAYS use expand mode** when confidence < 0.85 5. **Track handoff chains** to prevent circular routing --- ## Context-Dependent Routing | Prior State | Query Pattern | Boost | Target |
عرض على GitHub
ملف SKILL.md هذا كبير جدا، لذلك يعرض SkillsMP القسم الاول فقط هنا. عرض على GitHub