pdmt5 0.2.2__tar.gz → 0.2.4__tar.gz

pdmt5-0.2.4/.agents/skills/local-qa/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: local-qa
+description: Run local QA including formatting, linting, and testing for the repository. Use whenever any file has been updated.
+disable-model-invocation: false
+---
+
+# Local QA (format, lint, and test)
+
+Run the local QA script `scripts/qa.sh` in this skill.
+
+## 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 (`command not found`, missing executable, or equivalent), install the missing tool(s) and rerun `./scripts/qa.sh`.
+- Install tools using this order of preference:
+  1. Use the project's package manager when applicable (`uv`/`poetry` for Python, package manager scripts/dependencies for Node.js).
+  2. Use a system package manager (`brew` on macOS, `apt` on Debian/Ubuntu) when project-local install is not applicable.
+  3. Use language-specific installers as fallback (`pipx`/`pip`, `npm`, `go install`, etc.).
+- If multiple tools are missing, repeat install -> rerun until QA completes or you hit a blocker.
+- If installation fails or requires unavailable privileges, report what was attempted, the exact failure, and stop.
+- Do not run unrelated commands; only run commands needed for QA and missing-tool installation.

{pdmt5-0.2.2/.claude → pdmt5-0.2.4/.agents}/skills/local-qa/scripts/qa.sh

@@ -10,7 +10,7 @@ uv run pyright .
 uv run pytest
 
 # Markdown
-prettier --write './**/*.md'
+npx -y prettier --write './**/*.md'
 
 # GitHub Actions
 zizmor --fix=safe .github/workflows

pdmt5-0.2.4/.agents/skills/metatrader5-docs/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: metatrader5-docs
+description: Search the official MQL5 documentation for MetaTrader5 Python package usage. Use when the user needs help with MT5 Python API functions, parameters, return values, or usage examples.
+---
+
+# MetaTrader5 Python Documentation Search
+
+Search the official MQL5 documentation at `https://www.mql5.com/en/docs/python_metatrader5` for MetaTrader5 Python package usage.
+
+## Agent-Agnostic Compatibility
+
+- Prefer the agent's native web-fetch capability (for example: `WebFetch`, browser tool, or built-in URL retrieval).
+- If no native fetch tool exists, use CLI fallback (`curl` or `wget`) to retrieve docs pages.
+- If network access is blocked, state the limitation and provide the best guidance from known MT5 docs structure.
+
+## Procedure
+
+1. Identify the MT5 Python function(s) relevant to the user's query.
+2. Fetch the corresponding documentation page(s) using the available web retrieval method.
+3. Summarize the function signature, parameters, return value, and usage examples.
+4. If the user's query is general or unclear, fetch the index page first to find the right function.
+
+## Documentation URL Map
+
+Base URL: `https://www.mql5.com/en/docs/python_metatrader5`
+
+| Function               | URL Path                    |
+| ---------------------- | --------------------------- |
+| `initialize`           | `/mt5initialize_py`         |
+| `login`                | `/mt5login_py`              |
+| `shutdown`             | `/mt5shutdown_py`           |
+| `version`              | `/mt5version_py`            |
+| `last_error`           | `/mt5lasterror_py`          |
+| `account_info`         | `/mt5accountinfo_py`        |
+| `terminal_info`        | `/mt5terminalinfo_py`       |
+| `symbols_total`        | `/mt5symbolstotal_py`       |
+| `symbols_get`          | `/mt5symbolsget_py`         |
+| `symbol_info`          | `/mt5symbolinfo_py`         |
+| `symbol_info_tick`     | `/mt5symbolinfotick_py`     |
+| `symbol_select`        | `/mt5symbolselect_py`       |
+| `market_book_add`      | `/mt5marketbookadd_py`      |
+| `market_book_get`      | `/mt5marketbookget_py`      |
+| `market_book_release`  | `/mt5marketbookrelease_py`  |
+| `copy_rates_from`      | `/mt5copyratesfrom_py`      |
+| `copy_rates_from_pos`  | `/mt5copyratesfrompos_py`   |
+| `copy_rates_range`     | `/mt5copyratesrange_py`     |
+| `copy_ticks_from`      | `/mt5copyticksfrom_py`      |
+| `copy_ticks_range`     | `/mt5copyticksrange_py`     |
+| `orders_total`         | `/mt5orderstotal_py`        |
+| `orders_get`           | `/mt5ordersget_py`          |
+| `order_calc_margin`    | `/mt5ordercalcmargin_py`    |
+| `order_calc_profit`    | `/mt5ordercalcprofit_py`    |
+| `order_check`          | `/mt5ordercheck_py`         |
+| `order_send`           | `/mt5ordersend_py`          |
+| `positions_total`      | `/mt5positionstotal_py`     |
+| `positions_get`        | `/mt5positionsget_py`       |
+| `history_orders_total` | `/mt5historyorderstotal_py` |
+| `history_orders_get`   | `/mt5historyordersget_py`   |
+| `history_deals_total`  | `/mt5historydealstotal_py`  |
+| `history_deals_get`    | `/mt5historydealsget_py`    |
+
+## Function Categories
+
+Use these categories to narrow down the user's query:
+
+- **Connection**: `initialize`, `login`, `shutdown`
+- **Information**: `version`, `last_error`, `account_info`, `terminal_info`
+- **Symbols**: `symbols_total`, `symbols_get`, `symbol_info`, `symbol_info_tick`, `symbol_select`
+- **Market Depth**: `market_book_add`, `market_book_get`, `market_book_release`
+- **Market Data**: `copy_rates_from`, `copy_rates_from_pos`, `copy_rates_range`, `copy_ticks_from`, `copy_ticks_range`
+- **Orders**: `orders_total`, `orders_get`, `order_calc_margin`, `order_calc_profit`, `order_check`, `order_send`
+- **Positions**: `positions_total`, `positions_get`
+- **History**: `history_orders_total`, `history_orders_get`, `history_deals_total`, `history_deals_get`
+
+## Fetching Documentation
+
+For each relevant function, retrieve its documentation using whichever method the agent supports:
+
+- Native fetch tools (preferred).
+- Browser automation tools.
+- Shell fallback, for example:
+
+```bash
+curl -fsSL "https://www.mql5.com/en/docs/python_metatrader5<url_path>"
+```
+
+Extraction target for each page:
+
+- Function signature with all parameters.
+- Parameter descriptions and types.
+- Return value description.
+- Notes/remarks.
+- Full code example.
+
+When the query spans multiple functions, fetch pages in parallel when the agent/tooling supports it.
+
+## Response Format
+
+Present the results as:
+
+1. **Function**: `MetaTrader5.function_name()`
+2. **Description**: What the function does
+3. **Signature**: Full call signature with parameters
+4. **Parameters**: Table or list of parameter names, types, and descriptions
+5. **Returns**: Return type and description
+6. **Example**: Code example from the documentation
+7. **Source**: Link to the official documentation page

pdmt5-0.2.2/.codex/prompts/speckit.analyze.md → pdmt5-0.2.4/.agents/skills/speckit-analyze/SKILL.md

@@ -1,26 +1,31 @@
 ---
+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.
 ---
 
-## User Input
+# Spec Kit Analyze Skill
 
-```text
-$ARGUMENTS
-```
+## When to Use
 
-You **MUST** consider the user input before proceeding (if not empty).
+- You have `spec.md`, `plan.md`, and `tasks.md` and need a read-only consistency analysis before implementation.
+
+## Inputs
+
+- `specs/<feature>/spec.md`, `plan.md`, `tasks.md`
+- `.specify/memory/constitution.md`
+- Any user concerns or focus areas from the request
 
 ## Goal
 
-Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/speckit.tasks` has successfully produced a complete `tasks.md`.
+Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This skill MUST run only after a complete `tasks.md` exists (typically after speckit-tasks).
 
 ## Operating Constraints
 
-**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
+**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up edits are performed manually).
 
-**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`.
+**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside this skill.
 
-## Execution Steps
+## Workflow
 
 ### 1. Initialize Analysis Context
 
@@ -30,7 +35,7 @@ Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --inclu
 - PLAN = FEATURE_DIR/plan.md
 - TASKS = FEATURE_DIR/tasks.md
 
-Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command).
+Abort with an error message if any required file is missing (instruct the user to run the missing prerequisite skill or script).
 For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
 
 ### 2. Load Artifacts (Progressive Disclosure)
@@ -154,14 +159,18 @@ Output a Markdown report (no file writes) with the following structure:
 
 At end of report, output a concise Next Actions block:
 
-- If CRITICAL issues exist: Recommend resolving before `/speckit.implement`
+- If CRITICAL issues exist: Recommend resolving before speckit-implement
 - If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
-- Provide explicit command suggestions: e.g., "Run /speckit.specify with refinement", "Run /speckit.plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
+- Provide explicit next-step suggestions: e.g., "Run speckit-specify to refine requirements", "Run speckit-plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
 
 ### 8. Offer Remediation
 
 Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
 
+## Outputs
+
+- Read-only analysis report in the response (no file writes)
+
 ## Operating Principles
 
 ### Context Efficiency
@@ -181,4 +190,4 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t
 
 ## Context
 
-$ARGUMENTS
+the user's request and any stated focus areas

pdmt5-0.2.4/.agents/skills/speckit-baseline/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: speckit-baseline
+description: Generate feature specifications by analyzing existing source code.
+---
+
+# Spec Kit Baseline Skill
+
+## When to Use
+
+- You need a spec for existing or legacy code.
+- You want to document a feature before refactoring.
+- You inherited a codebase without written requirements.
+
+## Inputs
+
+- A target path, file list, or glob pattern describing the code to analyze.
+- Repo context with `.specify/` scripts and templates.
+
+If the target is missing or ambiguous, ask a focused question before continuing.
+
+## Goal
+
+Generate a technology-agnostic spec for existing code, then create the feature branch/spec file using the standard Spec Kit templates.
+
+## Workflow
+
+1. **Parse target input**: Identify files, directories, or patterns to analyze.
+   - Accept file paths, glob patterns, or directory paths.
+   - If empty: stop and ask for a concrete target.
+
+2. **Discover and read source files**:
+   - Expand globs to a file list.
+   - Read file contents for analysis.
+   - Identify primary language(s) and frameworks.
+   - Map key file relationships and dependencies.
+
+3. **Analyze code structure**:
+   - Identify entry points and public interfaces.
+   - Extract function/method signatures and behaviors.
+   - Find data models and entities.
+   - Detect API endpoints and routes.
+   - Identify user-facing functionality.
+
+4. **Generate a short name** (2-4 words) from the analyzed code:
+   - Use action-noun format (e.g., "user-auth", "payment-processing").
+   - Base on primary functionality discovered.
+   - Preserve technical terms where meaningful.
+
+5. **Create the feature branch and spec file**:
+   - Find the highest existing feature number for this short name (branches/specs).
+   - Run `.specify/scripts/bash/create-new-feature.sh --json` with the calculated number and short name.
+   - Read BRANCH_NAME, FEATURE_DIR, and SPEC_FILE paths from the script JSON output.
+   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+6. **Load the spec template** from `.specify/templates/spec-template.md`.
+
+7. **Draft the specification** using the template structure:
+   - **User Stories**: Infer from user-facing code paths and interactions.
+   - **Acceptance Scenarios**: Derive from validation logic, error handling, and tests.
+   - **Functional Requirements**: Extract from business rules and constraints.
+   - **Key Entities**: Identify from data models and schemas.
+   - **Success Criteria**: Infer from metrics, logging, or performance-related code.
+   - **Assumptions**: Document inferences made during analysis.
+
+8. **Abstract implementation details**:
+   - Convert technical patterns to user-focused requirements.
+   - Remove framework-specific terminology.
+   - Focus on WHAT the code does, not HOW it does it.
+
+9. **Create spec quality checklist** at `FEATURE_DIR/checklists/requirements.md`.
+
+10. **Report completion** with:
+    - Branch name and spec file path.
+    - Summary of analyzed files.
+    - Key features discovered.
+    - Areas needing clarification or review.
+
+## Outputs
+
+- `specs/<feature>/spec.md`
+- `specs/<feature>/checklists/requirements.md`
+
+## Key rules
+
+- Focus on extracting WHAT and WHY from HOW.
+- Abstract away implementation details in the generated spec.
+- Document assumptions made during code analysis.
+- Flag areas where code behavior is unclear.
+- Preserve discovered business rules and constraints.
+- Use `[NEEDS CLARIFICATION]` for ambiguous code sections (max 3).
+- Generated specs should be validated by someone who knows the feature.
+
+## Examples
+
+**Code Pattern → Spec Requirement**:
+
+- `if (user.role === 'admin')` → "System MUST restrict action to administrator users"
+- `password.length >= 8` → "Passwords MUST be at least 8 characters"
+- `cache.set(key, value, 3600)` → "System MUST cache results for improved performance"
+- `try { ... } catch (e) { notify(e) }` → "System MUST notify users when errors occur"
+
+**Code Pattern → User Story**:
+
+- Login endpoint with OAuth → "As a user, I can sign in using my social account"
+- Shopping cart logic → "As a customer, I can add items to my cart for later purchase"
+- Report generation → "As an analyst, I can generate reports on system activity"
+
+## Next Steps
+
+After generating spec.md:
+
+- **Clarify** with domain experts using speckit-clarify.
+- **Plan** modernization/refactoring with speckit-plan.
+- **Compare** the generated spec with actual requirements to identify gaps.

pdmt5-0.2.2/.codex/prompts/speckit.checklist.md → pdmt5-0.2.4/.agents/skills/speckit-checklist/SKILL.md

@@ -1,7 +1,21 @@
 ---
+name: speckit-checklist
 description: Generate a custom checklist for the current feature based on user requirements.
 ---
 
+# Spec Kit Checklist Skill
+
+## When to Use
+
+- You need a requirements-quality checklist tailored to a feature or domain.
+
+## Inputs
+
+- The user's request describing the checklist focus and scope.
+- Existing artifacts (spec/plan/tasks) for context when available.
+
+If the request is empty or unclear, ask a targeted question before continuing.
+
 ## Checklist Purpose: "Unit Tests for English"
 
 **CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR REQUIREMENTS WRITING** - they validate the quality, clarity, and completeness of requirements in a given domain.
@@ -23,15 +37,7 @@ description: Generate a custom checklist for the current feature based on user r
 
 **Metaphor**: If your spec is code written in English, the checklist is its unit test suite. You're testing whether the requirements are well-written, complete, unambiguous, and ready for implementation - NOT whether the implementation works.
 
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## Execution Steps
+## Workflow
 
 1. **Setup**: Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
    - All file paths must be absolute.
@@ -40,7 +46,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 2. **Clarify intent (dynamic)**: Derive up to THREE initial contextual clarifying questions (no pre-baked catalog). They MUST:
    - Be generated from the user's phrasing + extracted signals from spec/plan/tasks
    - Only ask about information that materially changes checklist content
-   - Be skipped individually if already unambiguous in `$ARGUMENTS`
+   - Be skipped individually if already unambiguous in the user's request
    - Prefer precision over breadth
 
    Generation algorithm:
@@ -69,7 +75,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
    Output the questions (label Q1/Q2/Q3). After answers: if ≥2 scenario classes (Alternate / Exception / Recovery / Non-Functional domain) remain unclear, you MAY ask up to TWO more targeted follow‑ups (Q4/Q5) with a one-line justification each (e.g., "Unresolved recovery path risk"). Do not exceed five total questions. Skip escalation if user explicitly declines more.
 
-3. **Understand user request**: Combine `$ARGUMENTS` + clarifying answers:
+3. **Understand user request**: Combine the user's request + clarifying answers:
    - Derive checklist theme (e.g., security, review, deploy, ux)
    - Consolidate explicit must-have items mentioned by user
    - Map focus selections to category scaffolding
@@ -93,7 +99,7 @@ You **MUST** consider the user input before proceeding (if not empty).
      - Format: `[domain].md`
      - If file exists, append to existing file
    - Number items sequentially starting from CHK001
-   - Each `/speckit.checklist` run creates a NEW file (never overwrites existing checklists)
+   - Each checklist run creates a NEW file (never overwrites existing checklists)
 
    **CORE PRINCIPLE - Test the Requirements, Not the Implementation**:
    Every checklist item MUST evaluate the REQUIREMENTS THEMSELVES for:
@@ -211,7 +217,7 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Actor/timing
    - Any explicit user-specified must-have items incorporated
 
-**Important**: Each `/speckit.checklist` command invocation creates a checklist file using short, descriptive names unless file already exists. This allows:
+**Important**: Each checklist run creates a checklist file using short, descriptive names unless the file already exists. This allows:
 
 - Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`)
 - Simple, memorable filenames that indicate checklist purpose
@@ -292,3 +298,7 @@ Sample items:
 - Correct: Validation of requirement quality
 - Wrong: "Does it do X?"
 - Correct: "Is X clearly specified?"
+
+## Outputs
+
+- `specs/<feature>/checklists/<domain>.md` (new checklist file per run)

pdmt5-0.2.2/.codex/prompts/speckit.clarify.md → pdmt5-0.2.4/.agents/skills/speckit-clarify/SKILL.md

@@ -1,24 +1,26 @@
 ---
+name: speckit-clarify
 description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
-handoffs:
-  - label: Build Technical Plan
-    agent: speckit.plan
-    prompt: Create a plan for the spec. I am building with...
 ---
 
-## User Input
+# Spec Kit Clarify Skill
 
-```text
-$ARGUMENTS
-```
+## When to Use
 
-You **MUST** consider the user input before proceeding (if not empty).
+- The feature spec exists but needs targeted clarification before planning.
 
-## Outline
+## Inputs
+
+- The current feature spec in `specs/<feature>/spec.md`.
+- The user's clarification intent or constraints from the request.
+
+If the request is empty or the spec is missing, ask a targeted question before proceeding.
+
+## Workflow
 
 Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
 
-Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/speckit.plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
+Note: This clarification workflow is expected to run (and be completed) BEFORE the speckit-plan skill. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
 
 Execution steps:
 
@@ -26,7 +28,7 @@ Execution steps:
    - `FEATURE_DIR`
    - `FEATURE_SPEC`
    - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
-   - If JSON parsing fails, abort and instruct user to re-run `/speckit.specify` or verify feature branch environment.
+   - If JSON parsing fails, abort and instruct the user to re-run speckit-specify or verify the feature branch environment.
    - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
 
 2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).
@@ -165,17 +167,27 @@ Execution steps:
    - Path to updated spec.
    - Sections touched (list names).
    - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact).
-   - If any Outstanding or Deferred remain, recommend whether to proceed to `/speckit.plan` or run `/speckit.clarify` again later post-plan.
-   - Suggested next command.
+   - If any Outstanding or Deferred remain, recommend whether to proceed to speckit-plan or run speckit-clarify again later post-plan.
+   - Suggested next step.
 
 Behavior rules:
 
 - If no meaningful ambiguities found (or all potential questions would be low-impact), respond: "No critical ambiguities detected worth formal clarification." and suggest proceeding.
-- If spec file missing, instruct user to run `/speckit.specify` first (do not create a new spec here).
+- If spec file missing, instruct the user to run speckit-specify first (do not create a new spec here).
 - Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).
 - Avoid speculative tech stack questions unless the absence blocks functional clarity.
 - Respect user early termination signals ("stop", "done", "proceed").
 - If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing.
 - If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale.
 
-Context for prioritization: $ARGUMENTS
+Context for prioritization: the user's request and any stated constraints
+
+## Outputs
+
+- Updated `specs/<feature>/spec.md` with clarifications appended and integrated
+
+## Next Steps
+
+After clarifications are resolved:
+
+- **Plan** implementation with speckit-plan.

pdmt5-0.2.2/.claude/commands/speckit.constitution.md → pdmt5-0.2.4/.agents/skills/speckit-constitution/SKILL.md

@@ -1,20 +1,22 @@
 ---
+name: speckit-constitution
 description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
-handoffs:
-  - label: Build Specification
-    agent: speckit.specify
-    prompt: Implement the feature specification based on the updated constitution. I want to build...
 ---
 
-## User Input
+# Spec Kit Constitution Skill
 
-```text
-$ARGUMENTS
-```
+## When to Use
 
-You **MUST** consider the user input before proceeding (if not empty).
+- Initial project setup or when governance principles need updates.
 
-## Outline
+## Inputs
+
+- User-provided principles or amendments.
+- Existing `.specify/memory/constitution.md` and templates.
+
+If the request is missing or ambiguous, ask focused questions before proceeding.
+
+## Workflow
 
 You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
 
@@ -44,7 +46,13 @@ Follow this execution flow:
    - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
    - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
    - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
+   - Review runtime prompts/agents for outdated references and align with updated principles:
+     - `.claude/commands/speckit.*.md`
+     - `.codex/prompts/speckit.*.md`
+     - `.gemini/commands/speckit.*.toml`
+     - `.github/prompts/speckit.*.prompt.md`
+     - `.github/agents/speckit.*.agent.md`
+     - `skills/speckit-*/SKILL.md`
    - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
 
 5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
@@ -80,3 +88,14 @@ If the user supplies partial updates (e.g., only one principle revision), still
 If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
 
 Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
+
+## Outputs
+
+- Updated `.specify/memory/constitution.md` (with Sync Impact Report comment)
+- Any updated templates or runtime guidance files required to stay consistent with the constitution
+
+## Next Steps
+
+After updating the constitution:
+
+- **Specify** new features with speckit-specify.

pdmt5-0.2.2/.codex/prompts/speckit.implement.md → pdmt5-0.2.4/.agents/skills/speckit-implement/SKILL.md

@@ -1,16 +1,23 @@
 ---
+name: speckit-implement
 description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
 ---
 
-## User Input
+# Spec Kit Implement Skill
 
-```text
-$ARGUMENTS
-```
+## When to Use
 
-You **MUST** consider the user input before proceeding (if not empty).
+- The plan and tasks are complete and you are ready to implement.
 
-## Outline
+## Inputs
+
+- `specs/<feature>/tasks.md` and `plan.md`
+- Optional artifacts: `data-model.md`, `contracts/`, `research.md`, `quickstart.md`
+- User constraints (e.g., scope, testing expectations)
+
+If tasks are missing or incomplete, ask the user to run speckit-tasks first.
+
+## Workflow
 
 1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
 
@@ -132,4 +139,10 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Confirm the implementation follows the technical plan
    - Report final status with summary of completed work
 
-Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/speckit.tasks` first to regenerate the task list.
+Note: This skill assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running speckit-tasks first to regenerate the task list.
+
+## Outputs
+
+- Implementation changes in the codebase
+- Updated `specs/<feature>/tasks.md` with completed tasks checked off
+- Any generated/updated ignore files (e.g., `.gitignore`, `.dockerignore`, `.eslintignore`, `.prettierignore`)