feat: add career-content skill with cross-review fixes and Skill-First refactor

.opencode/agents/blogger.md

@@ -16,6 +16,7 @@ permission:
     "*": "deny"
     "blogger": "allow"
     "brutal-critic": "allow"
+    "career-content": "allow"
   task:
     "*": "deny"
     "brutal-critic": "allow"
@@ -62,6 +63,7 @@ Content creation specialist for personal blogging, podcast ideation, and YouTube
 - Use one relevant skill by default; add a second only for explicit cross-domain needs.
 - If scope is ambiguous, ask a clarifying question before loading.
 - Load `blogger` for blog, podcast, or YouTube content creation tasks.
+- Load `career-content` for resume bullet polishing, LinkedIn copy, cover letters, and professional bios.
 - Use `brutal-critic` only for final quality-gate review or when requested.
 
 ## Validation & Handoff

.opencode/agents/em-advisor.md

@@ -20,6 +20,8 @@ permission:
     "project-bootstrap": "allow"
     "agent-diagnostics": "allow"
     "docs-validation": "allow"
+    "career-content": "allow"
+    "legal-advisor": "allow"
   task:
     "*": "deny"
     "explore": "allow"
@@ -124,6 +126,8 @@ Urgent + Important: Do now | Important, not urgent: Schedule | Urgent, not impor
 - Use one relevant skill by default; add a second only for explicit cross-domain needs.
 - If scope is ambiguous, ask a clarifying question before loading.
 - Skip skill loading for pure people/leadership coaching unless a concrete template is needed.
+- Load `career-content` for resume writing, LinkedIn optimization, cover letters, and career narrative work.
+- Load `legal-advisor` for license auditing, compliance checks, and regulatory guidance.
 
 ## Investigation tools
 - Use `read`, `glob`, and `grep` for file and content exploration.

.opencode/agents/legal-advisor.md

@@ -7,6 +7,7 @@ skill: true
 permission:
   "*": "deny"
   edit: "allow"
+  bash: "deny"
   read: "allow"
   glob: "allow"
   grep: "allow"
@@ -168,9 +169,12 @@ This agent may ONLY create `legal-review-*.md` files. Do NOT modify source code,
 
 ## Skill Activation Policy
 
-- Load the `legal-advisor` skill on activation for the research methodology framework, jurisdiction profiles, license matrix, and privacy checklists
-- Use webfetch for official legal sources; prefer government portals and court databases over secondary summaries
-- Cross-reference findings across multiple sources where possible
+- Load skills on demand only for active task/phase requirements.
+- Use one relevant skill by default; add a second only for explicit cross-domain needs.
+- If scope is ambiguous, ask a clarifying question before loading.
+- Load the `legal-advisor` skill for the research methodology framework, jurisdiction profiles, license compatibility matrix, and privacy checklists.
+- Use webfetch for official legal sources; prefer government portals and court databases over secondary summaries.
+- Cross-reference findings across multiple sources where possible.
 
 ## Limitations
 

.opencode/instructions/dotnet-clean-architecture.instructions.md

@@ -2,92 +2,31 @@
 description: Apply .NET Clean Architecture principles and C# best practices
 ---
 
-# .NET Clean Architecture Instructions
+# .NET Instructions
 
-## Architecture Layers
+## Skill-First Runtime
+- For .NET and C# tasks, load the `dotnet` skill on demand.
+- Treat this file as compact reference guidance; use the skill for detailed conventions.
 
-Follow Clean Architecture dependency rules:
-```
-Domain → Application → Infrastructure → WebAPI
-```
-
-**Dependency Rules:**
-- ✅ Infrastructure → Application → Domain
-- ❌ Domain must NOT depend on Application
-- ❌ Application must NOT depend on Infrastructure
-
-## Project Structure
-```
-src/
-├── Domain/              (Entities, ValueObjects, Interfaces)
-├── Application/         (Services, DTOs, Validators)
-├── Infrastructure/      (DbContext, Repositories)
-└── WebAPI/              (Controllers, Program.cs)
-```
-
-## C# Coding Standards
-
-### Naming Conventions
-- Classes/Methods: `PascalCase`
-- Interfaces: `IPascalCase`
-- Private fields: `_camelCase`
-- Parameters/locals: `camelCase`
-
-### Async/Await
-Always include `CancellationToken` in async methods. Use `ConfigureAwait(false)` where context capture is not needed.
-
-### Nullable Reference Types
-Enable in `.csproj` with `<Nullable>enable</Nullable>`. Initialize non-nullable strings with `= string.Empty`. Use `?` suffix for optional properties.
-
-### Dependency Injection
-Constructor injection only. Declare dependencies as `private readonly` fields initialized in the constructor. Register services with appropriate lifetimes (`Scoped`, `Singleton`, `Transient`).
-
-## Entity Framework Core
+## Core Guardrails
+- Respect Clean Architecture layer dependencies: Domain → Application → Infrastructure → WebAPI (inward-only).
+- Always include `CancellationToken` in async method signatures and pass it through the call chain.
+- Enable nullable reference types (`<Nullable>enable</Nullable>`) and initialize non-nullable strings.
+- Use constructor injection exclusively; declare dependencies as `private readonly` fields.
+- Optimize EF Core queries with `AsNoTracking()` for reads and early `Select()` projection.
+- Decorate controllers with `[ApiController]` and `[ProducesResponseType]`; return `ActionResult<T>`.
 
-### Entity Configuration
-Use `IEntityTypeConfiguration<T>` for fluent configuration. Configure via `builder.ToTable()`, `builder.HasKey()`, `builder.Property()`, `builder.HasIndex()`. Apply in `OnModelCreating` with `modelBuilder.ApplyConfigurationsFromAssembly()`.
-
-### Optimized Queries
-Use `AsNoTracking()` for read-only queries. Project to DTOs with `Select()` early. Always pass `CancellationToken` to async EF methods.
-
-## Testing Standards
-
-Use xUnit + Moq + FluentAssertions. Name tests with `MethodName_Scenario_ExpectedBehavior`. Follow Arrange/Act/Assert. Mock interfaces with `Mock<T>` and inject via constructor. Assert with `result.Should().NotBeNull()` style.
-
-## Repository Pattern
-
-Define repository interfaces in the Application layer (contracts). Implement in the Infrastructure layer with EF Core. Each repository method takes `CancellationToken`. Use `FirstOrDefaultAsync`, `ToListAsync`, `AddAsync`, etc.
-
-## Controller Pattern
-
-Use `[ApiController]` attribute for automatic model validation and error responses. Use `[ProducesResponseType]` for Swagger documentation. Inject services via constructor. Pass `CancellationToken` through to service calls. Return `ActionResult<T>` for proper status codes.
-
-## Quality Requirements
-
-**Every code change MUST:**
-1. ✅ Compile with zero warnings
-2. ✅ Pass all tests
-3. ✅ Use nullable reference types correctly
-4. ✅ Include async/await with CancellationToken
-5. ✅ Follow Clean Architecture layers
-6. ✅ Include XML documentation for public APIs
-
-## Common Patterns
-
-- Use `record` types for DTOs
-- Apply `sealed` to classes that shouldn't be inherited
-- Use `required` keyword for required properties (C# 11+)
-- Prefer `is not null` over `!= null`
-- Use `nameof()` for parameter names in exceptions
+## Testing & Quality
+- Use xUnit + Moq + FluentAssertions with Arrange/Act/Assert.
+- Name tests as `MethodName_Scenario_ExpectedBehavior`.
+- Keep build, format, and test checks green before delivery.
 
 ## Validation Commands
+Examples below are defaults; prefer project scripts when they exist.
 
-After code changes, run:
 ```bash
 dotnet restore
 dotnet build
 dotnet format
 dotnet test
 ```
-
-For detailed examples and extended guidance, see [dotnet-clean-architecture-reference.instructions.md](dotnet-clean-architecture-reference.instructions.md).

.opencode/instructions/go.instructions.md

@@ -1,43 +1,32 @@
----
-description: Go best practices for modules, testing, and concurrency
----
-
-# Go Instructions
-
-## Tooling & Modules
-- Require Go modules; keep `go.mod` and `go.sum` committed.
-- Enforce formatting with `gofmt` (or gofmt via `go fmt ./...`).
-- Lint with `go vet` plus a linter suite (e.g., `golangci-lint`).
-
-## Code Standards
-- Pass `context.Context` through I/O and long-running operations; avoid ignoring cancellations.
-- Return errors, not panics, for expected failure; wrap with context (`fmt.Errorf("...: %w", err)`).
-- Keep functions small and cohesive; avoid overusing global state.
-- Prefer interfaces on consumers, not providers; keep interfaces narrow.
-
-## Concurrency
-- Avoid goroutine leaks; cancel contexts, close channels when done.
-- Guard shared state with channels or sync primitives; avoid data races.
-- Bound concurrency (worker pools, semaphores) for external calls.
-
-## I/O & Errors
-- Close resources (`defer f.Close()`); handle errors explicitly.
-- Validate inputs; avoid silent failure.
-
-## Testing
-- Use `go test ./...` with table-driven tests; cover error paths.
-- Use golden files sparingly; keep fixtures minimal.
-- Avoid hitting real networks in unit tests; use httptest/fakes.
-- Prefer `go test -race ./...` for concurrency-heavy code when possible.
-
-## Performance & Observability
-- Measure before optimizing; use pprof/benchmarks when needed.
-- Log with structure; include correlation IDs when available.
-
-## Validation Commands
-```bash
-go mod tidy
-go vet ./...
-golangci-lint run || true  # if available
-go test ./...
-```
+---
+description: Go best practices for modules, testing, and concurrency
+---
+
+# Go Instructions
+
+## Skill-First Runtime
+- For Go tasks, load the `go` skill on demand.
+- Treat this file as compact reference guidance; use the skill for detailed conventions.
+
+## Core Guardrails
+- Pass `context.Context` through all I/O and long-running operations; honor cancellation.
+- Return errors, not panics, for expected failures; wrap with `%w` for caller inspection.
+- Prevent goroutine leaks: cancel contexts, close channels, and bound concurrency for external calls.
+- Define interfaces on the consumer side; keep them narrow and purposeful.
+- Defer resource cleanup (`defer f.Close()`); handle errors explicitly, never silently.
+- Guard shared state with channels or sync primitives; avoid data races.
+
+## Testing & Quality
+- Use `go test ./...` with table-driven tests; cover success and error paths.
+- Run `go test -race ./...` for concurrency-heavy code; keep fixtures minimal.
+- Keep vet, lint, and test checks green before delivery.
+
+## Validation Commands
+Examples below are defaults; prefer project scripts when they exist.
+
+```bash
+go mod tidy
+go vet ./...
+golangci-lint run || true  # if available
+go test ./...
+```

.opencode/instructions/java-spring-boot.instructions.md

@@ -2,88 +2,30 @@
 description: Java Spring Boot best practices with dependency injection, validation, and testing
 ---
 
-# Java Spring Boot Instructions
+# Spring Boot Instructions
 
-## Architecture Principles
+## Skill-First Runtime
+- For Java Spring Boot tasks, load the `java-spring` skill on demand.
+- Treat this file as compact reference guidance; use the skill for detailed conventions.
 
-**Follow Spring Boot conventions:**
-- Use constructor injection over field injection
-- Prefer immutable DTOs with records (Java 14+)
-- Apply proper layering (Controller → Service → Repository)
-- Use Optional for nullable return values
+## Core Guardrails
+- Use constructor injection exclusively; avoid `@Autowired` field injection.
+- Prefer Java records for immutable DTOs; apply Bean Validation annotations directly on components.
+- Annotate controllers with `@Validated` and request parameters with `@Valid`.
+- Centralize error handling via `@RestControllerAdvice` with per-exception `@ExceptionHandler` methods.
+- Extend `JpaRepository<T, ID>` for data access; use Spring Data method naming for custom finders.
+- Define a `SecurityFilterChain` bean; use `SessionCreationPolicy.STATELESS` for REST APIs.
 
-## Dependency Injection
-
-**Constructor injection only.** Avoid `@Autowired` field injection — it hides dependencies and complicates testing. Declare dependencies as `private final` fields initialized via the constructor.
-
-## Entity Design
-
-Use JPA annotations on entity classes: `@Entity`, `@Table`, `@Id`, `@GeneratedValue(strategy = GenerationType.IDENTITY)`. Mark timestamps with `@CreationTimestamp` / `@UpdateTimestamp`. Constrain columns with `@Column(nullable = false, unique = true)`.
-
-## DTOs and Records
-
-Prefer Java records for immutable DTOs (Java 14+). Apply Bean Validation annotations (`@NotBlank`, `@Email`, `@Size`) directly on record components. Create dedicated request/response record types per operation.
-
-## Validation
-
-Annotate controllers with `@Validated` and request bodies with `@Valid`. Validate path/query parameters with `@Min`, `@Positive`, etc. Return proper `ResponseEntity` with appropriate status codes (`created`, `ok`, `notFound`).
-
-## Error Handling
-
-Use `@RestControllerAdvice` with `@ExceptionHandler` methods per exception type. Return a consistent `ErrorResponse` structure. For validation failures, extract field errors from `BindingResult` via `getFieldErrors()`.
-
-## Testing
-
-Use `@SpringBootTest` with JUnit 5. Follow Given/When/Then pattern. Use AssertJ's `assertThat` for fluent assertions and `assertThatThrownBy` for exception verification. Use `@MockBean` for external dependencies.
-
-## Repository Pattern
-
-Extend `JpaRepository<T, ID>` for standard CRUD. Add custom finders following Spring Data method naming. Use `@Query` with JPQL for complex queries and `@Modifying` for update/delete operations. Pass `@Param` annotations for named parameters.
-
-## Configuration
-
-Use `application.yml` with structured profiles. Reference environment variables via `${VAR_NAME}`. In production: `ddl-auto: validate`, `show-sql: false`. Add logging level overrides per package.
-
-## Security
-
-Define a `SecurityFilterChain` bean. For stateless APIs use `SessionCreationPolicy.STATELESS`. Add JWT filter before `UsernamePasswordAuthenticationFilter`. Use `@PreAuthorize` for method-level fine-grained authorization.
-
-## Best Practices
-
-### Code Organization
-- Keep controllers thin — only HTTP concerns
-- Put business logic in service layer
-- Use repositories for data access only
-- Create custom exceptions for business errors
-
-### Performance
-- Use pagination for large result sets
-- Implement caching where appropriate
-- Use lazy loading judiciously
-- Monitor database query performance
-
-### Maintainability
-- Write descriptive method names
-- Add JavaDoc for public APIs
-- Keep methods small and focused
+## Testing & Quality
+- Use JUnit 5 with `@SpringBootTest` and the Given/When/Then pattern.
+- Prefer AssertJ `assertThat` for fluent assertions and `@MockBean` for external dependencies.
+- Keep build and test checks green before delivery.
 
 ## Validation Commands
+Examples below are defaults; prefer project scripts when they exist.
 
 ```bash
-# Build
 ./mvnw clean compile
-
-# Test
 ./mvnw test
-
-# Run
 ./mvnw spring-boot:run
-
-# Check dependencies
-./mvnw dependency:check
-
-# Run with profile
-./mvnw spring-boot:run -Dspring-boot.run.profiles=dev
 ```
-
-For detailed examples and extended guidance, see [java-spring-boot-reference.instructions.md](java-spring-boot-reference.instructions.md).