🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
agents-opencode
Advanced tools
agents-opencode - npm Package Compare versions
| # Career Content Examples | ||
| ## Resume Bullets — Before & After | ||
| ### Software Engineer | ||
| ``` | ||
| ❌ Worked on the backend API for the payment system | ||
| ✅ Architected a payment processing API handling 50K+ daily transactions, reducing latency by 35% | ||
| ❌ Helped migrate services to microservices | ||
| ✅ Led migration of 8 monolithic services to containerized microservices on Kubernetes, cutting deployment time from 2 hours to 8 minutes | ||
| ❌ Was responsible for code reviews | ||
| ✅ Mentored 4 junior engineers through weekly code reviews, reducing production bugs by 28% | ||
| ``` | ||
| ### Engineering Manager | ||
| ``` | ||
| ❌ Managed a team of engineers | ||
| ✅ Led a 12-person engineering team delivering 3 product launches in 18 months, growing ARR from $2M to $8M | ||
| ❌ Improved team processes | ||
| ✅ Introduced sprint retrospectives and quarterly OKRs, increasing sprint velocity by 22% and team satisfaction scores from 3.2 to 4.6 | ||
| ❌ Worked with stakeholders on roadmap | ||
| ✅ Partnered with Product and Sales to define a 12-month roadmap, aligning 40+ features to revenue goals and reducing churn by 15% | ||
| ``` | ||
| ### Data Scientist | ||
| ``` | ||
| ❌ Built machine learning models | ||
| ✅ Developed an XGBoost fraud detection model with 94% precision, saving $1.2M annually in false positives | ||
| ❌ Created dashboards for leadership | ||
| ✅ Designed 6 Tableau dashboards for C-suite, surfacing KPIs that drove a 20% increase in customer retention | ||
| ``` | ||
| ### Marketing | ||
| ``` | ||
| ❌ Ran email campaigns and social media | ||
| ✅ Designed and executed a multi-channel demand gen campaign (email, LinkedIn Ads, webinars), generating 2,400 qualified leads and $1.8M in pipeline in 6 months | ||
| ❌ Managed the company blog | ||
| ✅ Grew organic blog traffic from 12K to 85K monthly visitors through SEO-driven content strategy and CRO, converting 6.5% of readers into free-trial sign-ups | ||
| ❌ Helped with product launches | ||
| ✅ Led go-to-market for 3 product launches, coordinating across Product, Sales, and Design to achieve 110% of Q4 revenue target | ||
| ``` | ||
| ### Sales | ||
| ``` | ||
| ❌ Closed deals and managed accounts | ||
| ✅ Closed $4.2M in new ARR across 28 enterprise deals in 2025, averaging 45-day sales cycles and 22% above quota | ||
| ❌ Built relationships with clients | ||
| ✅ Cultivated 6 strategic accounts into $500K+ annual relationships through quarterly business reviews and executive alignment, reducing churn to under 3% | ||
| ❌ Worked on sales enablement | ||
| ✅ Developed a competitive battlecard library used by 45+ AEs, correlating to an 18% win-rate improvement against top 3 competitors | ||
| ``` | ||
| ### Operations | ||
| ``` | ||
| ❌ Improved internal processes | ||
| ✅ Redesigned the vendor onboarding workflow, cutting approval time from 14 days to 3 days and reducing procurement errors by 40% | ||
| ❌ Managed budgets and vendors | ||
| ✅ Oversaw a $2.5M annual ops budget across 18 vendor relationships, renegotiating 4 contracts to save $320K/year while maintaining SLA compliance | ||
| ❌ Helped with tool migrations | ||
| ✅ Led migration from 5 disparate tools to a unified ERP (NetSuite), training 120+ users and achieving full adoption within 90 days | ||
| ``` | ||
| ## Resume Summaries | ||
| ### Entry-Level Software Engineer | ||
| ``` | ||
| Software Engineer with 1 year of experience in full-stack web development. Skilled in React, Node.js, and PostgreSQL, with a track record of shipping 3 production features that reduced customer support tickets by 25%. Seeking to apply expertise in building scalable user-facing applications at a growth-stage startup. | ||
| ``` | ||
| ### Senior Engineering Manager | ||
| ``` | ||
| Engineering Manager with 12 years of experience in SaaS and developer tools. Skilled in team scaling, platform architecture, and org design, with a track record of growing engineering orgs from 15 to 60+ while maintaining 97% retention. Seeking to apply expertise to building high-performing, inclusive engineering cultures at mission-driven companies. | ||
| ``` | ||
| ## LinkedIn Headlines | ||
| ### Before | ||
| ``` | ||
| Software Engineer at Acme Corp | ||
| ``` | ||
| ### After | ||
| ``` | ||
| Senior Software Engineer at Acme Corp | Backend & Cloud Architecture | TypeScript, Go, AWS | Building scalable systems that process 10M+ events daily | ||
| ``` | ||
| ## LinkedIn Summary | ||
| ### Template | ||
| ``` | ||
| [Who you are] — I'm a [role] with [X] years of experience in [field], currently at [company] where I [primary impact]. | ||
| [Key achievement 1] — At [company], I led [project] that resulted in [metric-driven outcome]. This taught me [lesson or insight]. | ||
| [Key achievement 2] — Previously, I [action] that [result]. I'm passionate about [domain or technology] and how it can [impact]. | ||
| [Call to action] — I'm currently [looking for / open to / exploring] opportunities in [field or role]. Let's connect if you're working on [relevant problem space]. | ||
| ``` | ||
| ## Cover Letter Template | ||
| ``` | ||
| Dear [Hiring Manager Name], | ||
| I'm writing to apply for the [Role] position at [Company]. As a [current role] with [X] years of experience in [field], I've followed [Company]'s work in [specific project or value] and am excited about the opportunity to contribute. | ||
| In my current role at [Current Company], I [specific achievement with metric]. This required [skill or approach] that I believe directly applies to [Company]'s current focus on [relevant initiative]. | ||
| What draws me to [Company] is [specific reason — product, mission, culture, technology]. My experience in [skill area] and track record of [type of results] align with what you're looking for in this role. | ||
| I'd welcome the opportunity to discuss how I can contribute to [Company]'s [specific goal or team]. I'm available at [email] or [phone]. Thank you for your consideration. | ||
| [Name] | ||
| ``` | ||
| ## ATS Keywords by Role | ||
| ### Software Engineering | ||
| Languages, frameworks, cloud platforms, databases, CI/CD tools, testing frameworks, architecture patterns, Agile/Scrum | ||
| ### Engineering Management | ||
| Team leadership, roadmapping, stakeholder management, hiring/retention, OKRs, Agile, budget ownership, vendor management | ||
| ### Data Science | ||
| Python/R, SQL, ML frameworks, statistics, A/B testing, data visualization, feature engineering, model deployment | ||
| ### Product Management | ||
| User research, roadmap prioritization, A/B testing, stakeholder alignment, PRDs, analytics, go-to-market, cross-functional leadership | ||
| ### Marketing | ||
| Demand generation, SEO/SEM, content marketing, marketing automation (HubSpot, Marketo), CRM, funnel optimization, ABM, brand strategy, CRO | ||
| ### Sales | ||
| Enterprise sales, MEDDIC/MEDDPICC, pipeline management, Salesforce, outbound prospecting, negotiation, account planning, quota attainment | ||
| ### Operations | ||
| Process improvement, vendor management, ERP (NetSuite, SAP), procurement, logistics, KPI dashboards, change management, capacity planning |
| --- | ||
| name: career-content | ||
| description: Resume writing, LinkedIn profile optimization, cover letters, and professional bio creation. Use for career content involving ATS optimization, STAR method, action verbs, and personal branding. | ||
| license: MIT | ||
| compatibility: opencode | ||
| metadata: | ||
| author: shahboura | ||
| version: "2.0.0" | ||
| audience: professionals | ||
| workflow: career-content | ||
| --- | ||
| # Career Content Skill | ||
| ## When to Activate | ||
| Activate this skill when: | ||
| - Writing or updating a resume | ||
| - Optimizing a LinkedIn profile (headline, summary, experience) | ||
| - Drafting cover letters or professional bios | ||
| - Preparing career narratives for promotions or job applications | ||
| - Improving resume phrasing with action verbs and metrics | ||
| - Checking ATS (Applicant Tracking System) compatibility | ||
| ## Which Agent to Use | ||
| | Agent | Best For | Style | | ||
| |-------|----------|-------| | ||
| | **@em-advisor** | Career strategy — what to highlight, framing achievements, positioning for promotion | Strategic framing, achievement identification | | ||
| | **@blogger** | Copywriting — punchy bullets, headline formulas, summary phrasing | Fast iteration, compelling language | | ||
| **Recommended:** Use em-advisor to identify what to showcase, then blogger to polish the language. | ||
| ## Pre-Writing: Match Skills to the Job | ||
| Before writing anything: | ||
| 1. Extract 5-10 keywords and requirements from the target job description | ||
| 2. Map your top achievements to each requirement | ||
| 3. Use this mapping to decide which bullets to write — every bullet should trace back to a requirement | ||
| 4. Prioritize requirements that appear in the first half of the job description (most important) | ||
| ## Resume Rules | ||
| ### Structure | ||
| - 1 page for <10 years experience, 2 pages for 10+ | ||
| - Sections: Contact → Summary → Skills → Experience → Education → (Optional: Projects, Certifications) | ||
| - Reverse chronological within each section | ||
| - Save as `resume-<name>.md` — deliver as markdown for easy editing | ||
| ### Resume Summary | ||
| Write 2-3 sentences following: `[Role] with [X years] in [industry]. Skilled in [skill 1], [skill 2], and [skill 3], with a track record of [measurable achievement]. Seeking to apply expertise to [goal].` | ||
| - Skip if <3 years experience — use an objective statement instead | ||
| - Customize the last sentence for each application | ||
| ### Bullet Formula (STAR + Metrics) | ||
| Every experience bullet should follow: **Action Verb → Task → Result (with metric)** | ||
| ``` | ||
| ✅ Built a real-time dashboard using React and WebSockets, reducing incident response time by 60% | ||
| ❌ Worked on a dashboard project | ||
| ``` | ||
| ### ATS Optimization | ||
| - Use keywords from the target job description | ||
| - Avoid tables, columns, images, and headers/footers | ||
| - Use standard section names (Experience, not "Where I've Worked") | ||
| - Include both acronyms and full terms: "AWS (Amazon Web Services)" | ||
| - Save final version as plain text to verify ATS parseability | ||
| Modern ATS platforms (Greenhouse, Lever, Workday, Ashby) handle basic tables and columns better than older systems, but plain-text formatting remains the safest choice for broad compatibility. | ||
| ### Action Verbs | ||
| - **Leadership:** Led, Directed, Orchestrated, Spearheaded, Championed | ||
| - **Technical:** Architected, Engineered, Developed, Automated, Optimized | ||
| - **Impact:** Increased, Reduced, Accelerated, Streamlined, Transformed | ||
| - **Collaboration:** Partnered, Facilitated, Coordinated, Aligned | ||
| Avoid weak verbs: "Worked on," "Helped with," "Was responsible for," "Participated in" | ||
| ### Quantifying Impact Without Exact Metrics | ||
| When you don't have precise numbers, use reasonable estimates with approximate markers: | ||
| - Time savings: "reduced deployment time by ~70%" or "cut review cycles from days to hours" | ||
| - Volume/scale: "processed ~10K requests daily" or "supported 3x growth without adding headcount" | ||
| - Before/after comparisons: "improved test coverage from ~40% to 85%" | ||
| - Dollar impact via proxies: "saved ~$50K/year by consolidating 3 vendor tools into 1" | ||
| - Always prefer concrete ranges over vague adjectives ("improved" → "improved by 30-40%") | ||
| ## LinkedIn Rules | ||
| ### Headline Formula | ||
| ``` | ||
| [Role] at [Company] | [Specialty 1] | [Specialty 2] | [Value Statement] | ||
| ``` | ||
| Keep under 220 characters (LinkedIn's current limit). Include keywords recruiters search for. | ||
| ### Alternative Headline Strategies | ||
| Beyond the pipeline formula, consider: | ||
| - **Mission-driven:** "Helping startups scale their engineering teams from seed to Series B" | ||
| - **Personality-forward:** "Engineer by training, product thinker by instinct. Ask me about distributed systems." | ||
| - **Thought-leadership:** "Writing about engineering culture, hiring, and why monoliths aren't dead" | ||
| - Choose a style that matches your industry: pipeline for corporate/enterprise, mission-driven for startups, personality for creative roles | ||
| ### Profile Visuals | ||
| - **Banner/background photo**: Use a clean, professional image that reflects your industry (conference talk, workspace, abstract tech graphic). Avoid generic stock photos, personal/family photos, and overly busy images. Recommended dimensions: 1584 x 396 pixels. | ||
| - **Profile photo**: Headshot with plain background, well-lit, looking at the camera. You should occupy ~60% of the frame. | ||
| ### Summary Section | ||
| - 3-5 short paragraphs | ||
| - Paragraph 1: Who you are and what you do (present tense) | ||
| - Paragraph 2: Key achievements (past tense, metrics) | ||
| - Paragraph 3: What you're looking for or passionate about | ||
| - Include 3-5 core skills as hashtags | ||
| ### Summary Style Tips | ||
| - Write how you speak — read it aloud; if it sounds stiff, rewrite it | ||
| - Hook readers in the first sentence with a bold claim or personal angle | ||
| - Cut jargon and buzzwords ("synergy," "passionate," "results-driven") | ||
| - Add one personal element (hobby, side project, or non-work interest) | ||
| - Use white space — short paragraphs, 1-2 sentences each | ||
| - Avoid opening with "I am a..." — lead with impact instead | ||
| ### Experience Section | ||
| - Same STAR + metrics formula as resume | ||
| - 3-5 bullets per role | ||
| - Add media/links to projects when relevant | ||
| ### Skills Section | ||
| - Add all relevant skills (LinkedIn allows up to 50) | ||
| - **Pin your top 3** skills — these appear first and carry the most weight in recruiter searches | ||
| - Reorder remaining skills by relevance to your target role, not alphabetically | ||
| - Endorsements from colleagues add credibility; aim for 5+ endorsements on your top 3 pinned skills | ||
| ### Hard Skills Only | ||
| Your Skills section should contain only hard/technical skills. Soft skills belong in experience bullets: | ||
| - "Communication" → Demonstrate via "Presented quarterly roadmap to C-suite and 200+ engineers" | ||
| - "Leadership" → Demonstrate via "Led a team of 5 through a platform migration" | ||
| - "Problem-solving" → Demonstrate via "Reduced P95 latency by 60% through query optimization" | ||
| ## Cover Letters | ||
| > **Check relevance:** Many tech companies and startups no longer require cover letters. Before writing one, verify the role explicitly asks for it. If optional, a brief 150-200 word letter can still differentiate you — 94% of hiring managers say cover letters influence decisions (Resume Genius, 2026). | ||
| - 3-4 paragraphs, under 400 words | ||
| - Paragraph 1: Role you're applying for + why this company | ||
| - Paragraph 2: Your most relevant achievement (specific, metric-driven) | ||
| - Paragraph 3: Why you're a fit — connect your skills to their needs | ||
| - Paragraph 4: Call to action + contact info | ||
| - Research the company before writing; reference specific projects or values | ||
| ### Avoiding AI Detection | ||
| Cover letters are increasingly screened for generic AI-generated language. To sound authentic: | ||
| - Reference a specific company project, blog post, or product launch — something a template couldn't know | ||
| - Vary sentence structure; avoid the "I am writing to apply for X at Y because Z" monotone | ||
| - Add one sentence that only you could write (a personal connection to the company's mission or domain) | ||
| ## Writing Conventions | ||
| - Use active voice, present tense for current role, past tense for previous | ||
| - Numbers under 10: spell out. 10+: use digits. Percentages: "40%" not "40 percent" | ||
| - No personal pronouns in resume ("I," "me," "my") — implied subject | ||
| - Third person or first person OK for LinkedIn summary; be consistent | ||
| - **Date formatting:** Use MM/YYYY for all dates (e.g., "06/2021 — Present"). Avoid seasons ("Summer 2021"), day-level precision ("06/15/2021"), or abbreviations ("Jun. 2021"). Use "Present" (not "Current") for ongoing roles. | ||
| - File naming: `resume-<name>.md`, `cover-letter-<company>.md`, `linkedin-profile.md` | ||
| ### Proofreading Checklist | ||
| Before delivering any career document: | ||
| - [ ] Run spellcheck and grammar check (Grammarly, LanguageTool, or built-in) | ||
| - [ ] Read the entire document aloud — catches awkward phrasing and run-on sentences | ||
| - [ ] Verify all dates, job titles, and company names are accurate | ||
| - [ ] Confirm bullet formatting is consistent (same punctuation style, parallel structure) | ||
| - [ ] Check that every bullet has an action verb and (where possible) a metric | ||
| - [ ] Have another person review it — fresh eyes catch what you'll miss | ||
| - [ ] Paste the plain-text version into a text editor to verify ATS parseability | ||
| ### File Format Recommendations | ||
| - **Deliver as `.md`** (Markdown) for easy editing, collaboration, and version control | ||
| - **Export final as `.pdf`** for submission — PDF preserves formatting across devices | ||
| - Avoid `.docx` unless the employer specifically requires it; Word formatting can shift between versions | ||
| - Name files professionally: `Jane-Smith-Resume-2026.pdf`, not `resume_final_v3.pdf` | ||
| ## Quick Reference | ||
| For detailed before/after examples and templates, see [references/examples.md](references/examples.md). |
@@ -19,2 +19,3 @@ --- | ||
| "brutal-critic": "allow" | ||
| "career-content": "allow" | ||
| task: | ||
@@ -66,2 +67,3 @@ "*": "deny" | ||
| - 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. | ||
@@ -68,0 +70,0 @@ |
@@ -23,2 +23,4 @@ --- | ||
| "docs-validation": "allow" | ||
| "career-content": "allow" | ||
| "legal-advisor": "allow" | ||
| task: | ||
@@ -128,2 +130,4 @@ "*": "deny" | ||
| - 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. | ||
@@ -130,0 +134,0 @@ ## Investigation tools |
@@ -10,2 +10,3 @@ --- | ||
| edit: "allow" | ||
| bash: "deny" | ||
| read: "allow" | ||
@@ -172,5 +173,8 @@ glob: "allow" | ||
| - 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. | ||
@@ -177,0 +181,0 @@ ## Limitations |
@@ -5,83 +5,24 @@ --- | ||
| # .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 | ||
| ``` | ||
| ## 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>`. | ||
| **Dependency Rules:** | ||
| - ✅ Infrastructure → Application → Domain | ||
| - ❌ Domain must NOT depend on Application | ||
| - ❌ Application must NOT depend on Infrastructure | ||
| ## 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. | ||
| ## 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 | ||
| ### 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 | ||
| ## Validation Commands | ||
| Examples below are defaults; prefer project scripts when they exist. | ||
| After code changes, run: | ||
| ```bash | ||
@@ -93,3 +34,1 @@ dotnet restore | ||
| ``` | ||
| For detailed examples and extended guidance, see [dotnet-clean-architecture-reference.instructions.md](dotnet-clean-architecture-reference.instructions.md). |
@@ -7,33 +7,22 @@ --- | ||
| ## 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`). | ||
| ## 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. | ||
| ## 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. | ||
| ## 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. | ||
| - 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 & 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. | ||
| ## 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. | ||
| ## Validation Commands | ||
| Examples below are defaults; prefer project scripts when they exist. | ||
| ## Performance & Observability | ||
| - Measure before optimizing; use pprof/benchmarks when needed. | ||
| - Log with structure; include correlation IDs when available. | ||
| ## Validation Commands | ||
| ```bash | ||
@@ -40,0 +29,0 @@ go mod tidy |
@@ -5,86 +5,28 @@ --- | ||
| # 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 | ||
| ## 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. | ||
| **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 | ||
| ## 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). |
@@ -7,40 +7,22 @@ --- | ||
| ## Tooling & Runtime | ||
| - Target LTS Node; enforce engines in package.json. | ||
| - Prefer `npm ci` in CI; use lockfiles (package-lock.json) checked in. | ||
| - Lint with ESLint; format with Prettier (or equivalent) consistently. | ||
| - Environment config via dotenv or platform env vars; never commit secrets. | ||
| ## Skill-First Runtime | ||
| - For Node.js and Express tasks, load the `node-express` skill on demand. | ||
| - Treat this file as compact reference guidance; use the skill for detailed conventions. | ||
| ## Application Structure | ||
| ## Core Guardrails | ||
| - Use async/await exclusively; wrap async handlers to propagate errors to error middleware. | ||
| - Validate all input at the edge with a schema library (Joi, Zod) and reject early. | ||
| - Enable security middleware: helmet, CORS with explicit origins, rate limiting on sensitive routes. | ||
| - Centralize configuration via environment variables; never commit secrets. | ||
| - Use structured logging (pino/winston) with request IDs; avoid `console.log`. | ||
| - Keep layers separated: routes → controllers → services → data access. | ||
| - Use async/await; avoid callbacks and unhandled promises. | ||
| - Centralize configuration; avoid sprinkling process.env reads. | ||
| ## Routing & Middleware | ||
| - Use Express Router; keep routes thin, delegate to services. | ||
| - Validate input (Joi/Zod/class-validator) at the edge; reject early. | ||
| - Add global error-handling middleware; return consistent JSON shapes. | ||
| - Enable security middleware: helmet, compression (as needed), CORS with explicit origins, rate limiting on sensitive endpoints. | ||
| ## Testing & Quality | ||
| - Use Jest/Vitest/Mocha with isolated side effects; mock external services. | ||
| - Include coverage when feasible; avoid real network calls in unit tests. | ||
| - Keep lint, build, and test checks green before delivery. | ||
| ## Error Handling & Logging | ||
| - Use structured logging (pino/winston) with levels and request IDs; avoid console.log. | ||
| - Normalize errors; avoid leaking stack traces to clients. | ||
| - Wrap async handlers to propagate errors to the error middleware. | ||
| ## Validation Commands | ||
| Examples below are defaults; prefer project scripts when they exist. | ||
| ## Data & I/O | ||
| - Parameterize queries; avoid string interpolation for SQL. | ||
| - Time out external calls; add retries with backoff where appropriate. | ||
| - Close resources and streams; use `finally` for cleanup. | ||
| ## Testing | ||
| - Use Jest/Vitest/Mocha for unit/integration tests; isolate side effects. | ||
| - Mock external services; avoid real network calls. | ||
| - Provide test commands: `npm test`, with coverage when feasible. | ||
| ## Performance & Reliability | ||
| - Avoid blocking the event loop; offload CPU-heavy work. | ||
| - Cache hot data thoughtfully; document TTL/invalidation. | ||
| - Instrument with metrics/tracing where available. | ||
| ## Validation Commands | ||
| ```bash | ||
@@ -47,0 +29,0 @@ npm ci |
@@ -7,41 +7,22 @@ --- | ||
| ## Tooling | ||
| - Use TypeScript with strict mode; keep `tsconfig` clean (noImplicitAny, strictNullChecks). | ||
| - Enforce linting (ESLint) and formatting (Prettier); include lint/test scripts in package.json. | ||
| - Prefer `npm ci` in CI; commit lockfiles. | ||
| ## Skill-First Runtime | ||
| - For React and Next.js tasks, load the `react-next` skill on demand. | ||
| - Treat this file as compact reference guidance; use the skill for detailed conventions. | ||
| ## Components & State | ||
| - Favor function components and hooks; avoid legacy class components. | ||
| - Keep components small/presentational; lift state up; prefer derived state over duplicates. | ||
| - Use stable keys; avoid array index keys for dynamic lists. | ||
| - Memoize expensive computations (`useMemo`, `useCallback`) judiciously. | ||
| ## Core Guardrails | ||
| - Use function components and hooks exclusively; avoid legacy class components. | ||
| - Enable TypeScript strict mode with `noImplicitAny` and `strictNullChecks`. | ||
| - Use stable, unique keys for dynamic lists; never use array index as key. | ||
| - Wrap error-prone subtrees in error boundaries; surface user-friendly error messages. | ||
| - Prefer semantic HTML over divs; label interactive elements; ensure keyboard navigation. | ||
| - Keep styling consistent with a single approach (CSS modules, Tailwind, or tokens); avoid ad hoc patterns. | ||
| ## Data Fetching | ||
| - For Next.js, prefer `fetch`/`cache` APIs or data-fetching methods appropriate to the route type. | ||
| - Use React Query/SWR for client caching; handle loading/error/empty states explicitly. | ||
| - Avoid fetching in `useEffect` when server components or loaders are more appropriate. | ||
| ## Accessibility & UX | ||
| - Provide labels/aria attributes; manage focus; ensure keyboard navigation. | ||
| - Maintain color contrast; avoid motion without reduce-motion guardrails. | ||
| - Use semantic HTML over divs; prefer native controls where possible. | ||
| ## Error Handling | ||
| - Handle errors at boundaries; use error boundaries for React trees as needed. | ||
| - Don’t swallow async errors; surface user-friendly messages. | ||
| ## Styling | ||
| - Keep styling consistent (CSS modules, Tailwind, or chosen system); avoid mixed ad hoc patterns. | ||
| - Prefer design tokens/theme variables for colors/spacing/typography. | ||
| ## Testing | ||
| ## Testing & Quality | ||
| - Use React Testing Library + Jest/Vitest; test behavior, not implementation details. | ||
| - Mock network calls; avoid real backends in unit tests. | ||
| - Add smoke tests for critical flows and accessibility checks when feasible. | ||
| - Mock network calls; add smoke tests for critical flows and accessibility checks when feasible. | ||
| - Keep lint, build, and test checks green before delivery. | ||
| ## Performance | ||
| - Avoid unnecessary re-renders; split bundles where it matters (Next.js code-splitting/dynamic import). | ||
| - Optimize images via Next/Image or CDN; set caching headers. | ||
| ## Validation Commands | ||
| Examples below are defaults; prefer project scripts when they exist. | ||
| ## Validation Commands | ||
| ```bash | ||
@@ -48,0 +29,0 @@ npm ci |
@@ -16,3 +16,3 @@ import type { Plugin } from "@opencode-ai/plugin"; | ||
| level: "info", | ||
| message: `Agents Opencode v${PACKAGE_VERSION} loaded — 9 agents, 18 skills, 14 commands available`, | ||
| message: `Agents Opencode v${PACKAGE_VERSION} loaded — 9 agents, 19 skills, 14 commands available`, | ||
| }, | ||
@@ -42,3 +42,3 @@ }); | ||
| Active skills: 18 language/domain/utility skill packs loadable via skill tool. | ||
| Active skills: 19 language/domain/utility skill packs loadable via skill tool. | ||
| Active commands: 14 slash commands (type / to see autocomplete). | ||
@@ -45,0 +45,0 @@ |
@@ -10,2 +10,3 @@ --- | ||
| audience: developers | ||
| workflow: legal-compliance | ||
| --- | ||
@@ -12,0 +13,0 @@ |
+1
-1
| { | ||
| "name": "agents-opencode", | ||
| "version": "2.0.1", | ||
| "version": "2.1.0", | ||
| "description": "OpenCode Agents: Intelligent AI assistants for software development. Features 9 specialized agents (including legal-advisor for license auditing and compliance), 14 coding standards, automated code review, documentation generation, OpenCode plugin compatibility, and cross-platform installation. Supports .NET, Python, TypeScript, Flutter, Go, Java, Node.js, React, Ruby, and Rust with plan-first execution and context-aware assistance.", | ||
@@ -5,0 +5,0 @@ "files": [ |
No alert changes
Improved metrics
- Total package byte prevSize
341596
3.19%- Number of package files
99
2.06%No dependency changes