🎩 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
| --- | ||
| description: Emit structured phase-boundary checkpoint for human decision | ||
| agent: orchestrator | ||
| argument-hint: "[phase name or description]" | ||
| subtask: true | ||
| --- | ||
| # Phase Checkpoint | ||
| Emit a structured checkpoint at phase boundaries for human steering of multi-phase | ||
| orchestration. | ||
| ## Inputs | ||
| - Phase context: `$ARGUMENTS` | ||
| ## Checkpoint Template | ||
| ``` | ||
| ## Checkpoint: [Phase] Complete — Human Decision Required | ||
| **Phase:** [Description] | ||
| **Status:** Complete | Blocked | ||
| **Completed:** [What was done — files, key changes] | ||
| **Validated:** [Verification results] | ||
| **Next phase:** [Name and brief description] | ||
| **Decision:** Proceed to next phase? | ||
| **Options:** | ||
| [A] Proceed to next phase | ||
| [B] Review changes first, then proceed | ||
| [C] Skip this phase, jump to [alternative] | ||
| [D] Stop and hand off | ||
| ``` | ||
| ## When to Emit | ||
| - At the boundary between completed and pending phases in a multi-phase plan | ||
| - After high-risk changes (security, schema, contract, build configuration) | ||
| - When the orchestrator needs a decision before continuing | ||
| - Before Phase 7 of any plan (final validation gate) | ||
| - When a phase completes but validation reveals caveats | ||
| The checkpoint pauses execution until the human responds with a decision. |
| # Career Content Reference | ||
| > Part of the `blogger` skill. Use for resume writing, LinkedIn optimization, | ||
| > cover letters, and professional bios. | ||
| ## 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 [career-examples/examples.md](career-examples/examples.md). |
| # 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 |
| # Recipes — per-ecosystem detection, reverse-deps, and silent risks | ||
| Companion to `SKILL.md`. Read the section for the language(s) the change touches. | ||
| All `rg` (ripgrep) commands fall back to `grep -rn` if `rg` is absent. | ||
| ## 1. Reverse-dependency grep recipes | ||
| ### JavaScript / TypeScript | ||
| - Imports: `rg -n "from ['\"].*<modulePathOrPkg>['\"]" <root> -l` | ||
| - Path aliases: read `tsconfig.json` `compilerOptions.paths` | ||
| - Barrel files: grep symbol name: `rg -n "\b<Symbol>\b" <root> --type ts -l` | ||
| ### Python | ||
| - Imports: `rg -n "^\s*(from|import)\s+<dotted.module>" <root>` | ||
| - No compiler — signature changes are silent; run `mypy`/`pyright` if configured. | ||
| ### Go | ||
| - Imports: `rg -n "\"<module/import/path>\"" <root>` | ||
| - Exported identifiers: `rg -n "\b<pkg>\.<Symbol>\b" <root>` | ||
| - `go build ./...` and `go vet ./...` catch most ripples. | ||
| ### Java / Kotlin | ||
| - Imports: `rg -n "import\s+<package>\.<Class>" <root>` | ||
| - Symbol use: `rg -n "\b<Class>\b" <root> -l` | ||
| ### C# / .NET | ||
| - `using <Namespace>;` + symbol grep `rg -n "\b<Type>\b" <root> -l` | ||
| ### Ruby | ||
| - `rg -n "require(_relative)?\s+['\"].*<file>" <root>` + constant grep | ||
| ### Rust | ||
| - `rg -n "use\s+(crate|super|<crate_name>)::.*<item>" <root>` + symbol grep | ||
| ### PHP | ||
| - `rg -n "use\s+<Namespace>\\\\<Class>" <root>` + `new <Class>` grep | ||
| ### Cross-cutting (any language) | ||
| - Config/contract by string: `rg -n "<literal>" <root>` | ||
| ## 2. Detecting verify commands | ||
| | Ecosystem | Where commands live | Typical typecheck / build / test / lint | | ||
| |---|---|---| | ||
| | JS/TS | `package.json` `scripts` | `tsc --noEmit` · `build` · `test` · `eslint` | | ||
| | Python | `pyproject.toml`, `Makefile` | `mypy`/`pyright` · — · `pytest` · `ruff` | | ||
| | Go | `go.mod`, `Makefile` | `go build ./...` · same · `go test ./...` · `go vet` | | ||
| | Java/Kotlin | `pom.xml`, `build.gradle` | `mvn compile` · same · `mvn test` · checkstyle | | ||
| | C#/.NET | `*.sln`/`*.csproj` | `dotnet build` · same · `dotnet test` · analyzers | | ||
| | Ruby | `Rakefile`, `Gemfile` | — · — · `rspec` · `rubocop` | | ||
| | Rust | `Cargo.toml` | `cargo check` · `cargo build` · `cargo test` · `cargo clippy` | | ||
| | PHP | `composer.json` | `phpstan` · — · `phpunit` · `php-cs-fixer` | | ||
| Also check CI config — it is the canonical list of "what must pass". | ||
| ## 3. Mirror/twin files | ||
| A diff that edits one side and not the other is an impact finding: | ||
| - **Generated code** — `// Code generated` / `@generated` / "DO NOT EDIT" header | ||
| - **Cross-language duplicated constants** — same enum/status code in FE and BE | ||
| - **Paired fixtures / golden files / snapshots** — logic changes need updated recordings | ||
| - **Docs/specs that encode behavior** — OpenAPI, `.proto`, CODEOWNERS-flagged contract | ||
| ## 4. Surface-mapping | ||
| - **Web app** — find the route/page rendering the impacted component | ||
| - **Service/API** — find controller/handler, path + method, consumers | ||
| - **CLI** — find the command/subcommand wired to the impacted function | ||
| - **Library** — public API + tests, downstream consumers in monorepo | ||
| - **Background job / queue** — worker/handler bound to impacted code and trigger |
| --- | ||
| name: code-change-impact | ||
| description: >- | ||
| Trace the blast radius of a code change, find silent ripples the compiler | ||
| can't catch, and prove it didn't break anything else. Language- and | ||
| framework-agnostic. Use after a fix, before committing or opening a PR. | ||
| license: MIT | ||
| compatibility: opencode | ||
| metadata: | ||
| author: shahboura (methodology adapted from mghareeb/code-change-impact, MIT) | ||
| version: "1.0.0" | ||
| audience: developers | ||
| workflow: code-review | ||
| --- | ||
| # Code Change Impact — blast-radius / regression analysis | ||
| A fix is "done" only when you know what it touched *besides* the thing you were | ||
| fixing. This skill traces reverse dependencies, hunts silent behavioral ripples, | ||
| runs the project's own verification commands, and delivers a verdict. | ||
| Run it against the VCS diff — it adapts to whatever language and tooling the | ||
| repo uses by discovering the project's conventions first. | ||
| ## When to Activate | ||
| Activate this skill when: | ||
| - A change touches shared/core code, a public API, a type/interface, a serialized | ||
| contract, a DB schema, or global config — anything with non-obvious blast radius | ||
| - You need to prove a fix didn't break other features before merging | ||
| - Any request containing "did this break anything", "what else does this affect", | ||
| "check the impact", "is this safe to merge", or "regression check" | ||
| ## Methodology | ||
| ### Phase 1 — Discover the project + pin the epicenter | ||
| Establish the repo context: | ||
| 1. **Repo root + diff** — `git rev-parse --show-toplevel` then `git diff HEAD` | ||
| (for a whole branch: `git diff <base>...HEAD`) | ||
| 2. **Languages + ecosystems** — from manifests (`package.json`, `pyproject.toml`, | ||
| `go.mod`, `pom.xml`/`build.gradle`, `*.csproj`, `Gemfile`, `Cargo.toml`) | ||
| 3. **Verification commands** — typecheck, build, test, lint from manifests or CI. | ||
| Note targeted test scripts (named per area) — they verify a specific blast | ||
| radius far cheaper than the full suite. | ||
| Classify each changed file by coupling class: | ||
| | Changed file is… | Reach | | ||
| |---|---| | ||
| | shared/core/common/util module | **wide** — every importer | | ||
| | public/exported symbol, barrel/index, package public API | every caller, in and out of module | | ||
| | type / interface / schema / `.proto` | compiler-caught in typed langs; **silent** in dynamic | | ||
| | serialized contract (REST/GraphQL/DTO/protobuf) | cross-service — the other side of the wire | | ||
| | config/registry (route table, DI, feature flags) | fan-out — everything derived from it | | ||
| | DB schema / migration / ORM model | data layer — queries, models, other services | | ||
| | generated, duplicated, or cross-language **twin** file | paired — its twin must change in lockstep | | ||
| | global config / styles / theme / i18n strings | **global, silent** — no compiler signal | | ||
| | build / deps / lockfile / Dockerfile / CI | the whole app | | ||
| | internal change in a single leaf file | **local** — small verify, done | | ||
| If discovery is ambiguous, state findings and ask the user to confirm. | ||
| ### Phase 2 — Trace reverse dependencies | ||
| For each changed symbol, find who depends on it. The shape (per `references/recipes.md` §1): | ||
| ```bash | ||
| rg -n "<import-form-for-this-language targeting the changed module>" <root> -l | ||
| rg -n "\b<SymbolName>\b" <root> -l | ||
| # for a contract change: who is on the other side of the wire? | ||
| rg -n "<endpoint path | message name | field name>" <root> | ||
| ``` | ||
| Build two buckets: **directly impacted** (import/call the changed symbol) and | ||
| **transitively impacted** (depend on the directly-impacted). One hop is usually | ||
| enough; go deeper for shared/core and public-API changes. Map impacted code | ||
| to user-facing surfaces (route, endpoint, command, job). | ||
| ### Phase 3 — Hunt silent ripples (what the compiler can't see) | ||
| For each directly-impacted site, ask: did the change alter a **shape, signature, | ||
| default, side effect, or invariant** — or is it internal and safe? Then check | ||
| four categories of silent risk: | ||
| - **Shape drift** — serialization changes (nullable field, enum added, default | ||
| changed), mirror/twin files out of sync (generated code, cross-language | ||
| constants), regex/validation predicate changes | ||
| - **Behavioral shift** — changed defaults, sort order, comparator, rounding, | ||
| cache/memo key change, error-handling control flow | ||
| - **Environment sensitivity** — locale/time/number formatting, feature-flag | ||
| defaults, theme/token/i18n strings | ||
| - **Runtime hazards** — concurrency boundaries, transaction scope, retry policy, | ||
| global mutable state, persisted client state holding an old shape after upgrade | ||
| Dynamic languages (Python/Ruby/JS) have no compiler net — weight Phase 3 heavier | ||
| for those stacks. | ||
| ### Phase 4 — Verify (prove it, don't assert it) | ||
| Run the commands discovered in Phase 1, cheapest signal first, scaled to blast radius: | ||
| 1. Typecheck / compile — catches build-caught ripples fast | ||
| 2. Build — if shared/entry-point/build-path code was touched | ||
| 3. Tests — prefer targeted suites matching the impacted area | ||
| 4. Lint / static analysis — if the project gates on it | ||
| 5. Exercise impacted surfaces — hit the affected routes, endpoints, CLI commands | ||
| A green local build is not the same as deployed — never claim a change is live | ||
| in an environment you didn't check. | ||
| ### Phase 5 — Report | ||
| Always use this structure: | ||
| ``` | ||
| # Code Change Impact: <one-line description> | ||
| ## Verdict: SAFE | SAFE WITH CAVEATS | IMPACT FOUND | ||
| ## Project | ||
| - languages: <…> verify: typecheck=<…> build=<…> test=<…> | ||
| ## Epicenter | ||
| - <file:line> — <coupling class> — <what changed (shape/default/internal/…)> | ||
| ## Blast radius | ||
| ### Directly impacted | ||
| - <file/surface> — <route/endpoint/command> — <why> — risk: High|Med|Low | ||
| ### Transitively impacted | ||
| - <…> (or "none beyond build-checked usages") | ||
| ## Mirror / twin files | ||
| - <generated or duplicated file> — in sync? yes/NO | ||
| ## Silent-risk callouts | ||
| - <…> (or "none identified") | ||
| ## Verification | ||
| - typecheck/compile: PASS/FAIL build: PASS/FAIL/skipped | ||
| - tests: <which ran> → PASS/FAIL | ||
| - surfaces exercised: <list> → clean? errors? | ||
| ## Residual checklist | ||
| - [ ] <thing not auto-verifiable> | ||
| ``` | ||
| **Verdict rules:** | ||
| - **SAFE** — fully traced, twin files in sync, build/tests pass, surfaces clean, no silent risks. | ||
| - **SAFE WITH CAVEATS** — passes but residual checks remain. List them; don't paper over them. | ||
| - **IMPACT FOUND** — a twin is out of sync, a consumer breaks, or a silent ripple is confirmed. | ||
| List each breakage with file + fix. State it plainly, don't soften it — this is | ||
| the outcome the skill exists to catch. | ||
| ## Scope Discipline | ||
| - **Analyze; don't silently fix.** If you find collateral damage, report it and propose | ||
| the fix — let the user decide whether the change should grow. | ||
| - **Match effort to reach.** An internal one-liner in a leaf file needs a typecheck and | ||
| a glance. A shared/core, public-API, schema, or contract change earns the whole pipeline. | ||
| - **When unsure, say so.** If a ripple might be real but you can't confirm, put it on the | ||
| residual checklist rather than declaring SAFE. | ||
| ## Quick Reference | ||
| - `references/recipes.md` — Per-ecosystem grep recipes for reverse-dependency | ||
| tracing, verify-command detection, mirror-file finder, and surface-mapping. |
@@ -19,3 +19,2 @@ --- | ||
| "brutal-critic": "allow" | ||
| "career-content": "allow" | ||
| task: | ||
@@ -66,4 +65,3 @@ "*": "deny" | ||
| - 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. | ||
| - Load `blogger` for blog, podcast, YouTube, or career content (resumes, LinkedIn, bios) creation tasks. | ||
| - Use `brutal-critic` only for final quality-gate review or when requested. | ||
@@ -70,0 +68,0 @@ |
@@ -33,2 +33,3 @@ --- | ||
| "legal-advisor": "allow" | ||
| "code-change-impact": "allow" | ||
| task: | ||
@@ -79,2 +80,7 @@ "*": "deny" | ||
| - Summarize what was implemented | ||
| - Include a confidence declaration: | ||
| ``` | ||
| **Confidence:** HIGH | MODERATE | TENTATIVE | ||
| **Reasoning:** [Evidence strength, unknowns, assumptions made] | ||
| ``` | ||
| - Suggest handoffs to documentation or review agents | ||
@@ -81,0 +87,0 @@ - For license compliance or dependency licensing questions, consult @legal-advisor |
@@ -23,4 +23,4 @@ --- | ||
| "docs-validation": "allow" | ||
| "career-content": "allow" | ||
| "legal-advisor": "allow" | ||
| "blogger": "allow" | ||
| task: | ||
@@ -130,3 +130,3 @@ "*": "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 `blogger` for resume writing, LinkedIn optimization, cover letters, and career narrative work. | ||
| - Load `legal-advisor` for license auditing, compliance checks, and regulatory guidance. | ||
@@ -133,0 +133,0 @@ |
@@ -37,2 +37,3 @@ --- | ||
| "brutal-critic": "allow" | ||
| "code-change-impact": "allow" | ||
| task: | ||
@@ -77,2 +78,4 @@ "*": "deny" | ||
| - Use @orchestrator when coordination across multiple agents is needed | ||
| - Defer full doc/lint validation (`npm run doctor`, `npm run lint:md`) to the final | ||
| integration phase. Run targeted checks (typecheck, test) during implementation phases. | ||
@@ -88,3 +91,10 @@ ## Workflow | ||
| 2. **Analyze Current State** | ||
| 2. **Classify Intent (LLM-Driven Routing)** | ||
| - For ambiguous requests, classify the primary intent into one of: | ||
| `implementation`, `documentation`, `review`, `planning`, `content`, `legal` | ||
| - Use the classification to route to the appropriate agent and coordination pattern. | ||
| - If multiple intents are present, decompose and sequence them. | ||
| - Present the classification to the user for confirmation before dispatching. | ||
| 3. **Analyze Current State** | ||
| - Read existing codebase structure | ||
@@ -95,3 +105,3 @@ - Identify affected files and modules | ||
| 3. **Research & Context** | ||
| 4. **Research & Context** | ||
| - Fetch external documentation if needed | ||
@@ -101,3 +111,3 @@ - Review best practices for the technology | ||
| 4. **Create Detailed Plan** | ||
| 5. **Create Detailed Plan** | ||
| - Read `.opencode/instructions/orchestrator-reference.instructions.md` for the planning template format | ||
@@ -117,2 +127,7 @@ - Document steps with clear sequencing | ||
| 5. Validate results before next phase | ||
| 6. At phase boundaries, emit a checkpoint using the format in the orchestrator reference. | ||
| Await user decision before proceeding to the next phase. See `## Checkpoint Format` | ||
| in `.opencode/instructions/orchestrator-reference.instructions.md`. | ||
| 7. Before retrying any sub-task, check idempotently if it was already completed | ||
| (git status, file presence, test pass). Skip completed sub-tasks. | ||
@@ -131,3 +146,6 @@ ### Integration & Validation | ||
| - **Agent Selection Guide** — Which agent to delegate to for each task type | ||
| - **Coordination Patterns** — Four standard workflow patterns (Implementation Cycle, Documentation Refresh, Full Feature Delivery, Legal Review Cycle) | ||
| - **Coordination Patterns** — Seven workflow patterns (Implementation, Documentation, Full Feature, | ||
| Legal Review, Evaluator-Optimizer, Parallelization, Analyze-Then-Act) | ||
| - **Checkpoint Format** — Structured phase-boundary pause for human decision | ||
| - **Fallback Routing** — What to do when primary paths fail | ||
| - **Progress Tracking** — Status table format and update cadence for long-running work | ||
@@ -144,2 +162,4 @@ | ||
| - For cross-device UX/responsive phases, load `ux-responsive` on demand. | ||
| - For planning high-risk refactors or cross-cutting changes, load `code-change-impact` | ||
| to assess blast radius before delegating implementation. | ||
@@ -153,9 +173,2 @@ ## Communication Style | ||
| ## Safety & Validation | ||
| - Verify each phase completes successfully | ||
| - Check dependencies before starting next phase | ||
| - Validate integration points | ||
| - Run end-to-end tests when applicable | ||
| - Don't proceed if critical issues found | ||
| ## Safe Execution Loop Protocol | ||
@@ -169,33 +182,10 @@ | ||
| - If the same blocker repeats twice without meaningful progress, pause and escalate with options. | ||
| - For high-risk changes (security, broad refactor, CI/CD), require an independent verification pass (`@review`) before final completion. | ||
| - For high-risk changes (security, broad refactor, CI/CD), require an independent verification | ||
| pass (`@review`) before final completion. | ||
| - Before starting each cycle, check idempotently whether the sub-task was already completed. | ||
| ## Context Persistence | ||
| **At session start:** | ||
| 1. Read `AGENTS.md` for project context and recent activity | ||
| 2. Read `state/session-state.json` for working memory (if present) | ||
| 3. Read `handoff/latest.md` for continuation context (if present) | ||
| 4. Apply successful orchestration patterns from previous sessions | ||
| **At task completion:** | ||
| 1. Refresh `state/session-state.json` with current phase, risks, decisions, and next actions. | ||
| 2. Generate or refresh handoff packet using project tooling when phase state changed. | ||
| 3. Then update `AGENTS.md` with timestamped entry (latest first): | ||
| ```markdown | ||
| ### YYYY-MM-DD HH:MM - [Brief Task Description] | ||
| **Agent:** orchestrator | ||
| **Summary:** [What was coordinated] | ||
| - Phase sequence and agent handoffs used | ||
| - Workflow patterns that worked well | ||
| - Lessons learned for future orchestration | ||
| ``` | ||
| **Format requirements:** | ||
| - Date/time format: `YYYY-MM-DD HH:MM` (to minute precision) | ||
| - Latest entries first (prepend, don't append) | ||
| - Keep entries concise (3-5 bullets max) | ||
| - Include orchestration patterns and coordination approaches | ||
| - File auto-prunes when exceeding 100KB | ||
| **Present update for approval before ending task.** | ||
| **At session start:** Read `AGENTS.md`, `state/session-state.json`, and `handoff/latest.md`. | ||
| **At task completion:** Refresh state, generate handoff packet, and log a concise | ||
| timestamped entry (3-5 bullets) to `AGENTS.md`. Present update for approval before ending. |
@@ -30,2 +30,3 @@ --- | ||
| "agent-diagnostics": "allow" | ||
| "code-change-impact": "allow" | ||
| task: | ||
@@ -131,2 +132,4 @@ "*": "deny" | ||
| - For responsive/accessibility checks across breakpoints and input modes, load `ux-responsive` on demand. | ||
| - Load `code-change-impact` for structured blast-radius analysis — traces reverse | ||
| dependencies, finds silent ripples, and delivers a SAFE/SAFE WITH CAVEATS/IMPACT FOUND verdict. | ||
@@ -144,2 +147,7 @@ ## Review Guidelines | ||
| - Summarize key findings | ||
| - Include a confidence declaration: | ||
| ``` | ||
| **Confidence:** HIGH | MODERATE | TENTATIVE | ||
| **Reasoning:** [Evidence strength, unknown areas, assumptions] | ||
| ``` | ||
| - Suggest priority of fixes | ||
@@ -146,0 +154,0 @@ - Offer to help implement critical changes |
@@ -39,2 +39,3 @@ # OpenCode Commands | ||
| | `/stop-loop` | Stop iterative loop execution and report current state | orchestrator | `[optional reason or scope]` | | ||
| | `/checkpoint` | Structured phase-boundary checkpoint for human decision | orchestrator | `[phase name or description]` | | ||
@@ -41,0 +42,0 @@ ### Management |
@@ -116,2 +116,81 @@ --- | ||
| ### Pattern 5: Evaluator-Optimizer Loop | ||
| ``` | ||
| orchestrator → @codebase (generate solution) | ||
| → @review (evaluate against criteria) | ||
| → @codebase (iterate based on feedback) ⊛ loop | ||
| → @review (final gate) | ||
| ``` | ||
| Use when quality criteria are well-defined and iterative refinement demonstrably improves output. The evaluator (`@review` or `@brutal-critic`) provides feedback; the generator (`@codebase` or `@blogger`) iterates. Run up to 3 refinement cycles before gating. | ||
| ### Pattern 6: Parallelized Sub-Tasks | ||
| ``` | ||
| orchestrator → @codebase (frontend) ∥ @codebase (backend) | ||
| → @review (integration / contract gate) | ||
| → @docs (unified documentation) | ||
| ``` | ||
| Use when tasks can be cleanly sectioned into independent subtasks (e.g., frontend + backend, API + client SDK, multiple microservices). Aggregate results at the integration gate. Ensure consistent contracts across parallel workers. | ||
| ### Pattern 7: Analyze-Then-Act | ||
| ``` | ||
| orchestrator → @planner (deep analysis, no code changes) | ||
| → [present findings to human] | ||
| → @codebase (implement approved plan) | ||
| → @review (validate) | ||
| ``` | ||
| Use for high-risk or unfamiliar codebases where understanding must precede action. The read-only planner phase prevents premature implementation. | ||
| ## Checkpoint Format | ||
| At multi-phase boundaries, emit a structured checkpoint for human decision: | ||
| ``` | ||
| ## Checkpoint: [Phase Name] Complete — Human Decision Required | ||
| **Phase:** [Phase description] | ||
| **Status:** Complete | ||
| **Completed:** [What was done — files, key changes] | ||
| **Validated:** [Verification results — tests, lint, doctor] | ||
| **Next phase:** [Phase name and brief description] | ||
| **Decision:** Proceed to next phase? | ||
| **Options:** | ||
| [A] Proceed | ||
| [B] Review changes first, then proceed | ||
| [C] Skip this phase, jump to [alternative] | ||
| [D] Stop and hand off | ||
| ``` | ||
| Checkpoints should be emitted at: | ||
| - Phase boundaries in multi-phase plans | ||
| - After high-risk changes (security, schema, contract, build) | ||
| - When the orchestrator needs a decision before continuing | ||
| - Before Phase 7 of any plan (final validation gate) | ||
| ## Fallback Routing | ||
| When a primary path fails, route to alternatives instead of blocking: | ||
| ``` | ||
| orchestrator → @review (primary gate) | ||
| → if FAIL → @planner (diagnose root cause) | ||
| → @codebase (remediate) | ||
| → @review (re-validate) | ||
| → if FAIL again → escalate to human with options | ||
| ``` | ||
| Fallback patterns per failure type: | ||
| - **Review failure** → @planner diagnose → @codebase fix → @review re-validate | ||
| - **Build break** → @codebase fix (auto if safe) → build → re-validate | ||
| - **Test failure** → @planner analyze → @codebase fix → test → re-validate | ||
| - **Multiple cycles fail** → escalate with structured options (do not loop) | ||
| ## Idempotency & Resumption | ||
| When resuming or retrying, avoid re-executing completed work: | ||
| - Before each sub-task, check if it was already completed: | ||
| - `git diff --stat` for already-applied changes | ||
| - File existence for generated artifacts | ||
| - Test pass status for already-verified work | ||
| - Skip completed sub-tasks; report them as "already done" in checkpoint. | ||
| - Reference `state/session-state.json` for prior phase completion status. | ||
| ## Progress Tracking for Long-Running Work | ||
@@ -118,0 +197,0 @@ |
| --- | ||
| name: blogger | ||
| description: Concise content creation for tech, finance, and leadership blogging | ||
| description: Concise content creation for tech, finance, leadership blogging, and career content (resumes, LinkedIn, cover letters, professional bios) | ||
| license: MIT | ||
@@ -45,1 +45,15 @@ compatibility: opencode | ||
| ``` | ||
| ## Career Content (Resumes, LinkedIn, Cover Letters) | ||
| For resume writing, LinkedIn profile optimization, cover letters, and professional bios, | ||
| see [references/career-content.md](references/career-content.md) for detailed rules covering: | ||
| - STAR + metrics bullet formulas and ATS optimization | ||
| - LinkedIn headline strategies, profile visuals, and skills section | ||
| - Cover letter structure and AI-detection avoidance | ||
| - Writing conventions, proofreading checklist, and file format recommendations | ||
| The career-content reference was previously a standalone skill (`career-content`), now | ||
| consolidated under the blogger skill. Both `@blogger` and `@em-advisor` agents can use | ||
| this reference for career content tasks. |
+2
-2
| { | ||
| "name": "agents-opencode", | ||
| "version": "2.1.1", | ||
| "version": "2.2.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.", | ||
@@ -40,3 +40,3 @@ "files": [ | ||
| "devDependencies": { | ||
| "markdownlint-cli": "^0.48.0" | ||
| "markdownlint-cli": "^0.49.0" | ||
| }, | ||
@@ -43,0 +43,0 @@ "keywords": [ |
+22
-1
@@ -120,3 +120,3 @@ # OpenCode Agents | ||
| | `@brutal-critic` | Final content quality gate | | ||
| | `@legal-advisor` | License auditing, IP review, data privacy assessment, regulatory guidance | | ||
| | `@legal-advisor` | Legal research, jurisdiction-aware compliance, contract review, license auditing, data privacy, IP, export controls | | ||
@@ -169,2 +169,22 @@ Canonical source for exact allowlists and skill triggers: [Skills Matrix](./docs/skills-matrix.md) | ||
| ## Usage & Efficiency | ||
| OpenCode's context caching dramatically reduces token consumption across sessions. | ||
| The following metrics are from production usage (May–June 2026) with the | ||
| `deepseek-v4-pro` model. | ||
| | Metric | May 2026 | June 2026 | Combined | | ||
| |---|---|---|---| | ||
| | Cache Hit Tokens | 263.3M | 21.9M | 285.2M | | ||
| | Cache Miss Tokens | 7.9M | 1.3M | 9.2M | | ||
| | Output Tokens | 0.8M | 0.2M | 1.0M | | ||
| | Total Requests | 1,407 | 380 | 1,787 | | ||
| | **Cache Hit Rate** | **97.1%** | **94.5%** | **96.9%** | | ||
| | Avg Tokens/Request | 193K | 62K | 165K | | ||
| Key takeaway: persistent context reuse keeps ~97% of input tokens in cache, | ||
| avoiding costly re-processing across agent sessions. Cache-hit tokens cost | ||
| ~120× less than cache-miss tokens, translating to substantial efficiency | ||
| gains for long-running multi-agent workflows. | ||
| ## Commands | ||
@@ -189,2 +209,3 @@ | ||
| | `/stop-loop` | Stop loop and summarize state | | ||
| | `/checkpoint` | Phase-boundary checkpoint for human decision | | ||
| | `/1-on-1-prep` | Meeting preparation | | ||
@@ -191,0 +212,0 @@ |
| # 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). |
No alert changes
Improved metrics
- Total package byte prevSize
358785
5.03%- Number of package files
102
3.03%- Number of lines in readme file
229
10.1%No dependency changes