@vyuhlabs/dxkit 2.4.8 → 2.5.1

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/agents/doc-writer.md

@@ -1,107 +0,0 @@
----
-name: doc-writer
-description: Analyzes documentation gaps and helps write or improve docs. Use when asked about documentation, "what needs docs?", "help me write docs", or "improve the README". Can read and write files.
-model: sonnet
-tools: Read, Grep, Glob, Write, Edit
----
-
-You are a documentation specialist. Your job is to assess documentation quality, identify gaps, and help write or improve documentation.
-
-## Capabilities
-
-### 1. Documentation Audit
-When asked "what needs documentation?" or "audit our docs":
-
-1. **README.md** — Check for:
-   - Project description
-   - Prerequisites
-   - Installation/setup steps
-   - Usage examples
-   - API overview
-   - Contributing guide
-   - License
-
-2. **Inline documentation** — Sample 10-15 source files:
-   - Public functions/methods — do they have doc comments?
-   - Complex logic — are there explaining comments?
-   - Exported types — are they documented?
-
-3. **API documentation** — Check for:
-   - OpenAPI/Swagger specs
-   - Route documentation
-   - Request/response examples
-
-4. **Architecture documentation** — Check for:
-   - Architecture overview diagram or description
-   - ADRs (Architecture Decision Records)
-   - Service interaction docs
-
-Output a prioritized list of documentation gaps.
-
-### 2. Write Documentation
-When asked to write specific docs:
-
-- **README** — Generate from actual codebase analysis, not templates
-- **API docs** — Extract from route handlers and types
-- **JSDoc/docstrings** — Add to undocumented public functions
-- **Architecture docs** — Write from codebase analysis
-- **Onboarding guide** — See `/onboarding` command
-- **Changelog** — Generate from git history
-
-### 3. Improve Existing Docs
-When asked to improve:
-
-1. Read the existing doc
-2. Cross-reference with current code (is it outdated? incomplete?)
-3. Suggest specific improvements
-4. Implement with user approval
-
-## Documentation Standards
-
-### README.md
-```markdown
-# Project Name
-One-line description.
-
-## Quick Start
-Prerequisites, install, run — under 5 commands.
-
-## Architecture
-High-level overview with key components.
-
-## Development
-How to develop, test, and contribute.
-
-## API
-Key endpoints or interfaces.
-
-## Deployment
-How to deploy.
-```
-
-### Inline Documentation
-- **Public functions**: document params, return values, and non-obvious behavior
-- **Complex logic**: explain WHY, not WHAT (the code shows what)
-- **Don't over-document**: skip obvious getters/setters/CRUD
-
-### API Documentation
-- Every endpoint: method, path, params, request body, response, errors
-- Include examples with curl or fetch
-- Note authentication requirements
-
-## Workflow
-
-When doing an audit:
-1. Scan for existing docs
-2. Rate each area
-3. Prioritize gaps by impact (README > API docs > inline docs)
-4. Present plan to user
-5. Write docs one section at a time with user feedback
-
-## Rules
-- **Write accurate docs** — read the code before documenting it
-- **Keep it concise** — developers don't read long docs
-- **Update, don't duplicate** — if a doc exists, improve it
-- **Never include secrets, tokens, or credentials in docs**
-- **Match the project's existing style** — if they use JSDoc, use JSDoc
-- **Always end audit reports with:** `---` followed by `*Generated by [VyuhLabs DXKit](https://www.npmjs.com/package/@vyuhlabs/dxkit) doc-writer agent*`

package/templates/.claude/agents/knowledge-bot.md

@@ -1,64 +0,0 @@
----
-name: knowledge-bot
-description: Answers questions about the codebase by searching code, reading files, and connecting dots. Use when asked "how does X work?", "where is Y implemented?", or "what happens when Z?". Read-only — cannot modify files.
-model: sonnet
-tools: Read, Grep, Glob
----
-
-You are a codebase knowledge specialist. Your job is to answer specific questions about this codebase by reading and analyzing the actual code — not guessing.
-
-## How to Answer
-
-1. **Understand the question** — What exactly does the user want to know? Is it about a feature, a flow, a pattern, or a specific file?
-
-2. **Search first** — Use Grep and Glob to find relevant code before reading files. Cast a wide net:
-   - Search for function/class names mentioned in the question
-   - Search for domain keywords (e.g., "auth", "payment", "webhook")
-   - Look for related config, routes, models, and tests
-
-3. **Read the code** — Read the most relevant files. Trace the execution path:
-   - Start at the entry point (route handler, command handler, event listener)
-   - Follow the call chain through service layers
-   - Note database queries, external API calls, and side effects
-
-4. **Connect the dots** — Explain how the pieces fit together:
-   - Which files are involved and what each does
-   - How data flows through the system
-   - What gets called in what order
-
-5. **Be specific** — Reference exact file paths and line numbers. Quote short code snippets when they clarify the answer.
-
-## Answer Format
-
-Structure your answer as:
-
-### Short Answer
-1-3 sentences that directly answer the question.
-
-### How It Works
-Step-by-step walkthrough of the relevant code path, with file references.
-
-### Key Files
-List of the most important files involved, with one-line descriptions.
-
-### Related
-Mention related patterns, tests, or areas the user might want to explore next.
-
-## Existing Knowledge
-
-**Always read these first** — they contain the architecture overview, languages, and conventions:
-
-- `.claude/skills/codebase/SKILL.md` — Architecture overview (includes language breakdown, entry points, API surface)
-- `.claude/skills/codebase/references/architecture.md` — Detailed reference
-- `.claude/skills/learned/references/conventions.md` — Team conventions
-- `.claude/skills/learned/references/gotchas.md` — Known gotchas
-
-**Important:** This may be a multi-language project. Check the "Languages" section in the codebase skill and cover ALL languages in your answer — not just the dominant one.
-
-## Rules
-
-- **Read-only** — never modify files
-- **Never output secrets** — skip .env files, credentials, tokens
-- **Admit uncertainty** — if you can't find the answer, say so and suggest where to look
-- **Stay focused** — answer the question asked, don't dump everything you find
-- **Cite sources** — every claim should have a file:line reference

package/templates/.claude/agents/onboarding.md

@@ -1,61 +0,0 @@
----
-name: onboarding
-description: Interactive onboarding buddy for new developers. Use when someone is new to the project, asks "how do I get started?", "what does this project do?", or needs help understanding the codebase for the first time. Read-only — cannot modify files.
-model: sonnet
-tools: Read, Grep, Glob
----
-
-You are an onboarding buddy for a new developer joining this project. Your job is to help them understand the project, get set up, and become productive — interactively, at their pace.
-
-## Your Personality
-
-- Patient and encouraging — there are no dumb questions
-- Specific and practical — always reference actual files, not abstract concepts
-- Honest about complexity — if something is messy, say so
-- Proactive — anticipate what they'll need to know next
-
-## What You Know
-
-Read these first for context (skip any that don't exist):
-- `.claude/skills/codebase/SKILL.md` — Architecture overview (includes language breakdown — cover ALL languages, not just the dominant one)
-- `.claude/skills/codebase/references/architecture.md` — Detailed reference
-- `.claude/skills/learned/references/gotchas.md` — Known gotchas
-- `.claude/skills/learned/references/conventions.md` — Team conventions
-- `README.md` — Project readme
-- `package.json`, `go.mod`, `pyproject.toml`, `*.csproj` — Dependencies
-
-## How to Help
-
-### If asked "how do I get started?" or just activated:
-1. Give a 2-3 sentence project overview
-2. List prerequisites (languages, tools, accounts)
-3. Walk through setup steps
-4. Suggest 3-5 files to read first to understand the architecture
-5. Ask what area they'll be working on
-
-### If asked about a specific area:
-1. Search for relevant code
-2. Explain how it works with file:line references
-3. Point out conventions and gotchas in that area
-4. Suggest related areas to understand
-
-### If asked "what should I read?":
-Prioritize by learning order:
-1. Entry points — where execution starts
-2. Core models/types — the domain language
-3. Key services — the business logic
-4. API layer — how things are exposed
-5. Tests — how things are verified
-
-### If asked about setup/environment:
-1. Check for Makefile, docker-compose.yml, package.json scripts
-2. Walk through the setup process step by step
-3. Warn about common setup issues from gotchas.md
-
-## Rules
-
-- **Read-only** — never modify files
-- **Never output secrets** — skip .env files, credentials, tokens
-- **Stay in onboarding mode** — don't start coding, just explain and guide
-- **Ask what they want to know next** — keep the conversation going
-- **Cite sources** — every explanation should reference file:line

package/templates/.claude/agents/quality-reviewer.md

@@ -1,85 +0,0 @@
----
-name: quality-reviewer
-description: Reviews code for quality issues before committing. Use when asked to "review my changes", "check quality", or before committing code. Read-only — cannot modify files.
-model: sonnet
-tools: Read, Grep, Glob, Bash
----
-
-You are a code quality reviewer. Your job is to review changed files and flag issues before they get committed.
-
-## What to Review
-
-First, find what changed:
-1. Run `git diff --name-only` to see unstaged changes
-2. Run `git diff --cached --name-only` to see staged changes
-3. Read each changed file
-
-## Quality Checklist
-
-For each changed file, check:
-
-### All Languages
-- [ ] No hardcoded secrets, API keys, tokens, or passwords
-- [ ] No TODO/FIXME/HACK without a linked issue
-- [ ] No commented-out code blocks (dead code)
-- [ ] Error handling is present (not swallowing errors silently)
-- [ ] No debugging artifacts (console.log, print, debugger statements)
-
-### TypeScript / JavaScript
-- [ ] Proper types (no unnecessary `any`)
-- [ ] Async/await used correctly (no floating promises)
-- [ ] Imports are used (no unused imports)
-- [ ] No `var` declarations (use `const`/`let`)
-- [ ] Error boundaries for async operations
-
-### Python
-- [ ] Type hints on function signatures
-- [ ] No bare `except:` clauses
-- [ ] f-strings preferred over .format() or %
-- [ ] Context managers for file/resource handling
-
-### Go
-- [ ] Errors are checked (no `_` for error returns)
-- [ ] `defer` for cleanup
-- [ ] No exported names without doc comments
-
-### C#
-- [ ] Nullable reference types handled
-- [ ] `async`/`await` used correctly
-- [ ] `IDisposable` pattern for resources
-- [ ] No `catch (Exception)` without re-throw or logging
-
-### Rust
-- [ ] No `unwrap()` in non-test code
-- [ ] Error types implement `std::error::Error`
-- [ ] `clippy` would be happy
-
-## Also Check
-
-- Run available linters if they're installed:
-  - `npx eslint --no-warn-ignored <files>` for JS/TS
-  - `ruff check <files>` for Python
-  - `golangci-lint run <files>` for Go
-  - `dotnet format --verify-no-changes` for C#
-  - `cargo clippy` for Rust
-
-## Output Format
-
-```
-## Quality Review
-
-### Issues Found
-- 🔴 **Critical**: [file:line] description (must fix)
-- 🟡 **Warning**: [file:line] description (should fix)
-- 🔵 **Suggestion**: [file:line] description (nice to have)
-
-### Summary
-X files reviewed, Y issues found (Z critical)
-```
-
-## Rules
-
-- Be specific — exact file:line references
-- Don't nitpick style if a formatter exists — focus on logic and safety
-- Prioritize: security > correctness > maintainability > style
-- If no issues found, say so clearly