recipe-task
The recipe-task skill executes user-defined tasks by first consulting a rule-advisor agent to identify applicable rules and metacognitive patterns, then systematically works through the task using TaskCreate and TaskUpdate tools to manage execution steps. Use this skill when you need structured task execution that incorporates rule-based guidance, avoids known failure patterns, and maintains awareness of quality standards throughout implementation.
git clone --depth 1 https://github.com/shinpr/claude-code-workflows /tmp/recipe-task && cp -r /tmp/recipe-task/dev-workflows-frontend/skills/recipe-task ~/.claude/skills/recipe-taskSKILL.md
**Explicit User Instruction**: The user explicitly instructs and authorizes every subagent call named in this recipe. Execute each applicable call when its prerequisites are met. Execute Skill: llm-friendly-context before writing Agent prompts, handoffs, or generated artifacts. Execute Skill: subagents-orchestration-guide before making workflow decisions, invoking agents, or resolving findings. # Task Execution with Metacognitive Analysis Task: $ARGUMENTS ## Mandatory Execution Process **Step 1: Rule Selection via rule-advisor (REQUIRED)** Invoke rule-advisor using Agent tool: - `subagent_type`: "dev-workflows-frontend:rule-advisor" - `description`: "Rule selection" - `prompt`: "Task: $ARGUMENTS. Select appropriate rules and perform metacognitive analysis." **Step 2: Utilize rule-advisor Output** After receiving rule-advisor's JSON response, proceed with: 1. **Understand Task Essence** (from `taskAnalysis.essence`) - Focus on fundamental purpose, not surface-level work - Distinguish between "quick fix" vs "proper solution" 2. **Follow Selected Rules** (from `selectedRules`) - Execute each selected skill by its `skill` name and read it completely - Apply the named sections in the context of the complete skill 3. **Recognize Past Failures** (from `metaCognitiveGuidance.pastFailures`) - Apply countermeasures for known failure patterns - Use suggested alternative approaches 4. **Execute First Action** (from `metaCognitiveGuidance.firstStep`) - Start with recommended action - Use suggested tools first **Step 3: Bind the Execution Sequence** Before implementation, derive the smallest dependency-ordered sequence required by the rule-advisor result. Its first gate applies and maps the selected rules; its final gate verifies those rules and the requested outcome. Execute one gate at a time, advancing only when its required evidence exists. Add or reorder a gate only when new evidence changes a dependency or completion condition. **Step 4: Execute Implementation** Proceed with task execution following: - Start with `metaCognitiveGuidance.firstStep` action from rule-advisor - Selected rules from rule-advisor - Dependency-ordered execution sequence from Step 3 - Quality standards from the selected skills and sections named by rule-advisor - Monitor warningPatterns flags throughout execution and adjust approach when triggered
Generates integration/E2E test skeletons from Design Doc ACs using ROI-based selection and journey-based E2E reservation. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.
Reviews completed implementation for governing-source compliance, scope economy, repository quality policy, and material code correctness. Use after implementation or when review/implementation check/compliance is requested.
Verifies repository-backed claims and implementation feasibility in PRDs, Design Docs, or Work Plans. Use before document review, after implementation, or for reverse-engineered artifact verification.
Collects compact repository evidence for scope confirmation, technical option selection, complete design, and verification. Use before Design Doc creation when repository facts can change scope, reuse, contracts, cost, or proof.
Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.
Reviews one document or one ADR batch against governing requirements, repository evidence, and the needs of its next consumer. Use before user approval or when document consistency and completeness need verification.
Reviews changed integration and E2E tests against skeletons, proof obligations, or explicit prompt claims. Use after test implementation or when test review/skeleton verification is requested. Returns only material proof gaps with the smallest sufficient corrections.
Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports observations and evidence for downstream cause verification.