claude-dev-env 2.14.0 → 2.14.1

package/commands/hook-log-init.md

@@ -1,76 +0,0 @@
----
-description: Initialize the Neon schema used by the hook-log extractor
-allowed-tools: Bash
----
-
-Initialize the Neon Postgres schema that backs the hook-log diagnostic
-extractor. Run this once per new machine, or after rotating the Neon
-project, before the Stop hook begins inserting rows.
-
-## Prerequisites
-
-One-time setup on each machine:
-
-1. **Install the Bitwarden Secret Manager CLI** so the `bws` command is on PATH.
-   See https://bitwarden.com/help/secrets-manager-cli/ for platform-specific instructions.
-
-2. **Create a Bitwarden machine account** scoped to the Neon connection
-   secret, generate its access token, and export it to the current user
-   environment.
-
-   On Windows (PowerShell):
-
-   ```powershell
-   setx BWS_ACCESS_TOKEN "<machine-account-access-token>"
-   ```
-
-   Open a new terminal so the variable takes effect.
-
-   On macOS or Linux (bash/zsh — add to `~/.bashrc`, `~/.zshrc`, or the
-   equivalent profile so new shells inherit it):
-
-   ```bash
-   export BWS_ACCESS_TOKEN="<machine-account-access-token>"
-   ```
-
-3. **Store the Neon connection string** in the Bitwarden Secrets Manager
-   under the key `NEON_HOOK_LOGS_DATABASE_URL`. The value is the full
-   `postgres://user:password@host/database?sslmode=require` URL that
-   Neon provides on the project dashboard.
-
-4. **Install the Python dependencies** so the extractor can reach Neon.
-   Production runtime:
-
-   ```
-   pip install -r packages/claude-dev-env/hooks/diagnostic/requirements-hook-logs.txt
-   ```
-
-   Development (adds `pytest` on top of the runtime deps):
-
-   ```
-   pip install -r packages/claude-dev-env/hooks/diagnostic/requirements-hook-logs-dev.txt
-   ```
-
-## Run the init
-
-```
-bws run -- python packages/claude-dev-env/hooks/diagnostic/hook_log_init.py
-```
-
-The init script performs these steps in order:
-
-1. Verifies `NEON_HOOK_LOGS_DATABASE_URL` is set. `BWS_ACCESS_TOKEN` is
-   consumed by the outer `bws` CLI before it spawns the Python child
-   process; `bws run` intentionally strips it from the child
-   environment to prevent subprocess credential leakage, so the Python
-   script never sees it.
-2. Connects to Neon with a 5-second timeout.
-3. Applies the DDL in `packages/claude-dev-env/hooks/diagnostic/schema.sql`
-   using `CREATE TABLE IF NOT EXISTS`, `CREATE INDEX IF NOT EXISTS`, and
-   `CREATE OR REPLACE VIEW` so the script stays idempotent.
-4. Inserts a sentinel row with `outcome = 'init_probe'`, selects it back,
-   and deletes it to confirm read-write parity.
-5. Prints a success report showing the Neon host, table name, and row count.
-
-A missing environment variable exits with status 1 and lists the
-missing name on stderr; any other failure surfaces the psycopg exception.

package/commands/implement.md

@@ -1,102 +0,0 @@
----
-description: Provide full implementation context to right-sized engineer in XML format
-allowed-tools: Task, Read, Grep, Glob
----
-
-**Implementation with Full Context - XML-Structured Guidance**
-
-Launch a clean-coder agent — `model: sonnet`, worker-model routing per [`skills/orchestrator/SKILL.md`](../skills/orchestrator/SKILL.md#workflow-agent-routing); resolver-supplied sonnet-equivalent on third-party hosts — with COMPREHENSIVE implementation context provided in structured XML format.
-
-## Process:
-
-1. **Gather Complete Context** - Analyze the codebase to understand:
-   - Existing patterns and conventions
-   - Available dependencies and libraries
-   - Testing approaches and frameworks
-   - File organization and naming conventions
-
-2. **Structure the Implementation Request in XML**:
-   ```xml
-   <implementation-context>
-     <requirements>
-       <user-request>Exact user requirements</user-request>
-       <acceptance-criteria>What defines success</acceptance-criteria>
-       <constraints>Any limitations or must-haves</constraints>
-     </requirements>
-
-     <project-context>
-       <codebase-patterns>
-         <pattern>Existing patterns found in codebase</pattern>
-         <conventions>Naming and style conventions observed</conventions>
-         <architecture>Current architectural approach</architecture>
-       </codebase-patterns>
-       <dependencies>
-         <available>List of available libraries/frameworks</available>
-         <avoid>Libraries NOT to use</avoid>
-       </dependencies>
-       <testing-approach>
-         <framework>Testing framework in use</framework>
-         <patterns>Test file patterns and locations</patterns>
-       </testing-approach>
-     </project-context>
-
-     <implementation-plan>
-       <approach>High-level approach to implementation</approach>
-       <steps>
-         <step priority="1">First implementation step</step>
-         <step priority="2">Second implementation step</step>
-         <!-- Additional steps as needed -->
-       </steps>
-       <test-strategy>
-         <tdd-requirement>MANDATORY: Write failing tests first</tdd-requirement>
-         <coverage>Expected test coverage approach</coverage>
-       </test-strategy>
-     </implementation-plan>
-
-     <engineering-principles>
-       <must-follow>
-         <principle>TDD - No production code without failing test</principle>
-         <principle>Follow existing patterns exactly</principle>
-         <principle>Use available utilities - no reinventing</principle>
-         <principle>Small, focused functions</principle>
-         <principle>Proper error handling</principle>
-       </must-follow>
-       <avoid>
-         <anti-pattern>Over-engineering for current scale</anti-pattern>
-         <anti-pattern>Breaking existing conventions</anti-pattern>
-         <anti-pattern>Copy-paste programming</anti-pattern>
-         <anti-pattern>Magic numbers/strings</anti-pattern>
-       </avoid>
-     </engineering-principles>
-
-     <success-criteria>
-       <criterion>All tests pass</criterion>
-       <criterion>Follows existing patterns</criterion>
-       <criterion>No linting/type errors</criterion>
-       <criterion>Maintains backward compatibility</criterion>
-     </success-criteria>
-   </implementation-context>
-   ```
-
-3. **Provide to Agent with Clear Instructions**:
-   - "ULTRATHINK through this implementation"
-   - "Follow TDD strictly - write tests FIRST"
-   - "Match existing patterns EXACTLY"
-   - "Use the XML context to understand all requirements and constraints"
-
-4. **Agent Should**:
-   - Parse the XML context thoroughly
-   - Implement following TDD (Red-Green-Refactor)
-   - Match existing codebase patterns
-   - Use available utilities and libraries
-   - Apply right-sized engineering principles
-   - Validate against success criteria
-
-**CRITICAL REQUIREMENTS**:
-- Provide COMPLETE context - incomplete context leads to wrong implementations
-- Ensure XML is well-formed and comprehensive
-- Include concrete examples from existing code
-- Specify exact file locations and patterns
-- Make constraints and requirements crystal clear
-
-This ensures the implementation agent has everything needed to deliver a solution that integrates seamlessly with the existing codebase while following best practices.

package/commands/plan.md

@@ -1,14 +0,0 @@
-Plan a feature through the workflow-backed `anthropic-plan` skill.
-
-Invoke `anthropic-plan` with the user request. The skill launches the Claude Code Workflow at:
-
-`$HOME/.claude/skills/anthropic-plan/workflow/plan-packet.mjs`
-
-The workflow creates a validated `docs/plans/<slug>/` packet, spawns the fresh `plan-packet-validator` agent, repairs packet findings, and stops before implementation.
-
-Usage:
-
-```text
-/plan add user authentication
-/plan refactor the payment system
-```

package/commands/pr-comments.md

@@ -1,47 +0,0 @@
----
-description: Fetch and display all comments from a GitHub PR (fetches comments from the current repo)
----
-
-You are an AI assistant integrated into a git-based version control system. Your task is to fetch and display comments from a GitHub pull request.
-
-**CRITICAL: Detect the repository from the current git remote (upstream preferred, then origin).**
-
-Follow these steps:
-
-1. Detect `{owner}/{repo}` from `gh repo view --json nameWithOwner -q .nameWithOwner`
-2. Extract PR number from the argument (e.g., "PR44" → 44, "44" → 44)
-3. Use `gh api repos/{owner}/{repo}/issues/{number}/comments` to get PR-level comments
-4. Use `gh api repos/{owner}/{repo}/pulls/{number}/comments` to get inline review comments
-5. Use `gh api repos/{owner}/{repo}/pulls/{number}/reviews` to get review summaries
-6. Parse and format all comments in chronological order
-7. Return ONLY the formatted comments, with no additional text
-
-Format the comments as:
-
-## Comments
-
-### PR-level Comments
-
-[For each issue comment:]
-- @author (timestamp):
-  > quoted comment text
-
-### Review: @reviewer [action] (timestamp)
-
-[Review summary if present]
-
-[For each inline code comment:]
-- @author file.ts#line:
-  ```diff
-  [diff_hunk from the API response]
-  ```
-  > quoted comment text
-
-If there are no comments, return "No comments found."
-
-Remember:
-1. Only show the actual comments, no explanatory text
-2. Include PR-level comments, review summaries, and inline code review comments
-3. Preserve chronological order
-4. Show the file and line number context for inline code review comments
-5. Detect {owner}/{repo} dynamically from the current git remote

package/commands/review-plan.md

@@ -1,5 +0,0 @@
-Review the current plan against code standards.
-
-1. Identify plan files in `.planning/phases/` or `docs/plans/`
-2. Review the plan against CODE_RULES.md standards
-3. Report the verdict back to the user

package/commands/right-size.md

@@ -1,15 +0,0 @@
----
-description: Prevent over/under-engineering
-allowed-tools: Task
----
-
-Launch the clean-coder agent — `model: sonnet`, worker-model routing per [`skills/orchestrator/SKILL.md`](../skills/orchestrator/SKILL.md#workflow-agent-routing); resolver-supplied sonnet-equivalent on third-party hosts — to review code for appropriate engineering practices.
-
-The agent will evaluate whether abstractions, patterns, and practices match the actual needs of the project, ensuring code is neither over-engineered nor under-engineered for its current scale and purpose.
-
-The review will identify:
-- **Over-engineering**: Abstract classes with single implementations, unnecessary interfaces, complex patterns where simple functions would suffice
-- **Under-engineering**: Hardcoded values, magic numbers/strings, copy-pasted code, missing error handling
-- **Good examples**: Appropriate constant extraction, well-scoped functions, clear error handling, simple maintainable solutions
-
-The goal is to build it right, but build it simple - applying good engineering principles at the appropriate scale for the project.

package/commands/sum.md

@@ -1,30 +0,0 @@
----
-name: sum
-description: Generate a formatted session summary for quick pickup in new sessions
----
-
-Provide a nicely formatted summary of where we are leaving off in this session.
-
-Use this format with proper line breaks:
-
-```
----
-
-**Session Summary: [Project/Task Name]**
-
-**Status:** [Current state - e.g., Complete, In Progress, Blocked]
-
-**Commits:** (if any)
-- `hash` - Description
-
-**What's Done:**
-- Item 1
-- Item 2
-
-**Next Step:**
-[Single clear next action]
-
----
-```
-
-Keep it concise but readable. Focus on actionable context, not history.