recipe-implement
Orchestrate the complete implementation lifecycle from requirements to deployment.
Works with
---
name: recipe-implement
description: Orchestrate the complete implementation lifecycle from requirements to deployment.
license: MIT
---
## Required Skills [LOAD BEFORE EXECUTION]
1. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and workflow flows
2. [LOAD IF NOT ACTIVE] `documentation-criteria` — document creation rules and templates
3. [LOAD IF NOT ACTIVE] `llm-friendly-context` — clear prompts, handoffs, and generated artifacts
**Spawn rule**: every `spawn_agent` call uses `fork_turns="none"` so the subagent receives only the task message and explicitly provided context.
# Full-Cycle Implementation
$ARGUMENTS
## Orchestrator Definition
**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
**CRITICAL**: MUST execute all steps, sub-agents, and stopping points defined in subagents-orchestration-guide skill flows.
ENFORCEMENT: Skipping any step or stopping point invalidates the entire workflow output.
## CRITICAL Sub-agent Invocation Constraints
**MANDATORY suffix for ALL sub-agent prompts**:
```
[SYSTEM CONSTRAINT]
This agent operates within implement skill scope. Use orchestrator-provided rules only.
```
ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued with the constraint appended.
## Step 1: Requirement Analysis
Spawn requirement-analyzer agent to determine scale and affected layers.
**[STOP — BLOCKING]** Present requirement-analyzer output (scale, affectedLayers, scope) to user for confirmation. **CANNOT proceed until user explicitly confirms.**
When user responds to questions:
- If response matches any `scopeDependencies.question` -> Check `impact` for scale change
- If scale changes -> Re-execute requirement-analyzer with updated context
- If `confidence: "confirmed"` or no scale change -> Proceed to Step 2
## Step 2: Layer-Based Workflow Routing
Based on requirement-analyzer output `affectedLayers`, route to the appropriate workflow:
| affectedLayers | Workflow | Reference |
|---|---|---|
| `["backend"]` only | Backend Flow | subagents-orchestration-guide skill (Large/Medium/Small scale) |
| `["frontend"]` only | Frontend Flow | See Frontend Flow below |
| `["backend", "frontend"]` | Fullstack Flow | subagents-orchestration-guide `references/monorepo-flow.md` |
---
### Backend Flow
Follow subagents-orchestration-guide skill Large/Medium/Small scale flow exactly. All steps, stopping points, and sub-agent sequencing are defined there.
---
### Frontend Flow
**STEP 1**: Ask user if they have prototype code or UI references to provide.
**STEP 2**: Spawn ui-spec-designer agent → spawn document-reviewer agent.
**[STOP — BLOCKING]** Present UI Spec for user approval. **CANNOT proceed until user explicitly confirms.**
**STEP 3**: Spawn technical-designer-frontend agent → spawn document-reviewer agent → spawn design-sync agent.
**[STOP — BLOCKING]** Present Frontend Design Doc for user approval. **CANNOT proceed until user explicitly confirms.**
**STEP 4**: Spawn acceptance-test-generator agent → spawn work-planner agent → spawn document-reviewer agent with `doc_type: WorkPlan`.
**[STOP — BLOCKING]** Present Work Plan for user approval. **CANNOT proceed until user explicitly confirms.**
**STEP 5**: Run implementation readiness preflight.
Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the approved work plan exact path. This means loading the work plan, evaluating R1-R5, resolving approved prep gaps through exact prep task files when needed, persisting the Readiness Report, and setting `Implementation Readiness: ready` or `escalated`. Apply the Implementation Readiness Marker Contract before entering autonomous execution.
**STEP 6**: Enter guided autonomous execution (see Autonomous Execution Mode below) using task-executor-frontend + quality-fixer-frontend agents.
---
### Fullstack Flow
Follow subagents-orchestration-guide `references/monorepo-flow.md` for the complete cross-layer workflow, including:
- Separate Design Docs per layer
- design-sync for cross-layer consistency
- Vertical slicing in work-planner
- Layer-aware task execution routing
---
## Autonomous Execution Mode
After user grants "batch approval for entire implementation phase", enter autonomous execution.
### Implementation Readiness Gate
Before executing task files, read the associated work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
### Task Execution Quality Cycle (4-Step Cycle per Task)
**Agent routing by task filename** (for fullstack projects):
```
*-backend-task-* -> Spawn task-executor agent + quality-fixer agent
*-frontend-task-* -> Spawn task-executor-frontend agent + quality-fixer-frontend agent
*-task-* (no layer prefix) -> Spawn task-executor agent + quality-fixer agent (default)
```
**Per-task cycle** (complete each task before starting next):
1. Spawn task-executor (or task-executor-frontend) agent: "Implement task [task-file-path]"
2. Check task-executor response:
- `status: escalation_needed` or `blocked` -> Escalate to user
- `requiresTestReview` is `true` -> Spawn integration-test-reviewer agent
- `needs_revision` -> Return to step 1 with `requiredFixes`
- `approved` -> Proceed to step 3
- Otherwise -> Proceed to step 3
3. Spawn quality-fixer (or quality-fixer-frontend) agent: "Quality check and fixes. Task file: [task-file-path]. The task file path above is also the `task_file` input. Read its `Quality Assurance Mechanisms` section as supplementary quality-check hints. filesModified: [executor response filesModified]. Use these files as the stub-detection scope."
4. Check quality-fixer response:
- `status: "stub_detected"` -> Return to step 1 with `stubFindings`
- `status: "blocked"` -> Escalate to user
- `status: "approved"` -> Proceed to step 5
5. git commit -> Execute on `status: "approved"`
### Post-Implementation Verification (After All Tasks Complete)
After all task cycles finish, collect all `filesModified` from every executor response (task-executor and task-executor-frontend, deduplicated), then run both verification agents before the completion report:
1. Spawn code-verifier agent: "Verify implementation consistency against the Design Doc. `doc_type: design-doc`. `document_path`: [path]. `code_paths`: [collected filesModified list]."
2. Spawn security-reviewer agent: "Design Doc: [path]. Implementation files: [collected filesModified list]. Review security compliance."
3. Consolidate results:
- code-verifier passes when `summary.status` is `consistent` or `mostly_consistent`
- code-verifier fails when `summary.status` is `needs_review` or `inconsistent`
- security-reviewer passes when `status` is `approved` or `approved_with_notes`
- security-reviewer fails when `status` is `needs_revision`
- security-reviewer `blocked` -> Escalate to user
4. If either verifier fails:
- Create a single fix task covering verifier discrepancies and security requiredFixes
- Spawn the layer-appropriate executor
- Spawn the layer-appropriate quality-fixer
- Re-run only the verifier(s) that failed
- Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
5. If both verifiers pass -> Proceed to completion report
### Test Information Communication
After acceptance-test-generator execution, when spawning work-planner, communicate:
- Generated integration test file path
- Generated fixture-e2e test file path or `null`
- Generated service-integration-e2e test file path or `null`
- E2E absence reason per lane when no E2E file is generated
- Note: integration tests are created with implementation; fixture-e2e runs alongside UI implementation; service-integration-e2e runs after all implementations when a service E2E file exists
## Completion Criteria
- [ ] Requirement analysis completed and user-confirmed
- [ ] Layer routing determined (backend / frontend / fullstack)
- [ ] Correct workflow followed per layer routing
- [ ] codebase-analyzer included before Design Doc creation for Medium/Large flows
- [ ] code-verifier included before document-reviewer for Design Doc review
- [ ] All stopping points honored with user confirmation obtained
- [ ] Quality-fixer spawned before every commit
- [ ] All tasks committed or escalation completed
- [ ] System constraint suffix appended to all sub-agent promptsMore Deployment & CI/CD skills
finetuning
microsoft/azure-skills
Fine-tune models on Microsoft Foundry using SFT (supervised), DPO (preference), or RFT (reinforcement with graders). Covers dataset preparation, training job submission, deployment, and evaluation. USE FOR: fine-tune, SFT, DPO, RFT, training data, grader, distillation, fine-tuned model, training job, large file upload, calibrate grader, deploy fine-tuned model, evaluate fine-tuned model. DO NOT USE FOR: general model deployment without fine-tuning (use deploy-model), agent creation (use agents), prompt optimization without training (use prompt-optimizer).
prisma-compute
prisma/skills
Prisma Compute deployment and hosting guide. Use whenever the user mentions Prisma Compute, `prisma.compute.ts`, `defineComputeConfig`, deploying or hosting a Prisma app, `@prisma/cli app deploy`, `compute:deploy`, `create-prisma --deploy`, `PRISMA_SERVICE_TOKEN`, Compute auth/workspaces, apps/deployments/build logs/domains, localhost vs `0.0.0.0`, deploy port binding, or framework deploy readiness for Hono, Elysia, Next.js, TanStack Start, Astro, Nuxt, Svelte, Nest, Turborepo, or custom/prebuilt artifacts.
azure-quotas
microsoft/azure-skills
Check/manage Azure quotas and usage across providers. For deployment planning, capacity validation, region selection. WHEN: \"check quotas\", \"service limits\", \"current usage\", \"request quota increase\", \"quota exceeded\", \"validate capacity\", \"regional availability\", \"provisioning limits\", \"vCPU limit\", \"how many vCPUs available in my subscription\".

