codex-workflows 0.1.0

package/.agents/skills/documentation-criteria/references/ui-spec-template.md

@@ -0,0 +1,145 @@
+# [Feature Name] UI Specification
+
+## Overview
+
+[Purpose and scope of this UI Specification in 2-3 sentences]
+
+### Target PRD
+- PRD path: [docs/prd/xxx-prd.md | "N/A -- based on requirement-analyzer output"]
+- Feature scope: [Which PRD requirements this UI Spec covers | Summary of analyzed requirements]
+
+### Design Source
+| Source | Path | Version |
+|--------|------|---------|
+| Prototype code | [docs/ui-spec/assets/xxx/] | [commit SHA / tag] |
+
+## Prototype Management
+
+Prototype code is an **attachment** to this UI Spec. The canonical specification is always this document + the Design Doc.
+
+- **Attachment path**: [docs/ui-spec/assets/{feature-name}/]
+- **Version identification**: [commit SHA / tag]
+- **Compliance premise**: [e.g., design system compliance, component library usage]
+- **Relationship to canonical spec**: Differences between prototype and this spec are resolved in favor of this document. Prototype serves as visual/behavioral reference only.
+
+## AC Traceability (Prototype)
+
+Map PRD acceptance criteria to prototype references. Skip this section if no prototype is provided.
+
+| AC ID | AC Summary | Screen / State | Prototype Reference (element ID / path) | Adoption Decision |
+|-------|-----------|----------------|----------------------------------------|-------------------|
+| AC-01 | [EARS AC summary] | [Screen / state name] | [element or file reference] | Adopted / Not adopted / On hold |
+
+## Screen List and Transitions
+
+### Screen List
+
+| Screen ID | Screen Name | Description | Entry Condition |
+|-----------|------------|-------------|-----------------|
+| S-01 | [Screen name] | [Purpose] | [How user reaches this screen] |
+
+### Transition Conditions
+
+| Source | Destination | Trigger | Guard Condition |
+|--------|------------|---------|-----------------|
+| S-01 | S-02 | [User action] | [Precondition if any] |
+
+## Component Decomposition
+
+### Component Tree
+
+```
+[Page/Screen]
+  +-- [Container Component]
+  |   +-- [Presentational Component A]
+  |   +-- [Presentational Component B]
+  +-- [Container Component]
+      +-- [Presentational Component C]
+```
+
+### Component: [ComponentName]
+
+#### State x Display Matrix
+
+| State | Default | Loading | Empty | Error | Partial |
+|-------|---------|---------|-------|-------|---------|
+| Display | [Normal display] | [Skeleton / spinner] | [Empty state + CTA] | [Error message + recovery action] | [Cached / partial display] |
+
+#### Interaction Definition
+
+| AC ID | EARS Condition | User Action | System Response | State Transition | Error Handling |
+|-------|---------------|-------------|-----------------|-----------------|----------------|
+| AC-01 | When [trigger] | [Click / input / etc.] | [Expected behavior] | [From state -> To state] | [Retry / Reset / Fallback] |
+
+### Component: [ComponentName2]
+
+[Repeat State x Display Matrix and Interaction Definition for each component]
+
+## Design Tokens and Component Map
+
+### Environment Constraints
+- Target browsers: [e.g., Chrome 120+, Safari 17+]
+- Responsive breakpoints: [e.g., 768px, 1024px, 1280px]
+- Theme support: [e.g., light/dark, system preference]
+
+### Existing Component Reuse Map
+
+| UI Element | Decision | Existing Component | Notes |
+|-----------|----------|-------------------|-------|
+| [Button] | Reuse | [components/ui/Button] | [No modifications needed] |
+| [DataTable] | Extend | [components/ui/Table] | [Add sorting support] |
+| [FeatureCard] | New | - | [No similar component exists] |
+
+### Design Tokens
+
+| Token | Value | Usage |
+|-------|-------|-------|
+| [color-primary] | [value] | [Primary actions] |
+| [spacing-md] | [value] | [Component spacing] |
+
+## Visual Acceptance
+
+### Golden States
+Define the key visual states that serve as acceptance benchmarks:
+
+1. **[State name]**: [Description of what should be visually confirmed]
+2. **[State name]**: [Description]
+
+### Layout Constraints
+- [Min/max width, height constraints]
+- [Spacing rules between components]
+- [Overflow behavior]
+
+## Accessibility Requirements
+
+### Keyboard Navigation
+
+| Component | Tab Order | Key Binding | Behavior |
+|-----------|-----------|-------------|----------|
+| [Component] | [Order number] | [Enter / Space / Arrow] | [Expected behavior] |
+
+### Screen Reader
+
+| Component | Role | Accessible Name | Live Region |
+|-----------|------|-----------------|-------------|
+| [Component] | [ARIA role] | [aria-label / aria-labelledby] | [polite / assertive / none] |
+
+### Contrast Requirements
+
+| Element | Foreground | Background | Ratio Target |
+|---------|-----------|------------|-------------|
+| [Text element] | [Color] | [Color] | [4.5:1 for normal text / 3:1 for large text] |
+
+## Open Items
+
+| ID | Description | Owner | Deadline |
+|----|-------------|-------|----------|
+| TBD-01 | [Unresolved question or decision] | [Who resolves] | [Target date] |
+
+*All TBDs must have an owner and deadline. Resolve before Design Doc creation.*
+
+## Update History
+
+| Date | Version | Changes | Author |
+|------|---------|---------|--------|
+| YYYY-MM-DD | 1.0 | Initial version | [Name] |

package/.agents/skills/implementation-approach/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: implementation-approach
+description: "Implementation strategy selection framework with meta-cognitive approach. Use when: planning implementation strategy, selecting between vertical/horizontal slicing, or defining verification criteria for tasks."
+---
+
+# Implementation Strategy Selection Framework (Meta-cognitive Approach)
+
+## Meta-cognitive Strategy Selection Process [MANDATORY]
+
+### Phase 1: Comprehensive Current State Analysis
+
+**Core Question**: "What does the existing implementation look like?"
+
+#### Analysis Framework
+```yaml
+Architecture Analysis: Responsibility separation, data flow, dependencies, technical debt
+Implementation Quality Assessment: Code quality, test coverage, performance, security
+Historical Context Understanding: Current form rationale, past decision validity, constraint changes, requirement evolution
+```
+
+#### Meta-cognitive Question List [MANDATORY CHECKPOINTS]
+- What is the true responsibility of this implementation?
+- Which parts are business essence and which derive from technical constraints?
+- What dependencies or implicit preconditions are unclear from the code?
+- What benefits and constraints does the current design bring?
+
+**ENFORCEMENT**: CANNOT proceed to Phase 2 without answering all questions
+
+### Phase 2: Strategy Exploration and Creation
+
+**Core Question**: "When determining before to after, what implementation patterns or strategies should be referenced?"
+
+#### Strategy Discovery Process
+```yaml
+Research and Exploration: Tech stack examples, similar projects, OSS references, literature/blogs
+Creative Thinking: Strategy combinations, constraint-based design, phase division, extension point design
+```
+
+#### Reference Strategy Patterns (Creative Combinations Encouraged)
+
+**Legacy Handling Strategies**:
+- Strangler Pattern: Gradual migration through phased replacement
+- Facade Pattern: Complexity hiding through unified interface
+- Adapter Pattern: Bridge with existing systems
+
+**New Development Strategies**:
+- Feature-driven Development: Vertical implementation prioritizing user value
+- Foundation-driven Development: Foundation-first construction prioritizing stability
+- Risk-driven Development: Prioritize addressing maximum risk elements
+
+**Integration/Migration Strategies**:
+- Proxy Pattern: Transparent feature extension
+- Decorator Pattern: Phased enhancement of existing features
+- Bridge Pattern: Flexibility through abstraction
+
+**IMPORTANT**: The optimal solution is discovered through creative thinking according to each project's context. EVALUATE multiple strategy combinations before selecting.
+
+### Phase 3: Risk Assessment and Control [MANDATORY]
+
+**Core Question**: "What risks arise when applying this to existing implementation, and what's the best way to control them?"
+
+#### Risk Analysis Matrix
+```yaml
+Technical Risks: System impact, data consistency, performance degradation, integration complexity
+Operational Risks: Service availability, deployment downtime, process changes, rollback procedures
+Project Risks: Schedule delays, learning costs, quality achievement, team coordination
+```
+
+#### Risk Control Strategies
+```yaml
+Preventive Measures: Phased migration, parallel operation verification, integration/regression tests, monitoring setup
+Incident Response: Rollback procedures, log/metrics preparation, communication system, service continuation procedures
+```
+
+### Phase 4: Constraint Compatibility Verification
+
+**Core Question**: "What are this project's constraints?"
+
+#### Constraint Checklist
+```yaml
+Technical Constraints: Library compatibility, resource capacity, mandatory requirements, numerical targets
+Temporal Constraints: Deadlines/priorities, dependencies, milestones, learning periods
+Resource Constraints: Team/skills, work hours/systems, budget, external contracts
+Business Constraints: Market launch timing, customer impact, regulatory compliance
+```
+
+### Phase 5: Implementation Approach Decision
+
+Select optimal solution from basic implementation approaches (creative combinations encouraged):
+
+#### Vertical Slice (Feature-driven)
+**Characteristics**: Vertical implementation across all layers by feature unit
+**Application Conditions**: Low inter-feature dependencies, output in user-usable form, changes needed across all architecture layers
+**Verification Method**: End-user value delivery at each feature completion
+
+#### Horizontal Slice (Foundation-driven)
+**Characteristics**: Phased construction by architecture layer
+**Application Conditions**: Foundation system stability important, multiple features depend on common foundation, layer-by-layer verification effective
+**Verification Method**: Integrated operation verification when all foundation layers complete
+
+#### Hybrid (Creative Combination)
+**Characteristics**: Flexible combination according to project characteristics
+**Application Conditions**: Unclear requirements, need to change approach per phase, transition from prototyping to full implementation
+**Verification Method**: Verify at appropriate L1/L2/L3 levels according to each phase's goals
+
+### Phase 6: Decision Rationale Documentation
+
+**Design Doc Documentation**: Clearly specify implementation strategy selection reasons and rationale.
+
+## Verification Level Definitions
+
+Priority for completion verification of each task:
+
+- **L1: Functional Operation Verification** - Operates as end-user feature (e.g., search executable)
+- **L2: Test Operation Verification** - New tests added and passing
+- **L3: Build Success Verification** - Code builds/runs without errors
+
+**Priority**: L1 > L2 > L3 in order of verifiability importance
+
+## Integration Point Definitions
+
+Define integration points according to selected strategy:
+- **Strangler-based**: When switching between old and new systems for each feature
+- **Feature-driven**: When users can actually use the feature
+- **Foundation-driven**: When all architecture layers are ready and E2E tests pass
+- **Hybrid**: When individual goals defined for each phase are achieved
+
+## Anti-patterns [MANDATORY to detect]
+
+- **Pattern Fixation**: EVALUATE unique combinations instead of selecting only listed strategies
+- **Insufficient Analysis**: MUST complete Phase 1 analysis framework before strategy selection
+- **Risk Neglect**: MUST complete Phase 3 risk analysis matrix before implementation
+- **Constraint Ignorance**: MUST check Phase 4 constraint checklist before deciding strategy
+- **Rationale Omission**: MUST use Phase 6 documentation template when selecting strategy
+
+**ENFORCEMENT**: Detecting ANY anti-pattern requires IMMEDIATE correction before proceeding
+
+## Guidelines for Meta-cognitive Execution
+
+1. **Leverage Known Patterns**: Use as starting point, then EVALUATE creative combinations
+2. **Active Research**: Research implementation examples from similar tech stacks
+3. **Apply 5 Whys**: Pursue root causes to grasp essence
+4. **Multi-perspective Evaluation**: EVALUATE comprehensively from each Phase 1-4 perspective
+5. **Creative Thinking**: EVALUATE sequential application of multiple strategies and designs leveraging project-specific constraints
+6. **Clarify Decision Rationale**: Strategy selection rationale MUST be explicit in design documents

package/.agents/skills/implementation-approach/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Implementation Approach"
+  short_description: "Strategy selection framework"
+  default_prompt: "Use $implementation-approach to select an implementation strategy."
+
+policy:
+  allow_implicit_invocation: true

package/.agents/skills/integration-e2e-testing/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: integration-e2e-testing
+description: "Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria. Use when: designing integration tests, E2E tests, generating test skeletons, or reviewing test quality."
+---
+
+# Integration and E2E Testing Principles
+
+## References
+
+**E2E test design with Playwright**: See [references/e2e-design.md](references/e2e-design.md) for UI Spec-driven E2E test candidate selection and Playwright test architecture.
+
+## Test Type Definition and Limits [MANDATORY]
+
+| Test Type | Purpose | Scope | Limit per Feature | Implementation Timing |
+|-----------|---------|-------|-------------------|----------------------|
+| Integration | Verify component interactions | Partial system integration | MAX 3 | Created alongside implementation |
+| E2E | Verify critical user journeys | Full system | MAX 1-2 | Executed in final phase only |
+
+**ENFORCEMENT**: Exceeding test limits requires explicit justification
+
+## Behavior-First Principle [MANDATORY]
+
+### MUST Include (High ROI)
+- Business logic correctness (calculations, state transitions, data transformations)
+- Data integrity and persistence behavior
+- User-visible functionality completeness
+- Error handling behavior (what user sees/experiences)
+
+### MUST Exclude (Low ROI in CI/CD)
+- External service real connections — use contract/interface verification instead
+- Performance metrics — non-deterministic, defer to load testing
+- Implementation details — test observable behavior only
+- UI layout specifics — test information availability instead
+
+**ENFORCEMENT**: Test = User-observable behavior verifiable in isolated CI environment
+
+## ROI Calculation
+
+```
+ROI Score = (Business Value x User Frequency + Legal Requirement x 10 + Defect Detection)
+            / (Creation Cost + Execution Cost + Maintenance Cost)
+```
+
+### Cost Table
+
+| Test Type | Create | Execute | Maintain | Total |
+|-----------|--------|---------|----------|-------|
+| Unit | 1 | 1 | 1 | 3 |
+| Integration | 3 | 5 | 3 | 11 |
+| E2E | 10 | 20 | 8 | 38 |
+
+## Test Skeleton Specification [MANDATORY]
+
+### Required Comment Patterns
+
+Each test MUST include the following annotations:
+
+```
+// AC: [Original acceptance criteria text]
+// Behavior: [Trigger] -> [Process] -> [Observable Result]
+// @category: core-functionality | integration | edge-case | e2e
+// @dependency: none | [component names] | full-system
+// @complexity: low | medium | high
+// ROI: [score]
+```
+
+### Verification Items (Optional)
+
+When verification points need explicit enumeration:
+```
+// Verification items:
+// - [Item 1]
+// - [Item 2]
+```
+
+## EARS Format Mapping
+
+| EARS Keyword | Test Type | Generation Approach |
+|--------------|-----------|---------------------|
+| **When** | Event-driven | Trigger event -> verify outcome |
+| **While** | State condition | Setup state -> verify behavior |
+| **If-then** | Branch coverage | Both condition paths verified |
+| (none) | Basic functionality | Direct invocation -> verify result |
+
+## Test File Naming Convention
+
+- Integration tests: `*.int.test.*` or `*.integration.test.*`
+- E2E tests: `*.e2e.test.*`
+
+The test runner or framework in the project determines the appropriate file extension.
+
+## Review Criteria
+
+### Skeleton and Implementation Consistency
+
+| Check | Failure Condition |
+|-------|-------------------|
+| Behavior Verification | No assertion for "observable result" in skeleton |
+| Verification Item Coverage | Listed items not all covered by assertions |
+| Mock Boundary | Internal components mocked in integration test |
+
+### Implementation Quality
+
+| Check | Failure Condition |
+|-------|-------------------|
+| AAA Structure | Arrange/Act/Assert separation unclear |
+| Independence | State sharing between tests, order dependency |
+| Reproducibility | Date/random dependency, varying results |
+| Readability | Test name doesn't match verification content |
+
+## Quality Standards [MANDATORY]
+
+### REQUIRED
+- Each test MUST verify one behavior
+- Clear AAA (Arrange-Act-Assert) structure
+- No test interdependencies
+- Deterministic execution
+
+### PROHIBITED
+- Testing implementation details — test observable behavior only
+- Multiple behaviors per test — split into separate tests
+- Shared mutable state — each test creates its own state
+- Time-dependent assertions without mocking — use deterministic time
+
+**ENFORCEMENT**: Tests violating ANY standard MUST be rewritten before merge

package/.agents/skills/integration-e2e-testing/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Integration & E2E Testing"
+  short_description: "Test design and ROI calculation"
+  default_prompt: "Use $integration-e2e-testing to design integration tests."
+
+policy:
+  allow_implicit_invocation: true

package/.agents/skills/integration-e2e-testing/references/e2e-design.md

@@ -0,0 +1,86 @@
+# E2E Test Design with Playwright
+
+## When to Create E2E Tests
+
+E2E tests target **critical user journeys** that span multiple pages or require real browser interaction. Apply the same ROI framework from the parent skill -- only create E2E tests when ROI > 50.
+
+### Candidate Sources
+
+| Source | What to Extract |
+|--------|----------------|
+| **Design Doc ACs** | User journeys with EARS "When" keyword spanning multiple screens |
+| **UI Spec Screen Transitions** | Multi-step flows (e.g., form wizard, checkout) |
+| **UI Spec State x Display Matrix** | Error/empty/loading states requiring browser-level verification |
+| **UI Spec Interaction Definitions** | Complex interactions (drag-drop, keyboard navigation, responsive behavior) |
+
+### Selection Criteria
+
+**Include** (high E2E ROI):
+- Multi-page user journeys (login -> dashboard -> action -> confirmation)
+- Flows requiring real browser APIs (navigation, cookies, localStorage)
+- Accessibility verification requiring actual DOM rendering
+- Responsive behavior across viewports
+
+**Exclude** (use integration tests instead):
+- Single-component state changes (use RTL)
+- API response handling (use MSW + RTL)
+- Pure data transformations
+
+## UI Spec to E2E Test Mapping
+
+When a UI Spec exists, use it as the primary source for E2E test design:
+
+1. **Extract screen transitions** -> Each multi-step transition = 1 E2E candidate
+2. **Check state x display matrix** -> Error states requiring navigation = E2E candidate
+3. **Review interaction definitions** -> Browser-dependent interactions = E2E candidate
+4. **Cross-reference with Design Doc ACs** -> Ensure E2E candidates map to acceptance criteria
+
+### Mapping Template
+
+```
+Screen Transition: [Screen A] -> [Screen B] -> [Screen C]
+AC Reference: AC-{id}
+User Journey: [Description of what the user accomplishes]
+Preconditions: [Auth state, data state]
+Verification Points:
+  - [What to assert at each step]
+E2E ROI Score: [calculated score]
+```
+
+## Playwright Test Architecture
+
+### Page Object Pattern
+
+Organize browser interactions through page objects for maintainability:
+
+```
+tests/
+├── e2e/
+│   ├── pages/           # Page objects
+│   ├── fixtures/        # Test fixtures and helpers
+│   └── *.e2e.test.ts    # Test files
+```
+
+### Test Isolation
+
+- Each test starts from a clean browser context
+- No shared state between tests
+- Use `beforeEach` for common setup (auth, navigation)
+- Prefer `page.goto()` over in-test navigation for setup
+
+### Viewport Testing
+
+When UI Spec defines responsive behavior, test critical breakpoints:
+
+| Breakpoint | Width | When to Test |
+|-----------|-------|-------------|
+| Mobile | 375px | If UI Spec defines mobile-specific interactions |
+| Tablet | 768px | If UI Spec defines tablet layout differences |
+| Desktop | 1280px | Default -- always test |
+
+## Budget Enforcement
+
+Hard limits per feature (same as parent skill):
+- **E2E Tests**: MAX 1-2 tests
+- Only generate if ROI score > 50
+- Prefer fewer, comprehensive journey tests over many granular tests

package/.agents/skills/recipe-add-integration-tests/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: recipe-add-integration-tests
+description: "Add integration/E2E tests to existing codebase using Design Doc acceptance criteria."
+---
+
+## Required Skills [LOAD BEFORE EXECUTION]
+
+1. [LOAD IF NOT ACTIVE] `testing` — test strategy and quality gates
+2. [LOAD IF NOT ACTIVE] `integration-e2e-testing` — integration and E2E test patterns
+3. [LOAD IF NOT ACTIVE] `documentation-criteria` — document creation rules and templates
+
+**Context**: Test addition workflow for existing implementations
+
+## Orchestrator Definition
+
+**Core Identity**: "I am not a worker. I am an orchestrator."
+
+**First Action**: Register Steps 0-8 before any execution.
+
+**Why Spawn**: Orchestrator's context is shared across all steps. Direct implementation consumes context needed for review and quality check phases. Task files create context boundaries. Subagents work in isolated context.
+
+**Execution Method**:
+- Skeleton generation -> Spawn acceptance-test-generator agent
+- Task file creation -> Orchestrator creates directly (minimal context usage)
+- Test implementation -> Spawn task-executor agent
+- Test review -> Spawn integration-test-reviewer agent
+- Quality checks -> Spawn quality-fixer agent
+
+Design Doc path: $ARGUMENTS
+
+## Prerequisites
+
+- Design Doc must exist (created manually or via reverse-engineer)
+- Existing implementation to test
+
+## Execution Flow
+
+### Step 0: Prepare Context
+
+Reference documentation-criteria skill for task file template in Step 3.
+
+### Step 1: Validate Design Doc
+
+Verify Design Doc exists at $ARGUMENTS or find the most recent in docs/design/.
+
+### Step 2: Skeleton Generation
+
+Spawn acceptance-test-generator agent: "Generate test skeletons from Design Doc at [path from Step 1]."
+
+**Expected output**: `generatedFiles` containing integration and e2e paths
+
+### Step 3: Create Task File [GATE]
+
+**[STOP — BLOCKING]** Present task file content to user for confirmation before proceeding to implementation.
+**CANNOT proceed until user explicitly confirms.**
+
+Create task file at: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
+
+**Template**:
+```markdown
+---
+name: Implement integration tests for [feature name]
+type: test-implementation
+---
+
+## Objective
+
+Implement test cases defined in skeleton files.
+
+## Target Files
+
+- Skeleton: [path from Step 2 generatedFiles]
+- Design Doc: [path from Step 1]
+
+## Tasks
+
+- [ ] Implement each test case in skeleton
+- [ ] Verify all tests pass
+- [ ] Ensure coverage meets requirements
+
+## Acceptance Criteria
+
+- All skeleton test cases implemented
+- All tests passing
+- No quality issues
+```
+
+**Output**: "Task file created at [path]. Ready for Step 4."
+
+### Step 4: Test Implementation
+
+Spawn task-executor agent: "Implement integration tests. Task file: docs/plans/tasks/integration-tests-YYYYMMDD.md. Implement tests following the task file."
+
+**Expected output**: `status`, `testsAdded`
+
+### Step 5: Test Review
+
+Spawn integration-test-reviewer agent: "Review test quality. Test files: [paths from Step 4 testsAdded]. Skeleton files: [paths from Step 2 generatedFiles]."
+
+**Expected output**: `status` (approved/needs_revision), `requiredFixes`
+
+### Step 6: Apply Review Fixes
+
+Check Step 5 result:
+- `status: approved` -> Mark complete, proceed to Step 7
+- `status: needs_revision` -> Spawn task-executor agent: "Fix the following issues in test files: [requiredFixes from Step 5]." Then return to Step 5.
+
+### Step 7: Quality Check
+
+Spawn quality-fixer agent: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage."
+
+**Expected output**: `approved` (true/false)
+
+### Step 8: Commit
+
+On `approved: true` from quality-fixer:
+- MUST commit test files with appropriate message
+ENFORCEMENT: Commits without quality-fixer approval are invalid.
+
+## Completion Criteria
+
+- [ ] Design Doc validated and located
+- [ ] Skeleton generated via acceptance-test-generator
+- [ ] Task file created and confirmed
+- [ ] Tests implemented via task-executor
+- [ ] Tests reviewed via integration-test-reviewer (approved or fixes applied)
+- [ ] Quality check passed via quality-fixer
+- [ ] Test files committed

package/.agents/skills/recipe-add-integration-tests/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "recipe-add-integration-tests"
+  short_description: "Add integration/E2E tests from Design Doc"
+  default_prompt: "Use $recipe-add-integration-tests to add tests for: "
+
+policy:
+  allow_implicit_invocation: false