@vyuhlabs/dxkit 2.4.8 → 2.5.0

package/templates/.ai/prompts/planning-prompt.md

@@ -1,18 +0,0 @@
-I want to {YOUR_GOAL_HERE}
-{IF_CONTINUING_FROM_CHECKPOINT}
-I'm continuing from a previous session. Please read:
-{CHECKPOINT_PATH}
-
-Summarize what was accomplished and what's left to do.
-{END_IF}
-Before we start coding, let's plan this session:
-
-1. What files will we need to create/modify?
-2. What are the key components/functions?
-3. What dependencies or external services do we need?
-4. What tests should we write?
-5. Can we complete this in one session (within context window)?
-6. Does this align with our architecture?
-7. Are there relevant gotchas or conventions in `.claude/skills/` to be aware of?
-
-Once we have a solid plan that fits in one session, I'll ask you to proceed.

package/templates/.ai/prompts/session-end-template.md

@@ -1,182 +0,0 @@
-# Session End - Create Checkpoint
-
-Please create a comprehensive session checkpoint using your full conversation context.
-
-## Session Information
-- **Developer**: {DEVELOPER}
-- **Date**: {DATE}
-- **Session Number**: {SESSION_NUM}
-- **Checkpoint File**: `{CHECKPOINT_FILE}`
-
-## Your Task
-
-You have the complete context of this development session. Create a comprehensive checkpoint.
-
-### Step 1: Gather Information from User
-
-Ask me for any details you need to complete the checkpoint:
-- **Session duration**: Estimate from our conversation length, or ask me
-- **Blockers**: Any issues or concerns for next session?
-- **Completeness**: Did we finish what we planned, or is work in progress?
-- **Anything unclear**: Any decisions or context you're unsure about?
-
-### Step 2: Create Checkpoint File
-
-Create the checkpoint at: `{CHECKPOINT_FILE}`
-
-Use the template structure from: `.ai/templates/session-checkpoint-template.md`
-
-Fill out **all sections thoroughly** using:
-- ✅ **Our conversation history** - You know everything we discussed and built
-- ✅ **Files you touched** - You know every file created/modified
-- ✅ **Decisions we made** - You remember the reasoning and trade-offs
-- ✅ **Plans we made** - You know what's next
-
-## What to Document
-
-### Accomplished ✅
-List **specific** accomplishments (not vague):
-- ❌ Bad: "Worked on the client"
-- ✅ Good: "Implemented PolygonClient with 3 endpoints (get_quote, get_bars, get_options), added 15 unit tests, all passing"
-
-### Files Created/Modified
-Every file with description:
-- Created files with purpose
-- Modified files with what changed
-
-### Key Decisions
-Major decisions with reasoning:
-- What we decided
-- Why we chose this approach
-- Alternatives we considered
-- Trade-offs we accepted
-
-### Implementation Details
-How things work:
-- Architecture/patterns used
-- Key technical details
-- Where to find important logic
-
-### Testing Status
-- Tests added/updated
-- Coverage
-- Passing status
-- Manual testing done
-
-### Next Session
-**Clear, actionable steps** for next session:
-- Specific enough to start immediately
-- Ordered by priority
-- With enough context
-
-### Context for AI
-Detailed context for next session's AI agent:
-- What we just completed
-- Current state of the codebase
-- What to do next and why
-- Key facts to remember
-
-### Blockers / Considerations
-- Any blockers needing resolution
-- Technical debt taken
-- Things to watch
-- Dependencies
-
-## Recent Git Activity
-
-{GIT_COMMITS}
-
-{GIT_CHANGES}
-
----
-
-## Guidelines
-
-- **Be specific**: Include file paths, line counts, exact accomplishments
-- **Explain decisions**: Don't just say what, say why
-- **Actionable next steps**: Clear enough that anyone can continue
-- **Rich context**: Next AI agent should seamlessly pick up where we left off
-
----
-
-## Skill Evolution
-
-After creating the checkpoint, review this session for learnings worth capturing:
-
-### Gotchas
-If you encountered unexpected behaviors, edge cases, or failures:
-- Append to `.claude/skills/learned/references/gotchas.md` (general)
-- Or to `.claude/skills/<area>/references/gotchas.md` (area-specific: quality, test, deploy, gcloud, etc.)
-
-Format:
-```
-## {DATE} - {Category} / {Short Title}
-{Description of the issue}
-**Resolution:** {How it was resolved}
-```
-
-### Conventions
-If new team conventions or patterns were established:
-- Append to `.claude/skills/learned/references/conventions.md`
-
-Format:
-```
-## {Category} - {Convention Name}
-{Description}
-**Rationale:** {Why this convention was adopted}
-```
-
-### New Skills
-If this session introduced a significant new domain, workflow, or integration that doesn't fit any existing skill, create a new skill:
-
-1. Create directory: `.claude/skills/<skill-name>/`
-2. Create `SKILL.md` with proper frontmatter:
-```
----
-name: <skill-name>
-description: <what it does and when to use it — max 1024 chars>
----
-
-# <Skill Title>
-
-<Instructions, commands, patterns, gotchas>
-```
-3. Optionally add `references/gotchas.md` for area-specific gotchas
-
-**When to create a new skill vs. updating an existing one:**
-- New skill: the topic is distinct enough that it would clutter an existing skill (e.g., a specific API client, a migration workflow, a caching layer)
-- Update existing: the learning fits naturally into an existing skill's domain (e.g., a new Python lint gotcha → quality skill)
-
-**Naming rules** (per Agent Skills spec):
-- Lowercase letters, numbers, and hyphens only
-- No consecutive hyphens, don't start/end with hyphen
-- Directory name must match the `name` field in frontmatter
-
-### Deny Rule Recommendations
-If you encountered or nearly executed a dangerous command that should be permanently blocked:
-- Append to `.claude/skills/learned/references/deny-recommendations.md`
-
-Format:
-```
-## {DATE} - Rule
-`DenyPattern` — reason this should be blocked
-**Context:** what happened that surfaced this need
-```
-
-A developer should periodically review this file and promote entries to `.claude/settings.json` deny list. Claude cannot modify settings.json directly (security boundary).
-
-### Guidelines for Skill Evolution
-- Only add genuinely useful learnings (not obvious things)
-- Be specific: include file paths, error messages, exact symptoms
-- Focus on things that would save time if known in advance
-- Append-only for gotchas/conventions — never remove or edit existing entries
-- **NEVER include secret values, tokens, passwords, or API keys in any skill file**
-
----
-
-**Action**: Ask me any clarifying questions you need, then create the checkpoint file and update skills.
-
-Make it thorough enough that:
-1. Another developer can understand what was built
-2. Next session's AI agent can seamlessly continue
-3. We can remember context weeks/months from now

package/templates/.ai/prompts/session-end.md

@@ -1,132 +0,0 @@
-# Session End Prompt Template
-
-Use this prompt to wrap up an AI-assisted development session and create a checkpoint.
-
-## Prompt Template
-
-```
-We're wrapping up this session. Please create a session checkpoint document:
-
-1. Determine the developer name from git config (git config user.name)
-2. Convert to lowercase with hyphens (e.g., "John Doe" → "john-doe")
-3. Get today's date in YYYY-MM-DD format
-4. Check for existing session files in .ai/sessions/{developer-name}/{YYYY-MM-DD}/
-5. Create checkpoint file: .ai/sessions/{developer-name}/{YYYY-MM-DD}/session-{N}.md
-   - Create the date folder if it doesn't exist
-   - {N} is the session number for today (increment if multiple sessions today)
-
-6. Use the template from .ai/templates/session-checkpoint-template.md
-
-6. Fill in the template with:
-   - Session goal (what we set out to do)
-   - What we accomplished (specific, measurable)
-   - All files created/modified (with brief description of changes)
-   - Key decisions made (with reasoning)
-   - Implementation details (how things work)
-   - Testing status (what's tested, what's passing)
-   - Next steps (clear, actionable items for next session)
-   - Context for AI (detailed context for next session's agent)
-   - Any blockers or considerations
-
-Make the checkpoint detailed enough that someone else (or a fresh AI agent) can understand what was done and continue the work.
-```
-
-## What Makes a Good Checkpoint?
-
-### Essential Elements
-
-✅ **Clear Goal**
-- What we wanted to accomplish
-- Why this work matters
-
-✅ **Specific Accomplishments**
-- Not "worked on client" but "implemented PolygonClient with quote/bars endpoints, added Pydantic models, wrote 15 unit tests"
-
-✅ **File Changes**
-- Every file created or modified
-- What changed in each file
-
-✅ **Decision Rationale**
-- Why we chose approach A over B
-- Trade-offs we accepted
-
-✅ **Technical Details**
-- How the implementation works
-- Important patterns or techniques used
-- Where to find key logic
-
-✅ **Actionable Next Steps**
-- Specific, not vague
-- Ordered by priority
-- With enough context to start
-
-✅ **AI Context Block**
-- Detailed prompt for next session's agent
-- Key facts to remember
-- How to continue
-
-## Example Good vs Bad Checkpoints
-
-### ❌ Bad Checkpoint
-
-```markdown
-## Accomplished
-- Worked on the client
-- Made progress on tools
-- Fixed some bugs
-
-## Next Steps
-- Continue implementation
-- Add more tests
-```
-
-**Why bad:** Vague, no specifics, can't continue from this
-
-### ✅ Good Checkpoint
-
-```markdown
-## Accomplished
-- Implemented PolygonClient class in services/langgraph-service/src/clients/polygon/client.py
-  - Added async methods: get_quote(), get_bars(), get_options_chain()
-  - Implemented retry logic for rate limits (429 errors)
-  - Added authentication via Bearer token
-- Created Pydantic models in clients/polygon/models.py (Quote, Bar, OptionContract)
-- Added 15 unit tests in tests/clients/test_polygon.py (100% coverage)
-- All tests passing (make test)
-
-## Next Steps
-1. Integrate PolygonClient into market_data tool
-2. Update tool to use client's get_quote() method instead of mock data
-3. Add integration test with mocked PolygonClient
-4. Update tool registry to include new market data capabilities
-
-## Context for AI
-We've implemented the Polygon client infrastructure layer. The client handles all HTTP communication, auth, and retries.
-
-Next, we need to integrate it into the tool layer. The market_data.py tool currently returns mock data - replace the get_stock_quote() function to use polygon_client.get_quote().
-
-Remember to inject PolygonClient as a dependency (don't import directly) to keep tests mockable.
-```
-
-**Why good:** Specific files, concrete accomplishments, clear next steps, AI can continue easily
-
----
-
-## Skill Evolution
-
-After creating the checkpoint, review the session for learnings:
-
-✅ **Gotchas** — Unexpected behaviors, edge cases, or failure modes
-→ Append to `.claude/skills/learned/references/gotchas.md` or `.claude/skills/<area>/references/gotchas.md`
-
-✅ **Conventions** — New patterns or team agreements established
-→ Append to `.claude/skills/learned/references/conventions.md`
-
-✅ **New Skills** — If a new domain/workflow emerged that deserves its own skill
-→ Create `.claude/skills/<name>/SKILL.md` with frontmatter (`name`, `description`)
-
-⚠️ **NEVER include secret values, tokens, or credentials in skill files**
-
----
-
-**Remember:** A good checkpoint enables seamless continuation. Treat it like documentation for your future self (or the next AI agent).

package/templates/.ai/prompts/session-start.md

@@ -1,109 +0,0 @@
-# Session Start Prompt Template
-
-Use this prompt to start a new AI-assisted development session.
-
-## Prompt Template
-
-```
-I want to {SESSION_GOAL}.
-
-{IF CONTINUING FROM PREVIOUS SESSION:}
-I'm continuing from a previous session. Please read the checkpoint:
-.ai/sessions/{DEVELOPER_NAME}/{LAST_CHECKPOINT_FILE}
-
-Summarize what was accomplished and what's left to do.
-{END IF}
-
-Before we start coding, let's plan this session:
-
-1. What files will we need to create/modify?
-2. What are the key components/functions?
-3. What dependencies or external services do we need?
-4. What tests should we write?
-5. Can we complete this in one session (within context window)?
-6. Does this align with our architecture? (Check docs/architecture/system-overview.md and docs/developer-guide/key-principles.md)
-
-Once we have a solid plan that fits in one session, I'll ask you to proceed step by step.
-```
-
-## Example Usage
-
-### New Feature (No Previous Session)
-
-```
-I want to implement the Polygon client for fetching stock quotes and historical bars.
-
-Before we start coding, let's plan this session:
-
-1. What files will we need to create/modify?
-2. What are the key components/functions?
-3. What dependencies or external services do we need?
-4. What tests should we write?
-5. Can we complete this in one session (within context window)?
-6. Does this align with our architecture?
-
-Once we have a solid plan that fits in one session, I'll ask you to proceed step by step.
-```
-
-### Continuing from Previous Session
-
-```
-I want to continue implementing the market data integration.
-
-I'm continuing from a previous session. Please read the checkpoint:
-.ai/sessions/john-doe/2025-10-05-session-1.md
-
-Summarize what was accomplished and what's left to do.
-
-Before we start coding, let's plan this session...
-```
-
-## Before Planning
-
-Check Claude Code skills for relevant context before starting work:
-- `.claude/skills/codebase/SKILL.md` — Architecture overview (run `/project:explore-codebase` if missing)
-- `.claude/skills/learned/references/gotchas.md` — Known project gotchas (avoid repeating past mistakes)
-- `.claude/skills/learned/references/conventions.md` — Team conventions (follow established patterns)
-- `.claude/skills/<area>/references/gotchas.md` — Area-specific gotchas (quality, test, deploy, etc.)
-
-## What Good Planning Looks Like
-
-The AI agent should respond with:
-
-### File Plan
-- Clear list of files to create/modify
-- Rationale for each file
-- Estimated size/complexity
-
-### Component Breakdown
-- Main classes/functions to implement
-- How they fit together
-- Dependencies between components
-
-### Testing Plan
-- What needs unit tests
-- What needs integration tests
-- Test coverage strategy
-
-### Feasibility Check
-- Honest assessment of scope
-- Recommendation to split if too large
-- Estimated complexity
-
-## If the Plan Looks Good
-
-```
-Great plan! This looks achievable in one session and aligns with our architecture.
-
-Let's proceed step by step. Before implementing each component:
-1. Tell me what you're about to do
-2. Explain WHY we're doing it this way
-3. Explain HOW it fits into the architecture
-4. Then implement it
-
-Let's start with {FIRST_COMPONENT}.
-```
-
----
-
-**Remember:** Good planning saves time. Spend 5-10 minutes planning to save hours of refactoring.

package/templates/.ai/prompts/step-by-step.md

@@ -1,113 +0,0 @@
-# Step-by-Step Development Prompt
-
-Use this prompt during development to ensure AI agent explains before implementing.
-
-## Prompt Template
-
-```
-Great plan! Let's proceed step by step.
-
-Before implementing each component:
-1. Tell me what you're about to do
-2. Explain WHY we're doing it this way (business reason, architectural fit)
-3. Explain HOW it will work (technical approach)
-4. Then implement it
-
-Let's start with {FIRST_COMPONENT}.
-```
-
-## During Development - Validation Checkpoints
-
-After each major component is implemented, validate:
-
-```
-Before we continue, let's verify this implementation:
-
-1. Does it follow our architecture patterns?
-2. Is error handling consistent with our standards?
-3. Are we using dependency injection properly?
-4. Is logging structured and informative?
-5. Are type hints/types properly used?
-6. Is it testable (dependencies can be mocked)?
-
-If everything looks good, let's continue to {NEXT_COMPONENT}.
-If not, let's refine before moving on.
-```
-
-## Course Correction
-
-If something doesn't align with our patterns:
-
-```
-Wait, this doesn't follow our {PATTERN_NAME} pattern.
-
-According to docs/{RELEVANT_DOC}, we should {CORRECT_APPROACH}.
-
-Can you revise this to align with our standards?
-```
-
-## Example Flow
-
-### Step 1: Client Implementation
-
-```
-Let's start with implementing the PolygonClient class.
-
-Before coding:
-1. What are you about to do?
-2. Why this approach?
-3. How will it work technically?
-```
-
-**Agent explains...**
-
-```
-That makes sense. Please proceed with the implementation.
-```
-
-### Step 2: Testing
-
-```
-Finally, let's add tests.
-
-Before coding:
-1. What test coverage do we need?
-2. How will we mock the external API?
-3. What edge cases should we test?
-```
-
-## What Good Explanations Look Like
-
-### What to Do
-"I'm implementing the PolygonClient class with async methods for fetching quotes and historical bars."
-
-### Why This Way
-"We use an async client because we'll make multiple concurrent API calls. This is separated from the tool layer to follow our clean architecture pattern."
-
-### How It Works
-"The client will use httpx.AsyncClient for HTTP requests, handle authentication via headers, implement retry logic for rate limits, and parse responses into Pydantic models for type safety."
-
-## Red Flags - When to Stop
-
-❌ "I'll implement the client" → No explanation given
-❌ "This is the standard way" → Not specific to our architecture
-❌ "Let me write the code" → Skipping the explanation step
-❌ Hardcoded values → Should use config
-❌ No error handling mentioned → Missing critical aspect
-❌ No testability consideration → Will be hard to test
-
-## Session Flow Summary
-
-```
-1. Plan session ✓
-2. For each component:
-   a. Agent explains what/why/how
-   b. Developer validates explanation
-   c. Agent implements
-   d. Developer verifies implementation
-3. Create checkpoint ✓
-```
-
----
-
-**Key Principle:** Understand before coding. If you don't understand the "what/why/how", the code won't align with architecture.

package/templates/.claude/commands/setup-pr-review.md

@@ -1,72 +0,0 @@
----
-description: Set up automated PR review with Claude Code
----
-
-Set up a GitHub Action that automatically reviews pull requests using Claude Code.
-
-## What to Create
-
-Create `.github/workflows/pr-review.yml` with this content:
-
-```yaml
-name: PR Review
-
-on:
-  pull_request:
-    types: [opened, synchronize, reopened]
-
-permissions:
-  contents: read
-  pull-requests: write
-
-jobs:
-  review:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Install Claude Code
-        run: npm install -g @anthropic-ai/claude-code
-
-      - name: Review PR
-        env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
-        run: |
-          # Get the diff
-          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr-diff.txt
-
-          # Run Claude Code in non-interactive mode
-          claude -p "Review this pull request diff for bugs, security issues, and code quality problems. Focus on:
-          1. Logic errors and edge cases
-          2. Security vulnerabilities (hardcoded secrets, injection, auth gaps)
-          3. Error handling gaps
-          4. Breaking changes
-
-          Be specific: reference file:line numbers. Rate each issue as critical/warning/suggestion.
-          Only flag real issues — not style (linters handle that).
-
-          The diff:
-          $(cat /tmp/pr-diff.txt)" > /tmp/review.md
-
-      - name: Post Review Comment
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const fs = require('fs');
-            const review = fs.readFileSync('/tmp/review.md', 'utf8');
-            await github.rest.issues.createComment({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              issue_number: context.issue.number,
-              body: `## 🤖 Claude Code Review\n\n${review}\n\n---\n*Automated review by Claude Code*`
-            });
-```
-
-## After Creating
-
-Tell the user:
-1. Add `ANTHROPIC_API_KEY` to the repo's GitHub Secrets (Settings → Secrets → Actions)
-2. The workflow will run automatically on every PR
-3. Reviews appear as PR comments