@hienlh/ppm 0.9.79 → 0.9.81

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

@@ -0,0 +1,80 @@
+# 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

@@ -0,0 +1,65 @@
+# 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

@@ -0,0 +1,155 @@
+# 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

@@ -0,0 +1,119 @@
+---
+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

@@ -0,0 +1,113 @@
+---
+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

@@ -0,0 +1,144 @@
+---
+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.