codeforge-dev 1.9.0 → 1.11.0

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/spec-review/SKILL.md

@@ -0,0 +1,229 @@
+---
+name: spec-review
+description: >-
+  This skill should be used when the user asks to "review the spec",
+  "check spec adherence", "verify implementation", "spec-review",
+  "does code match spec", "audit implementation", or needs a standalone
+  deep implementation review that reads the code and confirms full
+  adherence to a specification.
+version: 0.1.0
+---
+
+# Spec Implementation Review
+
+## Mental Model
+
+A spec is a contract — but contracts only matter if someone verifies them. `/spec-review` is the verification step: given a spec and the code that claims to implement it, does the code actually do what the spec says?
+
+This is a standalone, single-spec, deep implementation review. Unlike `/spec-check` (which audits metadata health across all specs without reading code) and unlike `/spec-build` Phase 4 (which is locked inside the build workflow), `/spec-review` can be invoked independently at any time after implementation exists.
+
+Use cases:
+
+- **Manual implementation** — you built a feature without `/spec-build` and want to verify the work before running `/spec-update`
+- **Post-change regression check** — re-verify after modifying an already-implemented feature
+- **Pre-release audit** — confirm a feature still matches its spec before shipping
+- **Onboarding verification** — check if what's in the code matches what the spec says
+
+```
+Lifecycle positioning:
+
+/spec-new → /spec-refine → implement (manually or via /spec-build) → /spec-review → /spec-update
+
+Or with /spec-build (which has its own Phase 4):
+/spec-new → /spec-refine → /spec-build (includes review) → done
+
+/spec-review is independent — usable at any time after implementation exists.
+```
+
+---
+
+## Relationship to Other Skills
+
+| Skill | What it does | How `/spec-review` differs |
+|-------|-------------|---------------------------|
+| `/spec-check` | Batch metadata audit (all specs, no code reading) | Single-spec deep code audit |
+| `/spec-build` Phase 4 | Same depth, but embedded in the build workflow | Standalone, invokable independently |
+| `/spec-update` | Updates spec metadata after implementation | `/spec-review` audits first, then recommends `/spec-update` |
+
+---
+
+## Spec Edits During Review
+
+`/spec-review` makes limited spec edits — just enough to record what it verified:
+
+- Upgrade `[ ]` or `[~]` → `[x]` for criteria verified by passing tests
+- Downgrade `[x]` → `[ ]` if a previously-verified criterion now fails (regression)
+- Add entries to `## Discrepancies` for gaps found
+- Update `## Key Files` if paths are stale (files moved/deleted/added)
+- Update `**Last Updated:**` date
+
+It does NOT change `**Status:**` or add `## Implementation Notes` — that's `/spec-update`'s job. Clear boundary: `/spec-review` verifies and records findings; `/spec-update` closes the loop.
+
+---
+
+## Workflow
+
+### Step 1: Discovery
+
+**Find the spec.** Match `$ARGUMENTS` (feature name or path) against:
+
+```
+Glob: .specs/**/*.md
+```
+
+If ambiguous, list matching specs and ask which one to review.
+
+**Read the full spec.** Extract:
+
+- All FR-* and NFR-* requirements with their EARS-format text
+- All acceptance criteria with current markers (`[ ]`, `[~]`, `[x]`)
+- Key Files — every file path listed
+- Out of Scope — boundaries to respect
+- Discrepancies — any existing entries
+
+**Gate check.** `/spec-review` works on any spec with implementation to review:
+
+| Approval | Status | Action |
+|----------|--------|--------|
+| `user-approved` | `planned` | Proceed (reviewing work done against approved spec) |
+| `user-approved` | `partial` or `implemented` | Proceed (re-reviewing) |
+| `draft` | any | **Warn**: "This spec is `draft`. Requirements may not be validated. Consider running `/spec-refine` first. Proceed anyway?" |
+
+Unlike `/spec-build` which hard-blocks on `draft` (because it's about to write code), `/spec-review` is read-heavy — reviewing existing code against a draft spec is still useful, even if the spec itself isn't finalized.
+
+**Read every Key File.** Read all files listed in the spec's `## Key Files` section. These are the files the spec author identified as implementing the feature. Understanding them is prerequisite to the audit.
+
+---
+
+### Step 2: Requirement Coverage Audit
+
+Walk every FR-* and NFR-* requirement from the spec. Use the Spec Implementation Review Checklist at `spec-build/references/review-checklist.md` sections 4A and 4D as the authoritative guide.
+
+**For each FR-* requirement:**
+
+1. Identify the file(s) and function(s) that implement it
+2. Verify the implementation matches the EARS-format requirement text
+3. Confirm the requirement is fully addressed (not partially)
+4. Note if the requirement was met through a different approach than planned
+
+**For each NFR-* requirement:**
+
+1. Identify how the non-functional requirement is enforced
+2. Verify measurable NFRs have been tested or measured
+3. Confirm the NFR is met under expected conditions, not just ideal conditions
+
+**Cross-checks:**
+
+- Every FR-* has corresponding code — no requirements were skipped
+- Every NFR-* has corresponding enforcement — no hand-waving
+- No code was written that doesn't map to a requirement (scope creep check)
+- Out of Scope items from the spec were NOT implemented
+
+---
+
+### Step 3: Acceptance Criteria Verification
+
+For each acceptance criterion, locate or write the corresponding test. Use the Spec Implementation Review Checklist at `spec-build/references/review-checklist.md` sections 4B and 4C as the authoritative guide.
+
+**For each criterion:**
+
+1. Locate the corresponding test (unit, integration, or manual verification)
+2. If no test exists: **write one** — verification requires evidence, "no test exists" is not a valid review outcome
+3. Run the test
+4. If test passes → upgrade marker to `[x]` in the spec
+5. If test fails → note the failure, set marker to `[ ]`, document the issue
+
+**Summary checks:**
+
+- Count total criteria vs. verified `[x]` — report the ratio
+- Flag any criteria still `[ ]` (not started or regressed)
+- Flag any criteria that cannot be tested — document why and note as discrepancy
+- Verify tests actually test the criterion, not just exercise the code path
+
+**Code quality spot-check** per checklist section 4C:
+
+- Error handling at appropriate boundaries
+- No hardcoded values that should be configurable
+- Functions short and single-purpose
+- Nesting depth within limits
+- No regressions in existing tests
+
+---
+
+### Step 4: Report & Spec Updates
+
+#### Summary Report
+
+Present a structured report:
+
+```
+## Spec Implementation Review
+
+**Spec:** [feature name] ([spec file path])
+**Date:** YYYY-MM-DD
+**Reviewer:** /spec-review
+
+### Requirement Coverage
+- Functional: N/M addressed
+- Non-Functional: N/M addressed
+- Gaps: [list or "None"]
+
+### Acceptance Criteria
+- [x] Verified: N
+- [~] Implemented, pending: N
+- [ ] Not started / regressed: N
+- Failures: [list or "None"]
+
+### Code Quality
+- Issues found: [list or "None"]
+- Regressions: [list or "None"]
+
+### Spec Consistency
+- Key Files updates needed: [list or "None"]
+- Discrepancies: [list or "None"]
+
+### Recommendation
+[ ] All clear — run `/spec-update` to close the loop
+[ ] Fix issues first: [specific list]
+[ ] Requires user input: [specific questions]
+```
+
+#### Spec Edits
+
+Apply limited edits to the spec file:
+
+1. **Acceptance criteria markers** — update based on test results:
+   - Passed tests: upgrade `[ ]` or `[~]` → `[x]`
+   - Failed tests: downgrade `[x]` → `[ ]` (regression), keep `[ ]` or `[~]` as-is
+2. **Discrepancies** — add entries for any gaps found between spec and implementation
+3. **Key Files** — update paths if files moved, were deleted, or new files were created
+4. **Last Updated** — set to today's date
+
+Do NOT modify `**Status:**` or `## Implementation Notes` — those are `/spec-update`'s responsibility.
+
+#### Next Action
+
+Based on the review outcome, recommend:
+
+- **All clear**: "Run `/spec-update` to close the loop and mark the spec as implemented."
+- **Issues found**: "Fix the issues listed above, then re-run `/spec-review` to verify."
+- **User input needed**: Present specific questions and wait for direction.
+
+---
+
+## Ambiguity Policy
+
+- If `$ARGUMENTS` matches multiple specs, list them and ask which to review.
+- If a spec has no acceptance criteria, warn and offer to review requirements only.
+- If Key Files reference paths that don't exist, flag them as stale in the report and update the spec's Key Files section.
+- If the spec has no requirements section, warn that there's nothing to audit against and suggest running `/spec-new` or `/spec-update` to add requirements.
+- If all criteria are already `[x]`, still run the full review — regressions happen.
+
+---
+
+## Anti-Patterns
+
+- **Skipping test verification**: Marking criteria as `[x]` without running actual tests. Every `[x]` must be backed by a passing test or confirmed behavior.
+- **Reviewing without reading code**: The review must read the implementation files, not just check metadata. That's what `/spec-check` is for.
+- **Modifying implementation**: `/spec-review` is a review, not a fix. Report issues; don't fix them. The user decides what to do next.
+- **Changing spec status**: `/spec-review` records findings. `/spec-update` changes status. Respect the boundary.

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/spec-update/SKILL.md

@@ -18,6 +18,18 @@ This is not optional. Every implementation ends with a spec update.
 
 ---
 
+## Approval Gate
+
+Before performing an as-built update, check the spec's `**Approval:**` status:
+- If `user-approved` → proceed with the update
+- If `draft` → warn the user: "This spec is still `draft`. It should have gone through `/spec-refine` before implementation. Run `/spec-refine` now to validate, or proceed with the as-built update if the user confirms."
+
+This is a warning, not a blocker — the user decides whether to refine first or update as-is.
+
+For manually-implemented features (not using `/spec-build`), consider running `/spec-review` first to verify implementation adherence before updating the spec.
+
+---
+
 ## The 6-Step Workflow
 
 ### Step 1: Find the Spec
@@ -46,6 +58,7 @@ Review each acceptance criterion in the spec:
 - Mark as `[x]` if the criterion is met and verified (tests pass, behavior confirmed)
 - Leave as `[ ]` if not yet implemented
 - Add a note next to deferred criteria explaining why
+- If a criterion is marked `[~]` (implemented but not yet verified from a `/spec-build` run), treat it as `[ ]` — verify it now and upgrade to `[x]` if confirmed, or leave as `[ ]` if unverifiable
 
 If criteria were met through different means than originally planned, note the deviation.
 
@@ -71,7 +84,9 @@ Verify paths exist before listing them. Use absolute project-relative paths.
 ### Step 6: Update Metadata
 
 - Set `**Last Updated:**` to today's date (YYYY-MM-DD)
-- Verify `**Version:**` is correct
+- Verify `**Domain:**` is correct
+- Preserve the `**Approval:**` status — do NOT downgrade `user-approved` to `draft`
+- If the as-built update introduces new decisions not in the original spec, add them to `## Resolved Questions` if the user confirmed them, or `## Open Questions` if they were assumed during implementation
 
 ---
 
@@ -109,7 +124,11 @@ Before finishing the update:
 - [ ] Implementation Notes document deviations from original spec
 - [ ] File paths in Key Files are accurate and verified
 - [ ] Last Updated date is today
-- [ ] Spec is still ≤200 lines
+- [ ] `**Domain:**` is correct for the spec's location
+- [ ] `**Approval:**` status is preserved (not downgraded)
+- [ ] New implementation decisions are tracked in Resolved Questions or Open Questions
+- [ ] If the spec has grown past ~200 lines, note it and suggest splitting into separate specs in the domain folder
+- [ ] If `**Approval:**` is still `draft`, user was warned and confirmed proceeding
 - [ ] No source code was pasted inline (references only)
 
 ---
@@ -122,3 +141,6 @@ Before finishing the update:
   requirements to match what was built.
 - If acceptance criteria are ambiguous about whether they're met, note the
   ambiguity in Discrepancies rather than checking them off optimistically.
+- A spec-reminder advisory hook fires at Stop when code was modified but
+  specs weren't updated. If you see "[Spec Reminder]" in context, that's
+  the trigger — use this skill to resolve it.

package/.devcontainer/plugins/devs-marketplace/plugins/code-directive/skills/specification-writing/SKILL.md

@@ -30,11 +30,11 @@ Write specifications with a hostile reader in mind -- someone who will interpret
 
 ---
 
-## Spec Sizing & AI Context Rules
+## Spec Sizing Guidelines
 
 Specifications are loaded into AI context windows with limited capacity. Design for consumption.
 
-**Hard limit:** ≤200 lines per spec file. If a feature needs more, split into sub-specs (one per sub-feature) with a ≤50 line overview linking them.
+**Recommended target:** ~200 lines per spec file. When a spec grows beyond that, consider splitting into sub-specs (one per sub-feature) with a concise overview linking them. Complex features may justify longer specs — completeness matters more than hitting a number.
 
 **Reference, don't reproduce:** Never inline source code, SQL DDL, Pydantic models, or TypeScript interfaces. Reference the file path and line range instead. The code is the source of truth — duplicated snippets go stale silently.
 
@@ -176,12 +176,13 @@ Every spec file starts with metadata:
 
 ```
 # Feature: [Name]
-**Version:** v0.X.0
+**Domain:** [domain-name]
 **Status:** implemented | partial | planned
 **Last Updated:** YYYY-MM-DD
+**Approval:** draft | user-approved
 ```
 
-Status tells you whether to trust it, version tells you where it belongs, last-updated tells you when it was last verified.
+Status tells you whether to trust it, version tells you where it belongs, last-updated tells you when it was last verified. Approval tells you whether decisions in the spec have been explicitly validated by the user (`user-approved`) or are AI-generated hypotheses (`draft`).
 
 ### 1. Problem Statement
 What problem does this feature solve? Who has this problem? What's the cost of not solving it? (2-3 sentences)
@@ -218,20 +219,22 @@ so that [I can detect suspicious reset patterns].
 Use EARS format. Number each requirement for traceability:
 
 ```markdown
-- FR-1: When a user requests a password reset, the system shall send a reset email
+- FR-1 [assumed]: When a user requests a password reset, the system shall send a reset email
   to the registered email address within 60 seconds.
-- FR-2: The reset link shall contain a cryptographically random token (min 32 bytes).
-- FR-3: If the reset token is expired or already used, then the system shall display
+- FR-2 [assumed]: The reset link shall contain a cryptographically random token (min 32 bytes).
+- FR-3 [assumed]: If the reset token is expired or already used, then the system shall display
   an error message and offer to send a new reset email.
+
+Tag each requirement `[assumed]` when first written. Requirements become `[user-approved]` only after explicit user validation via `/spec-refine`.
 ```
 
 ### 5. Non-Functional Requirements
 Performance, security, scalability, accessibility:
 
 ```markdown
-- NFR-1: The password reset endpoint shall respond within 200ms (p95).
-- NFR-2: Reset tokens shall be stored as bcrypt hashes, not plaintext.
-- NFR-3: The reset flow shall be accessible with screen readers (WCAG 2.1 AA).
+- NFR-1 [assumed]: The password reset endpoint shall respond within 200ms (p95).
+- NFR-2 [assumed]: Reset tokens shall be stored as bcrypt hashes, not plaintext.
+- NFR-3 [assumed]: The reset flow shall be accessible with screen readers (WCAG 2.1 AA).
 ```
 
 ### 6. Edge Cases
@@ -249,13 +252,16 @@ The cases nobody thinks about until they happen:
 ### 7. Out of Scope
 Explicit non-goals to prevent scope creep (can reference the Scope section or expand here).
 
-### 8. Key Files
+### 8. Resolved Questions
+Decisions explicitly approved by the user via `/spec-refine`. Each entry: decision topic, chosen option, options considered, date, brief rationale. This section starts empty and is populated during the refinement process.
+
+### 9. Key Files
 Source files most relevant to this feature — paths an implementer should read.
 
-### 9. Implementation Notes
+### 10. Implementation Notes
 Post-implementation only. Capture deviations from the original spec — what changed and why.
 
-### 10. Discrepancies
+### 11. Discrepancies
 Gaps between spec intent and actual build. Prevents the next session from re-planning decided work.
 
 ---
@@ -309,6 +315,7 @@ These defaults apply when the user does not specify a preference. State the assu
 - **Edge cases:** Always include at least: empty input, maximum input, concurrent access, and external service failure.
 - **Out of scope:** Always include an out-of-scope section, even if brief, to establish boundaries.
 - **Numbering:** Number all requirements (FR-1, NFR-1) for traceability in code reviews and tests.
+- **Approval markers:** All requirements start as `[assumed]`. Only `/spec-refine` with explicit user validation upgrades them to `[user-approved]`. Spec-level `**Approval:**` starts as `draft` and becomes `user-approved` only when all requirements are `[user-approved]`.
 
 ---
 

package/.devcontainer/plugins/devs-marketplace/plugins/codeforge-lsp/.claude-plugin/plugin.json

@@ -1,7 +1,40 @@
 {
-  "name": "codeforge-lsp",
-  "description": "LSP servers for CodeForge (Python, TypeScript, Go)",
-  "author": {
-    "name": "AnExiledDev"
-  }
+	"name": "codeforge-lsp",
+	"description": "LSP servers for CodeForge (Python, TypeScript, Go)",
+	"author": {
+		"name": "AnExiledDev"
+	},
+	"lspServers": {
+		"pyright": {
+			"command": "pyright-langserver",
+			"args": ["--stdio"],
+			"extensionToLanguage": {
+				".py": "python",
+				".pyi": "python"
+			}
+		},
+		"typescript": {
+			"command": "typescript-language-server",
+			"args": ["--stdio"],
+			"extensionToLanguage": {
+				".ts": "typescript",
+				".tsx": "typescriptreact",
+				".js": "javascript",
+				".jsx": "javascriptreact",
+				".mts": "typescript",
+				".cts": "typescript",
+				".mjs": "javascript",
+				".cjs": "javascript"
+			}
+		},
+		"gopls": {
+			"command": "gopls",
+			"args": ["serve"],
+			"extensionToLanguage": {
+				".go": "go",
+				".mod": "go.mod",
+				".sum": "go.sum"
+			}
+		}
+	}
 }

package/.devcontainer/plugins/devs-marketplace/plugins/workspace-scope-guard/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+	"name": "workspace-scope-guard",
+	"description": "Enforces working directory scope — blocks writes and warns on reads outside the project",
+	"author": {
+		"name": "AnExiledDev"
+	}
+}

package/.devcontainer/plugins/devs-marketplace/plugins/workspace-scope-guard/hooks/hooks.json

@@ -0,0 +1,17 @@
+{
+	"description": "Enforce workspace scope for file operations",
+	"hooks": {
+		"PreToolUse": [
+			{
+				"matcher": "Read|Write|Edit|NotebookEdit|Glob|Grep",
+				"hooks": [
+					{
+						"type": "command",
+						"command": "python3 ${CLAUDE_PLUGIN_ROOT}/scripts/guard-workspace-scope.py",
+						"timeout": 5
+					}
+				]
+			}
+		]
+	}
+}

package/.devcontainer/plugins/devs-marketplace/plugins/workspace-scope-guard/scripts/guard-workspace-scope.py

@@ -0,0 +1,132 @@
+#!/usr/bin/env python3
+"""
+Enforce workspace scope for file operations.
+
+Blocks write operations (Write, Edit, NotebookEdit) to files outside the
+current working directory. Warns on read operations (Read, Glob, Grep)
+outside the working directory. Allows unrestricted access when cwd is
+/workspaces (the workspace root).
+
+Exit code 2 blocks the operation with an error message.
+Exit code 0 allows the operation to proceed (with optional warning context).
+"""
+
+import json
+import os
+import sys
+
+# Paths that are always allowed regardless of working directory
+ALLOWED_PREFIXES = [
+    "/workspaces/.claude/",
+    "/workspaces/.tmp/",
+    "/workspaces/.devcontainer/",
+    "/tmp/",
+    "/home/",
+]
+
+WRITE_TOOLS = {"Write", "Edit", "NotebookEdit"}
+READ_TOOLS = {"Read", "Glob", "Grep"}
+
+# Tool input field that contains the target path
+PATH_FIELDS = {
+    "Read": "file_path",
+    "Write": "file_path",
+    "Edit": "file_path",
+    "NotebookEdit": "notebook_path",
+    "Glob": "path",
+    "Grep": "path",
+}
+
+
+def get_target_path(tool_name: str, tool_input: dict) -> str | None:
+    """Extract the target path from tool input.
+
+    Returns None if no path field is present or the field is empty,
+    which means the tool defaults to cwd (always in scope).
+    """
+    field = PATH_FIELDS.get(tool_name)
+    if not field:
+        return None
+    return tool_input.get(field) or None
+
+
+def is_in_scope(resolved_path: str, cwd: str) -> bool:
+    """Check if resolved_path is within the working directory."""
+    cwd_prefix = cwd if cwd.endswith("/") else cwd + "/"
+    return resolved_path == cwd or resolved_path.startswith(cwd_prefix)
+
+
+def is_allowlisted(resolved_path: str) -> bool:
+    """Check if resolved_path falls under an allowed prefix."""
+    return any(resolved_path.startswith(prefix) for prefix in ALLOWED_PREFIXES)
+
+
+def main():
+    try:
+        input_data = json.load(sys.stdin)
+        tool_name = input_data.get("tool_name", "")
+        tool_input = input_data.get("tool_input", {})
+
+        cwd = os.getcwd()
+
+        # Unrestricted when working from the workspace root
+        if cwd == "/workspaces":
+            sys.exit(0)
+
+        target_path = get_target_path(tool_name, tool_input)
+
+        # No path specified — tool defaults to cwd, which is in scope
+        if target_path is None:
+            sys.exit(0)
+
+        resolved = os.path.realpath(target_path)
+
+        if is_in_scope(resolved, cwd):
+            sys.exit(0)
+
+        if is_allowlisted(resolved):
+            sys.exit(0)
+
+        # Out of scope
+        if tool_name in WRITE_TOOLS:
+            print(
+                json.dumps(
+                    {
+                        "error": (
+                            f"Blocked: {tool_name} targets '{target_path}' which is "
+                            f"outside the working directory ({cwd}). Move to that "
+                            f"project's directory first or work from /workspaces."
+                        )
+                    }
+                )
+            )
+            sys.exit(2)
+
+        if tool_name in READ_TOOLS:
+            print(
+                json.dumps(
+                    {
+                        "additionalContext": (
+                            f"Warning: {tool_name} targets '{target_path}' which is "
+                            f"outside the working directory ({cwd}). This read is "
+                            f"allowed but may indicate unintended cross-project access."
+                        )
+                    }
+                )
+            )
+            sys.exit(0)
+
+        # Unknown tool — allow by default
+        sys.exit(0)
+
+    except json.JSONDecodeError:
+        # Can't parse input — allow by default
+        sys.exit(0)
+    except Exception as e:
+        # Don't block on hook failure
+        print(f"Hook error: {e}", file=sys.stderr)
+        sys.exit(0)
+
+
+if __name__ == "__main__":
+    main()

package/.devcontainer/scripts/check-setup.sh

@@ -5,34 +5,37 @@
 echo "CodeForge Setup Check"
 echo "━━━━━━━━━━━━━━━━━━━━"
 
-PASS=0; FAIL=0; WARN=0
+PASS=0
+FAIL=0
+WARN=0
 
 check() {
-    local label="$1" cmd="$2"
-    if eval "$cmd" >/dev/null 2>&1; then
-        printf "  ✓ %s\n" "$label"
-        PASS=$((PASS + 1))
-    else
-        printf "  ✗ %s\n" "$label"
-        FAIL=$((FAIL + 1))
-    fi
+	local label="$1" cmd="$2"
+	if eval "$cmd" >/dev/null 2>&1; then
+		printf "  ✓ %s\n" "$label"
+		PASS=$((PASS + 1))
+	else
+		printf "  ✗ %s\n" "$label"
+		FAIL=$((FAIL + 1))
+	fi
 }
 
 warn_check() {
-    local label="$1" cmd="$2"
-    if eval "$cmd" >/dev/null 2>&1; then
-        printf "  ✓ %s\n" "$label"
-        PASS=$((PASS + 1))
-    else
-        printf "  ⚠ %s\n" "$label"
-        WARN=$((WARN + 1))
-    fi
+	local label="$1" cmd="$2"
+	if eval "$cmd" >/dev/null 2>&1; then
+		printf "  ✓ %s\n" "$label"
+		PASS=$((PASS + 1))
+	else
+		printf "  ⚠ %s\n" "$label"
+		WARN=$((WARN + 1))
+	fi
 }
 
 echo ""
 echo "Core:"
 check "Claude Code installed" "command -v claude"
-check "cc alias available" "type cc"
+warn_check "Claude native binary" "[ -x /usr/local/bin/claude ]"
+check "cc alias configured" "grep -q 'alias cc=' ~/.bashrc 2>/dev/null || grep -q 'alias cc=' ~/.zshrc 2>/dev/null"
 check "Config directory exists" "[ -d '${CLAUDE_CONFIG_DIR:-/workspaces/.claude}' ]"
 check "Settings file exists" "[ -f '${CLAUDE_CONFIG_DIR:-/workspaces/.claude}/settings.json' ]"
 
@@ -54,10 +57,6 @@ echo ""
 echo "Development:"
 warn_check "biome" "command -v biome"
 warn_check "ruff" "command -v ruff"
-warn_check "dprint" "command -v dprint"
-warn_check "shfmt" "command -v shfmt"
-warn_check "shellcheck" "command -v shellcheck"
-warn_check "hadolint" "command -v hadolint"
 warn_check "ast-grep" "command -v ast-grep"
 warn_check "tmux" "command -v tmux"
 
@@ -66,7 +65,7 @@ echo "━━━━━━━━━━━━━━━━━━━━"
 echo "  $PASS passed, $FAIL failed, $WARN warnings"
 
 if [ $FAIL -gt 0 ]; then
-    echo ""
-    echo "  Run 'cc-tools' for detailed version info."
-    exit 1
+	echo ""
+	echo "  Run 'cc-tools' for detailed version info."
+	exit 1
 fi