@botdigit/agent-blueprint 1.0.0

package/frameworks/axum/SKILL.md

@@ -0,0 +1,73 @@
+# Axum Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/rust
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with Axum projects. Activated when Axum is detected in a Rust project.
+
+---
+
+## Architecture understanding
+
+Axum is an ergonomic, composable Rust web framework built on Tokio and Tower. Understand:
+- **Routers** — route composition and nesting
+- **Handlers** — async functions or `State` extractors
+- **Extractors** — how request data is extracted (JSON, form, headers, path, state)
+- **Middlewares** — Tower middleware stack
+- **State** — shared application state
+- **Error handling** — `Result`, `IntoResponse`, custom error types
+
+---
+
+## Conventions
+
+### Handlers and extractors
+
+- Handlers should be focused. A handler that does too much is a sign that logic should be extracted.
+- Use extractors for request data. Do not manually parse requests when extractors can do it.
+- Pydantic... err, the Rust equivalent: use serde for serialization. Validate input at the boundary.
+
+### State management
+
+- Axum's `State` extractor shares application state. Understand what the project puts in state.
+- State should be shared safely (Arc, Mutex, RwLock, or similar). Understand the project's choice.
+- Do not put mutable state in handlers without synchronization.
+
+### Error handling
+
+- Use `Result` with custom error types that implement `IntoResponse`.
+- Errors should be informative to the client (within security limits) and to the logs.
+- Do not expose internal error details to clients.
+
+### Middleware
+
+- Tower middleware is the mechanism. Use it for cross-cutting concerns.
+- Do not put business logic in middleware.
+
+### Database
+
+- The project's database choice is its own (SQLx, Diesel, SeaORM, or similar).
+- Understand how the project manages connections (pool, state, or other).
+- Migrations are the source of truth for schema.
+
+### Testing
+
+- Axum provides `TestClient` (via `axum::testing` or similar). Use it for integration tests.
+- Use tokio's test macros for async tests.
+- Test business logic, API endpoints, and critical flows.
+
+---
+
+## Anti-patterns
+
+- Business logic in handlers.
+- Ignoring error handling (unwrap in handlers).
+- Shared mutable state without synchronization.
+- Hardcoded secrets in source code.
+- Not using extractors when they apply.

package/frameworks/django/SKILL.md

@@ -0,0 +1,71 @@
+# Django Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/python
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with Django projects. Activated when Django structure is detected.
+
+---
+
+## Architecture understanding
+
+Django is a "batteries included" framework. Understand what the project uses:
+- **MVT** — models, views, templates
+- **Class-based views** vs **function-based views**
+- **REST framework** — if the project is an API
+- **DRF serializers** — API data shaping
+- **Admin** — Django's admin interface (customized or stock)
+- **Signals** — event hooks (use sparingly)
+- **Middleware** — cross-cutting concerns
+- **Celery / Django Q / similar** — background tasks
+- **ORM** — Django's ORM is central
+
+---
+
+## Conventions
+
+### Models and the ORM
+
+- Models are the heart of a Django project. Understand the project's models, relationships, and constraints.
+- The ORM is powerful. Understand query evaluation to avoid N+1 and unnecessary queries.
+- Migrations are the source of truth for schema. Do not edit the database outside of migrations.
+- Model methods and properties are good places for model-specific logic. Business logic that spans models belongs elsewhere.
+
+### Views
+
+- Views handle request → response. They should not contain business logic that belongs in models, services, or forms.
+- Form handling: use Django forms or the project's chosen form library. Validation belongs with the form or serializer.
+- Class-based views provide structure. If the project uses them, understand the lifecycle. If it uses function-based views, follow that convention.
+
+### API design (if DRF)
+
+- Serializers define the API contract. Understand what each serializer does.
+- ViewSets and routers provide convention. Follow the project's pattern.
+- Authentication and permission classes are the place for access control.
+
+### Settings
+
+- Django settings are significant. Understand the project's settings structure (single file, split by environment, django-configurations, or similar).
+- Secrets in settings: the project should use environment variables, not hardcoded values.
+
+### Testing
+
+- Django has a strong testing framework. Use it.
+- The `TestCase` class provides database isolation. Use it for tests that touch the database.
+- Test business logic, API endpoints, and critical flows.
+
+---
+
+## Anti-patterns
+
+- Business logic in views.
+- N+1 queries from unfiltered related object access.
+- Using signals for core business logic (signals hide control flow).
+- Editing the database directly instead of writing migrations.
+- Hardcoded secrets in settings files.

package/frameworks/fastapi/SKILL.md

@@ -0,0 +1,73 @@
+# FastAPI Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/python
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with FastAPI projects. Activated when FastAPI is detected.
+
+---
+
+## Architecture understanding
+
+FastAPI is a modern, async-first Python framework. Understand:
+- **Path operations** — the endpoint handlers
+- **Dependency injection** — FastAPI's DI system
+- **Pydantic models** — request/response validation and serialization
+- **Async/await** — the project's async usage
+- **Background tasks** — if used
+- **Database integration** — SQLAlchemy, SQLModel, Tortoise, or similar
+
+---
+
+## Conventions
+
+### Pydantic models
+
+- Pydantic models define the API contract. They are the source of truth for request and response shapes.
+- Use them for validation. Do not manually validate input that Pydantic can validate.
+- Models should be meaningful, not just `BaseModel` with arbitrary fields.
+
+### Dependency injection
+
+- FastAPI's DI is a feature. Use it for shared logic (auth, database session, current user).
+- Dependencies should be well-defined. Avoid hidden dependencies.
+
+### Async
+
+- FastAPI supports async path operations. Use async where it helps (I/O-bound operations).
+- Async is not magic. A slow synchronous operation in an async handler blocks the event loop.
+- Understand which database drivers and libraries are async-compatible before making everything async.
+
+### Error handling
+
+- Use HTTPException for HTTP errors.
+- Use custom exception handlers for application-specific errors where appropriate.
+- Do not expose internal errors to clients.
+
+### Database
+
+- The project's database integration is its choice. Understand it.
+- Migrations (Alembic or similar) are the source of truth for schema.
+- Connection management: understand how the project manages database sessions (dependency, context manager, or other).
+
+### Testing
+
+- FastAPI provides a `TestClient`. Use it for integration tests.
+- The project may use pytest or similar. Follow the project's choice.
+- Test business logic, API endpoints, and critical flows.
+
+---
+
+## Anti-patterns
+
+- Putting business logic in path operation functions.
+- Ignoring Pydantic validation and doing manual validation.
+- Mixing sync and async without understanding the implications.
+- Hardcoded secrets in the application code.
+- Returning raw database models as API responses without a defined contract.

package/frameworks/laravel/SKILL.md

@@ -0,0 +1,67 @@
+# Laravel Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/php
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with Laravel projects. Activated when Laravel structure is detected.
+
+---
+
+## Architecture understanding
+
+Laravel is a full-stack framework with conventions. Understand what the project uses:
+- **MVC** — controllers, models, views (Blade or Inertia or API)
+- **API-only** — resource/controllers, no views
+- **Inertia** — SPA with server-side routing
+- **Livewire** — dynamic interfaces without full SPA
+- **Queue workers** — background processing
+- **Events / Listeners** — event-driven architecture
+- **Jobs / Scheduled tasks** — async and cron
+
+---
+
+## Conventions
+
+### Eloquent and the database
+
+- Eloquent is an ORM. Understand the project's models, relationships, and scopes.
+- N+1 queries are a common problem. Use eager loading where appropriate.
+- Migrations are the source of truth for schema. Do not edit the database directly in a way that diverges from migrations.
+- Seeders and factories are for test data and development. Do not rely on them for production data.
+
+### Controllers
+
+- Controllers should be thin. Business logic belongs in models, services, actions, or similar — matching the project's convention.
+- If the project uses Form Requests for validation, use them. Do not validate in the controller body if Form Requests exist.
+
+### Service layer
+
+- If the project has a service layer, use it. If it does not, understand why before adding one.
+- Do not add a service layer because "that's what frameworks do." Add it if the project needs it.
+
+### Middleware
+
+- Middleware is for cross-cutting concerns (auth, logging, CORS). Use it for those.
+- Do not put business logic in middleware.
+
+### Testing
+
+- Laravel has a testing framework built in. Use it.
+- The project may use Pest or PHPUnit. Follow the project's choice.
+- Test the behavior that matters: business rules, API endpoints, critical user flows.
+
+---
+
+## Anti-patterns
+
+- Fat controllers with business logic.
+- N+1 queries from lazy loading in loops.
+- Putting business logic in routes files.
+- Ignoring migrations and editing the database directly.
+- Using `DB::raw` where Eloquent would do, without understanding the SQL injection risk.

package/frameworks/nextjs/SKILL.md

@@ -0,0 +1,60 @@
+# Next.js Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/typescript or stacks/javascript
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with Next.js projects. Activated when `next.config` and Next.js project structure are detected.
+
+---
+
+## Architecture understanding
+
+Next.js provides several rendering strategies. Understand which the project uses:
+- **SSR** (Server-Side Rendering) — `getServerSideProps` or Server Components
+- **SSG** (Static Site Generation) — `getStaticProps` or static Server Components
+- **ISR** (Incremental Static Regeneration)
+- **Client Components** — `'use client'`
+- **API Routes** — `app/api/` or `pages/api/`
+- **Server Actions** — if used
+
+The rendering strategy affects data flow, caching, and architectural decisions. Understand the project's choice before modifying.
+
+---
+
+## Conventions
+
+### App Router vs Pages Router
+
+- The project uses one or the other. Follow it. Do not mix unless the migration is explicit and documented.
+- App Router is the current direction. Pages Router is still valid for existing projects.
+
+### Server vs Client components
+
+- Server Components are the default in App Router. Use Client Components where interactivity requires it.
+- Do not make everything a Client Component "because it's easier." Understand the boundary.
+
+### Data fetching
+
+- Data fetching strategy (server-side, client-side, hybrid) is an architectural decision. Understand what the project does and why.
+- Caching behavior in Next.js is specific. Understand it before changing data fetching.
+
+### Environment variables
+
+- Next.js has specific environment variable conventions (`NEXT_PUBLIC_` for client exposure).
+- Do not expose secrets to the client. Next.js makes this explicit with the `NEXT_PUBLIC_` prefix. Respect it.
+
+---
+
+## Anti-patterns
+
+- Making all components Client Components.
+- Mixing App Router and Pages Router without a migration plan.
+- Exposing secrets via `NEXT_PUBLIC_` variables.
+- Fetching data on every render without caching strategy.
+- Putting business logic in components instead of server functions or services.

package/frameworks/rails/SKILL.md

@@ -0,0 +1,78 @@
+# Ruby on Rails Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/ruby
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with Ruby on Rails projects. Activated when Rails is detected.
+
+---
+
+## Architecture understanding
+
+Rails is an opinionated MVC framework. Understand what the project uses:
+- **MVC** — models, controllers, views
+- **ActiveRecord** — the ORM
+- **Routes** — `config/routes.rb`
+- **Mailers** — email delivery
+- **Jobs** — Active Job and the backend (Sidekiq, Resque, etc.)
+- **Assets** — the asset pipeline or import maps or a JS bundler
+- **API mode** — if the project is API-only
+
+---
+
+## Conventions
+
+### ActiveRecord and the database
+
+- ActiveRecord models are central. Understand the project's models, associations, validations, and scopes.
+- Migrations are the source of truth for schema. Do not edit the database outside of migrations.
+- N+1 queries are common. Use `includes`, `preload`, or `eager_load` where appropriate.
+- Callbacks are powerful and can hide control flow. Understand the project's use of them. Overuse of callbacks is a common Rails problem.
+
+### Controllers
+
+- Controllers should be thin. They handle request/response, not business logic.
+- Strong parameters are the mechanism for permitted input. Use them.
+- Before actions are for cross-cutting controller concerns. Do not put business logic in them.
+
+### Business logic placement
+
+- Rails does not enforce where business logic lives. The project's convention is what matters.
+- Common patterns: models, service objects, interactors, commands, queries. Follow the project's convention.
+- Do not introduce a pattern the project does not use without a reason.
+
+### Views
+
+- Views should present data, not compute it.
+- Helpers are for presentation logic that is reused across views.
+- Partials are for reusable view fragments.
+
+### Background jobs
+
+- Active Job is the abstraction. The backend (Sidekiq, Resque, etc.) is the implementation.
+- Understand the project's job infrastructure before adding or modifying jobs.
+- Jobs should be idempotent where possible.
+
+### Testing
+
+- Rails has a testing framework built in. Use it.
+- The project may use RSpec, Minitest, or similar. Follow the project's choice.
+- Test business logic, controllers, models where appropriate, and critical flows.
+- Factory bot or similar for test data. Follow the project's choice.
+
+---
+
+## Anti-patterns
+
+- Fat controllers with business logic.
+- Fat models with unrelated responsibilities.
+- Callbacks that do more than they appear to do.
+- N+1 queries.
+- Editing the database directly instead of migrations.
+- Hardcoded secrets in credentials or source.

package/frameworks/react/SKILL.md

@@ -0,0 +1,58 @@
+# React Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/typescript or stacks/javascript
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with React projects (SPA or library usage). Activated when React is detected without Next.js.
+
+---
+
+## Architecture understanding
+
+- Is this a SPA (single-page application) with client-side routing?
+- Is it embedded in a larger application (micro-frontend, widget)?
+- Is it using a state management library? Which one? (Redux, Zustand, Jotai, Context, MobX, or none)
+- Is it using a routing library? Which one?
+- Is it server-rendered at all, or purely client-side?
+
+---
+
+## Conventions
+
+### Component design
+
+- Components should be focused. A component that does too much is a sign that it should be split.
+- Custom hooks extract behavior. If a component has logic that could be reused, consider a hook.
+- Props should be as specific as practical. Avoid passing large objects when specific values would do.
+
+### State management
+
+- Start simple. Local state, then context, then a state library if there is a real need.
+- Not everything needs to be in a global store. State that is only used in one component tree should stay there.
+
+### Data flow
+
+- Data flows down. Events flow up. This is the React model. Respect it.
+- Avoid mutating props.
+- If data is shared across distant components, understand why before choosing a solution.
+
+### Effects
+
+- `useEffect` is for side effects, not for derived state. If you can compute a value during render, do that instead.
+- Effect dependencies should be correct. Missing dependencies cause bugs. Unnecessary dependencies cause re-renders.
+
+---
+
+## Anti-patterns
+
+- Putting business logic in UI components.
+- Using effect for everything.
+- Prop drilling without considering context or component restructuring.
+- Global state for everything.
+- Uncontrolled components where controlled would be clearer (or vice versa, depending on the actual need).

package/frameworks/spring/SKILL.md

@@ -0,0 +1,79 @@
+# Spring Boot Framework Skill
+
+**Version:** 1.0.0
+**Compatible:** project_skills >= 1.0
+**Requires:** stacks/java
+**Outputs:** (none — guidance only)
+
+---
+
+## Purpose
+
+Guidance for working with Spring Boot projects. Activated when Spring Boot is detected.
+
+---
+
+## Architecture understanding
+
+Spring Boot is a convention-driven Java framework. Understand:
+- ** layered architecture** — controllers, services, repositories
+- **Dependency injection** — Spring's IoC container
+- **Spring Data** — JPA, JDBC, MongoDB, or other repositories
+- **REST controllers** — `@RestController`, `@RequestMapping`
+- **Security** — Spring Security configuration
+- **Transactions** — `@Transactional`
+- **Async** — `@Async`, task executors
+- **Configuration** — `application.properties` / `application.yml`, profiles
+
+---
+
+## Conventions
+
+### Layered architecture
+
+- Controllers handle HTTP. Services handle business logic. Repositories handle data access.
+- This is the conventional Spring layout. Follow it unless the project has a documented alternative.
+- Do not put business logic in controllers. Do not put HTTP concerns in services.
+
+### Dependency injection
+
+- Spring's DI is central. Understand the project's bean configuration (component scanning, explicit beans, or both).
+- Constructor injection is preferred over field injection. Follow the project's convention.
+- Beans have a lifecycle. Understand the scope of the beans you use.
+
+### Data access
+
+- Spring Data repositories provide a convention. Understand what the project uses (JpaRepository, CrudRepository, custom repositories, or raw JPA).
+- `@Transactional` boundaries matter. Understand where transactions start and end.
+- N+1 queries are possible with JPA. Understand the project's fetch strategy.
+- Migrations: Flyway or Liquibase are common. If the project uses them, follow them. If it does not, note that as a gap.
+
+### REST API design
+
+- `@RestController` and `@RequestMapping` define the API.
+- DTOs (Data Transfer Objects) are common for API contracts. Understand the project's approach (DTOs, records, or direct entity exposure).
+- Validation: Bean Validation (JSR-380) is the standard. Use it for input validation.
+- Error handling: `@ControllerAdvice` and `@ExceptionHandler` are the conventional mechanism.
+
+### Security
+
+- Spring Security is powerful and can be complex. Understand the project's security configuration.
+- Authentication and authorization are configured in Security configuration. Understand how.
+- Do not rely on security by obscurity. Configure explicit access rules.
+
+### Testing
+
+- Spring Boot provides test support (`@SpringBootTest`, `@DataJpaTest`, `@WebMvcTest`, and similar).
+- Use the right slice for the right test. A repository test does not need the full application context.
+- JUnit 5 is the standard. The project may use AssertJ, Mockito, or similar. Follow the project's choice.
+
+---
+
+## Anti-patterns
+
+- Business logic in controllers.
+- Field injection everywhere (hard to test, hides dependencies).
+- Bidirectional entity relationships without understanding the consequences.
+- Ignoring transaction boundaries.
+- Exposing entities directly as API responses without a deliberate choice.
+- Hardcoded secrets in configuration files.

package/install.sh

@@ -0,0 +1,83 @@
+#!/usr/bin/env bash
+# ==============================================================================
+# Agent Blueprint — Universal AI Agent Skills Installer & Project Linker
+# Can be run locally OR remotely via:
+# curl -fsSL https://raw.githubusercontent.com/botdigit-official/agent-blueprint/main/install.sh | bash
+# ==============================================================================
+
+set -euo pipefail
+
+REPO_URL="https://github.com/botdigit-official/agent-blueprint.git"
+GLOBAL_CACHE_DIR="${HOME}/.agent-blueprint"
+TARGET_DIR="${1:-.}"
+
+echo "====================================================="
+echo "  📐 Agent Blueprint — AI Agent Skills Installer"
+echo "  Standardizing Living Docs & Architectural Rigor"
+echo "====================================================="
+
+TARGET_FULL_PATH="$(cd "$TARGET_DIR" 2>/dev/null && pwd || pwd)"
+
+# Step 1: Ensure we have the latest Agent Blueprint source via git clone / pull
+if [ -d "$GLOBAL_CACHE_DIR/.git" ]; then
+  echo "🔄 Pulling latest Agent Blueprint skills from GitHub..."
+  (cd "$GLOBAL_CACHE_DIR" && git pull --quiet origin main 2>/dev/null || git pull --quiet origin master 2>/dev/null || true)
+else
+  echo "📥 Cloning Agent Blueprint from GitHub ($REPO_URL)..."
+  mkdir -p "$GLOBAL_CACHE_DIR"
+  git clone --depth 1 "$REPO_URL" "$GLOBAL_CACHE_DIR" --quiet
+fi
+
+BLUEPRINT_ROOT="$GLOBAL_CACHE_DIR"
+
+echo "📂 Source Blueprint: $BLUEPRINT_ROOT"
+echo "🎯 Target Project:   $TARGET_FULL_PATH"
+
+DEST_AGENTS_DIR="$TARGET_FULL_PATH/.agents"
+DEST_SKILLS_DIR="$DEST_AGENTS_DIR/skills"
+
+mkdir -p "$DEST_SKILLS_DIR"
+
+# Link or copy AGENTS.md entry point
+if [ ! -f "$TARGET_FULL_PATH/AGENTS.md" ]; then
+  cp "$BLUEPRINT_ROOT/AGENTS.md" "$TARGET_FULL_PATH/AGENTS.md"
+  echo "📄 Created AGENTS.md at project root"
+fi
+
+# Link all modular skills
+for skill_path in "$BLUEPRINT_ROOT/skills"/*; do
+  if [ -d "$skill_path" ]; then
+    skill_name="$(basename "$skill_path")"
+    rm -rf "$DEST_SKILLS_DIR/$skill_name"
+    ln -s "$skill_path" "$DEST_SKILLS_DIR/$skill_name"
+  fi
+done
+
+# Create a local helper script in the project for easy updating
+cat << 'EOF' > "$TARGET_FULL_PATH/blueprint"
+#!/usr/bin/env bash
+set -e
+CACHE="${HOME}/.agent-blueprint"
+if [ "$1" = "update" ]; then
+  echo "🔄 Updating Agent Blueprint skills from GitHub..."
+  (cd "$CACHE" && git pull origin main)
+  echo "✅ Skills updated to latest version."
+elif [ "$1" = "audit" ]; then
+  echo "🔍 Starting Agent Blueprint discovery & audit..."
+  echo "👉 Prompt your agent: 'Read AGENTS.md and start audit (skills/10-audit)'"
+elif [ "$1" = "status" ]; then
+  echo "📐 Agent Blueprint installed at: .agents/skills"
+  (cd "$CACHE" && git log -1 --oneline)
+else
+  echo "Usage: ./blueprint [update | audit | status]"
+fi
+EOF
+chmod +x "$TARGET_FULL_PATH/blueprint"
+
+echo ""
+echo "✅ Agent Blueprint successfully installed in $TARGET_FULL_PATH!"
+echo "   - Skills directory: .agents/skills/"
+echo "   - Agent manual:     AGENTS.md"
+echo "   - Helper CLI:       ./blueprint [update | audit | status]"
+echo ""
+echo "🎉 Prompt your agent: 'Read AGENTS.md and start project discovery'."

package/llms.txt

@@ -0,0 +1,26 @@
+# Agent Blueprint
+
+> The universal blueprint and skill standard for AI coding agents — teaching LLMs how to think, audit, architect, and properly document any software project.
+
+## Core Rules for LLMs
+- The agent must adapt to the project. The project must not be forced to adapt to the skill.
+- Inspect before assuming. Understand existing architecture, dependencies, and state machines before editing.
+- Business logic comes before code structure. Security and data integrity come before features.
+- Deterministic tools before AI. Use AI only where reasoning adds unique value.
+- Never rewrite working systems unnecessarily. Preserve existing functionality unless explicitly deprecated.
+- Every architectural decision needs an Architectural Decision Record (ADR).
+- Every major change needs automated tests and must update living documentation in docs/.
+
+## Key Documents
+- [AGENTS.md](AGENTS.md): Entry point and complete execution lifecycle for AI coding agents.
+- [Orchestrator](skills/00-orchestrator/SKILL.md): Project classification, technology detection, and skill activation.
+- [Discovery](skills/01-discovery/SKILL.md): Locating projects in monorepos or nested directories.
+- [Project Context](skills/02-project-context/SKILL.md): Inspecting frameworks, languages, databases, and dependencies.
+- [Business Architecture](skills/03-business-architecture/SKILL.md): Domain modeling, actor definitions, workflows, and state machines.
+- [Architecture](skills/04-architecture/SKILL.md): System boundaries, modular monoliths, and ADR templates.
+- [Documentation Standard](skills/05-documentation/SKILL.md): Living documentation framework (docs/ hierarchy).
+- [Codebase Audit](skills/06-codebase-audit/SKILL.md): Static code hygiene, patterns, and debt discovery.
+- [Security](skills/07-security/SKILL.md): Defense-in-depth, cryptographic hashing, CSRF, and rate limiting.
+- [Testing](skills/08-testing/SKILL.md): Test strategy, regression suites, and verification matrix.
+- [Performance](skills/09-performance/SKILL.md): Query optimization, caching, latency profiling.
+- [Full Audit](skills/10-audit/SKILL.md): Combined forensic audit workflow.