agentboot 0.1.0 → 0.3.0

package/CLAUDE.md

@@ -1,230 +0,0 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Commands
-
-```bash
-npm install          # Install dependencies (required before anything else)
-npm run validate     # Run pre-build validation checks
-npm run build        # Compile traits into persona output files
-npm run sync         # Distribute compiled output to target repos
-npm run clean        # Remove dist/
-npm run full-build   # clean → validate → build → dev-sync pipeline
-npm run dev-sync     # Copy dist/ to local repo for dogfooding (gitignored)
-npm run lint         # TypeScript type checking + lint
-npm run test         # Run vitest
-npm run test:watch   # Watch mode testing
-npm run typecheck    # TypeScript type checking (tsc --noEmit)
-npm run cli          # Run the agentboot CLI (e.g., npm run cli -- build)
-```
-
-The CLI (`scripts/cli.ts`) wraps all pipeline commands with proper argument parsing:
-```bash
-npx tsx scripts/cli.ts build [-c config]
-npx tsx scripts/cli.ts validate [--strict]
-npx tsx scripts/cli.ts sync [--repos-file path] [--dry-run]
-npx tsx scripts/cli.ts full-build
-npx tsx scripts/cli.ts --help
-```
-
-Run a single test file: `npx vitest run <path-to-test-file>`
-
-## Architecture
-
-AgentBoot is a **build tool** (not a runtime framework) that compiles agentic personas for distribution to target repos. The pipeline is: validate → compile → sync.
-
-### Core Concepts
-
-**Traits** (`core/traits/`) are reusable behavioral building blocks (e.g., `critical-thinking.md`, `source-citation.md`). They are composed at build time — never at runtime. (Trait weight configurations are a Phase 2 feature.)
-
-**Personas** (`core/personas/{name}/`) each contain:
-- `SKILL.md` — the agent definition with `<!-- traits:start -->` / `<!-- traits:end -->` injection markers
-- `persona.config.json` — build metadata specifying which traits to inject
-
-**Always-on Instructions** (`core/instructions/`) are universal guardrails distributed to every repo regardless of persona configuration.
-
-**Gotchas** (`core/gotchas/`) are path-scoped knowledge rules that encode battle-tested operational knowledge. They use `paths:` frontmatter to activate only for matching files and are compiled into `.claude/rules/` during build.
-
-### Build Pipeline
-
-1. **`scripts/validate.ts`** — 4 pre-build checks: persona existence, trait references, SKILL.md frontmatter, secret scanning
-2. **`scripts/compile.ts`** — loads `agentboot.config.json`, resolves trait references from `persona.config.json`, and emits **one self-contained folder per platform** under `dist/`:
-   - **`dist/skill/`** — cross-platform SKILL.md (agentskills.io format, traits inlined) + PERSONAS.md
-   - **`dist/claude/`** — CC-native: agents, skills, rules, traits, CLAUDE.md (`@imports`), settings.json, .mcp.json
-   - **`dist/copilot/`** — per-persona copilot-instructions.md fragments + instructions
-3. **`scripts/sync.ts`** — reads `repos.json`, reads from `dist/{platform}/`, merges scopes (core → group → team, team wins on conflicts), writes to target repos in platform-native locations, generates `.agentboot-manifest.json` with file hashes
-4. **`scripts/dev-sync.ts`** — copies `dist/{platform}/core/` to platform-native locations in the current repo for local dogfooding (gitignored output only, not the production sync)
-
-Each `dist/{platform}/` folder is self-contained. Scope hierarchy (core → groups → teams) is preserved within each platform folder. Duplication across platforms is intentional (generated files are cattle not pets). `full-build` runs dev-sync (not sync) to load compiled personas locally.
-
-### Scope Hierarchy
-
-Four-level hierarchy: Org → Group → Team → Repo. More specific scopes layer on top of general ones. For optional behaviors, team overrides group overrides core. For mandatory behaviors, inheritance is top-down (org wins). Scope merging happens in `sync.ts`. For public repos, repo-specific enrichments live in the hub under `public-repos/{repo}/` (not committed to the public repo) — see "Public repo pattern" in concepts.md.
-
-### Output Structure
-
-Compiled artifacts go to `dist/`, organized by platform first, then by scope:
-- `dist/skill/` — cross-platform SKILL.md (agentskills.io format, traits inlined) + persona.config.json + PERSONAS.md
-- `dist/claude/` — CC-native: agents, skills, rules, traits, CLAUDE.md (@imports), settings.json, .mcp.json, PERSONAS.md
-- `dist/copilot/` — per-persona copilot-instructions.md fragments + instructions + PERSONAS.md
-
-Cursor and Gemini output are planned for Phase 2.
-
-Within each platform folder, scope hierarchy is preserved:
-- `dist/{platform}/core/` — org-level personas
-- `dist/{platform}/groups/{group}/` — group-level overrides
-- `dist/{platform}/teams/{group}/{team}/` — team-level overrides
-
-### Distribution Model (Hub-and-Spoke)
-
-This repo acts as the **hub**. Target repos listed in `repos.json` are **spokes**. One-way flow: hub publishes compiled artifacts → spokes receive them. Spokes don't hold source of truth.
-
-### Configuration
-
-Everything is driven by `agentboot.config.json` (JSONC format). Key sections: `org`, `groups`, `personas.enabled`, `traits.enabled`, `instructions.enabled`, `sync.repos`, `sync.dryRun`.
-
-### Key Design Concepts
-
-All design ideas are documented in `docs/concepts.md`:
-
-**Core (Tier 1):** agentskills.io format, build-time trait composition, scope hierarchy, hub-and-spoke distribution, multi-format output. (Trait weight system — HIGH/MEDIUM/LOW — is designed but not yet implemented.)
-
-**High Value (Tier 2):** per-persona extensions, gotchas rules (path-scoped battle-tested knowledge), compliance hooks (3-layer defense-in-depth), ADR governance (permanent exception lifecycle), behavioral tests, self-improvement reflections (A→B→C), reviewer selection config.
-
-**V2+ (Tier 3):** HARD/SOFT guardrail elevation, team champions, SME discoverability fragment, MCP-first integrations, structured telemetry (GELF/NDJSON), persona arbitrator, autonomy progression (Advisory→Auto-approve→Autonomous), two-channel MDM distribution.
-
-**Anti-patterns:** overcommitting V1 scope, plain text logs, runtime trait inclusion, vendor-locked formats, forking base personas, deep inheritance hierarchies.
-
-See `docs/concepts.md` for full design rationale.
-
-### Delivery Methods
-
-`docs/delivery-methods.md` analyzes 8 delivery channels. Key decisions:
-- **CC Plugin** is the primary delivery method (native marketplace, force-enable via managed settings)
-- **CLI** (`agentboot`) is the build tool, not the end-user tool
-- **Managed settings** carry HARD guardrails only (compliance, not convenience)
-- **MCP server** is the cross-platform bridge for multi-agent orgs
-- **Cowork** extends reach to non-engineers via the same plugin format
-- `docs/org-connection.md` — how developers get their org's customizations (three-path strategy: managed settings, repo sync, self-service)
-
-### Privacy & Psychological Safety
-
-`docs/privacy-and-safety.md` — the prompt confidentiality model:
-- **Three tiers:** Private (raw prompts, never leave machine) → Privileged (LLM analysis via Claude API, developer approves sharing) → Organizational (persona output metrics, anonymized)
-- Raw prompts are NOT collected, transmitted, or exfiltrated. This is a design invariant, not a config option.
-- `/insights` sends transcripts to Claude API (same trust boundary already in use), extracts patterns not transcripts, developer sees first and approves sharing
-- Org dashboard shows persona effectiveness (rephrase rates, false positives, cost by team) — never individual prompts
-- Escalation exception for genuinely harmful content (exfiltration, guardrail circumvention, harassment) — flag category only, not transcript
-- High rephrase rates are framed as persona quality problems, not developer intelligence problems
-
-### Prompt & Cost Optimization
-
-`docs/prompt-optimization.md` — 8 sections covering the full optimization lifecycle:
-- `agentboot lint` — static prompt analysis (token budgets, vague language, conflicts, security)
-- Token budget system — per-persona context cost calculation and enforcement
-- Model selection matrix — Haiku/Sonnet/Opus guidance per persona type
-- `agentboot cost-estimate` — projected monthly cost per persona across the org
-- Effectiveness metrics — efficiency (tokens, cost, latency), quality (accuracy, false positive rate), business (adoption, bug escapes)
-- Prompt style guide — imperative voice, 20-rule max, falsifiable instructions, examples over descriptions
-- `agentboot test` — deterministic (free) + behavioral (LLM) + regression (snapshot) testing
-- Continuous optimization loop — weekly review process with metrics-driven prompt improvements
-
-### CLI Design
-
-`docs/cli-design.md` — standalone binary via `brew install agentboot`:
-- `agentboot setup` — interactive wizard that detects role/tools/org and executes the right setup
-- `agentboot build/sync/export/publish` — build pipeline for platform teams
-- `agentboot connect` — developer self-service org connection
-- `agentboot doctor/status` — diagnostics and deployment dashboard
-- `agentboot add` — scaffold personas, traits, domains, gotchas, hooks; `add prompt` ingests raw prompts
-- `agentboot discover` — scan repos/machines for existing agentic content, overlap analysis, migration plan
-- Distributed via brew/apt/choco (zero runtime deps), npm/npx as fallback
-
-### Knowledge Layer
-
-`docs/knowledge-layer.md` — three-stage progression from flat files to RAG:
-- **Stage 1 (Flat files):** Current default. Markdown gotchas/traits with path scoping. Works for 5-50 items.
-- **Stage 2 (Structured store):** SQLite index generated from frontmatter. MCP server exposes tag/category queries. Handles 50-500 items. Zero new infrastructure.
-- **Stage 3 (Vector/RAG):** Embeddings + semantic retrieval via sqlite-vss. Personas find knowledge by relevance, not keywords. "This code is similar to an incident last year." Handles 500+ items.
-- MCP interface stays stable across all three stages — personas don't change when the backing store upgrades.
-- Killer use case: context-aware review that brings organizational memory (incidents, ADRs, patterns) to every PR.
-- Most orgs stay at Stage 1 forever. Stage 2 is the sweet spot for mature orgs. Stage 3 is for compliance-heavy industries.
-
-### Test Plan
-
-`docs/test-plan.md` — 6-layer test pyramid:
-- **Unit/Schema** (free, every commit): config validation, frontmatter, trait composition, lint rules
-- **Integration** (free, every commit): full build pipeline, plugin export, sync, uninstall
-- **Behavioral** (~$5/PR): `claude -p` with known-buggy code, assert on findings patterns, 2-of-3 flake tolerance
-- **Snapshot/Regression** (~$5, persona changes): compare output across versions, detect regressions
-- **LLM-as-Judge** (~$20, major changes): Opus evaluates persona quality on 5 dimensions
-- **Human Review** (monthly): `agentboot review` with guided questions on curated samples, 15min/persona
-- Agents test agents, but humans always decide. Automation removes burden, not judgment.
-- Mutation testing validates that tests catch the regressions they should.
-- Monthly automated testing budget: ~$165 for 4 personas (less than 1 hour of manual review)
-
-### Developer Onboarding
-
-`docs/developer-onboarding.md` — lightweight agentic training assist (not an LMS):
-- First-session welcome (~80 tokens in CLAUDE.md — try these personas now)
-- `/learn` skill — contextual help ("how do I review one file?", "what do severity levels mean?")
-- Curated external resource links (Anthropic docs, community guides) — AgentBoot curates, doesn't build content
-- Contextual tips in persona output (first-invocation hints, vague-prompt nudges, rate-limited, disable-able)
-- Generated onboarding checklist from org's actual config
-- Org-authored tips (`onboarding/` dir in personas repo — institutional knowledge transfer)
-
-### Marketplace & Community Sharing
-
-`docs/marketplace.md` — three-layer marketplace (Core → Verified → Community):
-- Traits are the most shareable unit (context-free behavioral blocks)
-- Gotchas rules are technology-specific, not org-specific (universally useful)
-- Domain layers package traits + personas + gotchas for compliance regimes (healthcare, fintech, govtech)
-- SuperClaude partnership: shared trait format standard + cross-listing in marketplaces
-- Contribution model with review process for Verified tier
-- CC plugin packaging: each domain/category = one installable plugin
-- Monetization paths documented for V2+ (premium domains, managed marketplace, consulting, certification)
-
-### Third-Party Ecosystem
-
-`docs/third-party-ecosystem.md` — 5 key tools analyzed (SuperClaude, ArcKit, spec-kit, Trail of Bits config + skills):
-- AgentBoot is the governance/distribution layer, not competing with content tools
-- All ideas developed independently; 3P tools are prior art (parallel evolution, not derivation)
-- Marketplace curation (point to upstream) is the recommended partnership model over bundling
-- Apache 2.0 license for core; domain layers carry their own licenses
-- ACKNOWLEDGMENTS.md with prior art / complementary / integrated / includes categories
-- CC-BY-SA-4.0 (ToB skills) requires ShareAlike — cannot be relicensed as MIT
-
-### CI/CD & Automation
-
-`docs/ci-cd-automation.md` covers 5 CI methods:
-- `claude -p --agent --output-format json` is the primary CI interface (cost-bounded, schema-enforced)
-- Hook scripts for deterministic compliance gates (free, <1s, no LLM)
-- `agentboot validate/build/sync` for the personas repo pipeline
-- MCP server for non-CC CI environments
-- Reusable GitHub Actions workflow for lowest-friction integration
-
-### Claude Code Reference
-
-`docs/claude-code-reference/` is the living knowledge base of every CC feature:
-- `feature-inventory.md` — exhaustive reference (35 tools, 25 hook events, all settings, all frontmatter fields)
-- `agentboot-coverage.md` — gap analysis with 24 prioritized action items
-
-### Planning Documents
-
-`docs/plans/` contains the formal planning docs synthesized from all design work:
-- `prd.md` (2,090 lines) — problem, users, vision, 52 feature requirements across 9 subsystems, 8 non-goals, success metrics, 32 open questions, 40+ term glossary
-- `architecture.md` (2,658 lines) — system context, 8 component diagrams, data schemas, scope merge semantics, build pipeline, distribution, security, cross-platform, 15 architectural decisions (AD-01–AD-15), 20 open questions
-- `technical-spec.md` (2,943 lines) — all 21 CLI commands specified, build system algorithms, persona.config.json schema (newly designed), 15 lint rules, canonical test YAML format, telemetry schema, MCP tools, plugin packaging, 20 open questions
-- `design.md` (2,213 lines) — UX per user segment, privacy deep dive (13 subsections), marketplace/community, prompt lifecycle, onboarding flows, uninstall, brand, licensing, 31 open questions
-
-Total: ~9,900 lines of planning documentation with ~103 open questions to resolve.
-
-## Known Gaps
-
-- No cursor or gemini output formats (Phase 2)
-- Trait weight system (HIGH/MEDIUM/LOW) not yet implemented — traits are included or not (Phase 2)
-- No runtime config schema validation (zod planned but not wired in) (Phase 2)
-- Extension path `./personas` in config warns but doesn't block
-- `repos.json` is empty — production sync path untested in real workflow (uses dev-sync for dogfooding)
-- This repo is the build tool, not a personas hub — orgs create a separate `personas` repo that uses AgentBoot as the build tool

package/CONTRIBUTING.md

@@ -1,168 +0,0 @@
-# Contributing to AgentBoot
-
-AgentBoot is a community project. This document explains what we are building together,
-what belongs in the core versus a domain layer, and the quality bar for contributions.
-
----
-
-## What is in scope
-
-### New core personas
-A persona belongs in core if it addresses a universal development concern — something
-any engineering team in any industry would benefit from. Good examples: an architecture
-reviewer, a documentation reviewer, a dependency audit persona.
-
-A persona does NOT belong in core if it assumes specific frameworks, compliance regimes,
-business domains, or organizational structures. Those belong in a domain layer.
-
-### New core traits
-Traits are behavioral building blocks. A trait belongs in core if it describes a
-reusable cognitive stance or output discipline that is domain-agnostic — the way
-`critical-thinking` or `structured-output` are. If the trait only makes sense in the
-context of a specific domain, it belongs in a domain layer instead.
-
-### Domain templates
-New domain templates under `domains/` are welcome. A domain template shows teams in
-a specific vertical (healthcare, fintech, defense, government) how to build a compliance
-layer on top of AgentBoot core without modifying core itself. Domain templates must
-be generic enough that any team in that vertical can use them as a starting point.
-They must not include real regulatory text, proprietary content, or org-specific rules.
-
-### Bug fixes
-Any defect in a persona, trait, instruction fragment, build script, sync script, or
-CI configuration is in scope.
-
-### Documentation
-Improvements to any file under `docs/`, the main `README.md`, or inline documentation
-inside trait and persona files are always welcome.
-
----
-
-## What is NOT in scope
-
-- **Org-specific personas.** A persona built for one company's engineering standards is
-  not useful to anyone else. Fork the repo or use the `extend` field in
-  `agentboot.config.json` to keep it private.
-- **Proprietary domain content.** Do not contribute traits or personas that contain
-  internal compliance rules, internal coding standards, or references to non-public
-  specifications.
-- **Opinions about coding styles.** AgentBoot ships agnostic on tabs vs. spaces,
-  semicolons, naming conventions, etc. Personas that enforce any particular style
-  convention belong in org forks, not in core.
-- **Tool-specific integrations that are not widely applicable.** An integration with
-  a niche internal tool is not core material.
-
----
-
-## How to propose a new persona
-
-**Issue first, then PR.** Do not open a PR for a new persona without a corresponding
-issue that has been acknowledged by a maintainer.
-
-1. Open an issue using the [Persona Request](.github/ISSUE_TEMPLATE/persona-request.md)
-   template.
-2. Describe the use case clearly. What problem does this persona solve? What does a
-   team look like before and after deploying it?
-3. List the traits it would compose. If it requires a new trait, say so and explain why
-   existing traits are insufficient.
-4. Provide an example invocation — a realistic prompt a developer would give it and
-   the output they would expect.
-5. Explain why this belongs in core rather than a domain extension (see scope rules above).
-6. Wait for maintainer acknowledgment before writing code. This prevents wasted effort
-   on proposals that don't fit the project direction.
-
----
-
-## Trait design principles
-
-Traits are the foundation of AgentBoot's composability. Bad traits make the whole system
-worse. Good traits follow these principles:
-
-**Generic, not specific.** A trait describes a cognitive stance or output discipline, not
-a checklist of domain rules. `critical-thinking` is a stance. "Check that HIPAA audit
-logs are present" is a domain rule and belongs in a domain layer.
-
-**Composable, not monolithic.** A trait does one thing. If you are writing a trait that
-covers two unrelated concerns, split it. Traits that try to do everything end up doing
-nothing well.
-
-**No domain assumptions.** A trait must not assume any particular framework, language,
-industry, compliance regime, or organizational structure. If your trait works for a
-Spring Boot API team but not for a React frontend team, it is not a core trait.
-
-**Configurable where it matters.** Look at `critical-thinking` as the model: the trait
-defines the behavior at each weight level, and the persona that composes it sets the
-weight. Traits that have meaningful axes of variation should expose them in frontmatter
-rather than hardcoding a single behavior.
-
-**Negative space matters.** Every trait must include a "what not to do" section. Personas
-that lack this section tend to produce output that is exhaustive but not useful.
-
----
-
-## Persona quality bar
-
-A persona is not ready to merge until it meets all of these requirements.
-
-**Frontmatter.** Every persona file must include a YAML frontmatter block with:
-- `id`: the slash-command identifier (e.g., `review-code`)
-- `name`: human-readable display name
-- `version`: semantic version starting at `1.0.0`
-- `traits`: list of trait IDs with weights where applicable
-- `scope`: one of `file`, `pr`, `repo`, `session`
-- `output_format`: one of `structured`, `prose`, or `mixed`
-
-**System prompt.** The persona must have a clear, complete system prompt that defines
-its role, its operating assumptions, and its mandate. The system prompt should not be
-a list of rules — it should read like a job description.
-
-**Output format specification.** The persona must specify exactly what its output looks
-like. If the output is structured, show the schema. If it is prose, describe the
-sections. Ambiguous output specs lead to inconsistent persona behavior across models.
-
-**What-not-to-do section.** Every persona must have a section describing anti-patterns —
-things the persona must not do, tempting behaviors that would make it less useful, and
-scope boundaries it must not cross.
-
-**Example.** Every new persona must include at least one worked example: a realistic
-input and the expected output. This is the primary way reviewers verify that the persona
-does what it claims.
-
----
-
-## Contributor License Agreement
-
-First-time contributors must sign our CLA. When you open your first pull request,
-the CLA bot will post a comment with instructions. This is a one-time process that
-takes about 30 seconds — you sign by posting a comment on the PR.
-
-The CLA grants the project maintainers the right to relicense your contributions if
-needed for the long-term sustainability of the project. Your contributions remain
-attributed to you. The full agreement is in [`CLA.md`](CLA.md).
-
----
-
-## PR checklist
-
-Before opening a PR, verify:
-
-- [ ] `npm run validate` passes with no errors
-- [ ] `npm run build` passes with no errors
-- [ ] `PERSONAS.md` is updated if you added or changed a persona
-- [ ] `README.md` is updated if the change affects the project overview
-- [ ] An example is included if you added a new persona
-- [ ] The trait design principles are satisfied if you added a new trait
-- [ ] The persona quality bar is met if you added a new persona
-- [ ] The issue number is referenced in the PR description
-
----
-
-## Code of conduct
-
-AgentBoot follows the [Contributor Covenant](https://www.contributor-covenant.org/version/2/1/code_of_conduct/)
-version 2.1. By contributing, you agree to uphold these standards. Report violations
-to the project maintainers.
-
----
-
-*Thank you for making AgentBoot better.*

package/PERSONAS.md

@@ -1,156 +0,0 @@
-# AgentBoot Persona Registry
-
-This file is the authoritative registry of all personas shipped with AgentBoot core.
-It is generated automatically by `npm run build` — do not edit it manually.
-If this file is out of date, run `npm run build` and commit the result.
-
----
-
-## V1 Personas
-
-| Persona | ID | Invocation | Scope | Traits Composed | IDE Available |
-|---|---|---|---|---|---|
-| Code Reviewer | `code-reviewer` | `/review-code` | PR / file | critical-thinking (MEDIUM), structured-output, source-citation, confidence-signaling | Yes |
-| Security Reviewer | `security-reviewer` | `/review-security` | PR / file | critical-thinking (HIGH), structured-output, source-citation, confidence-signaling, audit-trail | Yes |
-| Test Generator | `test-generator` | `/gen-tests` | file | schema-awareness, structured-output, source-citation | Yes |
-| Test Data Expert | `test-data-expert` | `/gen-testdata` | session | schema-awareness, structured-output | Yes |
-
-### Code Reviewer
-
-Performs code review against your team's standards. Produces severity-tiered findings
-(CRITICAL / WARN / INFO) with source citations. Uses `critical-thinking: MEDIUM` —
-flags clear defects and significant design concerns without opining on style preferences.
-
-**Typical invocation:**
-```
-/review-code
-```
-or on a specific file:
-```
-/review-code src/services/payment-service.ts
-```
-
-**Output format:** Structured findings list. Each finding includes: severity, location
-(file + line), description, citation, and recommendation.
-
----
-
-### Security Reviewer
-
-Security-focused code review. Uses `critical-thinking: HIGH` — treats absence of
-evidence as a gap, surfaces worst-case scenarios first, never softens findings to
-avoid friction. Covers: authentication, authorization, input validation, cryptographic
-usage, secret handling, injection risks, and dependency vulnerabilities.
-
-**Typical invocation:**
-```
-/review-security
-```
-or targeted:
-```
-/review-security src/auth/
-```
-
-**Output format:** Structured findings list. Security findings include an additional
-`cvss_estimate` field (LOW / MEDIUM / HIGH / CRITICAL) and an `exploitability` note.
-
----
-
-### Test Generator
-
-Generates unit and integration tests from function signatures, class definitions, or
-module exports. Produces tests in the testing framework already used in the repo
-(detected from `package.json` devDependencies and existing test files). Covers: happy
-path, boundary conditions, error cases, and null/undefined handling.
-
-**Typical invocation:**
-```
-/gen-tests src/services/user-service.ts
-```
-
-**Output format:** Ready-to-run test file(s) following the repo's existing test
-conventions. Includes a brief explanation of what each test covers and why.
-
----
-
-### Test Data Expert
-
-Generates realistic, schema-consistent synthetic test data. Reads the data model from
-TypeScript types, Zod schemas, or database schema files and produces data that is
-structurally valid, type-correct, and diverse enough to exercise edge cases.
-
-**Typical invocation:**
-```
-/gen-testdata src/domains/user/user.types.ts
-```
-
-**Output format:** TypeScript constant declarations, JSON fixtures, or SQL INSERT
-statements (detected from context). Each output includes a comment explaining any
-domain assumptions made.
-
----
-
-## IDE Availability
-
-All V1 personas are available via Claude Code slash commands (the primary interface).
-All personas that produce structured output also work in editor integrated mode —
-when invoked from within an open file, they automatically scope to the visible file
-context.
-
-For GitHub Copilot and Cursor compatibility, see the note about agentskills.io in
-[`README.md`](README.md). Personas compiled from AgentBoot follow the SKILL.md standard
-and work in any agentskills.io-compatible tool.
-
----
-
-## V1 Core Traits
-
-| Trait | ID | Configurable | Used By |
-|---|---|---|---|
-| Critical Thinking | `critical-thinking` | Yes (HIGH/MEDIUM/LOW) | code-reviewer, security-reviewer |
-| Structured Output | `structured-output` | No | all V1 personas |
-| Source Citation | `source-citation` | No | code-reviewer, security-reviewer, test-generator |
-| Confidence Signaling | `confidence-signaling` | No | code-reviewer, security-reviewer |
-| Audit Trail | `audit-trail` | No | security-reviewer |
-| Schema Awareness | `schema-awareness` | No | test-generator, test-data-expert |
-
----
-
-## Personas in the growth pipeline
-
-The following personas are under consideration for V2. None are committed or scheduled.
-If you want to work on one, open an issue using the
-[Persona Request](.github/ISSUE_TEMPLATE/persona-request.md) template.
-
-- **Architecture Reviewer** — Reviews structural decisions, dependency direction, and
-  bounded context violations. Candidate scope: PR / ADR file.
-- **Documentation Reviewer** — Checks that public APIs, complex functions, and
-  architectural decisions are documented adequately. Candidate scope: PR / file.
-- **Dependency Auditor** — Audits `package.json` / `pom.xml` / `go.mod` for outdated,
-  vulnerable, or license-incompatible dependencies. Candidate scope: session.
-- **Incident Analyst** — Given a log dump or error trace, identifies root cause, blast
-  radius, and remediation path. Candidate scope: session.
-- **Database Reviewer** — Reviews schema migrations for safety, reversibility, and
-  performance risks. Candidate scope: PR / migration file.
-
----
-
-## How to contribute a persona
-
-1. Read [`docs/concepts.md`](docs/concepts.md) to understand what a persona is and how
-   it composes traits.
-2. Read [`CONTRIBUTING.md`](CONTRIBUTING.md) for the quality bar and the issue-first policy.
-3. Open a [Persona Request](.github/ISSUE_TEMPLATE/persona-request.md) issue.
-4. Wait for maintainer acknowledgment before writing code.
-
-The quality bar for a merged persona:
-- Complete SKILL.md frontmatter (id, name, version, traits, scope, output_format)
-- Clear system prompt that reads like a job description
-- Explicit output format specification
-- What-not-to-do section
-- At least one worked example
-
----
-
-*Generated by AgentBoot build. Do not edit manually.*
-*Last updated: 2026-03-17*