cokit-cli 1.3.0 → 1.4.0

package/skills/security/SKILL.md

@@ -1,139 +0,0 @@
----
-name: security
-description: "STRIDE + OWASP-based security audit with optional auto-fix. Scans code for vulnerabilities, categorizes by severity, and can iteratively fix findings using ck:autoresearch pattern."
-argument-hint: "<scope glob or 'full'> [--fix] [--iterations N]"
----
-
-# ck:security — Security Audit
-
-Runs a structured STRIDE + OWASP security audit on a given scope. Produces a severity-ranked findings report. With `--fix`, applies fixes iteratively using the ck:autoresearch guard pattern.
-
-## When to Use
-
-- Before a release or major deployment
-- After adding auth, payment, or data-handling features
-- Periodic security review (monthly/quarterly)
-- Compliance check (SOC 2, GDPR, PCI-DSS prep)
-
-## When NOT to Use
-
-- Purely cosmetic changes (CSS, copy edits)
-- No user-facing code or data handling involved
-
----
-
-## Modes
-
-| Mode | Invocation | Behavior |
-|------|-----------|----------|
-| Audit only | `/ck-security <scope>` | Scan → categorize → report |
-| Audit + Fix | `/ck-security <scope> --fix` | Scan → categorize → fix iteratively |
-| Bounded fix | `/ck-security <scope> --fix --iterations N` | Limit fix iterations to N |
-
----
-
-## Audit Methodology
-
-### 1. Scope Resolution
-Expand the provided glob or `full` keyword into a file list. Read all in-scope files before analysis.
-
-### 2. STRIDE Analysis
-Evaluate each threat category systematically:
-- **S**poofing — identity/authentication weaknesses
-- **T**ampering — input validation, integrity controls
-- **R**epudiation — audit logging gaps
-- **I**nformation Disclosure — data leakage, secret exposure
-- **D**enial of Service — rate limits, resource exhaustion
-- **E**levation of Privilege — broken access control, RBAC gaps
-
-### 3. OWASP Top 10 Check
-Map findings to OWASP categories (A01–A10). See `references/stride-owasp-checklist.md` for per-category checks.
-
-### 4. Dependency Audit
-Run the appropriate package audit tool for the detected stack:
-- Node.js: `npm audit`
-- Python: `pip-audit`
-- Go: `govulncheck`
-- Ruby: `bundle audit`
-
-### 5. Secret Detection
-Scan for hardcoded API keys, passwords, tokens, and private keys using regex patterns. See `references/stride-owasp-checklist.md` → Secret Patterns.
-
-### 6. Finding Categorization
-Assign each finding a severity level (see Severity Definitions below).
-
----
-
-## Output Format
-
-```
-## Security Audit Report
-
-### Summary
-- Files scanned: N
-- Findings: X critical, Y high, Z medium, W low, V info
-
-### Findings
-
-| # | Severity | Category | File:Line | Description | Fix Recommendation |
-|---|----------|----------|-----------|-------------|-------------------|
-| 1 | Critical  | Injection | api/users.ts:45 | SQL string concatenation | Use parameterized queries |
-| 2 | High      | Auth      | auth/login.ts:12 | No rate limiting | Add express-rate-limit |
-```
-
----
-
-## Fix Mode (--fix)
-
-When `--fix` is provided, apply fixes iteratively after the audit:
-
-1. Sort all findings by severity (Critical → High → Medium → Low)
-2. For each finding:
-   a. Apply one targeted fix
-   b. Run guard (tests or lint) to verify no regression
-   c. Commit: `security(fix-N): <short description>`
-   d. Advance to next finding
-3. Stop early if guard fails — report the failure instead of proceeding
-4. Uses `autoresearch` guard pattern for regression prevention
-
-> Tip: Use `--iterations N` to cap total fix iterations when scope is large.
-
----
-
-## Severity Definitions
-
-| Severity | Description | Fix Priority |
-|----------|-------------|-------------|
-| Critical | Exploitable now, data breach or RCE risk | Immediate — block release |
-| High | Exploitable with moderate effort, significant impact | This sprint |
-| Medium | Limited exploitability or impact | Next sprint |
-| Low | Theoretical risk, defense-in-depth improvement | Backlog |
-| Info | Best practice suggestion, no direct risk | Optional |
-
----
-
-## Integration with Other Skills
-
-- Run after `predict` when the security persona flags concerns
-- Feed Critical/High findings into `ck:autoresearch --fix` for automated remediation
-- Use `scenario` with `--focus authorization` for deeper auth flow testing
-- Pair with `plan` to schedule Medium/Low findings as sprint tasks
-
----
-
-## Example Invocations
-
-```bash
-# Audit API layer only
-/ck-security src/api/**/*.ts
-
-# Audit entire src/ and auto-fix, max 15 iterations
-/ck-security src/ --fix --iterations 15
-
-# Full codebase audit (no fix)
-/ck-security full
-```
-
----
-
-See `references/stride-owasp-checklist.md` for the detailed per-category checklist and secret detection regex patterns.

package/skills/sequential-thinking/SKILL.md

@@ -1,94 +0,0 @@
----
-name: sequential-thinking
-description: Apply step-by-step analysis for complex problems with revision capability. Use for multi-step reasoning, hypothesis verification, adaptive planning, problem decomposition, course correction.
-license: MIT
-argument-hint: "[problem to analyze step-by-step]"
----
-
-# Sequential Thinking
-
-Structured problem-solving via manageable, reflective thought sequences with dynamic adjustment.
-
-## When to Apply
-
-- Complex problem decomposition
-- Adaptive planning with revision capability
-- Analysis needing course correction
-- Problems with unclear/emerging scope
-- Multi-step solutions requiring context maintenance
-- Hypothesis-driven investigation/debugging
-
-## Core Process
-
-### 1. Start with Loose Estimate
-```
-Thought 1/5: [Initial analysis]
-```
-Adjust dynamically as understanding evolves.
-
-### 2. Structure Each Thought
-- Build on previous context explicitly
-- Address one aspect per thought
-- State assumptions, uncertainties, realizations
-- Signal what next thought should address
-
-### 3. Apply Dynamic Adjustment
-- **Expand**: More complexity discovered → increase total
-- **Contract**: Simpler than expected → decrease total
-- **Revise**: New insight invalidates previous → mark revision
-- **Branch**: Multiple approaches → explore alternatives
-
-### 4. Use Revision When Needed
-```
-Thought 5/8 [REVISION of Thought 2]: [Corrected understanding]
-- Original: [What was stated]
-- Why revised: [New insight]
-- Impact: [What changes]
-```
-
-### 5. Branch for Alternatives
-```
-Thought 4/7 [BRANCH A from Thought 2]: [Approach A]
-Thought 4/7 [BRANCH B from Thought 2]: [Approach B]
-```
-Compare explicitly, converge with decision rationale.
-
-### 6. Generate & Verify Hypotheses
-```
-Thought 6/9 [HYPOTHESIS]: [Proposed solution]
-Thought 7/9 [VERIFICATION]: [Test results]
-```
-Iterate until hypothesis verified.
-
-### 7. Complete Only When Ready
-Mark final: `Thought N/N [FINAL]`
-
-Complete when:
-- Solution verified
-- All critical aspects addressed
-- Confidence achieved
-- No outstanding uncertainties
-
-## Application Modes
-
-**Explicit**: Use visible thought markers when complexity warrants visible reasoning or user requests breakdown.
-
-**Implicit**: Apply methodology internally for routine problem-solving where thinking aids accuracy without cluttering response.
-
-## Scripts (Optional)
-
-Optional scripts for deterministic validation/tracking:
-- `scripts/process-thought.js` - Validate & track thoughts with history
-- `scripts/format-thought.js` - Format for display (box/markdown/simple)
-
-See README.md for usage examples. Use when validation/persistence needed; otherwise apply methodology directly.
-
-## References
-
-Load when deeper understanding needed:
-- `references/core-patterns.md` - Revision & branching patterns
-- `references/examples-api.md` - API design example
-- `references/examples-debug.md` - Debugging example
-- `references/examples-architecture.md` - Architecture decision example
-- `references/advanced-techniques.md` - Spiral refinement, hypothesis testing, convergence
-- `references/advanced-strategies.md` - Uncertainty, revision cascades, meta-thinking

package/skills/ship/SKILL.md

@@ -1,116 +0,0 @@
----
-name: ship
-description: "Ship pipeline: merge main, test, review, commit, push, PR. Single command from feature branch to PR URL. Use for shipping official releases to main/master or beta releases to dev/beta branches."
-argument-hint: "[official|beta] [--skip-tests] [--skip-review] [--skip-journal] [--skip-docs] [--dry-run]"
-license: MIT
----
-
-# Ship: Unified Ship Pipeline
-
-Single command to ship a feature branch. Fully automated — only stops for test failures, critical review issues, or major version bumps.
-
-**Inspired by:** gstack `/ship` by Garry Tan. Adapted for framework-agnostic, multi-language support.
-
-## Arguments
-
-| Flag | Effect |
-|------|--------|
-| `official` | Ship to default branch (main/master). Full pipeline with docs + journal |
-| `beta` | Ship to dev/beta branch. Lighter pipeline, skip docs update |
-| (none) | Auto-detect: if base branch is main/master → official, else → beta |
-| `--skip-tests` | Skip test step (use when tests already passed) |
-| `--skip-review` | Skip pre-landing review step |
-| `--skip-journal` | Skip journal writing step |
-| `--skip-docs` | Skip docs update step |
-| `--dry-run` | Show what would happen without executing |
-
-## Ship Mode Detection
-
-```
-If argument = "official" → target = main/master (auto-detect default branch)
-If argument = "beta"     → target = dev/beta (auto-detect dev branch)
-If no argument           → infer from current branch naming:
-  - feature/* hotfix/* bugfix/* → official (target main)
-  - dev/* beta/* experiment/*  → beta (target dev/beta)
-  - unclear                    → asking the user
-```
-
-## When to Stop (blocking)
-
-- On target branch already → abort
-- Merge conflicts that can't be auto-resolved → stop, show conflicts
-- Test failures → stop, show failures
-- Critical review issues → asking the user per issue
-- Major/minor version bump needed → asking the user
-
-## When NOT to Stop
-
-- Uncommitted changes → always include them
-- Patch version bump → auto-decide
-- Changelog content → auto-generate
-- Commit message → auto-compose
-- No version file → skip version step silently
-- No changelog → skip changelog step silently
-
-## Pipeline
-
-```
-Step 1:  Pre-flight      → Branch check, mode detection, status, diff analysis
-Step 2:  Link Issues      → Find/create related GitHub issues
-Step 3:  Merge target     → Fetch + merge origin/<target-branch>
-Step 4:  Run tests        → Auto-detect test runner, run, check results
-Step 5:  Review           → Two-pass checklist review (critical + informational)
-Step 6:  Version bump     → Auto-detect version file, bump patch/minor
-Step 7:  Changelog        → Auto-generate from commits + diff
-Step 8:  Journal          → Write technical journal via /ck-journal
-Step 9:  Docs update      → Update project docs via /ck-docs update (official only)
-Step 10: Commit           → Conventional commit with version/changelog
-Step 11: Push             → git push -u origin <branch>
-Step 12: Create PR        → gh pr create with structured body + linked issues
-```
-
-**Detailed steps:** Load `references/ship-workflow.md`
-**Auto-detection:** Load `references/auto-detect.md`
-**PR template:** Load `references/pr-template.md`
-
-## Token Efficiency Rules
-
-- Steps 4 (tests) and 5 (review): delegate to `tester` and `code-reviewer` subagents — don't inline
-- Steps 8 (journal) and 9 (docs): run in **background** — don't block pipeline
-- Step 2 (issues): use single `gh` command batch — avoid multiple API calls
-- Skip steps early via flags to save tokens on unnecessary work
-- Beta mode auto-skips: docs update (Step 9)
-- Capture step outputs inline — don't re-read files already in context
-
-## Quick Start
-
-User says `/ck-ship` → run full pipeline → output PR URL.
-User says `/ck-ship beta` → ship to dev branch with lighter pipeline.
-User says `/ck-ship official` → ship to main with full docs + journal.
-
-## Output Format
-
-```
-✓ Pre-flight: branch feature/foo, 5 commits, +200/-50 lines (mode: official)
-✓ Issues: linked #42, created #43
-✓ Merged: origin/main (up to date)
-✓ Tests: 42 passed, 0 failed
-✓ Review: 0 critical, 2 informational
-✓ Version: 1.2.3 → 1.2.4
-✓ Changelog: updated
-✓ Journal: written (background)
-✓ Docs: updated (background)
-✓ Committed: feat(auth): add OAuth2 login flow
-✓ Pushed: origin/feature/foo
-✓ PR: https://github.com/org/repo/pull/123 (linked: #42, #43)
-```
-
-## Important Rules
-
-- **Never skip tests** (unless `--skip-tests`). If tests fail, stop.
-- **Never force push.** Regular `git push` only.
-- **Never ask for confirmation** except for critical review issues and major/minor version bumps.
-- **Auto-detect everything.** Test runner, version file, changelog format, target branch — detect from project files.
-- **Framework-agnostic.** Works for Node, Python, Rust, Go, Ruby, Java, or any project with a test command.
-- **Subagent delegation.** Use `tester` for tests, `code-reviewer` for review, `journal-writer` for journal, `docs-manager` for docs. Don't inline.
-- **Background tasks.** Journal and docs run in background to not block the pipeline.

package/skills/ship/references/ship-workflow.md

@@ -1,241 +0,0 @@
-# Ship Workflow — Detailed Steps
-
-## Step 1: Pre-flight
-
-1. Check current branch: `git branch --show-current`
-   - If on target branch (main/master/dev): **ABORT** — "Ship from a feature branch, not the target branch."
-2. Determine ship mode from arguments:
-   - `official` → target = auto-detect default branch (main/master)
-   - `beta` → target = auto-detect dev branch (dev/beta/develop)
-   - No argument → infer from branch name:
-     - `feature/* hotfix/* bugfix/*` → official
-     - `dev/* beta/* experiment/*` → beta
-     - Unclear → asking the user with options: "Official (main)", "Beta (dev)"
-3. Auto-detect target branch:
-   ```bash
-   # For official: detect default branch
-   git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
-   # Fallback
-   git rev-parse --verify origin/main 2>/dev/null && echo "main" || echo "master"
-
-   # For beta: detect dev branch
-   for b in dev beta develop; do
-     git rev-parse --verify origin/$b 2>/dev/null && echo "$b" && break
-   done
-   ```
-4. Run `git status` (never use `-uall`). Uncommitted changes are always included.
-5. Run `git diff <target>...HEAD --stat` and `git log <target>..HEAD --oneline` to understand what's being shipped.
-6. If `--dry-run`: output what would happen at each step and stop here.
-
-## Step 2: Link Issues
-
-Find or create related GitHub issues for traceability.
-
-1. Search for related open issues by keywords from branch name and commit messages:
-   ```bash
-   # Extract keywords from branch name
-   BRANCH=$(git branch --show-current)
-   KEYWORDS=$(echo "$BRANCH" | sed 's/[^a-zA-Z0-9]/ /g' | tr '[:upper:]' '[:lower:]')
-
-   # Search existing issues
-   gh issue list --state open --limit 10 --search "$KEYWORDS"
-   ```
-
-2. Also check if any issues are referenced in commit messages:
-   ```bash
-   git log <target>..HEAD --oneline | grep -oE '#[0-9]+' | sort -u
-   ```
-
-3. **If related issues found:** Note issue numbers for PR linking.
-
-4. **If NO related issues found:** Create a new issue with structured format:
-   ```bash
-   gh issue create --title "<type>: <summary from commits>" --body "$(cat <<'EOF'
-   ## Problem Statement
-   <infer from diff and commit messages>
-
-   ## Proposal
-   <summarize the implementation approach>
-
-   ## How It Works
-   <describe key changes with bullet points>
-
-   ### Architecture
-   ```
-   <ASCII diagram of component interactions>
-   ```
-
-   ## Challenges
-   - <potential edge cases or risks>
-
-   ## Plan & Phases
-   - [x] Implementation complete
-   - [x] Tests passing
-   - [ ] Code review approved
-   - [ ] Merged to <target>
-
-   ## Human Review Tasks
-   - [ ] Verify business logic correctness
-   - [ ] Check for edge cases not covered by tests
-   - [ ] Validate UX/API contract changes (if any)
-   EOF
-   )"
-   ```
-
-5. Store issue numbers for Step 12 (PR creation).
-
-## Step 3: Merge target branch
-
-Fetch and merge so tests run against the merged state:
-
-```bash
-git fetch origin <target> && git merge origin/<target> --no-edit
-```
-
-- **If merge conflicts:** Try auto-resolve simple ones (lockfiles, version files). For complex conflicts, **STOP** and show them.
-- **If already up to date:** Continue silently.
-
-## Step 4: Run Tests
-
-**Skip if:** `--skip-tests` flag.
-
-1. Auto-detect test command (see `auto-detect.md`)
-2. Delegate to `tester` subagent — don't inline test execution
-3. Check pass/fail from agent result
-
-- **If any test fails:** Show failures and **STOP**. Do not proceed.
-- **If all pass:** Note counts briefly and continue.
-- **If no test runner detected:** Use asking the user — "No test runner detected. Skip tests or provide command?"
-
-## Step 5: Pre-Landing Review
-
-**Skip if:** `--skip-review` flag.
-
-1. Run `git diff origin/<target>` to get the full diff
-2. Delegate to `code-reviewer` subagent with the diff
-3. Two-pass model:
-   - **Pass 1 (CRITICAL):** Security, injection, race conditions, auth bypass
-   - **Pass 2 (INFORMATIONAL):** Dead code, magic numbers, test gaps, style
-
-4. **Output findings:**
-   ```
-   Pre-Landing Review: N issues (X critical, Y informational)
-   ```
-
-5. **If critical issues found:** For EACH critical issue, ask the user:
-   - Problem description with `file:line`
-   - Recommended fix
-   - Options: A) Fix now (recommended), B) Acknowledge and ship, C) False positive — skip
-
-6. **If user chose Fix (A):** Apply fixes, commit fixed files, then **re-run tests** (Step 4) before continuing.
-7. **If only informational:** Include in PR body, continue.
-8. **If no issues:** Output "No issues found." and continue.
-
-## Step 6: Version Bump (conditional)
-
-1. Auto-detect version source (see `auto-detect.md`)
-2. If no version file found: **skip silently**
-3. Auto-decide bump level from diff size:
-   - **< 50 lines:** patch bump
-   - **50+ lines:** patch bump (default safe choice)
-   - **Major feature or breaking change:** Use asking the user — "This looks like a significant change. Bump minor or patch?"
-4. For beta mode: use prerelease suffix (e.g., `1.2.4-beta.1`)
-5. Write new version to detected file
-
-## Step 7: Changelog (conditional)
-
-1. Check for CHANGELOG.md or CHANGES.md
-2. If not found: **skip silently**
-3. Auto-generate entry from ALL commits on branch:
-   - `git log <target>..HEAD --oneline` for commit list
-   - `git diff <target>...HEAD` for full diff context
-4. Categorize into: Added, Changed, Fixed, Removed
-5. Insert after file header, dated today
-6. Format: `## [X.Y.Z] - YYYY-MM-DD`
-
-**Do NOT ask user to describe changes.** Infer from diff and commits.
-
-## Step 8: Journal (background)
-
-**Skip if:** `--skip-journal` flag.
-
-Write a technical journal entry capturing this ship session. Run as **background task** to not block pipeline.
-
-1. Invoke `/ck-journal` skill via `journal-writer` subagent in background:
-   - Topic: summary of shipped changes (from commit messages + diff stats)
-   - Include: what was shipped, key decisions, technical challenges encountered
-   - Output: saved to `./docs/journals/` directory
-2. Don't wait for completion — continue to next step immediately.
-
-## Step 9: Docs Update (conditional, background)
-
-**Skip if:** `--skip-docs` flag OR ship mode is `beta`.
-
-Update project documentation for official releases. Run as **background task**.
-
-1. Invoke `/ck-docs update` skill via `docs-manager` subagent in background:
-   - Analyzes code changes since last release
-   - Updates relevant docs in `./docs/` directory
-2. Don't wait for completion — continue to next step immediately.
-
-## Step 10: Commit
-
-1. Stage all changes: `git add -A`
-2. Security check: scan staged diff for secrets (API keys, tokens, passwords)
-   - If secrets found: **STOP**, warn user, suggest `.gitignore`
-3. Compose commit message:
-   - Format: `type(scope): description`
-   - Infer type from changes (feat/fix/refactor/chore)
-   - If version + changelog present, include in same commit
-4. Commit:
-
-```bash
-git commit -m "$(cat <<'EOF'
-type(scope): description
-
-Brief body describing the changes.
-EOF
-)"
-```
-
-## Step 11: Push
-
-```bash
-git push -u origin $(git branch --show-current)
-```
-
-- **Never force push.**
-- If push rejected: suggest `git pull --rebase` and retry once.
-
-## Step 12: Create PR
-
-Check if `gh` CLI is available:
-```bash
-which gh 2>/dev/null || echo "MISSING"
-```
-
-If missing: output "Install GitHub CLI (gh) to auto-create PRs" and stop after push.
-
-Create PR targeting the correct branch:
-```bash
-gh pr create --base <target-branch> --title "<type>: <summary>" --body "$(cat <<'EOF'
-<PR body from pr-template.md>
-EOF
-)"
-```
-
-**Link issues** collected from Step 2:
-```bash
-# If issues were found/created, add closing keywords in PR body
-# e.g., "Closes #42, Relates to #43"
-```
-
-**Output the PR URL** — this is the final output the user sees.
-
-If PR already exists for this branch, update it instead:
-```bash
-gh pr edit --title "<type>: <summary>" --body "$(cat <<'EOF'
-<PR body>
-EOF
-)"
-```

package/skills/test/SKILL.md

@@ -1,111 +0,0 @@
----
-name: test
-description: "Run unit, integration, e2e, and UI tests. Use for test execution, coverage analysis, build verification, visual regression, and QA reports."
-argument-hint: "[context] OR ui [url]"
----
-
-# Testing & Quality Assurance
-
-Comprehensive testing framework covering code-level testing (unit, integration, e2e), UI/visual testing via browser automation, coverage analysis, and structured QA reporting.
-
-## Default (No Arguments)
-
-If invoked with context (test scope), proceed with testing. If invoked WITHOUT arguments, ask the user to present available test operations:
-
-| Operation | Description |
-|-----------|-------------|
-| `(default)` | Run unit/integration/e2e tests |
-| `ui` | Run UI tests on a website |
-
-Present as options by asking the user with header "Test Operation", question "What would you like to do?".
-
-## Core Principle
-
-**NEVER IGNORE FAILING TESTS.** Fix root causes, not symptoms. No mocks/cheats/tricks to pass builds.
-
-## When to Use
-
-- **After implementation**: Validate new features or bug fixes
-- **Coverage checks**: Ensure coverage meets project thresholds (80%+)
-- **UI verification**: Visual regression, responsive layout, accessibility
-- **Build validation**: Verify build process, dependencies, CI/CD compatibility
-- **Pre-commit/push**: Final quality gate
-
-## Workflows
-
-### 1. Code Testing (`references/test-execution-workflow.md`)
-
-Execute test suites, analyze results, generate coverage. Supports JS/TS (Jest/Vitest/Mocha), Python (pytest), Go, Rust, Flutter. Includes working process, quality standards, and tool commands.
-
-**Load when:** Running unit/integration/e2e tests, checking coverage, validating builds
-
-### 2. UI Testing (`references/ui-testing-workflow.md`)
-
-Browser-based visual testing via `chrome-devtools` (if available) skill. Screenshots, responsive checks, accessibility audits, form automation, console error collection. Includes auth injection for protected routes.
-
-**Load when:** Visual regression testing, UI bugs, responsive layout checks, accessibility audits
-
-### 3. Report Format (`references/report-format.md`)
-
-Structured QA report template: test results overview, coverage metrics, failed tests, performance, build status, recommendations.
-
-**Load when:** Generating test summary reports
-
-## Quick Reference
-
-```
-Code tests     → test-execution-workflow.md
-  npm test / pytest / go test / cargo test / flutter test
-  Coverage: npm run test:coverage / pytest --cov
-
-UI tests       → ui-testing-workflow.md
-  Screenshots, responsive, a11y, forms, console errors
-  Auth: inject-auth.js for protected routes
-
-Reports        → report-format.md
-  Structured QA summary with metrics & recommendations
-```
-
-## Working Process
-
-1. Identify testing scope from recent changes or requirements
-2. Run typecheck/analyze commands to catch syntax errors first
-3. Execute appropriate test suites
-4. Analyze results — focus on failures
-5. Generate coverage reports if applicable
-6. For frontend: run UI tests via `chrome-devtools` (if available) skill
-7. Produce structured summary report
-
-## Tools Integration
-
-- **Test runners**: Jest, Vitest, Mocha, pytest, go test, cargo test, flutter test
-- **Coverage**: Istanbul/c8/nyc, pytest-cov, go cover
-- **Browser**: `chrome-devtools` (if available) skill for UI testing (screenshots, ARIA, console, network)
-- **Analysis**: `ai-multimodal` (if available) skill for screenshot analysis
-- **Debugging**: `debug` skill when tests reveal bugs requiring investigation
-- **Thinking**: `sequential-thinking` skill for complex test failure analysis
-
-## Quality Standards
-
-- All critical paths must have test coverage
-- Validate happy path AND error scenarios
-- Ensure test isolation — no interdependencies
-- Tests must be deterministic and reproducible
-- Clean up test data after execution
-- Never ignore failing tests to pass the build
-
-## Report Output
-**IMPORTANT:** Invoke "/ck-project-organization" skill to organize the outputs.
-
-Use naming pattern from `## Naming` section injected by hooks.
-
-## Team Mode
-
-When operating as teammate:
-1. On start: check `TaskList`, claim assigned/next unblocked task via `TaskUpdate`
-2. Read full task description via `TaskGet` before starting
-3. Wait for blocked tasks (implementation) to complete before testing
-4. Respect file ownership — only create/edit test files assigned
-5. When done: `TaskUpdate(status: "completed")` then `SendMessage` results to lead
-
-**Fallback:** Task tools (`TaskList`/`TaskUpdate`/`TaskGet`) are CLI-only — unavailable in VSCode extension. If they error, use `TodoWrite` for progress tracking and coordinate via `SendMessage` only.