tribunal-kit 9.2.4 → 9.2.5

package/skills/red-team-tactics/SKILL.md

@@ -1,191 +1,191 @@
----
-name: red-team-tactics
-description: "Use when Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - vulnerability-scanner
-  - backend-security-expert
-  - api-security-auditor
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Red Team & Penetration Testing Principles
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Hallucination Traps (Read First)
-
-- ❌ Testing only happy-path authentication -> ✅ Red teaming must test token reuse, expired tokens, forged tokens, and privilege escalation
-- ❌ Reporting vulnerabilities without proof-of-concept -> ✅ Every finding needs a reproducible PoC and severity rating (CVSS)
-- ❌ Stopping after finding the first vulnerability -> ✅ Real attackers chain multiple low-severity issues; test for escalation paths
-
----
-
-A red team engagement is a controlled attack.
-The goal is to find what a real attacker would find — before they do.
-
-⚠️ **These techniques are for authorized security testing only. Unauthorized use is illegal.**
-
----
-
-## Engagement Scope First
-
-Before any testing activity:
-
-1. **Written authorization** — who authorized this engagement and in what scope?
-2. **Scope definition** — which systems, IPs, domains, time windows are in scope?
-3. **Rules of engagement** — what is prohibited? (production data access, social engineering of specific roles, DDoS)
-4. **Emergency contact** — who do you call if you discover a critical live breach mid-engagement?
-5. **Deconfliction** — does the blue team know an engagement is running, or is it blind?
-
-No authorization = no testing.
-
----
-
-## Attack Phases (Based on MITRE ATT&CK)
-
-### 1. Reconnaissance
-
-Passive and active information gathering before touching the target.
-
-**Passive (no target contact):**
-
-- DNS lookup: `nslookup`, `dig`, certificate transparency logs
-- OSINT: LinkedIn for employee names/roles, GitHub for leaked configs, Shodan for exposed infrastructure
-
-**Active (target is contacted):**
-
-- Port scanning: `nmap -sV -sC <target>`
-- Web tech detection: `whatweb`, `wappalyzer`
-- Subdomain enumeration: `amass`, `subfinder`
-
-### 2. Initial Access
-
-How does an attacker get their first foothold?
-
-Common vectors:
-
-- Phishing (credential harvest or malicious attachment)
-- Exposed admin interfaces with default or weak credentials
-- Publicly exposed vulnerable services (`searchsploit`, `nuclei`)
-- Supply chain compromise (malicious npm package, CI/CD injection)
-
-### 3. Persistence
-
-Maintaining access after initial compromise:
-
-- Scheduled tasks / cron jobs
-- Web shells on compromised web servers
-- New user accounts with admin rights
-- SSH authorized_keys injection
-
-### 4. Lateral Movement
-
-Moving from initial foothold to higher-value targets:
-
-- Pass-the-hash / pass-the-ticket (Active Directory)
-- SSH key reuse across hosts
-- Credential reuse (if one service is compromised, others sharing the password are vulnerable)
-- Internal network scanning to map new targets
-
-### 5. Exfiltration
-
-Getting data out without triggering alerts:
-
-- Small, slow transfers to blend with normal traffic
-- Staging data in cloud storage linked to attacker-controlled accounts
-- DNS exfiltration (for heavily monitored networks)
-
----
-
-## Common Vulnerability Targets
-
-| Target                   | What to Test                                                |
-| ------------------------ | ----------------------------------------------------------- |
-| Web applications         | OWASP Top 10, auth bypass, IDOR, SSRF                       |
-| APIs                     | Object-level authorization, mass assignment, rate limiting  |
-| Authentication           | Brute force protection, token entropy, password reset flow  |
-| Secrets                  | Exposed env files, git history, CI/CD environment variables |
-| Third-party integrations | Webhook validation, OAuth redirect URI validation           |
-| Infrastructure           | Open S3 buckets, exposed admin ports, default credentials   |
-
----
-
-## Detection Evasion (for Authorized Testing)
-
-When testing detection capabilities:
-
-- Slow scan rates to stay under IDS thresholds
-- Use legitimate user agents and headers
-- Blend with normal traffic patterns
-- Test from IP ranges the organization wouldn't expect
-
----
-
-## Reporting Format
-
-```markdown
-# Red Team Report: [Engagement Name]
-
-## Executive Summary
-
-[2–3 sentences: what was tested, biggest risk found, business impact]
-
-## Scope
-
-[Systems tested, date range, authorization reference]
-
-## Critical Findings
-
-### CRIT-01: [Title]
-
-**Risk:** Critical
-**CVSS:** 9.8
-**Description:** [What the vulnerability is]
-**Evidence:** [Screenshot, payload, response]
-**Impact:** [What an attacker could do]
-**Remediation:** [Specific fix with code or config example]
-
-## Attack Narrative
-
-[Chronological story of the full attack path from initial access to objective]
-
-## Remediation Priority
-
-| Finding | Severity | Fix By |
-| ------- | -------- | ------ |
-```
-
----
-
-## Ethical Boundaries
-
-- Stop immediately if you discover evidence of an active breach by a real attacker — report it, don't continue testing
-- Don't access, copy, or delete real user data even if you can
-- Document everything — every command run, every finding noted
-- Brief the client team before leaving — no surprises in the report
-
----
-
-## Output Format
-
-When this skill produces a recommendation or design decision, structure your output as:
-
-```
-━━━ Red Team Tactics Recommendation ━━━━━━━━━━━━━━━━
-Decision:    [what was chosen / proposed]
-Rationale:   [why — one concise line]
-Trade-offs:  [what is consciously accepted]
-Next action: [concrete next step for the user]
-─────────────────────────────────────────────────
-Pre-Flight:  ✅ All checks passed
-             or ❌ [blocking item that must be resolved first]
-```
+---
+name: red-team-tactics
+description: "Use when Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - vulnerability-scanner
+  - backend-security-expert
+  - api-security-auditor
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Red Team & Penetration Testing Principles
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+## Hallucination Traps (Read First)
+
+- ❌ Testing only happy-path authentication -> ✅ Red teaming must test token reuse, expired tokens, forged tokens, and privilege escalation
+- ❌ Reporting vulnerabilities without proof-of-concept -> ✅ Every finding needs a reproducible PoC and severity rating (CVSS)
+- ❌ Stopping after finding the first vulnerability -> ✅ Real attackers chain multiple low-severity issues; test for escalation paths
+
+---
+
+A red team engagement is a controlled attack.
+The goal is to find what a real attacker would find — before they do.
+
+⚠️ **These techniques are for authorized security testing only. Unauthorized use is illegal.**
+
+---
+
+## Engagement Scope First
+
+Before any testing activity:
+
+1. **Written authorization** — who authorized this engagement and in what scope?
+2. **Scope definition** — which systems, IPs, domains, time windows are in scope?
+3. **Rules of engagement** — what is prohibited? (production data access, social engineering of specific roles, DDoS)
+4. **Emergency contact** — who do you call if you discover a critical live breach mid-engagement?
+5. **Deconfliction** — does the blue team know an engagement is running, or is it blind?
+
+No authorization = no testing.
+
+---
+
+## Attack Phases (Based on MITRE ATT&CK)
+
+### 1. Reconnaissance
+
+Passive and active information gathering before touching the target.
+
+**Passive (no target contact):**
+
+- DNS lookup: `nslookup`, `dig`, certificate transparency logs
+- OSINT: LinkedIn for employee names/roles, GitHub for leaked configs, Shodan for exposed infrastructure
+
+**Active (target is contacted):**
+
+- Port scanning: `nmap -sV -sC <target>`
+- Web tech detection: `whatweb`, `wappalyzer`
+- Subdomain enumeration: `amass`, `subfinder`
+
+### 2. Initial Access
+
+How does an attacker get their first foothold?
+
+Common vectors:
+
+- Phishing (credential harvest or malicious attachment)
+- Exposed admin interfaces with default or weak credentials
+- Publicly exposed vulnerable services (`searchsploit`, `nuclei`)
+- Supply chain compromise (malicious npm package, CI/CD injection)
+
+### 3. Persistence
+
+Maintaining access after initial compromise:
+
+- Scheduled tasks / cron jobs
+- Web shells on compromised web servers
+- New user accounts with admin rights
+- SSH authorized_keys injection
+
+### 4. Lateral Movement
+
+Moving from initial foothold to higher-value targets:
+
+- Pass-the-hash / pass-the-ticket (Active Directory)
+- SSH key reuse across hosts
+- Credential reuse (if one service is compromised, others sharing the password are vulnerable)
+- Internal network scanning to map new targets
+
+### 5. Exfiltration
+
+Getting data out without triggering alerts:
+
+- Small, slow transfers to blend with normal traffic
+- Staging data in cloud storage linked to attacker-controlled accounts
+- DNS exfiltration (for heavily monitored networks)
+
+---
+
+## Common Vulnerability Targets
+
+| Target                   | What to Test                                                |
+| ------------------------ | ----------------------------------------------------------- |
+| Web applications         | OWASP Top 10, auth bypass, IDOR, SSRF                       |
+| APIs                     | Object-level authorization, mass assignment, rate limiting  |
+| Authentication           | Brute force protection, token entropy, password reset flow  |
+| Secrets                  | Exposed env files, git history, CI/CD environment variables |
+| Third-party integrations | Webhook validation, OAuth redirect URI validation           |
+| Infrastructure           | Open S3 buckets, exposed admin ports, default credentials   |
+
+---
+
+## Detection Evasion (for Authorized Testing)
+
+When testing detection capabilities:
+
+- Slow scan rates to stay under IDS thresholds
+- Use legitimate user agents and headers
+- Blend with normal traffic patterns
+- Test from IP ranges the organization wouldn't expect
+
+---
+
+## Reporting Format
+
+```markdown
+# Red Team Report: [Engagement Name]
+
+## Executive Summary
+
+[2–3 sentences: what was tested, biggest risk found, business impact]
+
+## Scope
+
+[Systems tested, date range, authorization reference]
+
+## Critical Findings
+
+### CRIT-01: [Title]
+
+**Risk:** Critical
+**CVSS:** 9.8
+**Description:** [What the vulnerability is]
+**Evidence:** [Screenshot, payload, response]
+**Impact:** [What an attacker could do]
+**Remediation:** [Specific fix with code or config example]
+
+## Attack Narrative
+
+[Chronological story of the full attack path from initial access to objective]
+
+## Remediation Priority
+
+| Finding | Severity | Fix By |
+| ------- | -------- | ------ |
+```
+
+---
+
+## Ethical Boundaries
+
+- Stop immediately if you discover evidence of an active breach by a real attacker — report it, don't continue testing
+- Don't access, copy, or delete real user data even if you can
+- Document everything — every command run, every finding noted
+- Brief the client team before leaving — no surprises in the report
+
+---
+
+## Output Format
+
+When this skill produces a recommendation or design decision, structure your output as:
+
+```
+━━━ Red Team Tactics Recommendation ━━━━━━━━━━━━━━━━
+Decision:    [what was chosen / proposed]
+Rationale:   [why — one concise line]
+Trade-offs:  [what is consciously accepted]
+Next action: [concrete next step for the user]
+─────────────────────────────────────────────────
+Pre-Flight:  ✅ All checks passed
+             or ❌ [blocking item that must be resolved first]
+```

package/skills/redesign-skill/SKILL.md

@@ -1,46 +1,46 @@
----
-name: redesign-skill
-description: "Use when Audit and upgrade existing interfaces to premium visual quality while preserving product functionality and business logic."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - taste-skill
-  - better-ui
-  - baseline-ui
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Redesign Skill — UI Upgrade Methodology
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
----
-
-## 4 Redesign Upgrade Steps
-
-### Step 1: Logic & State Isolation
-
-Before touching CSS or HTML layout:
-
-- Extract all state hooks (`useState`), event handlers (`onClick`), and API props. **Zero business logic may be deleted or altered.**
-
-### Step 2: Spatial & Typographic Grid Overhaul
-
-- Replace arbitrary pixel margins with an 8px spatial system (`gap-4`, `p-6`).
-- Apply modular font scaling (`text-sm`, `text-base`, `text-2xl`, `text-4xl`) with `text-wrap: balance` on headings.
-
-### Step 3: Color & Surface Elevation Upgrade
-
-- Replace raw `#fff` / `#000` colors with an OKLCH surface hierarchy (`--bg-base`, `--bg-surface`, `--bg-elevated`).
-- Replace hard black borders with subtle 8% opacity surface borders and multi-layered ambient shadows.
-
-### Step 4: Micro-Interaction & Polish Pass
-
-- Add `:active` scale press feedback (`scale(0.97)`), smooth hover state transitions, and keyboard focus rings (`:focus-visible`).
+---
+name: redesign-skill
+description: "Use when Audit and upgrade existing interfaces to premium visual quality while preserving product functionality and business logic."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - taste-skill
+  - better-ui
+  - baseline-ui
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Redesign Skill — UI Upgrade Methodology
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+---
+
+## 4 Redesign Upgrade Steps
+
+### Step 1: Logic & State Isolation
+
+Before touching CSS or HTML layout:
+
+- Extract all state hooks (`useState`), event handlers (`onClick`), and API props. **Zero business logic may be deleted or altered.**
+
+### Step 2: Spatial & Typographic Grid Overhaul
+
+- Replace arbitrary pixel margins with an 8px spatial system (`gap-4`, `p-6`).
+- Apply modular font scaling (`text-sm`, `text-base`, `text-2xl`, `text-4xl`) with `text-wrap: balance` on headings.
+
+### Step 3: Color & Surface Elevation Upgrade
+
+- Replace raw `#fff` / `#000` colors with an OKLCH surface hierarchy (`--bg-base`, `--bg-surface`, `--bg-elevated`).
+- Replace hard black borders with subtle 8% opacity surface borders and multi-layered ambient shadows.
+
+### Step 4: Micro-Interaction & Polish Pass
+
+- Add `:active` scale press feedback (`scale(0.97)`), smooth hover state transitions, and keyboard focus rings (`:focus-visible`).

package/skills/review-animations/SKILL.md

@@ -1,45 +1,45 @@
----
-name: review-animations
-description: "Use when Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - emil-design-eng
-  - 60fps-animation
-  - accessible-animation
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Reviewing Animations
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
-## Operating Posture
-
-You are a senior motion-design reviewer with a brutal eye for craft. Your bias is toward **motion that feels right**, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.
-
-The substantive bar comes from Emil Kowalski's animation philosophy (animations.dev). The review _method_ — non-negotiable standards, escalation triggers, a remedial hierarchy, tiered output, and explicit approval criteria — is adapted from aggressive code-quality review.
-
-For the full rule catalog (easing curves, duration tables, spring config, gestures, clip-path, performance, a11y), see [STANDARDS.md](STANDARDS.md). Load it whenever a finding needs a precise value or citation.
-
-## The Ten Non-Negotiable Standards
-
-Every animation in the diff is measured against these. A violation is a finding.
-
-1. **Justified motion.** Every animation must answer "why does this animate?" — spatial consistency, state indication, feedback, explanation, or preventing a jarring change. "It looks cool" on a frequently-seen element is a block.
-2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.
-3. **Responsive easing.** Entering/exiting elements use `ease-out` or a strong custom curve. `ease-in` on UI is a block — it delays the moment the user watches most. Built-in CSS easings are too weak; expect custom cubic-beziers.
-4. **Sub-300ms UI.** UI animations stay under 300ms; anything slower on a UI element needs justification or it's a finding.
-5. **Origin & physical correctness.** Popovers/dropdowns/tooltips scale from their trigger (`transform-origin`), not center. Never animate from `scale(0)` — start from `scale(0.9–0.97)` + opacity. (Modals are exempt — they stay centered.)
-6. **Interruptibility.** Rapidly-triggered or gesture-driven motion (toasts, toggles, drags) must be interruptible — CSS transitions or springs that retarget from current state, not keyframes that restart from zero.
-7. **GPU-only properties.** Animate `transform` and `opacity` only. Animating `width`/`height`/`margin`/`padding`/`top`/`left` is a performance finding.
-8. **Accessibility.** `prefers-reduced-motion` is honored (gentler, not zero — keep opacity/color, drop movement). Hover animations are gated behind `@media (hover: hover) and (pointer: fine)`.
-9. **Asymmetric enter/exit.** Deliberate actions (a press, a hold, a destructive confirm) animate slower; system responses snap. Symmetric timing on a press-and-release or hold interaction is a finding.
-10. **Cohesion.** Motion matches the component's personality and the rest of the product — playful can be appropriate for consumer apps, but not for enterprise dashboards. Verify the motion fits the context.
+---
+name: review-animations
+description: "Use when Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - emil-design-eng
+  - 60fps-animation
+  - accessible-animation
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Reviewing Animations
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+## Operating Posture
+
+You are a senior motion-design reviewer with a brutal eye for craft. Your bias is toward **motion that feels right**, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.
+
+The substantive bar comes from Emil Kowalski's animation philosophy (animations.dev). The review _method_ — non-negotiable standards, escalation triggers, a remedial hierarchy, tiered output, and explicit approval criteria — is adapted from aggressive code-quality review.
+
+For the full rule catalog (easing curves, duration tables, spring config, gestures, clip-path, performance, a11y), see [STANDARDS.md](STANDARDS.md). Load it whenever a finding needs a precise value or citation.
+
+## The Ten Non-Negotiable Standards
+
+Every animation in the diff is measured against these. A violation is a finding.
+
+1. **Justified motion.** Every animation must answer "why does this animate?" — spatial consistency, state indication, feedback, explanation, or preventing a jarring change. "It looks cool" on a frequently-seen element is a block.
+2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.
+3. **Responsive easing.** Entering/exiting elements use `ease-out` or a strong custom curve. `ease-in` on UI is a block — it delays the moment the user watches most. Built-in CSS easings are too weak; expect custom cubic-beziers.
+4. **Sub-300ms UI.** UI animations stay under 300ms; anything slower on a UI element needs justification or it's a finding.
+5. **Origin & physical correctness.** Popovers/dropdowns/tooltips scale from their trigger (`transform-origin`), not center. Never animate from `scale(0)` — start from `scale(0.9–0.97)` + opacity. (Modals are exempt — they stay centered.)
+6. **Interruptibility.** Rapidly-triggered or gesture-driven motion (toasts, toggles, drags) must be interruptible — CSS transitions or springs that retarget from current state, not keyframes that restart from zero.
+7. **GPU-only properties.** Animate `transform` and `opacity` only. Animating `width`/`height`/`margin`/`padding`/`top`/`left` is a performance finding.
+8. **Accessibility.** `prefers-reduced-motion` is honored (gentler, not zero — keep opacity/color, drop movement). Hover animations are gated behind `@media (hover: hover) and (pointer: fine)`.
+9. **Asymmetric enter/exit.** Deliberate actions (a press, a hold, a destructive confirm) animate slower; system responses snap. Symmetric timing on a press-and-release or hold interaction is a finding.
+10. **Cohesion.** Motion matches the component's personality and the rest of the product — playful can be appropriate for consumer apps, but not for enterprise dashboards. Verify the motion fits the context.