shmakk 1.1.0 → 1.2.0

package/skills/dev-merge.md

@@ -0,0 +1,73 @@
+---
+name: merge
+description: Merge changes from the topic branch to the merge base branch. Use when the user wants to merge their session's work back to the base branch.
+category: dev
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Merge Changes
+
+Merge the topic branch (checked out in the current worktree) into the merge base branch (checked out in the main worktree). The context block appended to the prompt contains the source branch, target branch, and main worktree path.
+
+## Guidelines
+
+- **Never force-push** (`--force`, `--force-with-lease`) without explicit user approval.
+- **Never skip pre-push hooks** (do not use `--no-verify`).
+- **Never rewrite or drop commits** without asking the user.
+- When in doubt about conflict resolution — ask the user.
+
+## Workflow
+
+### 1. Commit uncommitted changes in the current worktree
+
+Check for uncommitted changes in the current worktree:
+```
+git status --porcelain
+```
+If there are uncommitted changes, use the `/commit` skill to commit them before continuing.
+
+### 2. Merge the topic branch into the base branch
+
+Use `git -C <main-worktree-path>` to run commands against the main worktree without leaving the current worktree.
+
+```
+git -C <main-worktree-path> merge <topic-branch>
+```
+
+### 3. Handle merge conflicts
+
+If the merge reports conflicts:
+
+3.1. List conflicted files:
+```
+git -C <main-worktree-path> diff --name-only --diff-filter=U
+```
+
+3.2. For each conflicted file, read the file content, resolve the conflict by preserving the intent of both sides, and stage the resolved file:
+```
+git -C <main-worktree-path> add <resolved-file>
+```
+
+3.3. When in doubt on how to resolve a merge conflict, ask the user for guidance. If the user wants to abort, run:
+```
+git -C <main-worktree-path> merge --abort
+```
+
+3.4. Once all conflicts are resolved and staged, commit the merge:
+```
+git -C <main-worktree-path> commit --no-edit
+```
+
+## Validation
+
+After the merge completes, verify the result:
+
+1. Confirm the main worktree is clean:
+```
+git -C <main-worktree-path> status --porcelain
+```
+
+2. Confirm the topic branch is an ancestor of the base branch (i.e. all commits are merged):
+```
+git -C <main-worktree-path> merge-base --is-ancestor <topic-branch> HEAD
+```

package/skills/dev-migrate-create.md

@@ -0,0 +1,36 @@
+---
+name: migrate-create
+description: Create a new sequentially numbered database migration with up/down SQL files
+argument-hint: "<name>"
+allowed-tools: Read Write Glob Bash mcp__claude-flow__memory_store mcp__claude-flow__memory_search mcp__claude-flow__agentdb_pattern-search
+category: dev
+---
+
+# Migrate Create
+
+Generate a new database migration with sequential numbering and up/down SQL file pair.
+
+## When to use
+
+When you need to create a new database migration for schema changes such as creating tables, adding columns, creating indexes, or modifying constraints.
+
+## Steps
+
+1. **Determine next number** -- use `Glob` to scan the migrations directory for existing migration files and find the highest number, then increment by 1 (zero-pad to 3 digits)
+2. **Select template** -- based on the `<name>`, choose the appropriate SQL template:
+   - Names starting with `create_` -> CREATE TABLE template
+   - Names starting with `add_` -> ALTER TABLE ADD COLUMN template
+   - Names starting with `drop_` -> DROP with safety checks
+   - Names containing `index` -> CREATE INDEX template
+   - Other -> generic migration template with placeholder comments
+3. **Generate up migration** -- write `NNN_<name>.up.sql` with the appropriate SQL using IF NOT EXISTS for idempotency
+4. **Generate down migration** -- write `NNN_<name>.down.sql` with the reverse operation using IF EXISTS
+5. **Search past patterns** -- call `mcp__claude-flow__agentdb_pattern-search` (ReasoningBank-routed; **don't** pass a `namespace` argument — pattern-* tools ignore it).
+6. **Store metadata** -- call `mcp__claude-flow__memory_store --namespace migrations` to record the migration with number, name, status (pending), and file paths. The `memory_*` tool family routes by namespace; `agentdb_hierarchical-*` does NOT (it routes by tier `working|episodic|semantic`), so use `memory_*` here. See [ruflo-agentdb ADR-0001 §"Namespace convention"](../../../ruflo-agentdb/docs/adrs/0001-agentdb-optimization.md).
+7. **Report** -- display: migration number, file paths created, template used, any similar past migrations found
+
+## CLI alternative
+
+```bash
+npx @claude-flow/cli@latest memory store --namespace migrations --key "migration-NNN_NAME" --value '{"number": NNN, "name": "NAME", "status": "pending"}'
+```

package/skills/dev-migrate-validate.md

@@ -0,0 +1,36 @@
+---
+name: migrate-validate
+description: Validate pending migrations for foreign key consistency, rollback safety, and best practices
+argument-hint: ""
+allowed-tools: Read Glob Grep Bash mcp__claude-flow__memory_search mcp__claude-flow__memory_list mcp__claude-flow__memory_store mcp__claude-flow__agentdb_pattern-store mcp__claude-flow__agentdb_semantic-route
+category: dev
+---
+
+# Migrate Validate
+
+Validate all pending database migrations for correctness, safety, and adherence to best practices.
+
+## When to use
+
+Before applying migrations to catch issues early -- foreign key references to non-existent tables, missing rollback SQL, destructive operations without safeguards, and naming convention violations.
+
+## Steps
+
+1. **Find pending migrations** -- use `Glob` to list all migration files, cross-reference with applied history via `mcp__claude-flow__memory_search --namespace migrations` (or `memory_list`) to identify pending ones. The `memory_*` tool family routes by namespace; `agentdb_hierarchical-*` does NOT (it routes by tier), so use `memory_*` here.
+2. **Parse SQL** -- use `Read` to load each pending `.up.sql` and `.down.sql` file and parse the SQL statements
+3. **Check foreign keys** -- verify that all REFERENCES targets exist in the current schema or in prior migrations (both applied and pending)
+4. **Check NOT NULL defaults** -- verify that any ADD COLUMN with NOT NULL has a DEFAULT value
+5. **Check rollback completeness** -- verify every CREATE/ALTER in the UP file has a corresponding DROP/ALTER in the DOWN file
+6. **Flag destructive ops** -- warn on DROP TABLE, DROP COLUMN, TRUNCATE without explicit confirmation
+7. **Check idempotency** -- verify IF EXISTS / IF NOT EXISTS is used for safety
+8. **Check naming** -- verify table names are plural, column names are snake_case, index names follow `idx_table_column` convention
+9. **Store validation patterns** -- two paths (per ruflo-cost-tracker ADR-0001 dual-path pattern):
+   - **Pattern store (typed, recommended)**: `mcp__claude-flow__agentdb_pattern-store` with `type: 'migration-validation'`. No namespace arg — ReasoningBank routes it.
+   - **Plain store (namespace-routable)**: `mcp__claude-flow__memory_store --namespace migrations` for validation results tied to a specific migration number.
+10. **Report** -- display: errors (must fix), warnings (should fix), info (suggestions), with file path and line number for each issue
+
+## CLI alternative
+
+```bash
+npx @claude-flow/cli@latest memory search --query "migration validation results" --namespace migrations
+```

package/skills/dev-my-issues.md

@@ -0,0 +1,9 @@
+---
+name: my-issues
+description: 'List my issues in the current repository'
+category: dev
+---
+
+Search the current repo (using #githubRepo for the repo info) and list any issues you find (using #list_issues) that are assigned to me.
+
+Suggest issues that I might want to focus on based on their age, the amount of comments, and their status (open/closed).

package/skills/dev-my-pull-requests.md

@@ -0,0 +1,15 @@
+---
+name: my-pull-requests
+description: 'List my pull requests in the current repository'
+category: dev
+---
+
+Search the current repo (using #githubRepo for the repo info) and list any pull requests you find (using #list_pull_requests) that are assigned to me.
+
+Describe the purpose and details of each pull request.
+
+If a PR is waiting for someone to review, highlight that in the response.
+
+If there were any check failures on the PR, describe them and suggest possible fixes.
+
+If there was no review done by Copilot, offer to request one using #request_copilot_review.

package/skills/dev-planning-oracle-to-postgres-migration-integration-testing.md

@@ -0,0 +1,45 @@
+---
+name: planning-oracle-to-postgres-migration-integration-testing
+description: 'Creates an integration testing plan for .NET data access artifacts during Oracle-to-PostgreSQL database migrations. Analyzes a single project to identify repositories, DAOs, and service layers that interact with the database, then produces a structured testing plan. Use when planning integration test coverage for a migrated project, identifying which data access methods need tests, or preparing for Oracle-to-PostgreSQL migration validation.'
+category: dev
+---
+
+# Planning Integration Testing for Oracle-to-PostgreSQL Migration
+
+Analyze a single target project to identify data access artifacts that require integration testing, then produce a structured, actionable testing plan.
+
+## Workflow
+
+```
+Progress:
+- [ ] Step 1: Identify data access artifacts
+- [ ] Step 2: Classify testing priorities
+- [ ] Step 3: Write the testing plan
+```
+
+**Step 1: Identify data access artifacts**
+
+Scope to the target project only. Find classes and methods that interact directly with the database — repositories, DAOs, stored procedure callers, service layers performing CRUD operations.
+
+**Step 2: Classify testing priorities**
+
+Rank artifacts by migration risk. Prioritize methods that use Oracle-specific features (refcursors, `TO_CHAR`, implicit type coercion, `NO_DATA_FOUND`) over simple CRUD.
+
+**Step 3: Write the testing plan**
+
+Write a markdown plan covering:
+- List of testable artifacts with method signatures
+- Recommended test cases per artifact
+- Seed data requirements
+- Known Oracle→PostgreSQL behavioral differences to validate
+
+## Output
+
+Write the plan to: `.github/oracle-to-postgres-migration/Reports/{TARGET_PROJECT} Integration Testing Plan.md`
+
+## Key Constraints
+
+- **Single project scope** — only plan tests for artifacts within the target project.
+- **Database interactions only** — skip business logic that does not touch the database.
+- **Oracle is the golden source** — tests should capture Oracle's expected behavior for comparison against PostgreSQL.
+- **No multi-connection harnessing** — migrated applications are copied and renamed (e.g., `MyApp.Postgres`), so each instance targets one database.

package/skills/dev-playwright-generate-test.md

@@ -0,0 +1,18 @@
+---
+name: playwright-generate-test
+description: 'Generate a Playwright test based on a scenario using Playwright MCP'
+category: dev
+---
+
+# Test Generation with Playwright MCP
+
+Your goal is to generate a Playwright test based on the provided scenario after completing all prescribed steps.
+
+## Specific Instructions
+
+- You are given a scenario, and you need to generate a playwright test for it. If the user does not provide a scenario, you will ask them to provide one.
+- DO NOT generate test code prematurely or based solely on the scenario without completing all prescribed steps.
+- DO run steps one by one using the tools provided by the Playwright MCP.
+- Only after all steps are completed, emit a Playwright TypeScript test that uses `@playwright/test` based on message history
+- Save generated test file in the tests directory
+- Execute the test file and iterate until the test passes

package/skills/dev-playwright.md

@@ -0,0 +1,148 @@
+---
+name: "playwright"
+description: "Use when the task requires automating a real browser from the terminal (navigation, form filling, snapshots, screenshots, data extraction, UI-flow debugging) via `playwright-cli` or the bundled wrapper script."
+category: dev
+---
+
+
+# Playwright CLI Skill
+
+Drive a real browser from the terminal using `playwright-cli`. Prefer the bundled wrapper script so the CLI works even when it is not globally installed.
+Treat this skill as CLI-first automation. Do not pivot to `@playwright/test` unless the user explicitly asks for test files.
+
+## Prerequisite check (required)
+
+Before proposing commands, check whether `npx` is available (the wrapper depends on it):
+
+```bash
+command -v npx >/dev/null 2>&1
+```
+
+If it is not available, pause and ask the user to install Node.js/npm (which provides `npx`). Provide these steps verbatim:
+
+```bash
+# Verify Node/npm are installed
+node --version
+npm --version
+
+# If missing, install Node.js/npm, then:
+npm install -g @playwright/cli@latest
+playwright-cli --help
+```
+
+Once `npx` is present, proceed with the wrapper script. A global install of `playwright-cli` is optional.
+
+## Skill path (set once)
+
+```bash
+export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
+export PWCLI="$CODEX_HOME/skills/playwright/scripts/playwright_cli.sh"
+```
+
+User-scoped skills install under `$CODEX_HOME/skills` (default: `~/.codex/skills`).
+
+## Quick start
+
+Use the wrapper script:
+
+```bash
+"$PWCLI" open https://playwright.dev --headed
+"$PWCLI" snapshot
+"$PWCLI" click e15
+"$PWCLI" type "Playwright"
+"$PWCLI" press Enter
+"$PWCLI" screenshot
+```
+
+If the user prefers a global install, this is also valid:
+
+```bash
+npm install -g @playwright/cli@latest
+playwright-cli --help
+```
+
+## Core workflow
+
+1. Open the page.
+2. Snapshot to get stable element refs.
+3. Interact using refs from the latest snapshot.
+4. Re-snapshot after navigation or significant DOM changes.
+5. Capture artifacts (screenshot, pdf, traces) when useful.
+
+Minimal loop:
+
+```bash
+"$PWCLI" open https://example.com
+"$PWCLI" snapshot
+"$PWCLI" click e3
+"$PWCLI" snapshot
+```
+
+## When to snapshot again
+
+Snapshot again after:
+
+- navigation
+- clicking elements that change the UI substantially
+- opening/closing modals or menus
+- tab switches
+
+Refs can go stale. When a command fails due to a missing ref, snapshot again.
+
+## Recommended patterns
+
+### Form fill and submit
+
+```bash
+"$PWCLI" open https://example.com/form
+"$PWCLI" snapshot
+"$PWCLI" fill e1 "user@example.com"
+"$PWCLI" fill e2 "password123"
+"$PWCLI" click e3
+"$PWCLI" snapshot
+```
+
+### Debug a UI flow with traces
+
+```bash
+"$PWCLI" open https://example.com --headed
+"$PWCLI" tracing-start
+# ...interactions...
+"$PWCLI" tracing-stop
+```
+
+### Multi-tab work
+
+```bash
+"$PWCLI" tab-new https://example.com
+"$PWCLI" tab-list
+"$PWCLI" tab-select 0
+"$PWCLI" snapshot
+```
+
+## Wrapper script
+
+The wrapper script uses `npx --package @playwright/cli playwright-cli` so the CLI can run without a global install:
+
+```bash
+"$PWCLI" --help
+```
+
+Prefer the wrapper unless the repository already standardizes on a global install.
+
+## References
+
+Open only what you need:
+
+- CLI command reference: `references/cli.md`
+- Practical workflows and troubleshooting: `references/workflows.md`
+
+## Guardrails
+
+- Always snapshot before referencing element ids like `e12`.
+- Re-snapshot when refs seem stale.
+- Prefer explicit commands over `eval` and `run-code` unless needed.
+- When you do not have a fresh snapshot, use placeholder refs like `eX` and say why; do not bypass refs with `run-code`.
+- Use `--headed` when a visual check will help.
+- When capturing artifacts in this repo, use `output/playwright/` and avoid introducing new top-level artifact folders.
+- Default to CLI commands and workflows, not Playwright test specs.

package/skills/dev-prompt-builder.md

@@ -0,0 +1,142 @@
+---
+name: prompt-builder
+description: 'Guide users through creating high-quality GitHub Copilot prompts with proper structure, tools, and best practices.'
+category: dev
+---
+
+# Professional Prompt Builder
+
+You are an expert prompt engineer specializing in GitHub Copilot prompt development with deep knowledge of:
+- Prompt engineering best practices and patterns
+- VS Code Copilot customization capabilities  
+- Effective persona design and task specification
+- Tool integration and front matter configuration
+- Output format optimization for AI consumption
+
+Your task is to guide me through creating a new `.prompt.md` file by systematically gathering requirements and generating a complete, production-ready prompt file.
+
+## Discovery Process
+
+I will ask you targeted questions to gather all necessary information. After collecting your responses, I will generate the complete prompt file content following established patterns from this repository.
+
+### 1. **Prompt Identity & Purpose**
+- What is the intended filename for your prompt (e.g., `generate-react-component.prompt.md`)?
+- Provide a clear, one-sentence description of what this prompt accomplishes
+- What category does this prompt fall into? (code generation, analysis, documentation, testing, refactoring, architecture, etc.)
+
+### 2. **Persona Definition**
+- What role/expertise should Copilot embody? Be specific about:
+    - Technical expertise level (junior, senior, expert, specialist)
+    - Domain knowledge (languages, frameworks, tools)
+    - Years of experience or specific qualifications
+    - Example: "You are a senior .NET architect with 10+ years of experience in enterprise applications and extensive knowledge of C# 12, ASP.NET Core, and clean architecture patterns"
+
+### 3. **Task Specification**
+- What is the primary task this prompt performs? Be explicit and measurable
+- Are there secondary or optional tasks?
+- What should the user provide as input? (selection, file, parameters, etc.)
+- What constraints or requirements must be followed?
+
+### 4. **Context & Variable Requirements**
+- Will it use `${selection}` (user's selected code)?
+- Will it use `${file}` (current file) or other file references?
+- Does it need input variables like `${input:variableName}` or `${input:variableName:placeholder}`?
+- Will it reference workspace variables (`${workspaceFolder}`, etc.)?
+- Does it need to access other files or prompt files as dependencies?
+
+### 5. **Detailed Instructions & Standards**
+- What step-by-step process should Copilot follow?
+- Are there specific coding standards, frameworks, or libraries to use?
+- What patterns or best practices should be enforced?
+- Are there things to avoid or constraints to respect?
+- Should it follow any existing instruction files (`.instructions.md`)?
+
+### 6. **Output Requirements**
+- What format should the output be? (code, markdown, JSON, structured data, etc.)
+- Should it create new files? If so, where and with what naming convention?
+- Should it modify existing files?
+- Do you have examples of ideal output that can be used for few-shot learning?
+- Are there specific formatting or structure requirements?
+
+### 7. **Tool & Capability Requirements**
+Which tools does this prompt need? Common options include:
+- **File Operations**: `codebase`, `editFiles`, `search`, `problems`
+- **Execution**: `runCommands`, `runTasks`, `runTests`, `terminalLastCommand`
+- **External**: `fetch`, `githubRepo`, `openSimpleBrowser`
+- **Specialized**: `playwright`, `usages`, `vscodeAPI`, `extensions`
+- **Analysis**: `changes`, `findTestFiles`, `testFailure`, `searchResults`
+
+### 8. **Technical Configuration**
+- Should this run in a specific mode? (`agent`, `ask`, `edit`)
+- Does it require a specific model? (usually auto-detected)
+- Are there any special requirements or constraints?
+
+### 9. **Quality & Validation Criteria**
+- How should success be measured?
+- What validation steps should be included?
+- Are there common failure modes to address?
+- Should it include error handling or recovery steps?
+
+## Best Practices Integration
+
+Based on analysis of existing prompts, I will ensure your prompt includes:
+
+✅ **Clear Structure**: Well-organized sections with logical flow
+✅ **Specific Instructions**: Actionable, unambiguous directions  
+✅ **Proper Context**: All necessary information for task completion
+✅ **Tool Integration**: Appropriate tool selection for the task
+✅ **Error Handling**: Guidance for edge cases and failures
+✅ **Output Standards**: Clear formatting and structure requirements
+✅ **Validation**: Criteria for measuring success
+✅ **Maintainability**: Easy to update and extend
+
+## Next Steps
+
+Please start by answering the questions in section 1 (Prompt Identity & Purpose). I'll guide you through each section systematically, then generate your complete prompt file.
+
+## Template Generation
+
+After gathering all requirements, I will generate a complete `.prompt.md` file following this structure:
+
+```markdown
+---
+description: "[Clear, concise description from requirements]"
+agent: "[agent|ask|edit based on task type]"
+tools: ["[appropriate tools based on functionality]"]
+model: "[only if specific model required]"
+---
+
+# [Prompt Title]
+
+[Persona definition - specific role and expertise]
+
+## [Task Section]
+[Clear task description with specific requirements]
+
+## [Instructions Section]
+[Step-by-step instructions following established patterns]
+
+## [Context/Input Section] 
+[Variable usage and context requirements]
+
+## [Output Section]
+[Expected output format and structure]
+
+## [Quality/Validation Section]
+[Success criteria and validation steps]
+```
+
+The generated prompt will follow patterns observed in high-quality prompts like:
+- **Comprehensive blueprints** (architecture-blueprint-generator)
+- **Structured specifications** (create-github-action-workflow-specification)  
+- **Best practice guides** (dotnet-best-practices, csharp-xunit)
+- **Implementation plans** (create-implementation-plan)
+- **Code generation** (playwright-generate-test)
+
+Each prompt will be optimized for:
+- **AI Consumption**: Token-efficient, structured content
+- **Maintainability**: Clear sections, consistent formatting
+- **Extensibility**: Easy to modify and enhance
+- **Reliability**: Comprehensive instructions and error handling
+
+Please start by telling me the name and description for the new prompt you want to build.

package/skills/dev-pytest-coverage.md

@@ -0,0 +1,29 @@
+---
+name: pytest-coverage
+description: 'Run pytest tests with coverage, discover lines missing coverage, and increase coverage to 100%.'
+category: dev
+---
+
+The goal is for the tests to cover all lines of code.
+
+Generate a coverage report with:
+
+pytest --cov --cov-report=annotate:cov_annotate
+
+If you are checking for coverage of a specific module, you can specify it like this:
+
+pytest --cov=your_module_name --cov-report=annotate:cov_annotate
+
+You can also specify specific tests to run, for example:
+
+pytest tests/test_your_module.py --cov=your_module_name --cov-report=annotate:cov_annotate
+
+Open the cov_annotate directory to view the annotated source code.
+There will be one file per source file. If a file has 100% source coverage, it means all lines are covered by tests, so you do not need to open the file.
+
+For each file that has less than 100% test coverage, find the matching file in cov_annotate and review the file.
+
+If a line starts with a ! (exclamation mark), it means that the line is not covered by tests.
+Add tests to cover the missing lines.
+
+Keep running the tests and improving coverage until all lines are covered.