tribunal-kit 5.8.4 → 6.0.0

package/.agent/workflows/debug.md

@@ -1,6 +1,15 @@
 ---
 description: Debugging command. Activates DEBUG mode for systematic problem investigation using the 4-phase methodology (Collect → Hypothesize → Test → Fix). No fix is suggested until the root cause is confirmed and tested. No random changes. No guessing.
-required-skills: systematic-debugging
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - systematic-debugging
+  - test-result-analyzer
+  - clean-code
+scripts-binding:
+  - .agent/scripts/test_runner.js
+  - .agent/scripts/lint_runner.js
 ---
 
 # /debug — Root Cause Investigation
@@ -9,16 +18,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE hypothesizing:
-□ Error output / stack trace  → Exact error text, not a paraphrase
-□ Target file                → The file referenced in the error
-□ git diff (recent changes)  → What changed since last working state
-□ .env / .env.example        → Check for missing/rotated secrets
-□ package.json               → Check for recent dependency changes
-```
+Before investigating or attempting any code modification during a bug report, you MUST inspect:
+1. Exact Error Traceback / Stack Log → Read raw error logs without paraphrasing; ban making diagnostic hypotheses without tracebacks
+2. Target File & Callers → Inspect file referenced in error trace along with its upstream callers
+3. Recent Changes (`git diff`) → Inspect recent edits to identify regressions before mutating code
 
 ---
 

package/.agent/workflows/deploy.md

@@ -1,6 +1,16 @@
 ---
 description: Production deployment command. Runs pre-flight safety checks (tests, type-check, lint, security, build), creates a rollback baseline, confirms Human Gate, then executes deployment. Requires explicit human approval before going live.
-required-skills: deployment-procedures, devops-engineer
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - deployment-procedures
+  - devops-engineer
+  - verify_all
+scripts-binding:
+  - .agent/scripts/verify_all.js
+  - .agent/scripts/security_scan.js
+  - .agent/scripts/bundle_analyzer.js
 ---
 
 # /deploy — Production Deployment
@@ -9,14 +19,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE deploying:
-□ package.json                → Identify build/test scripts
-□ CI/CD configs               → GitHub Actions, render.yaml, fly.toml
-□ Database schema             → Check if migrations are pending
-```
+Before triggering production deployment or executing deploy scripts, you MUST inspect:
+1. Full Pre-Flight Verification Suite (`verify_all.js`) → Verify tests, type-checking, lint, security scans, and production build output cleanly
+2. CI/CD Manifests (`.github/workflows`, `fly.toml`, `render.yaml`, etc.) → Check deployment targets and environment variable requirements
+3. Human Gate & Rollback Baseline → Confirm baseline git tag/commit and secure explicit human approval before publishing release
 
 ---
 

package/.agent/workflows/enhance.md

@@ -1,6 +1,15 @@
 ---
 description: Add or update features in existing applications. Performs impact analysis before any code change — identifies all dependents, detects breaking changes, generates Tribunal-reviewed modifications. No change is written to disk without Human Gate approval.
-required-skills: clean-code
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - clean-code
+  - codebase-design
+  - test-engineer
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/test_runner.js
 ---
 
 # /enhance — Feature Addition & Modification
@@ -9,16 +18,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE any modification:
-□ Target file              → Understand current implementation
-□ Target file's importers  → Map the impact zone (grep callers)
-□ package.json             → Verify dependencies exist
-□ tsconfig.json            → Understand path aliases and strictness
-□ Related test files        → Know what tests exist for this module
-```
+Before modifying existing features or appending functionality, you MUST inspect:
+1. Impact Zone Identification → Grep for all callers and importers of the target file to map blast radius
+2. Existing Contract & Unit Tests → Inspect existing tests and type signatures for the target module to prevent regression
+3. Breaking Change Detection → Ensure signature changes update all dependent call sites simultaneously before writing to disk
 
 ---
 

package/.agent/workflows/fix.md

@@ -1,6 +1,15 @@
 ---
 description: Auto-fix known issues with lint, formatting, imports, and TypeScript errors. Runs lint_runner.js and auto-fixers. Human approval required before applying any changes. Shows a diff of what will change before writing to disk.
-required-skills: lint-and-validate, clean-code
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - lint-and-validate
+  - clean-code
+  - typescript-advanced
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
 ---
 
 # /fix — Automated Error Resolution
@@ -9,14 +18,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE fixing:
-□ package.json                → Identify lint/format tools and scripts
-□ tsconfig.json               → Understand strictness levels
-□ .eslintrc / prettierrc      → Understand code style rules
-```
+Before executing auto-fixers or modifying code files to resolve lint/type issues, you MUST inspect:
+1. Workspace Linter & Compiler Settings (`tsconfig.json`, `.eslintrc`, `biome.json`) → Confirm rule strictness and formatting standards
+2. Target File Lint Output → Execute `node .agent/scripts/lint_runner.js` to gather precise error line numbers and rule IDs
+3. Diff Verification Before Disk Write → Show explicit diff of proposed changes and confirm Human Gate approval before saving
 
 ---
 

package/.agent/workflows/generate.md

@@ -1,6 +1,16 @@
 ---
 description: Generate code using the full Tribunal Anti-Hallucination pipeline. Maker generates grounded in real project context at low temperature → domain-selected reviewers audit in parallel → Human Gate for final approval. Nothing is written to disk without explicit approval.
-required-skills: auto-detected from request keywords (see Reviewer Auto-Selection table)
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - clean-code
+  - codebase-design
+  - lint-and-validate
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/security_scan.js
+  - .agent/scripts/verify_all.js
 ---
 
 # /generate — Hallucination-Free Code Generation
@@ -9,16 +19,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE generating any code (MANDATORY — never skip):
-□ package.json      → Verify all imports exist before using them
-□ tsconfig.json     → Understand strictness, paths aliases, target version
-□ context/*.acf     → Load explicit goals, rules, and boundaries
-□ .env.example      → Know available environment variables
-□ Referenced files   → Understand actual data shapes and types
-```
+Before generating code modules or invoking the Maker pipeline, you MUST inspect:
+1. Workspace Package Dependencies (`package.json`) → Confirm all imported libraries exist; ban unverified phantom imports
+2. Type Definitions & Path Aliases (`tsconfig.json`) → Verify module resolution paths and compiler strictness
+3. Parallel Tribunal Review Assignment → Select relevant domain reviewers (`logic`, `security`, `frontend`, `backend`, `database`, `mobile`) prior to Human Gate submission
 
 ---
 
@@ -128,7 +134,7 @@ complexity-reviewer→ Enforces the Dependency Ladder to prevent over-engineerin
 | `aria`, `wcag`, `a11y`, `accessibility`                     | `accessibility-reviewer` + `ui-ux-auditor`                     |
 | `import`, `package`, `npm`, `require`                       | `dependency-reviewer`                                          |
 
-> For maximum safety on critical code: use `/tribunal-full` for all 19 reviewers simultaneously.
+> For maximum safety on critical code: use `/tribunal-full` for all 21 reviewers simultaneously.
 
 ---
 

package/.agent/workflows/marathon.md

@@ -1,6 +1,15 @@
 ---
 description: Long-running agent harness for multi-session projects. Decomposes specs into atomic features tracked in JSON, ensures clean handoffs between sessions, and provides structured progress tracking. Based on Anthropic's long-running agent patterns.
-required-skills: harness-protocol, agent-organizer
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - harness-protocol
+  - agent-organizer
+  - project-planner
+scripts-binding:
+  - .agent/scripts/session_manager.js
+  - .agent/scripts/verify_all.js
 ---
 
 # /marathon — Long-Running Agent Harness
@@ -9,14 +18,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE marathon start/continue:
-□ progress.json               → See current marathon state
-□ feature_list.json           → View remaining tasks
-□ git log --oneline -5        → Check recent commits
-```
+Before initiating or resuming a multi-session marathon harness, you MUST inspect:
+1. Marathon State Ledger (`progress.json`, `feature_list.json`) → Verify current session index, completed features, and active task
+2. Session Continuity Manager (`.agent/scripts/session_manager.js`) → Verify state snapshot before context truncation
+3. Atomic Feature Handoff Protocol → Ensure each session completes exactly ONE atomic feature, runs `verify_all.js`, and commits state before handoff
 
 ---
 

package/.agent/workflows/migrate.md

@@ -1,6 +1,16 @@
 ---
 description: Migration workflow for framework upgrades, dependency bumps, and database migrations. Impact analysis first, expand-and-contract for DB, dependency compatibility matrix before upgrading, rollback tested before deploy.
-required-skills: plan-writing, architecture
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - plan-writing
+  - architecture
+  - database-design
+scripts-binding:
+  - .agent/scripts/dependency_analyzer.js
+  - .agent/scripts/schema_validator.js
+  - .agent/scripts/verify_all.js
 ---
 
 # /migrate — Safe Migration Execution
@@ -9,14 +19,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE migrating:
-□ package.json                → Identify current vs target dependency versions
-□ Target files/schemas         → Understand the exact structural changes needed
-□ Release notes/Changelogs     → Understand breaking changes in the target version
-```
+Before running framework upgrades, major dependency bumps, or database migrations, you MUST inspect:
+1. Dependency Compatibility Matrix (`dependency_analyzer.js`) → Verify target version peer dependencies and breaking changes
+2. Database Expand-and-Contract Plan (`schema_validator.js`) → Ensure database column changes add new fields before dropping old ones
+3. Rollback Protocol Verification → Test local rollback procedure (e.g. SQLite backup or DB transaction revert) before applying migration
 
 ---
 

package/.agent/workflows/minimal.md

@@ -0,0 +1,94 @@
+---
+description: Analyze requested implementation for minimal viable change. Enforces the 7-level Decision Order (NO_CHANGE to CREATE), Change Budget estimation, Minimality Score (0-100), Complexity Flags detection, and repository search.
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 6.0.0
+last-updated: 2026-07-30
+required-skills:
+  - clean-code
+  - codebase-design
+scripts-binding:
+  - .agent/scripts/minimal_change_engine.js
+  - .agent/scripts/case_law_manager.js
+---
+
+# /minimal — Minimal Change Governance Workflow
+
+$ARGUMENTS
+
+---
+
+## Mandatory Pre-Flight Context Inspection
+
+Before proposing any code change, you MUST evaluate the **10 Core Governance Questions**:
+1. Does anything need to change? (`NO_CHANGE`)
+2. Does the repository already solve this? (`REUSE`)
+3. Does an existing function, component, utility, service, or abstraction solve it? (`REUSE`)
+4. Does the language standard library solve it? (`REUSE`)
+5. Does the framework or platform solve it? (`REUSE`)
+6. Does an existing dependency solve it? (`REUSE`)
+7. Is configuration enough? (`CONFIGURE`)
+8. Is deletion or simplification better than addition? (`DELETE`)
+9. Is the proposed abstraction necessary for the current requirement? (`MODIFY`/`EXTEND`)
+10. What is the smallest implementation that satisfies the request? (`MODIFY`/`EXTEND` vs `CREATE`)
+
+---
+
+## Sub-Commands
+
+| Command | Description |
+| :--- | :--- |
+| `/minimal` | Analyze requested implementation and determine smallest viable change footprint |
+| `/minimal-review` | Review proposed change diff for unnecessary complexity and file proliferation |
+| `/change-budget` | Display estimated Change Budget (files added/modified, lines, deps, abstractions) |
+| `/complexity-audit` | Audit proposal for 14 standardized complexity flags and overengineering patterns |
+| `/reuse-check` | Search repository for existing functions, symbols, and utilities before creating code |
+
+---
+
+## Decision Order Hierarchy
+
+Evaluate solutions strictly in this order:
+```
+NO_CHANGE ➔ REUSE ➔ CONFIGURE ➔ DELETE ➔ MODIFY ➔ EXTEND ➔ CREATE
+```
+
+---
+
+## Output Schema
+
+```
+━━━ Minimal Change Governance Audit ━━━━━━━━━━━━━━━━━━━━━━
+
+Minimality Score:          88/100 (PASSED)
+Decision Classification:   MODIFY
+Strictness Mode:           balanced
+
+━━━ Change Budget ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+files_added:               0
+files_modified:            2
+dependencies_added:        0
+new_abstractions:          0
+estimated_lines_added:     14
+estimated_lines_removed:    4
+
+━━━ Complexity Flags ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ None detected
+
+━━━ Reuse Opportunities ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+- Extend src/utils/http.ts for retry policy rather than creating a new service file
+
+━━━ Recommendation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Proceed with MODIFY strategy on src/utils/http.ts
+```
+
+---
+
+## Usage Examples
+
+```
+/minimal add request retry handling to API calls
+/minimal-review src/services/retryQueue.ts
+/change-budget
+/complexity-audit
+/reuse-check fetchRetry
+```

package/.agent/workflows/orchestrate.md

@@ -1,6 +1,15 @@
 ---
 description: Coordinate multiple agents for complex tasks. Use for multi-perspective analysis, comprehensive reviews requiring different domain expertise, or tasks where a single agent would miss domain-specific failures. Fan-Out dispatch → parallel execution → Fan-In synthesis → Human Gate.
-required-skills: agent-organizer, parallel-agents
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - agent-organizer
+  - parallel-agents
+  - swarm-dispatcher
+scripts-binding:
+  - .agent/scripts/swarm_dispatcher.js
+  - .agent/scripts/verify_all.js
 ---
 
 # /orchestrate — Multi-Agent Coordination
@@ -9,14 +18,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE orchestrating:
-□ Target scope                → Identify the boundaries of the review/task
-□ Agent list                  → Determine which specialist agents are needed
-□ Context budget              → Determine how to split files among agents
-```
+Before dispatching multi-agent orchestrations or parallel sub-task workers, you MUST inspect:
+1. Orchestrator Payload Validator (`swarm_dispatcher.js`) → Validate subagent payload contracts and JSON schema before fan-out
+2. Context Window Budget Allocation → Provide scoped `context_summary` per worker; ban dumping full conversation history to workers
+3. Fan-In Synthesis & Human Gate → Collect all worker outputs via `Promise.allSettled()` pattern and present unified synthesis before writing disk changes
 
 ---
 

package/.agent/workflows/performance-benchmarker.md

@@ -1,6 +1,15 @@
 ---
 description: Run standardized performance benchmarks including Lighthouse CI, bundle analysis, and API latency checks. Records before/after metrics. No optimization claims without measured evidence.
-required-skills: performance-profiling, vitals-reviewer
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - performance-profiling
+  - vitals-reviewer
+  - 60fps-animation
+scripts-binding:
+  - .agent/scripts/bundle_analyzer.js
+  - .agent/scripts/verify_all.js
 ---
 
 # /performance-benchmarker — Evidence-Based Performance Measurement
@@ -9,14 +18,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE benchmarking:
-□ package.json                → Identify build/start scripts and profiling tools
-□ Application URL             → Verify the local URL and port
-□ Database connection          → Verify if DB profiling is supported
-```
+Before running performance benchmarks or capturing latency metrics, you MUST inspect:
+1. Target App Environment & Build Command (`package.json`) → Confirm production build output and dev/preview server URL
+2. Benchmark Scripts Availability (`.agent/scripts/bundle_analyzer.js`) → Verify automated bundle and latency measurement tooling
+3. Before/After Metric Recording Constraint → Require side-by-side metric tables (LCP, CLS, INP, TTFB, Bundle Size) for every benchmark pass
 
 ---
 

package/.agent/workflows/pipeline.md

@@ -0,0 +1,155 @@
+---
+description: Hybrid 3-Pass Code Generation pipeline. Pass 1 (Planner) → Pass 2 (Builder) → Pass 3 (Zero-LLM Deterministic Validator). Maximizes code generation quality while keeping prompt context hyper-efficient.
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - clean-code
+  - codebase-design
+  - lint-and-validate
+scripts-binding:
+  - .agent/scripts/pipeline_engine.js
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/security_scan.js
+---
+
+# /pipeline — Hybrid 3-Pass Code Generation
+
+$ARGUMENTS
+
+---
+
+## Mandatory Pre-Flight Context Inspection
+
+Before running 3-pass pipeline generation, you MUST inspect:
+1. Pipeline Engine Script (`.agent/scripts/pipeline_engine.js`) → Verify availability and options (`--task`, `--file`, `--phase`)
+2. Context Token Allocation -> Keep Pass 2 builder prompt under 2,500 tokens (loading max 3 essential skill key-rules)
+3. Zero-LLM Pass 3 Validator → Run deterministic security, lint, and type checks on generated code prior to Human Gate submission
+
+## When to Use /pipeline
+
+| Use `/pipeline` when...                         | Use something else when...                     |
+| :---------------------------------------------- | :--------------------------------------------- |
+| Code generation quality is the top priority     | Quick single-line fix → direct edit            |
+| Context window saturation is causing weak output | Need full tribunal review → `/generate`        |
+| Building UI components, APIs, or complex logic  | Exploring options → `/brainstorm`              |
+| You want maximum LLM attention on code synthesis | Planning architecture → `/plan`                |
+
+---
+
+## Architecture
+
+```
+User Task → Pass 1 (Planner) → Pass 2 (Builder) → Pass 3 (Validator) → Human Gate
+              ~1,500 tokens     ~2,500 tokens       0 tokens (deterministic)
+```
+
+**vs. monolithic /generate: ~12,000–18,000 tokens in a single pass**
+
+---
+
+## Phase 1 — Plan (Automatic)
+
+The pipeline engine classifies the task, detects the stack, and selects 2-3 essential skills.
+
+```bash
+node .agent/scripts/pipeline_engine.js --task "$TASK" --file "$FILE" --phase plan --output json
+```
+
+Output: Structured spec JSON with task_type, stack, essential_skills, and constraints.
+
+**Human Gate**: Review the spec before proceeding to generation.
+
+---
+
+## Phase 2 — Build (Focused Generation)
+
+Assembles a minimal prompt containing ONLY:
+- The spec from Phase 1
+- 2-3 essential skill key-rules (condensed)
+- Target file content (if modifying existing code)
+
+```bash
+node .agent/scripts/pipeline_engine.js --task "$TASK" --file "$FILE" --phase build --output prompt
+```
+
+**What is NOT in the prompt (saving ~10,000 tokens):**
+- ❌ Full GEMINI.md master rules
+- ❌ Agent persona definitions
+- ❌ Tribunal gate rules
+- ❌ Error recovery protocol
+- ❌ Fabel Protocol cognitive loops
+- ❌ Unrelated domain skills
+
+The LLM receives a clean, focused prompt and can dedicate 75%+ of its attention to generating high-quality code.
+
+---
+
+## Phase 3 — Validate (Zero-LLM Deterministic)
+
+After code is generated, run deterministic validation:
+
+```bash
+node .agent/scripts/pipeline_engine.js --phase validate --code ./output.tsx
+```
+
+Checks:
+- ✅ OWASP security patterns (eval, innerHTML, hardcoded secrets, SQL injection)
+- ✅ TypeScript `any` usage
+- ✅ Empty catch blocks
+- ✅ Console.log pollution
+- ✅ Error handling gaps
+
+If validation fails → structured feedback is generated for automated retry (max 3 attempts).
+
+---
+
+## Full Pipeline (All Phases)
+
+```bash
+node .agent/scripts/pipeline_engine.js --task "$TASK" --file "$FILE" --output report
+```
+
+Or in dry-run mode:
+```bash
+node .agent/scripts/pipeline_engine.js --task "$TASK" --file "$FILE" --dry-run
+```
+
+---
+
+## Pipeline Guard
+
+```
+❌ Never load GEMINI.md into Pass 2 — the planner already distilled what's needed
+❌ Never skip Pass 3 validation — it's zero-cost (no LLM calls)
+❌ Never select more than 3 skills for a single generation pass
+❌ Never inject agent persona definitions into the builder prompt
+❌ Never bypass the Human Gate — even in pipeline mode
+```
+
+---
+
+## Comparison: /generate vs /pipeline
+
+| Dimension                     | `/generate` (current) | `/pipeline` (new)       |
+| :---------------------------- | :-------------------- | :---------------------- |
+| System prompt tokens          | ~12,000–18,000        | ~2,500 (Pass 2)         |
+| % context for actual task     | ~11%                  | ~75%                    |
+| Governance overhead           | ~89%                  | ~25%                    |
+| Post-gen validation           | LLM-based (expensive) | Deterministic (free)    |
+| Skills loaded per generation  | 6–10                  | 2–3                     |
+| Self-healing retry            | Full re-generation    | Targeted feedback loop  |
+| Backward compatibility        | N/A                   | 100% (additive)         |
+
+---
+
+## After /pipeline — Next Steps
+
+| Outcome                       | Next Command                        |
+| :---------------------------- | :---------------------------------- |
+| Code generated, needs review  | → `/review` for human audit         |
+| Code has issues after retry   | → `/generate` with full tribunal    |
+| Code passed, ready to test    | → `/test` for test generation       |
+| Code passed, ready to deploy  | → `/deploy` with pre-flight checks  |
+
+---

package/.agent/workflows/plan.md

@@ -1,6 +1,14 @@
 ---
 description: Create project plan using project-planner agent. 4-phase approach: Analyze → Research → Plan Document → Human Gate. NO code writing — only plan file generation. Writing begins only after explicit human approval.
-required-skills: plan-writing, architecture
+tools: Read, Grep, Glob, Bash, Edit, Write
+version: 3.0.0
+last-updated: 2026-07-30
+required-skills:
+  - plan-writing
+  - architecture
+  - project-planner
+scripts-binding:
+  - .agent/scripts/verify_all.js
 ---
 
 # /plan — Strategic Implementation Planning
@@ -9,16 +17,12 @@ $ARGUMENTS
 
 ---
 
-## $CONTEXT_REQUIRED
+## Mandatory Pre-Flight Context Inspection
 
-```
-Read BEFORE writing the plan:
-□ package.json             → Actual dependencies and scripts
-□ tsconfig.json            → TypeScript config and path aliases
-□ prisma/schema.prisma     → If DB changes planned (skip if not applicable)
-□ src/ directory listing   → Current project structure
-□ git log --oneline -5     → Recent work context
-```
+Before drafting implementation plans or technical blueprints, you MUST inspect:
+1. Workspace Context & Dependencies (`package.json`, `tsconfig.json`) → Confirm current stack capabilities and path mappings
+2. Existing Architecture & Directory Layout → Review current module boundaries to prevent redundant architectural patterns
+3. Zero Code Modification Rule → Restrict outputs in `/plan` mode to research, architectural design, and plan artifact generation; ban code generation before Plan approval
 
 ---