Work heavyweight framework or library tasks with planning-first research, selective deep analysis, and rigorous handoff
Handle $ARGUMENTS. Use this for architectural, comparative, benchmark, migration, or proposal-grade work where wrong framing is expensive. Be deep, not bloated. Be explicit, not ceremonial.
<task>#$ARGUMENTS</task>
gh issue view first.gh pr view first.#555: resolve it against the current gh repo first, then fetch it with gh issue view.planning-with-files immediately.ce:plan when the work needs a real implementation plan, phased rollout, or a plan artifact.learnings-researcher early when the domain smells repeated or the repo has prior decisions worth mining.@docs/analysis/editor-architecture-candidates.md as the candidate map instead of widening the field randomly... first per AGENTS. If missing, clone it. Only then reach for official docs.main, pull the latest main, then create a repo-convention branch before editingApply this section only when the task source is a tracker item.
gh for fetch and sync-back.<issue-number> <issue-title>.planning-with-files
Use by default here. Major work should not rely on short-lived memory.ce:plan
Use for phased implementation plans, rollout plans, or plan artifacts.learnings-researcher
Use early when prior repo decisions, solutions, or repeated failures may matter.repo-research-analyst
Default repo-grounding helper for major work.architecture-strategist
Use for public API design, layering, ownership boundaries, abstraction cleanup, and major cross-package refactors.pattern-recognition-specialist
Use when the question needs repo-wide pattern extraction, repeated smell detection, or design consistency analysis across packages.framework-docs-researcher
Use only after local clone/source/docs work per AGENTS is not enough, or when competing framework behavior must be grounded in official docs.best-practices-researcher
Use only when official docs leave gaps or the task genuinely needs broader field patterns beyond official sources.performance-oracle
Use for benchmark design, scalability analysis, hot-path tradeoffs, or performance validation strategy.spec-flow-analyzer
Use for RFCs, proposals, acceptance criteria, rollout plans, and completeness pressure-testing.issue-intelligence-analyst or git-history-analyzer
Use only when issue churn, historical regressions, or design history matter to the decision.coherence-reviewer and feasibility-reviewer
Default pair for explicit document review.scope-guardian-reviewer
Use when scope, abstraction count, or rollout shape may be inflated.product-lens-reviewer
Use when the document is making product framing, value, or roadmap claims.adversarial-document-reviewer
Use for larger, riskier, or more assumption-heavy docs where premise stress-testing is worth the cost.ce-review, correctness-reviewer, maintainability-reviewer, project-standards-reviewer, code-simplicity-reviewer
Use only when major work actually turns into risky code-changing execution or architecture-sensitive diffs.agent-native-reviewer
Use only when the change touches .agents/**, .claude/**, AI/tooling surfaces, commands, or user actions that an agent should also be able to perform.dev-browser
Use only when there is a real browser surface to verify.agent-browser-issue
Use when browser automation is blocked by a likely reusable tool-side issue that deserves a separate GitHub follow-up.changeset
Use when verified work changes a published package under packages/ and the repo expects release notes before completion.git-commit-push-pr
Use when verified code-changing work should ship as a PR.ce-compound
Use only after verified, non-trivial work that produced reusable knowledge.@docs/analysis/editor-architecture-candidates.mdPlate vs Slate first for direct inheritance pressureProseMirror and Lexical when questioning deeper runtime or architecture directionTiptap more for product-layer or packaging cost than raw engine performancePretext or Premirror when the question is pagination, composition, or layout-aware editing@docs/analysis/editor-architecture-candidates.md.spec-flow-analyzer to pressure-test completeness.ce:brainstorm first.coherence-reviewerfeasibility-reviewerscope-guardian-reviewer when the document introduces multiple new abstractions, broad rollout shape, or scope that may have drifted past the stated goal.product-lens-reviewer when the document is making product framing, roadmap, UX-value, or "are we solving the right thing?" claims.adversarial-document-reviewer when the document has more than 5 requirements or implementation units, makes significant architectural decisions, proposes new abstractions, or feels high-stakes enough that premise stress-testing is worth the cost.Keep verification mandatory but proportional.
task.mdc:
Apply this section only when the task came from a tracker item and reached a meaningful outcome.
task.mdc.planning-with-files was loaded before the work sprawled.