tribunal-kit 2.4.6 → 3.0.0

package/.agent/workflows/changelog.md

@@ -1,144 +1,112 @@
----
-description: Auto-generate changelogs from git history. Categorizes changes by type and follows Keep a Changelog format.
----
-
-# /changelog — Generate Change History
-
-$ARGUMENTS
-
----
-
-This command generates a structured changelog from git history. It reads real commits and categorizes them — it never invents changes that don't exist.
-
----
-
-## When to Use This
-
-- Before a release to document what changed
-- When preparing release notes for stakeholders
-- To create or update `CHANGELOG.md`
-- To summarize work completed in a sprint or between two tags
-
----
-
-## What Happens
-
-### Stage 1 — Determine Range
-
-Default range: commits since the last tag. Override with:
-
-```bash
-# Default: since last tag
-// turbo
-git log $(git describe --tags --abbrev=0)..HEAD --oneline --format="%h %ad %s" --date=short
-
-# Last N commits
-git log -n 20 --oneline --format="%h %ad %s" --date=short
-
-# Between specific tags
-git log v1.0.0..v2.0.0 --oneline --format="%h %ad %s" --date=short
-
-# Since a date
-git log --since="2025-01-01" --oneline --format="%h %ad %s" --date=short
-```
-
-If no tags exist: default to last 20 commits and flag no tags found.
-
-### Stage 2 — Collect and Categorize
-
-Read the git log and categorize each commit by prefix:
-
-| Commit Prefix | Category | Icon |
-|---|---|---|
-| `feat:`, `feature:`, `add:` | Features | ✨ |
-| `fix:`, `bugfix:`, `hotfix:` | Fixes | 🐛 |
-| `refactor:`, `cleanup:` | Refactors | ♻️ |
-| `docs:`, `doc:` | Documentation | 📝 |
-| `test:`, `tests:` | Tests | ✅ |
-| `chore:`, `build:`, `ci:` | Maintenance | 🔧 |
-| `perf:`, `performance:` | Performance | ⚡ |
-| `security:`, `sec:` | Security | 🔒 |
-| `BREAKING:`, `breaking:`, `!` after scope | Breaking Changes | 💥 |
-| (no recognized prefix) | Other | 📦 |
-
-### Stage 3 — Generate Output
-
-Output follows [Keep a Changelog](https://keepachangelog.com/) format:
-
-```markdown
-# Changelog
-
-## [Unreleased] — YYYY-MM-DD
-
-### 💥 Breaking Changes
-- `abc1234` — Description of breaking change
-
-### ✨ Features
-- `def5678` — Description of new feature
-
-### 🐛 Fixes
-- `ghi9012` — Description of bug fix
-
-### ⚡ Performance
-- `jkl3456` — Description of performance improvement
-
-### 🔒 Security
-- `mno7890` — Description of security fix
-
-### ♻️ Refactors
-- `pqr1234` — Description of refactor
-
-### 📝 Documentation
-- `stu5678` — Description of docs change
-
-### 🔧 Maintenance
-- `vwx9012` — Description of chore/dependency bump
-```
-
-### Stage 4 — Review and Save
-
-Present the generated summary before writing:
-
-```
-📋 Generated changelog from [range]:
-  💥 1 breaking change
-  ✨ 3 features
-  🐛 5 fixes
-  📦 2 uncategorized commits
-
-Save to CHANGELOG.md? [Y = append | N = cancel | S = stdout only]
-```
-
-> ⏸️ **Human Gate** — CHANGELOG.md is not written without confirmation.
-
----
-
-## Hallucination Guard
-
-- **Only include commits that actually exist** in git history — read from `git log`, never invent
-- **Never summarize or paraphrase** ambiguous commit messages — include verbatim if unclear
-- **Always show the commit hash** for traceability beside each entry
-- **Never infer intent** from a commit message — report what was written, not what it "probably meant"
-- Breaking changes need to be explicitly labeled in the commit — never infer breakage from code
-
----
-
-## Cross-Workflow Navigation
-
-| After /changelog reveals... | Go to |
-|---|---|
-| Many uncategorized commits | Enforce commit conventions in the team |
-| Breaking changes need documentation | Update API docs or migration guides |
-| Ready for release | `/deploy` to complete the release pipeline |
-
----
-
-## Usage
-
-```
-/changelog since the last release
-/changelog for the last 50 commits
-/changelog between v1.0 and v2.0
-/changelog generate and save to CHANGELOG.md
-/changelog sprint summary since 2025-03-01
-```
+---
+description: Auto-generate changelogs from git history. Categorizes commits by type (feat/fix/chore/breaking) and follows Keep a Changelog format. Requires conventional commit messages for accurate categorization.
+---
+
+# /changelog — Git History to Changelog
+
+$ARGUMENTS
+
+---
+
+## When to Use /changelog
+
+| Use `/changelog` when... | |
+|:---|:---|
+| Preparing a release | Generate for specific version range |
+| Documenting recent changes | Generate since last tag |
+| Onboarding someone to codebase history | Generate entire history |
+
+---
+
+## Commit Convention (Required for Accuracy)
+
+```
+Format: <type>(<scope>): <description>
+
+Types:
+  feat:     New functionality (appears in "Added")
+  fix:      Bug fix (appears in "Fixed")
+  chore:    Maintenance, deps (appears in "Changed")
+  docs:     Documentation only
+  perf:     Performance improvement (appears in "Changed")
+  refactor: Internal restructuring (appears in "Changed")
+  test:     Test-only changes
+  BREAKING CHANGE: Footer or body annotation (appears in "Breaking Changes")
+```
+
+---
+
+## Git Log Commands
+
+```bash
+# Since last tag
+git log $(git describe --tags --abbrev=0)..HEAD --oneline --no-merges
+
+# Since a specific date
+git log --since="2026-01-01" --oneline --no-merges
+
+# Since specific commit
+git log abc123def..HEAD --oneline --no-merges
+
+# With full commit message (for BREAKING CHANGE in body)
+git log $(git describe --tags --abbrev=0)..HEAD --format="%H %s%n%b"
+```
+
+---
+
+## Output Format (Keep a Changelog)
+
+```markdown
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [1.2.0] — 2026-04-02
+
+### Breaking Changes
+- **auth**: JWT token format changed — clients must re-authenticate ([abc123](link))
+
+### Added
+- User notification system with email and in-app alerts ([def456](link))
+- Pagination on /api/users endpoint with meta.total in response ([ghi789](link))
+
+### Fixed
+- JWT verify no longer accepts 'none' algorithm ([jkl012](link))
+- Checkout form no longer loses data on page refresh ([mno345](link))
+
+### Changed
+- Upgraded Prisma 5 to 6 — findOne calls migrated to findUnique ([pqr678](link))
+- Bundle size reduced 64% via dynamic import for chart library ([stu901](link))
+
+## [1.1.0] — 2026-03-15
+[...]
+
+[Unreleased]: https://github.com/user/repo/compare/v1.2.0...HEAD
+[1.2.0]: https://github.com/user/repo/compare/v1.1.0...v1.2.0
+```
+
+---
+
+## Semver Decision Guide
+
+```
+MAJOR (1.0.0 → 2.0.0): Any BREAKING CHANGE
+MINOR (1.0.0 → 1.1.0): New features, backward-compatible (feat:)  
+PATCH (1.0.0 → 1.0.1): Bug fixes only (fix:)
+```
+
+---
+
+## Usage Examples
+
+```
+/changelog since last release tag
+/changelog for version 1.2.0 including all commits since v1.1.0
+/changelog since 2026-01-01
+/changelog what changed in the authentication module this month
+```

package/.agent/workflows/create.md

@@ -1,139 +1,124 @@
----
-description: Create new application command. Triggers App Builder skill and starts interactive dialogue with user.
----
-
-# /create — Build Something New
-
-$ARGUMENTS
-
----
-
-This command starts a structured creation process. **Code only appears after requirements are clear and a plan is approved.** Building before understanding is the number one source of wasted work.
-
----
-
-## When to Use /create vs Other Commands
-
-| Use `/create` when... | Use something else when... |
-|---|---|
-| Starting something from scratch | Extending existing code → `/enhance` |
-| Building a complete feature (frontend + backend + DB) | Single function needed → `/generate` |
-| You need a plan before code | Plan only, no code → `/plan` |
-| Multi-domain coordination required | Single domain → `/generate` with right tribunal |
-
----
-
-## The Four Stages
-
-### Stage 1 — Understand (not optional)
-
-Before any planning begins, these four things must be established:
-
-```
-1. What is the user's actual goal?     (not the feature — the outcome)
-2. What stack are we working in?       (existing project or greenfield?)
-3. What is explicitly out of scope?    (boundary prevents scope creep)
-4. What's the observable done state?   (how do we know it's finished?)
-```
-
-**If anything is unclear → ask. Do not skip to Stage 2 on assumptions.**
-
-Minimum Socratic gate questions by project type:
-
-| Project type | Questions to ask before planning |
-|---|---|
-| API / backend | Auth strategy? Database? Error format? Rate limiting? |
-| Frontend / UI | Framework? Design system? State management? SSR? |
-| Full-stack | All of the above + deployment target |
-| CLI tool | Target OS? Binary or script? Package manager integration? |
-
----
-
-### Stage 2 — Plan
-
-Engage `project-planner` to write a structured plan:
-
-```
-Location: docs/PLAN-{task-slug}.md
-
-Must contain:
-  - Goal (one sentence)
-  - Out-of-scope list (what we won't build in this version)
-  - Open questions with [VERIFY] tags
-  - Task table: task / agent / dependency / done-condition
-  - Tribunal gate per task
-  - Time estimates: optimistic / realistic / pessimistic + confidence level
-```
-
-**The plan is shown to the user before any code is written.**
-
-> ⏸️ "Here's the plan: `docs/PLAN-{slug}.md` — proceed?"
-> Do not advance until explicitly confirmed with **Y**.
-
----
-
-### Stage 3 — Build (Parallel agents, after approval)
-
-| Layer | Primary Agent | Review Gate |
-|---|---|---|
-| Data schema / migrations | `database-architect` | `/tribunal-database` |
-| API & server logic | `backend-specialist` | `/tribunal-backend` |
-| UI & components | `frontend-specialist` | `/tribunal-frontend` |
-| Test coverage | `test-engineer` | `logic + test-coverage-reviewer` |
-| DevOps / deploy config | `devops-engineer` | `/tribunal-backend` |
-
-Each agent's code goes through Tribunal before being shown to the user.
-
-**Wave execution (if multiple layers):**
-
-```
-Wave 1: database-architect → reviewed → Human Gate
-Wave 2: backend-specialist (uses Wave 1 schema) → reviewed → Human Gate
-Wave 3: frontend-specialist + test-engineer (parallel) → reviewed → Human Gate
-```
-
----
-
-### Stage 4 — Verify
-
-```
-□ Did the code satisfy every done-condition from Stage 1?
-□ Did all Tribunal reviewers return APPROVED?
-□ Are untested paths labeled // TODO with an explanation?
-□ Does the plan file match what was actually built?
-```
-
-All four must be checked before the task is declared done.
-
----
-
-## Hallucination Rules
-
-- Every import must exist in the project's `package.json` or carry `// VERIFY: add to deps`
-- No invented framework methods — `// VERIFY: check docs for this method` on any uncertain call
-- No agent touches code outside its domain (frontend agent never writes DB migrations)
-- No full-application generation in one shot — build in layers with Human Gates between waves
-
----
-
-## Cross-Workflow Navigation
-
-| If during /create you need to... | Go to |
-|---|---|
-| Understand the existing codebase first | Use `explorer-agent` before Stage 2 |
-| Only write the plan (not build it) | `/plan` |
-| Add to an already built feature | `/enhance` |
-| Debug something during Stage 3 | `/debug` |
-| Run a full safety check before shipping | `/audit` |
-
----
-
-## Usage
-
-```
-/create a REST API with JWT auth
-/create a React dashboard with real-time chart updates
-/create a complete user onboarding flow (frontend + backend + DB)
-/create a CLI tool that validates JSON schemas against a spec
-/create a scheduled background job for sending email digests
-```
+---
+description: Create new application command. Triggers full stack creation from requirements gathering → stack selection → scaffolding → Tribunal code generation. Everything through the pipeline before writing a single file.
+---
+
+# /create — Full Application Builder
+
+$ARGUMENTS
+
+---
+
+## When to Use /create
+
+| Use `/create` when... | Use something else when... |
+|:---|:---|
+| Starting a new project from scratch | Adding to an existing project → `/enhance` |
+| No codebase exists yet | Generating a focused code snippet → `/generate` |
+| You need a working scaffold with structure | Planning and understanding → `/plan` |
+
+---
+
+## Phase 1 — Requirements Gathering (Socratic Gate)
+
+Before a single line of code is written, the `app-builder` agent asks these questions:
+
+```
+1. What does this application DO? (one sentence — the core user action)
+2. Who uses it? (end users, internal team, API consumers)
+3. What is the target platform? (web, mobile, server, CLI, desktop)
+4. Are there any tech constraints? (must use X, must run on Y)
+5. What data does it store? (users, products, documents, real-time events)
+6. Is authentication required? (yes/no/type: email, OAuth, API key)
+7. Are there external integrations? (Stripe, OpenAI, Twilio, etc.)
+```
+
+No scaffolding starts until all questions are answered.
+
+---
+
+## Phase 2 — Stack Selection
+
+Based on the answers, the agent selects the appropriate stack:
+
+| App Type | Recommended Stack |
+|:---|:---|
+| Web app (content + interaction) | Next.js 15, TypeScript, Tailwind v4, Prisma |
+| API server only | Hono on Node 22, Zod, TypeScript |
+| Real-time app | Next.js 15 + WebSocket (Socket.io) or SSE |
+| Mobile app | Expo + React Native, Expo Router v4 |
+| CLI tool | Node 22, Commander.js, TypeScript |
+| E-commerce | Next.js 15 + Stripe + Prisma |
+
+Stack selection is presented to the user for approval before scaffolding begins.
+
+---
+
+## Phase 3 — Scaffolding Plan
+
+The agent produces an implementation plan showing:
+
+```
+Files to create:
+├── Core structure (package.json, tsconfig, config files)
+├── Database schema (prisma/schema.prisma)
+├── Authentication setup (auth.ts, middleware.ts)
+├── Core API routes or Server Actions
+├── Base UI components and layouts
+└── Initial tests and CI pipeline
+```
+
+> **Human Gate:** User approves the plan before any files are written.
+
+---
+
+## Phase 4 — Tribunal Generation
+
+All generated code runs through the Tribunal pipeline:
+
+```
+Maker generates each module individually
+    → logic-reviewer + security-auditor on every module
+    → domain-specific reviewers activated by module type
+    → Human Gate before each major file group is written
+```
+
+No module is written without passing Tribunal review.
+
+---
+
+## Phase 5 — Verification
+
+After scaffolding:
+
+```
+□ npm install completes without errors
+□ npx tsc --noEmit passes clean
+□ npm run dev starts successfully
+□ npm test runs and passes (for any generated tests)
+□ Linting passes (if configured)
+```
+
+---
+
+## Hallucination Guard (Create-Specific)
+
+```
+❌ Never generate the entire application as one massive code block
+❌ Never import packages not added to package.json in this session
+❌ Never assume a framework's default file structure — check with --help or docs
+❌ Never hardcode environment variables in generated files
+❌ Never use deprecated Next.js 13/14 patterns (pages/, getServerSideProps)
+❌ Never use React 18 hooks deprecated in React 19
+```
+
+---
+
+## Usage Examples
+
+```
+/create a REST API for a todo app with JWT auth and PostgreSQL
+/create a Next.js 15 e-commerce site with Stripe and Prisma
+/create a CLI tool for generating Tribunal-compliant code reviews
+/create an Expo app for tracking workout sessions with offline support
+/create a real-time chat app using Next.js and Server-Sent Events
+```