mt5api 0.0.1__tar.gz

mt5api-0.0.1/.agents/skills/local-qa/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: local-qa
+description: Run local QA for the repository. Use when asked to run formatting, linting, testing, or pre-commit checks, when verifying local QA, or whenever any file has been updated and local QA should be re-run.
+---
+
+# Local QA (format, lint, and test)
+
+Run the local QA script from the directory of this file:
+
+```bash
+./scripts/qa.sh
+```
+
+## Procedure
+
+- Execute the script exactly as shown above when this skill is triggered.
+- Capture and summarize key output (success/failure, major warnings, and any files modified).
+- If the script fails due to missing tooling, report the missing tool(s) and stop unless the user asks to install or fix them.
+- Do not run additional commands unless the user requests them.

mt5api-0.0.1/.agents/skills/local-qa/scripts/qa.sh

@@ -0,0 +1,26 @@
+#!/usr/bin/env bash
+
+set -euox pipefail
+cd "$(git rev-parse --show-toplevel)"
+
+# Python
+uv run ruff format .
+uv run ruff check --fix .
+uv run pyright .
+uv run pytest
+
+# Markdown
+npx prettier --write './**/*.md'
+
+# GitHub Actions
+case "${OSTYPE}" in
+  darwin* | linux* )
+    zizmor --fix=safe .github/workflows
+    git ls-files -z -- '.github/workflows/*.yml' | xargs -0 -t actionlint
+    git ls-files -z -- '.github/workflows/*.yml' | xargs -0 -t yamllint -d '{"extends": "relaxed", "rules": {"line-length": "disable"}}'
+    checkov --framework=all --output=github_failed_only --directory=.
+    ;;
+  * )
+    echo "GitHub Actions linting is only supported on Linux and macOS."
+    ;;
+esac

mt5api-0.0.1/.agents/skills/mt5-account/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: mt5-account
+description: Retrieve MT5 trading account information or terminal details from the MT5 API. Use when the user wants to check account balance, equity, margin, leverage, or terminal status.
+allowed-tools: Bash
+---
+
+# MT5 Account & Terminal
+
+Query account and terminal information endpoints on the mt5api.
+
+## Configuration
+
+The API base URL defaults to `http://localhost:8000`. Set `MT5_API_URL` to override.
+All endpoints require the `X-API-Key` header. Set `MT5_API_KEY` in the environment.
+
+## Endpoints
+
+### Account Info
+
+Get current trading account details (balance, equity, margin, leverage, etc.).
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/account" | python -m json.tool
+```
+
+Returns a `DataResponse` containing account fields such as:
+
+- `login` - Account number
+- `balance` - Account balance
+- `equity` - Account equity
+- `margin` - Used margin
+- `margin_free` - Free margin
+- `margin_level` - Margin level percentage
+- `leverage` - Account leverage
+- `currency` - Account currency
+- `server` - Trade server name
+- `name` - Account holder name
+
+### Terminal Info
+
+Get MetaTrader 5 terminal information.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/terminal" | python -m json.tool
+```
+
+Returns a `DataResponse` with terminal details such as build number, platform, data path, and connection status.
+
+## Procedure
+
+1. Determine whether the user needs account info or terminal info.
+2. Run the appropriate `curl` command.
+3. Parse and summarize the JSON response, highlighting key financial metrics (balance, equity, margin) for account queries or connection status for terminal queries.

mt5api-0.0.1/.agents/skills/mt5-health/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: mt5-health
+description: Check MT5 API health status and retrieve MT5 terminal version information. Use when verifying API availability, checking MT5 terminal connectivity, or retrieving version details.
+allowed-tools: Bash
+---
+
+# MT5 Health & Version
+
+Query the mt5api health check and version endpoints.
+
+## Configuration
+
+The API base URL defaults to `http://localhost:8000`. Set `MT5_API_URL` to override.
+Authenticated endpoints require the `X-API-Key` header. Set `MT5_API_KEY` in the environment.
+
+## Endpoints
+
+### Health Check (public, no auth required)
+
+```bash
+curl -s "${MT5_API_URL:-http://localhost:8000}/api/v1/health" | python -m json.tool
+```
+
+Returns:
+
+| Field         | Type    | Description                    |
+| ------------- | ------- | ------------------------------ |
+| status        | string  | `healthy` or `unhealthy`       |
+| mt5_connected | bool    | MT5 terminal connection status |
+| mt5_version   | string? | MT5 terminal version string    |
+| api_version   | string  | API version (e.g., `1.0.0`)    |
+
+### MT5 Version (requires API key)
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/version" | python -m json.tool
+```
+
+Returns a `DataResponse` with version data.
+
+## Procedure
+
+1. Determine which endpoint the user needs (health check or version).
+2. Run the appropriate `curl` command above.
+3. Parse and summarize the JSON response for the user.
+4. If the health status is `unhealthy`, note that the MT5 terminal may not be running or reachable.

mt5api-0.0.1/.agents/skills/mt5-history/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: mt5-history
+description: Query open positions, pending orders, historical orders, and historical deals from the MT5 API. Use when the user wants to check current trades, pending orders, or trade history.
+allowed-tools: Bash
+---
+
+# MT5 Positions, Orders & History
+
+Query trading state and history endpoints on the mt5api.
+
+## Configuration
+
+The API base URL defaults to `http://localhost:8000`. Set `MT5_API_URL` to override.
+All endpoints require the `X-API-Key` header. Set `MT5_API_KEY` in the environment.
+
+## Endpoints
+
+### Open Positions
+
+Get current open positions with optional filters.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/positions" | python -m json.tool
+```
+
+| Parameter | Type   | Required | Description               |
+| --------- | ------ | -------- | ------------------------- |
+| symbol    | string | no       | Filter by symbol          |
+| group     | string | no       | Filter by group pattern   |
+| ticket    | int    | no       | Filter by position ticket |
+
+Example with symbol filter:
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/positions?symbol=EURUSD" | python -m json.tool
+```
+
+### Pending Orders
+
+Get current pending orders with optional filters.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/orders" | python -m json.tool
+```
+
+| Parameter | Type   | Required | Description             |
+| --------- | ------ | -------- | ----------------------- |
+| symbol    | string | no       | Filter by symbol        |
+| group     | string | no       | Filter by group pattern |
+| ticket    | int    | no       | Filter by order ticket  |
+
+### Historical Orders
+
+Get historical orders filtered by date range or ticket/position.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/history/orders?date_from=2024-01-01T00:00:00Z&date_to=2024-01-31T23:59:59Z" \
+  | python -m json.tool
+```
+
+| Parameter | Type     | Required | Description                                       |
+| --------- | -------- | -------- | ------------------------------------------------- |
+| date_from | datetime | cond.    | Start date (required if no ticket/position)       |
+| date_to   | datetime | cond.    | End date (required if no ticket/position)         |
+| ticket    | int      | cond.    | Filter by ticket (alternative to date range)      |
+| position  | int      | cond.    | Filter by position ID (alternative to date range) |
+| symbol    | string   | no       | Filter by symbol                                  |
+| group     | string   | no       | Filter by group pattern                           |
+
+Either `(date_from AND date_to)` or `(ticket OR position)` must be provided.
+
+Example by ticket:
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/history/orders?ticket=123456" \
+  | python -m json.tool
+```
+
+### Historical Deals
+
+Get historical deals filtered by date range or ticket/position.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/history/deals?date_from=2024-01-01T00:00:00Z&date_to=2024-01-31T23:59:59Z" \
+  | python -m json.tool
+```
+
+| Parameter | Type     | Required | Description                                       |
+| --------- | -------- | -------- | ------------------------------------------------- |
+| date_from | datetime | cond.    | Start date (required if no ticket/position)       |
+| date_to   | datetime | cond.    | End date (required if no ticket/position)         |
+| ticket    | int      | cond.    | Filter by ticket (alternative to date range)      |
+| position  | int      | cond.    | Filter by position ID (alternative to date range) |
+| symbol    | string   | no       | Filter by symbol                                  |
+| group     | string   | no       | Filter by group pattern                           |
+
+Either `(date_from AND date_to)` or `(ticket OR position)` must be provided.
+
+## Procedure
+
+1. Identify the user's query: open positions, pending orders, historical orders, or historical deals.
+2. Gather required filters (dates, symbol, ticket, or position).
+3. Construct and run the `curl` command with the appropriate query parameters.
+4. Parse the JSON response and summarize the results (number of records, P/L for positions, order types, deal volumes, etc.).
+5. For historical queries, remind the user that either a date range or a ticket/position filter is required.

mt5api-0.0.1/.agents/skills/mt5-market/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: mt5-market
+description: Fetch historical OHLCV rates, tick data, or market depth (DOM) from the MT5 API. Use when the user needs candlestick data, price history, tick-level data, or order book depth for a trading symbol.
+allowed-tools: Bash
+---
+
+# MT5 Market Data
+
+Query market data endpoints on the mt5api for historical rates, ticks, and market depth.
+
+## Configuration
+
+The API base URL defaults to `http://localhost:8000`. Set `MT5_API_URL` to override.
+All endpoints require the `X-API-Key` header. Set `MT5_API_KEY` in the environment.
+
+## Endpoints
+
+### Rates from Date
+
+Get historical OHLCV candles starting from a specific date.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/rates/from?symbol=EURUSD&timeframe=60&date_from=2024-01-01T00:00:00Z&count=100" \
+  | python -m json.tool
+```
+
+| Parameter | Type     | Required | Description                                    |
+| --------- | -------- | -------- | ---------------------------------------------- |
+| symbol    | string   | yes      | Symbol name                                    |
+| timeframe | int      | yes      | Timeframe in minutes (1, 5, 15, 60, 240, 1440) |
+| date_from | datetime | yes      | Start date (ISO 8601)                          |
+| count     | int      | yes      | Number of candles (1–100000)                   |
+
+### Rates from Position
+
+Get historical OHLCV candles starting from a bar index.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/rates/from-pos?symbol=EURUSD&timeframe=60&start_pos=0&count=100" \
+  | python -m json.tool
+```
+
+| Parameter | Type | Required | Description                      |
+| --------- | ---- | -------- | -------------------------------- |
+| symbol    | str  | yes      | Symbol name                      |
+| timeframe | int  | yes      | Timeframe in minutes             |
+| start_pos | int  | yes      | Start position (0 = current bar) |
+| count     | int  | yes      | Number of candles (1–100000)     |
+
+### Rates in Range
+
+Get historical OHLCV candles for a date range.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/rates/range?symbol=EURUSD&timeframe=60&date_from=2024-01-01T00:00:00Z&date_to=2024-01-31T23:59:59Z" \
+  | python -m json.tool
+```
+
+| Parameter | Type     | Required | Description           |
+| --------- | -------- | -------- | --------------------- |
+| symbol    | string   | yes      | Symbol name           |
+| timeframe | int      | yes      | Timeframe in minutes  |
+| date_from | datetime | yes      | Start date (ISO 8601) |
+| date_to   | datetime | yes      | End date (ISO 8601)   |
+
+### Ticks from Date
+
+Get tick-level data starting from a date.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/ticks/from?symbol=EURUSD&date_from=2024-01-02T10:00:00Z&count=500" \
+  | python -m json.tool
+```
+
+| Parameter | Type     | Required | Default | Description                         |
+| --------- | -------- | -------- | ------- | ----------------------------------- |
+| symbol    | string   | yes      |         | Symbol name                         |
+| date_from | datetime | yes      |         | Start date (ISO 8601)               |
+| count     | int      | yes      |         | Number of ticks (1–100000)          |
+| flags     | int      | no       | 6       | Tick flags (2=INFO, 4=TRADE, 6=ALL) |
+
+### Ticks in Range
+
+Get tick-level data for a date range.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/ticks/range?symbol=EURUSD&date_from=2024-01-02T10:00:00Z&date_to=2024-01-02T11:00:00Z" \
+  | python -m json.tool
+```
+
+| Parameter | Type     | Required | Default | Description                         |
+| --------- | -------- | -------- | ------- | ----------------------------------- |
+| symbol    | string   | yes      |         | Symbol name                         |
+| date_from | datetime | yes      |         | Start date (ISO 8601)               |
+| date_to   | datetime | yes      |         | End date (ISO 8601)                 |
+| flags     | int      | no       | 6       | Tick flags (2=INFO, 4=TRADE, 6=ALL) |
+
+### Market Book (DOM)
+
+Get market depth (order book) for a symbol.
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/market-book/EURUSD" | python -m json.tool
+```
+
+| Parameter | Type   | Required | Description |
+| --------- | ------ | -------- | ----------- |
+| symbol    | string | yes      | Symbol name |
+
+## Procedure
+
+1. Identify which market data endpoint the user needs.
+2. Gather the required parameters (symbol, timeframe, dates, count).
+3. Construct and run the appropriate `curl` command.
+4. Parse the JSON response and summarize the data (number of records, date range covered, OHLCV summary, etc.).
+5. If the user requests Parquet format, append `format=parquet` as a query parameter (use `?` if the URL has no existing parameters, or `&` if it does) and note the binary response.

mt5api-0.0.1/.agents/skills/mt5-symbols/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: mt5-symbols
+description: List available trading symbols, get detailed symbol information, or fetch the latest tick for a symbol from the MT5 API. Use when the user wants to browse symbols, look up symbol details, or check current prices.
+allowed-tools: Bash
+---
+
+# MT5 Symbols
+
+Query symbol-related endpoints on the mt5api.
+
+## Configuration
+
+The API base URL defaults to `http://localhost:8000`. Set `MT5_API_URL` to override.
+All endpoints require the `X-API-Key` header. Set `MT5_API_KEY` in the environment.
+
+## Endpoints
+
+### List Symbols
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/symbols" | python -m json.tool
+```
+
+Optional query parameters:
+
+| Parameter | Type   | Description                                   |
+| --------- | ------ | --------------------------------------------- |
+| group     | string | Symbol group filter (e.g., `*USD*`, `Forex*`) |
+
+Example with filter:
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/symbols?group=*USD*" | python -m json.tool
+```
+
+### Get Symbol Info
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/symbols/EURUSD" | python -m json.tool
+```
+
+Path parameters:
+
+| Parameter | Type   | Description                  |
+| --------- | ------ | ---------------------------- |
+| symbol    | string | Symbol name (e.g., `EURUSD`) |
+
+### Get Latest Tick
+
+```bash
+curl -s -H "X-API-Key: ${MT5_API_KEY}" \
+  "${MT5_API_URL:-http://localhost:8000}/api/v1/symbols/EURUSD/tick" | python -m json.tool
+```
+
+Path parameters:
+
+| Parameter | Type   | Description |
+| --------- | ------ | ----------- |
+| symbol    | string | Symbol name |
+
+## Procedure
+
+1. Identify which symbol operation the user needs (list, info, or tick).
+2. Substitute the correct symbol name and optional filters into the URL.
+3. Run the `curl` command and parse the JSON response.
+4. Summarize the results, highlighting key fields such as bid/ask prices, spread, symbol properties, or available symbols.

mt5api-0.0.1/.agents/skills/speckit-analyze/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: speckit-analyze
+description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
+allowed-tools: Bash, Read, Grep, Glob
+---
+
+# Spec-Kit Analyze
+
+Cross-artifact consistency and quality analysis for feature specifications. Validation step after creating tasks.md.
+
+## When to Use
+
+- After creating tasks.md with `speckit-tasks`
+- Before starting implementation with `speckit-implement`
+- Need to identify gaps or conflicts before coding
+
+## Execution Workflow
+
+**STRICTLY READ-ONLY** - Does not modify any files.
+
+1. **Initialize analysis context**: Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` to get FEATURE_DIR and AVAILABLE_DOCS. Derive paths:
+   - SPEC = FEATURE_DIR/spec.md
+   - PLAN = FEATURE_DIR/plan.md
+   - TASKS = FEATURE_DIR/tasks.md
+   - CONSTITUTION = .specify/memory/constitution.md
+2. **Load artifacts** (progressive disclosure - minimal context):
+   - From spec.md: Overview, Functional Requirements, Non-Functional Requirements, User Stories, Edge Cases
+   - From plan.md: Architecture/stack choices, Data Model references, Phases, Technical constraints
+   - From tasks.md: Task IDs, Descriptions, Phase grouping, Parallel markers `[P]`, File paths
+   - From constitution.md: Project principles, MUST/SHOULD requirements
+3. **Build semantic models** (internal representations):
+   - Requirements inventory with stable keys
+   - User story/action inventory with acceptance criteria
+   - Task coverage mapping (maps tasks to requirements)
+   - Constitution rule set (principle names and normative statements)
+4. **Detection passes** (maximum 50 findings total - aggregate overflow):
+   - **Duplication**: Near-duplicate requirements, lower-quality phrasing
+   - **Ambiguity**: Vague adjectives (fast, scalable, secure, intuitive, robust), unresolved placeholders (TODO, ???, `<placeholder>`)
+   - **Underspecification**: Requirements missing object/outcome, user stories missing acceptance criteria, tasks referencing undefined files
+   - **Constitution Alignment**: Conflicts with MUST principles (ALWAYS CRITICAL), missing mandated sections/gates
+   - **Coverage Gaps**: Requirements with zero tasks, tasks with no mapped requirement, missing non-functional task coverage
+   - **Inconsistency**: Terminology drift, data entities in plan but not spec, task ordering contradictions, conflicting requirements
+5. **Severity assignment**:
+   - CRITICAL: Violates constitution MUST, missing core spec artifact, requirement with zero coverage blocking baseline
+   - HIGH: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion
+   - MEDIUM: Terminology drift, missing non-functional task coverage, underspecified edge case
+   - LOW: Style/wording improvements, minor redundancy
+6. **Produce compact analysis report** (Markdown, no file writes):
+   - Findings table: ID, Category, Severity, Location(s), Summary, Recommendation
+   - Coverage summary: Requirement → Tasks mapping
+   - Constitution alignment issues table
+   - Unmapped tasks table
+   - Metrics: Total requirements, total tasks, coverage %, ambiguity count, duplication count, critical/high/medium/low issues
+7. **Next actions**:
+   - If CRITICAL: Must resolve before implementation
+   - If only LOW/MEDIUM: May proceed with improvements recommended
+   - Provide explicit command suggestions
+8. **Offer remediation**: Ask if user wants concrete edit suggestions (not applied automatically)
+
+## Key Points
+
+- **NEVER modify files** - read-only analysis
+- **Constitution violations are ALWAYS CRITICAL** - non-negotiable
+- **Progressive disclosure** - load artifacts incrementally, don't dump all content
+- **Token-efficient output** - tables over prose, limit to 50 findings, aggregate overflow
+- **Deterministic results** - rerunning without changes produces consistent IDs and counts
+- **Coverage % guidelines**:
+  - 100%: Perfect (rare)
+  - 80-99%: Excellent
+  - 60-79%: Good (review gaps)
+  - < 60%: Poor (significant gaps)
+- **Report zero issues gracefully** - emit success report with coverage statistics
+
+## Next Steps
+
+After analysis:
+
+- **Fix CRITICAL** - Update spec/plan/tasks
+- **Start implementation** - Use `speckit-implement`
+- **Re-analyze** - After fixes to verify
+
+## See Also
+
+- `speckit-plan` - Create technical implementation strategy
+- `speckit-tasks` - Break plan into actionable tasks
+- `speckit-implement` - Execute implementation plan

mt5api-0.0.1/.agents/skills/speckit-checklist/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: speckit-checklist
+description: Generate a custom checklist for the current feature based on user requirements.
+allowed-tools: Bash, Read, Write, Grep, Glob
+---
+
+# Spec-Kit Checklist
+
+Generate requirement quality validation checklists. "Unit Tests for English" - validates requirements are complete, clear, and consistent.
+
+## Core Concept: Unit Tests for Requirements
+
+**CRITICAL:** Checklists test **REQUIREMENTS QUALITY**, not implementation.
+
+**❌ NOT for verification/testing:**
+
+- "Verify button clicks correctly"
+- "Test error handling works"
+- "Confirm API returns 200"
+- Checking if code matches spec
+
+**✅ FOR requirements quality:**
+
+- "Are visual hierarchy requirements defined for all card types?" [Completeness]
+- "Is 'prominent display' quantified with specific sizing?" [Clarity]
+- "Are hover state requirements consistent across interactive elements?" [Consistency]
+- "Are accessibility requirements defined for keyboard navigation?" [Coverage]
+- "Does spec define fallback when logo image fails to load?" [Edge Cases]
+
+**Metaphor:** If your spec is code written in English, the checklist is its unit test suite.
+
+## When to Use
+
+- After creating spec.md or plan.md
+- Before implementation to validate requirements
+- For PR review quality gates
+- Need to ensure requirements are implementation-ready
+
+## Execution Workflow
+
+1. **Setup**: Run `.specify/scripts/bash/check-prerequisites.sh --json` to get FEATURE_DIR and AVAILABLE_DOCS
+2. **Clarify intent** (dynamic, up to 3 questions):
+   - Generate from user phrasing + extracted signals from spec/plan/tasks
+   - Only ask about information that materially changes checklist content
+   - Skip if already unambiguous in user input
+   - Generation algorithm:
+     - Extract signals: domain keywords, risk indicators, stakeholder hints, explicit deliverables
+     - Cluster into candidate focus areas (max 4) ranked by relevance
+     - Identify probable audience & timing if not explicit
+     - Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries
+     - Formulate questions from archetypes: scope refinement, risk prioritization, depth calibration, audience framing, boundary exclusion, scenario class gap
+   - Question formatting: compact table with Option | Candidate | Why It Matters
+   - Defaults when interaction impossible: Depth=Standard, Audience=Reviewer (PR)
+3. **Understand user request**: Combine user input + clarifying answers to derive checklist theme, must-have items, focus selections
+4. **Load feature context**: Read spec.md, plan.md (if exists), tasks.md (if exists) - only necessary portions, summarize long sections
+5. **Generate checklist**:
+   - Create `FEATURE_DIR/checklists/` directory if doesn't exist
+   - Generate unique filename: `[domain].md` (e.g., ux.md, api.md, security.md)
+   - Each run creates NEW file (never overwrites existing checklists)
+   - Number items sequentially starting from CHK001
+   - **Soft cap: 40 items** - if more candidates, prioritize by risk/impact and merge near-duplicates
+6. **Checklist structure** - Group items by requirement quality dimensions:
+   - Requirement Completeness (are all necessary requirements documented?)
+   - Requirement Clarity (are requirements specific and unambiguous?)
+   - Requirement Consistency (do requirements align without conflicts?)
+   - Acceptance Criteria Quality (are success criteria measurable?)
+   - Scenario Coverage (are all flows/cases addressed?)
+   - Edge Case Coverage (are boundary conditions defined?)
+   - Non-Functional Requirements (are performance, security, accessibility specified?)
+   - Dependencies & Assumptions (are they documented and validated?)
+   - Ambiguities & Conflicts (what needs clarification?)
+7. **Item structure**: Each item follows pattern:
+   - `- [ ] CHK### - [Question about requirement quality]? [Dimension, Reference]`
+   - Question format focusing on what's WRITTEN (or missing) in spec
+   - Quality dimension marker: [Completeness/Clarity/Consistency/Coverage/Measurability/etc.]
+   - Traceability: [Spec §X.Y] or [Gap] or [Ambiguity] or [Conflict]
+   - MINIMUM: ≥80% of items MUST include traceability reference
+8. **Report**: Output full path, item count, focus areas, depth level, actor/timing
+
+## Key Points
+
+- **Test requirements, NOT implementation**
+  - WRONG: "Verify landing page displays 3 episode cards"
+  - CORRECT: "Are the number and layout of featured episodes explicitly specified? [Completeness, Spec §FR-001]"
+- **Question format** - "Are requirements X...?" not "Does system X...?"
+- **Add traceability** - Reference spec sections or mark gaps (≥80% requirement)
+- **Focus scope** - One domain per checklist (UX, API, Security, etc.)
+- **Balance depth** - 15-40 items for focused, actionable validation
+- **Content consolidation** - Soft cap 40 items, merge near-duplicates, prioritize by risk/impact
+- **Prohibited patterns** - Any item starting with "Verify", "Test", "Confirm", "Check" + implementation behavior
+- **Required patterns** - "Are [requirement type] defined/specified/documented for [scenario]?"
+
+## Next Steps
+
+After creating checklist:
+
+- **Use for PR reviews** - Validate spec/plan before approval
+- **Self-review** - Author validates own requirements
+- **QA validation** - Ensure testable acceptance criteria
+- **Implementation** - Use `speckit-implement` after validation
+
+## See Also
+
+- `speckit-specify` - Create feature specifications
+- `speckit-plan` - Create technical implementation strategy
+- `speckit-implement` - Execute implementation plan