during-task

name	during-task
description	Lightweight tactical guidance during implementation. Just MCP suggestions and quick lookups, no heavy Graphiti searches.

@during-task - Lightweight Tactical Guidance

Use DURING:

• Implementing tasks from tasks.md
• Before coding each subtask
• When switching implementation areas
• When unsure which MCP for specific subtask

CAN be called MULTIPLE times (designed for this!)

---

What It Does (Lightweight!)

1. Get MCP suggestions for subtask (no full Graphiti search)
2. Quick gotcha lookup (optional, only if stuck)
3. Brief workflow guidance

Token cost: ~300 tokens
Frequency: 5-10 times per spec
ROI: Stays aligned = prevents rework

---

Execution

Default: Just MCP Suggestions

suggest_mcps({
  task: "[specific subtask]",
  include_examples: false
});

Returns:

• Vibe (might change if switching domains)
• Top 3 MCPs for this subtask
• Brief purpose

When Stuck: Quick Gotcha Lookup

search_memory_facts({
  query: "[specific tech/component] [specific issue]",
  group_ids: ["screengraph"],
  max_facts: 3  // Just top 3, not 10!
});

Returns:

• Known workarounds
• Quick fixes
• Past solutions

---

Output Format (Brief!)

**Task**: [subtask]
**MCPs**: [mcp1], [mcp2], [mcp3]

Do this:
1. [action 1]
2. [action 2]

~5 lines. That's it.

---

Integration

With Spec-Kit Implementation

# Already ran @before-task during discovery
# Now implementing tasks.md

# Task 1: Create database schema
@during-task Create user table schema
→ MCPs: encore-mcp, context7
# Code it

# Task 2: Add API endpoint  
@during-task Add user registration endpoint
→ MCPs: encore-mcp, sequential-thinking
# Code it

# Task 3: Build UI component
@during-task Build registration form
→ MCPs: svelte, browser
# Code it

# All tasks done → Run @after-task

Domain Switching

# Working on backend
@during-task Add database migration
→ Vibe: backend_vibe, MCPs: encore-mcp

# Now switching to frontend
@during-task Update UI to show new field
→ Vibe: frontend_vibe, MCPs: svelte, browser
# ✅ Vibe changed automatically!

---

Token Efficiency

Good Usage (Specific)

@during-task Add password validation logic      → 300 tokens ✅
@during-task Create login form component        → 300 tokens ✅
@during-task Write unit test for auth endpoint  → 300 tokens ✅

Bad Usage (Too Broad)

@during-task Implement entire authentication feature → 2000 tokens ❌
# This should be @before-task, not @during-task!

---

Rules

✅ Call for each subtask - Designed for frequent use
✅ Be specific - "Add validation" not "implement feature"
✅ Skip Graphiti re-search - Already have context from @before-task
❌ Don't use for discovery - That's @before-task
❌ Don't call for trivial changes - Changing a variable name doesn't need context

---

When NOT to Call

Skip @during-task for:

• Trivial changes (typo fixes, variable renames)
• Copy-paste work (adapting existing code)
• Following exact instructions from plan.md

Use @during-task for:

• New implementation work
• Switching between domains
• Unsure which MCP to use
• Implementing complex logic

---

Comparison

Without @during-task:
  → Implement blindly
  → Use wrong MCP
  → Waste time

With @during-task:
  → Quick guidance (300 tokens)
  → Right MCP immediately
  → Stay on track

300 tokens to avoid 30 minutes of wrong direction = 100x ROI.

---

Purpose: Provide lightweight, frequent check-ins during implementation without burning tokens on redundant searches.