@hienlh/ppm 0.9.81 → 0.9.83

package/.opencode/skills/ck-plan/references/validate-question-framework.md

@@ -1,80 +0,0 @@
-# Validation Question Framework
-
-## Question Categories
-
-| Category | Keywords to detect |
-|----------|-------------------|
-| **Architecture** | "approach", "pattern", "design", "structure", "database", "API" |
-| **Assumptions** | "assume", "expect", "should", "will", "must", "default" |
-| **Tradeoffs** | "tradeoff", "vs", "alternative", "option", "choice", "either/or" |
-| **Risks** | "risk", "might", "could fail", "dependency", "blocker", "concern" |
-| **Scope** | "phase", "MVP", "future", "out of scope", "nice to have" |
-
-## Question Format Rules
-
-- Each question must have 2-4 concrete options
-- Mark recommended option with "(Recommended)" suffix
-- "Other" option is automatic
-- Questions should surface implicit decisions
-
-## Example Questions
-
-Category: Architecture
-Question: "How should the validation results be persisted?"
-Options:
-1. Save to plan.md frontmatter (Recommended)
-2. Create validation-answers.md
-3. Don't persist
-
-Category: Assumptions
-Question: "The plan assumes API rate limiting is not needed. Is this correct?"
-Options:
-1. Yes, not needed for MVP
-2. No, add basic rate limiting now (Recommended)
-3. Defer to Phase 2
-
-## Validation Log Format
-
-```markdown
-## Validation Log
-
-### Session {N} — {YYYY-MM-DD}
-**Trigger:** {what prompted this validation}
-**Questions asked:** {count}
-
-#### Questions & Answers
-
-1. **[{Category}]** {full question text}
-   - Options: {A} | {B} | {C}
-   - **Answer:** {user's choice}
-   - **Custom input:** {verbatim "Other" text if applicable}
-   - **Rationale:** {why this decision matters}
-
-#### Confirmed Decisions
-- {decision}: {choice} — {brief why}
-
-#### Action Items
-- [ ] {specific change needed}
-
-#### Impact on Phases
-- Phase {N}: {what needs updating and why}
-```
-
-## Recording Rules
-
-- **Full question text**: exact question, not summary
-- **All options**: every option presented
-- **Verbatim custom input**: record "Other" text exactly
-- **Rationale**: explain why decision affects implementation
-- **Session numbering**: increment from last session
-- **Trigger**: state what prompted validation
-
-## Section Mapping for Phase Propagation
-
-| Change Type | Target Section |
-|-------------|----------------|
-| Requirements | Requirements |
-| Architecture | Architecture |
-| Scope | Overview / Implementation Steps |
-| Risk | Risk Assessment |
-| Unknown | Key Insights (new subsection) |

package/.opencode/skills/ck-plan/references/validate-workflow.md

@@ -1,65 +0,0 @@
-# Validate Workflow
-
-Interview the user with critical questions to validate assumptions, confirm decisions, and surface potential issues in an implementation plan before coding begins.
-
-## Plan Resolution
-
-1. If `$ARGUMENTS` provided → Use that path
-2. Else check `## Plan Context` section → Use active plan path
-3. If no plan found → Ask user to specify path or run `/ck:plan --hard` first
-
-## Configuration
-
-Check `## Plan Context` section for validation settings:
-- `mode` - Controls auto/prompt/off behavior
-- `questions` - Range like `3-8` (min-max)
-
-## Workflow
-
-### Step 1: Read Plan Files
-- `plan.md` - Overview and phases list
-- `phase-*.md` - All phase files
-- Look for decision points, assumptions, risks, tradeoffs
-
-### Step 2: Extract Question Topics
-Load: `references/validate-question-framework.md`
-
-### Step 3: Generate Questions
-For each detected topic, formulate a concrete question with 2-4 options.
-Mark recommended option with "(Recommended)" suffix.
-
-### Step 4: Interview User
-Use `AskUserQuestion` tool.
-- Use question count from `## Plan Context` validation settings
-- Group related questions (max 4 per tool call)
-- Focus on: assumptions, risks, tradeoffs, architecture
-
-### Step 5: Document Answers
-Add or append `## Validation Log` section in `plan.md`.
-Load: `references/validate-question-framework.md` for recording format.
-
-### Step 6: Propagate Changes to Phases
-Auto-propagate validation decisions to affected phase files.
-Add marker: `<!-- Updated: Validation Session N - {change} -->`
-
-## Output
-- Number of questions asked
-- Key decisions confirmed
-- Phase propagation results
-- Recommendation: proceed or revise
-
-## Next Steps (MANDATORY)
-Remind user with absolute path:
-> **Best Practice:** Run `/clear` before implementing to start with fresh context.
-> Then run:
-> ```
-> /ck:cook --auto {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
-> ```
-> **Why `--auto`?** Plan was already validated — safe to skip review gates.
-> **Why absolute path?** After `/clear`, the new session loses previous context.
-> Fresh context helps Claude focus solely on implementation without planning context pollution.
-
-## Important Notes
-- Only ask about genuine decision points
-- If plan is simple, fewer than min questions is okay
-- Prioritize questions that could change implementation significantly

package/.opencode/skills/ck-plan/references/workflow-modes.md

@@ -1,155 +0,0 @@
-# Workflow Modes
-
-## Auto-Detection (Default: `--auto`)
-
-When no flag specified, analyze task and pick mode:
-
-| Signal | Mode | Rationale |
-|--------|------|-----------|
-| Simple task, clear scope, no unknowns | fast | Skip research overhead |
-| Complex task, unfamiliar domain, new tech | hard | Research needed |
-| 3+ independent features/layers/modules | parallel | Enable concurrent agents |
-| Ambiguous approach, multiple valid paths | two | Compare alternatives |
-
-Use `AskUserQuestion` if detection is uncertain.
-
-## Scope Challenge Integration
-
-Step 0 (Scope Challenge, see `scope-challenge.md`) runs before mode detection and can influence it:
-- If user selects **EXPANSION** → auto-suggest `--hard` or `--two`
-- If user selects **REDUCTION** → auto-suggest `--fast`
-- If user selects **HOLD** → proceed with auto-detected mode
-
-Mode can still be overridden by explicit flags (`--fast`, `--hard`, etc.).
-Scope challenge is skipped when `--fast` is explicitly set or task is trivial.
-
-## Fast Mode (`--fast`)
-
-No research. Analyze → Plan → Hydrate Tasks.
-
-1. Read codebase docs (`codebase-summary.md`, `code-standards.md`, `system-architecture.md`)
-2. Use `planner` subagent to create plan
-3. Hydrate tasks (unless `--no-tasks`)
-4. **Context reminder:** `/ck:cook --auto {absolute-plan-path}/plan.md`
-
-**Why `--auto` cook flag?** Fast planning pairs with fast execution — skip review gates.
-
-## Hard Mode (`--hard`)
-
-Research → Scout → Plan → Red Team → Validate → Hydrate Tasks.
-
-1. Spawn max 2 `researcher` agents in parallel (different aspects, max 5 calls each)
-2. Read codebase docs; if stale/missing: run `/ck:scout` to search codebase
-3. Gather research + scout report filepaths → pass to `planner` subagent
-4. Post-plan red team review (see Red Team Review section below)
-5. Post-plan validation (see Validation section below)
-6. Hydrate tasks (unless `--no-tasks`)
-7. **Context reminder:** `/ck:cook {absolute-plan-path}/plan.md`
-
-**Why no cook flag?** Thorough planning needs interactive review gates.
-
-## Parallel Mode (`--parallel`)
-
-Research → Scout → Plan with file ownership → Red Team → Validate → Hydrate Tasks with dependency graph.
-
-1. Same as Hard mode steps 1-3
-2. Planner creates phases with:
-   - **Exclusive file ownership** per phase (no overlap)
-   - **Dependency matrix** (which phases run concurrently vs sequentially)
-   - **Conflict prevention** strategy
-3. plan.md includes: dependency graph, execution strategy, file ownership matrix
-4. Hydrate tasks: `addBlockedBy` for sequential deps, no blockers for parallel groups
-5. Post-plan red team review
-6. Post-plan validation
-7. **Context reminder:** `/ck:cook --parallel {absolute-plan-path}/plan.md`
-
-### Parallel Phase Requirements
-- Each phase self-contained, no runtime deps on other phases
-- Clear file boundaries — each file modified in ONE phase only
-- Group by: architectural layer, feature domain, or technology stack
-- Example: Phases 1-3 parallel (DB/API/UI), Phase 4 sequential (integration tests)
-
-## Two-Approach Mode (`--two`)
-
-Research → Scout → Plan 2 approaches → Compare → Hydrate Tasks.
-
-1. Same as Hard mode steps 1-3
-2. Planner creates 2 implementation approaches with:
-   - Clear trade-offs (pros/cons each)
-   - Recommended approach with rationale
-3. User selects approach
-4. Post-plan red team review on selected approach
-5. Post-plan validation
-6. Hydrate tasks for selected approach (unless `--no-tasks`)
-7. **Context reminder:** `/ck:cook {absolute-plan-path}/plan.md`
-
-## Task Hydration Per Mode
-
-| Mode | Task Granularity | Dependency Pattern |
-|------|------------------|--------------------|
-| fast | Phase-level only | Sequential chain |
-| hard | Phase + critical steps | Sequential + step deps |
-| parallel | Phase + steps + ownership | Parallel groups + sequential deps |
-| two | After user selects approach | Sequential chain |
-
-All modes: See `task-management.md` for TaskCreate patterns and metadata.
-
-## Post-Plan Red Team Review
-
-Adversarial review that spawns hostile reviewers to find flaws before validation.
-
-**Available in:** hard, parallel, two modes. **Skipped in:** fast mode.
-
-**Invocation:** Run `/ck:plan red-team {plan-directory-path}`.
-```
-/ck:plan red-team {plan-directory-path}
-```
-
-**Sequence:** Red team runs BEFORE validation because:
-1. Red team may change the plan (added risks, removed sections, new constraints)
-2. Validation should confirm the FINAL plan, not a pre-review draft
-3. Validating first then red-teaming would invalidate validation answers
-
-## Post-Plan Validation
-
-Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:
-
-| Mode | Behavior |
-|------|----------|
-| `prompt` | Ask: "Validate this plan with interview?" → Yes (Recommended) / No |
-| `auto` | Run `/ck:plan validate {plan-directory-path}` |
-| `off` | Skip validation |
-
-**Invocation (when prompt mode, user says yes):** Run:
-```
-/ck:plan validate {plan-directory-path}
-```
-
-**Available in:** hard, parallel, two modes. **Skipped in:** fast mode.
-
-## Context Reminder (MANDATORY)
-
-After plan creation, MUST output with **actual absolute path**:
-
-| Mode | Cook Command |
-|------|-----------------------------|
-| fast | `/ck:cook --auto {path}/plan.md` |
-| hard | `/ck:cook {path}/plan.md` |
-| parallel | `/ck:cook --parallel {path}/plan.md` |
-| two | `/ck:cook {path}/plan.md` |
-
-> **Best Practice:** Run `/clear` before implementing to reduce planning-context carryover.
-> Then run the cook command above.
-
-**Why absolute path?** After `/clear`, the new session loses previous context.
-This reminder is **NON-NEGOTIABLE** — always output after presenting the plan.
-
-## Pre-Creation Check
-
-Check `## Plan Context` in injected context:
-- **"Plan: {path}"** → Ask "Continue with existing plan? [Y/n]"
-- **"Suggested: {path}"** → Branch hint only, ask if activate or create new
-- **"Plan: none"** → Create new using `Plan dir:` from `## Naming`
-
-After creating: `node .opencode/scripts/set-active-plan.cjs {plan-dir}`
-Pass plan directory path to every subagent during the process.

package/.opencode/skills/ck-predict/SKILL.md

@@ -1,119 +0,0 @@
----
-name: ck:predict
-description: "5 expert personas debate proposed changes before implementation. Catches architectural, security, performance, and UX issues early. Use before major features or risky changes."
-argument-hint: "<feature description or change proposal> [--files <glob>]"
-metadata:
-  author: claudekit
-  attribution: "Multi-persona prediction pattern adapted from autoresearch by Udit Goenka (MIT)"
-  license: MIT
-  version: "1.0.0"
----
-
-# ck:predict — Multi-Persona Pre-Analysis
-
-Five expert personas independently analyze a proposed change, then debate conflicts to produce a consensus verdict before a single line of code is written.
-
-## When to Use
-
-- Before implementing a major or high-risk feature
-- Before a significant refactor or architecture change
-- Evaluating competing technical approaches
-- Stress-testing assumptions in a proposed design
-
-## When NOT to Use
-
-- Trivial or low-risk changes (use `ck:debug` for bugs, `ck:plan` for already-decided tasks)
-- Already-approved work with no open design questions
-- Pure dependency upgrades with no API changes
-
----
-
-## The 5 Personas
-
-| Persona | Focus | Core Questions |
-|---------|-------|----------------|
-| **Architect** | System design, scalability, coupling | Does this fit the architecture? Will it scale? What new coupling does it introduce? |
-| **Security** | Attack surface, data protection, auth | What can be abused? Where is data exposed? Are auth boundaries respected? |
-| **Performance** | Latency, memory, queries, bundle size | What is the latency impact? N+1 queries? Memory leaks? Bundle bloat? |
-| **UX** | User experience, accessibility, error states | Is this intuitive? What does the error state look like? Accessible on mobile? |
-| **Devil's Advocate** | Hidden assumptions, simpler alternatives | Why not do nothing? What is the simplest alternative? Which assumption could be wrong? |
-
----
-
-## Debate Protocol
-
-1. **Read** the proposed change/feature description from the argument
-2. **Read relevant code** if file paths are provided (grep for affected areas)
-3. **Each persona analyzes independently** — do not let personas influence each other during this phase
-4. **Identify agreements** — points where all (or 4+) personas align
-5. **Identify conflicts** — points where personas meaningfully disagree
-6. **Weigh tradeoffs** — for each conflict, evaluate which concern has higher impact
-7. **Produce verdict** — GO / CAUTION / STOP with actionable recommendations
-
----
-
-## Output Format
-
-```
-## Prediction Report: [proposal title]
-
-## Verdict: GO | CAUTION | STOP
-
-### Agreements (all personas align)
-- [Point 1 — what they all agree on]
-- [Point 2]
-
-### Conflicts & Resolutions
-
-| Topic | Architect | Security | Performance | UX | Devil's Advocate | Resolution |
-|-------|-----------|----------|-------------|-----|-----------------|------------|
-| [Issue] | [View] | [View] | [View] | [View] | [View] | [Recommendation] |
-
-### Risk Summary
-
-| Risk | Severity | Mitigation |
-|------|----------|------------|
-| [Risk description] | Critical/High/Medium/Low | [Concrete action] |
-
-### Recommendations
-1. [Action item — rationale]
-2. [Action item — rationale]
-3. [Action item — rationale]
-```
-
----
-
-## Verdict Levels
-
-| Verdict | Meaning |
-|---------|---------|
-| **GO** | All personas aligned, no critical risks, proceed with confidence |
-| **CAUTION** | Concerns exist but are manageable — mitigations identified, proceed carefully |
-| **STOP** | Critical unresolved issue found — needs redesign or more information before proceeding |
-
-### STOP Triggers (any one is sufficient)
-- Security persona identifies auth bypass or data exposure with no viable mitigation
-- Architect identifies fundamental design incompatibility requiring significant rework
-- Performance persona identifies unacceptable latency or query explosion with no workaround
-- Devil's Advocate exposes a false assumption that invalidates the entire approach
-
----
-
-## Integration with Other Skills
-
-| Workflow Step | Skill | How |
-|---------------|-------|-----|
-| Deepen risk scenarios | `ck:scenario` | Feed Risk Summary rows as feature description |
-| Create implementation plan | `ck:plan` | Attach Recommendations as constraints to planner |
-| High-risk feature implementation | `ck:cook` | Reference CAUTION/STOP items as acceptance gates |
-
----
-
-## Example Invocations
-
-```
-/ck:predict "Add WebSocket support for real-time notifications"
-/ck:predict "Migrate authentication from JWT to session cookies"
-/ck:predict "Add multi-tenancy to the database layer"
-/ck:predict "Replace REST API with GraphQL" --files src/api/**/*.ts
-```

package/.opencode/skills/ck-scenario/SKILL.md

@@ -1,113 +0,0 @@
----
-name: ck:scenario
-description: "Generate comprehensive edge cases and test scenarios by decomposing features across 12 dimensions. Use before implementation or testing to catch issues early."
-argument-hint: "<file path or feature description>"
-metadata:
-  author: claudekit
-  attribution: "Scenario exploration pattern adapted from autoresearch by Udit Goenka (MIT)"
-  license: MIT
-  version: "1.0.0"
----
-
-# ck:scenario — Edge Case & Scenario Explorer
-
-Decompose any feature or code path across 12 dimensions to surface edge cases, risks, and test targets before implementation begins.
-
-## When to Use
-
-- Before implementing complex or stateful features
-- Before writing tests (generates test targets)
-- Risk assessment during planning or code review
-- API design review — surface contract edge cases early
-
-## When NOT to Use
-
-- Trivial single-line changes or cosmetic UI tweaks
-- Already well-tested, stable code with no recent modifications
-- Pure configuration changes with no logic paths
-
----
-
-## 12 Decomposition Dimensions
-
-Not all 12 apply to every feature. Identify relevant dimensions first, then generate scenarios only for those.
-
-| # | Dimension | What to Look For |
-|---|-----------|------------------|
-| 1 | **User Types** | admin, guest, banned, new user, power user, bot/scraper |
-| 2 | **Input Extremes** | empty, null, max length, unicode, special chars, SQL/script injection |
-| 3 | **Timing** | concurrent access, race conditions, timeout, slow network, retry storms |
-| 4 | **Scale** | 0 items, 1 item, 1M items, pagination boundary, cursor wrap |
-| 5 | **State Transitions** | first use, mid-flow abort, resume after crash, partial completion |
-| 6 | **Environment** | mobile/low-end CPU, no JS, screen reader, proxy/VPN, different timezone/locale |
-| 7 | **Error Cascades** | DB down, API timeout, disk full, OOM, network partition, partial write |
-| 8 | **Authorization** | expired token, wrong role, shared/public link, CORS, CSRF, privilege escalation |
-| 9 | **Data Integrity** | duplicate entries, orphan references, encoding mismatch, concurrent schema migration |
-| 10 | **Integration** | webhook replay, API version mismatch, third-party outage, contract drift |
-| 11 | **Compliance** | GDPR deletion request, audit logging gap, data retention, accidental PII exposure |
-| 12 | **Business Logic** | edge pricing (zero/negative), coupon stacking, refund after partial delivery, free tier limits |
-
----
-
-## Workflow
-
-1. **Read** target file(s) or parse feature description from argument
-2. **Filter dimensions** — mark which of the 12 apply; skip irrelevant ones explicitly
-3. **Generate 3–5 scenarios** per relevant dimension
-4. **Categorize severity** — Critical / High / Medium / Low
-5. **Output** as structured table (see format below)
-6. **Summarize** total scenario count by severity
-
-### Severity Criteria
-
-| Level | Meaning |
-|-------|---------|
-| **Critical** | Data loss, security breach, auth bypass, silent corruption |
-| **High** | Feature broken for a subset of users, data inconsistency |
-| **Medium** | Degraded UX, recoverable error not surfaced to user |
-| **Low** | Minor visual glitch, non-blocking warning |
-
----
-
-## Output Format
-
-```
-## Scenario Report: [target]
-
-Dimensions analyzed: [list]
-Dimensions skipped: [list + reason]
-
-| # | Dimension | Scenario | Severity | Expected Behavior |
-|---|-----------|----------|----------|-------------------|
-| 1 | Input Extremes | Empty string for required name field | High | Return 400 with field error |
-| 2 | Authorization | Expired JWT accessing protected route | Critical | Redirect to login, invalidate session |
-| 3 | Timing | Two users submit same form simultaneously | High | Idempotency key or conflict error |
-
-### Summary
-- Critical: N
-- High: N
-- Medium: N
-- Low: N
-- Total: N scenarios across X dimensions
-```
-
----
-
-## Integration with Other Skills
-
-| Next Step | Skill | How |
-|-----------|-------|-----|
-| Generate test cases from scenarios | `ck:test` | Pass scenario table as input context |
-| Inform implementation plan risks | `ck:plan` | Paste Critical/High rows into risk assessment |
-| Deep persona debate on top risks | `ck:predict` | Feed Critical scenarios as the change proposal |
-
----
-
-## Example Invocations
-
-```
-/ck:scenario src/api/payment.ts
-/ck:scenario "User registration with OAuth providers"
-/ck:scenario src/middleware/auth.ts
-/ck:scenario "Add multi-tenancy to the database layer"
-```

package/.opencode/skills/ck-security/SKILL.md

@@ -1,144 +0,0 @@
----
-name: ck: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]"
-metadata:
-  author: claudekit
-  attribution: "Security audit pattern adapted from autoresearch by Udit Goenka (MIT)"
-  license: MIT
-  version: "1.0.0"
----
-
-# 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 `ck: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 `ck:predict` when the security persona flags concerns
-- Feed Critical/High findings into `ck:autoresearch --fix` for automated remediation
-- Use `ck:scenario` with `--focus authorization` for deeper auth flow testing
-- Pair with `ck: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.