If the request names a squad, recommend that squad's members. If it names a team, list that team's members. Otherwise infer the team from the task (file types, domain, keywords), then pick the single best member — and a squad if the task spans teams. Invoke a member with @agent-<team>-<role> (Claude) / <team>-<role> (Antigravity). Prefer the most specific member; do not fan out the whole team. Explain the choice in one line.

Members (team-role: use when)

web-api: Designing or changing backend HTTP/GraphQL APIs, OpenAPI/GraphQL schemas, request validation, route handlers, auth middleware, or database migrations that shape the frontend contract.
web-fe: Building or modifying UI components, styling, accessibility (ARIA/axe), client-side routing, Storybook stories, or data-bound views against an API contract
web-webarch: Delegate for framework selection/upgrades, rendering-strategy decisions (SSR/SSG/ISR/CSR), monorepo package boundaries, cache-control and CDN topology, design-system governance, or any cross-cutting architectural trade-off requiring an RFC/ADR.
web-webqa: End-to-end/cross-browser test authoring or review, Playwright/Cypress suites, Lighthouse performance/accessibility budgets, visual-regression diffing, or filing/triaging bug reports for web features marked ready for QA.
web-websec: Auditing web code, configs, or dependencies for vulnerabilities — OWASP Top 10 checks, security header/CSP validation, npm/pnpm dependency audits, secret scanning, auth/session/token review, or CORS policy enforcement before merge or release.
go-goarch: Designing or reviewing service boundaries, defining Go interfaces before implementation, governing .proto/RPC contracts, modeling goroutine lifecycles, or planning cross-service refactors and distributed tracing topology.
go-godev: Writing or modifying Go source — implementing services, CLIs (cobra), libraries, concurrency, error handling, or module hygiene in cmd/, internal/, or pkg/.
go-goqa: Validating a Go implementation marked Ready for QA — running the race detector, writing fuzz/benchmark/integration tests, enforcing coverage gates, or chasing goroutine leaks and flaky tests.
go-gosec: A Go change needs a security review: gosec/govulncheck findings, new go.mod dependencies, CVE/SBOM auditing, secret handling, TLS/mTLS config, or container privilege hardening before staging promotion.
terraform-aws-cloudarch: Designing AWS account topology, landing zones, VPC/network tiers, multi-region RPO/RTO strategy, ADRs, or evaluating designs against the Well-Architected pillars and cost governance.
terraform-aws-cloudsec: Static policy scanning of Terraform (checkov/tfsec), IAM role and policy audits, encryption-at-rest enforcement, CloudTrail/VPC Flow Log verification, S3 public access blocks, or SCP guardrail authoring.
terraform-aws-infra: Authoring or refactoring Terraform modules, composing root modules in environments/, writing variable blocks, configuring remote state, reviewing terraform plan output, or applying tagging and lifecycle rules to AWS resources
terraform-aws-platform: Setting up or fixing CI/CD pipelines, GitHub Actions workflows, Atlantis configs, ECR lifecycle policies, ECS/EKS rollouts, container build automation, or CI secret handling via OIDC for AWS workloads.
ai-ci-aiarch: Designing or reviewing agentic workflows, RAG/retrieval architecture, multi-model chains, model tier policies, eval harnesses, or LLMOps system design and ADRs
ai-ci-aidev: Building or modifying LLM-backed features — prompt pipelines, RAG, embeddings, structured-output parsing, model-abstraction wrappers, or eval suites under evals/
ai-ci-ci: Authoring or fixing CI pipelines — GitHub Actions YAML, Makefile targets, caching strategy, build matrices, runner provisioning, concurrency controls, or speeding up lint/test jobs.
ai-ci-modelops: The session needs to deploy, configure, or scale model-serving stacks (Ollama/LiteLLM/vLLM), manage GPU resource limits and VRAM, maintain the model registry, set inference latency SLOs, or design canary rollouts and air-gap model mirrors.
architecture-adversary: Independently verifying or refuting a claim, finding, or another agent's answer before it is trusted — adversarial second-opinion on audit/review output, fact-checking a conclusion against the actual source, calibrating severity, and filtering false positives out of a set of findings.
architecture-em: The main session needs cross-team conflict resolution among architects, translation of business goals into engineering objectives, roadmap or risk-register updates, priority arbitration, plain-language stakeholder summaries of architectural decisions, or organizing a new objective (a GitHub issue or a gss draft PR) into the docs/mbo design→spec→plan pipeline via the mbo-plan skill.
architecture-principal: A change touches auth, data migrations, public APIs, or core infrastructure and needs a mandatory critical review; engineering standards, linter configs, or the design pattern library must be defined or enforced; tech debt must be cataloged or prioritized for sprint allocation.
architecture-secarch: Designing or reviewing security architecture — STRIDE threat models, zero-trust enforcement, identity/OAuth2/OIDC flows, secrets management strategy, compliance mapping (SOC 2, GDPR, HIPAA), or blast-radius analysis of a new service or major feature.
architecture-sysarch: Significant design decisions, service-boundary or data-store choices, multi-team/multi-service changes, cross-cutting contracts (observability/auth/error propagation), dependency-graph review, or capacity modeling before production.

Squads (cross-team)

fullstack-feature: web/fe, web/api, go/godev, architecture/sysarch
secure-release: go/gosec, web/websec, architecture/secarch
infra-rollout: terraform-aws/infra, terraform-aws/platform, terraform-aws/cloudsec
adversarial-review: architecture/adversary, architecture/principal

Más de este repositorio

mismo repositorio

google-docs

sfc-gh-eraigosa/dotfiles

Integration for interacting with Google Docs and Google Workspace using the 'gws' CLI.

2026-07-0743

mbo-plan

sfc-gh-eraigosa/dotfiles

Plan a new objective end-to-end in this repo's docs/mbo Management-By-Objective system — turn a GitHub issue or a gss draft-PR worktree into consistent design/spec/plan artifacts and track it in docs/mbo/index.md. Use this whenever the user wants to START planning or designing a new feature, skill, CLI, or service: "plan this issue", "let's design X", "spec this out", "write a plan for #N", "start an MBO / a design doc", or when they're working in a gss draft PR and want to scope the work — even if they don't say "mbo". Routes the task to the right skill workflow (skill-creator, brainstorming→writing-plans, the go/web teams) per docs/mbo/AGENTS.md. Also anchors the objective to a GitHub design issue + a gss draft PR, and — when the plan is ready and it's time to BUILD — asks whether to "break out the work / parallelize / divide it across the teams": a dependency graph of leaf tasks, each a gss feature worker with its own worktree, draft PR, and linked GitHub sub-issue, fanned out via a Workflow, blocking task

2026-07-0743

remote-claude-session

sfc-gh-eraigosa/dotfiles

Start, restart, or attach to a persistent Claude --remote-control session on any remote SSH host inside a specified git repository. Use this skill whenever the user asks to "start a remote Claude session", "spin up Claude on [host]", "set up remote control on [host]", "launch Claude remotely in [repo]", "start an AI session on [machine]", "restart the remote Claude session", or any variation of establishing or checking a remote Claude Code instance. Also triggers when the user asks to check whether a remote session is running or to get the attach command for an existing one.

2026-07-0743

sync-skills

sfc-gh-eraigosa/dotfiles

Synchronize AI agent skills and build binaries from the dotfiles repository.

2026-07-0743

gsl-status

sfc-gh-eraigosa/dotfiles

Query and configure the gsl (Go Status Line) that renders a powerline-style status bar in Claude Code and Antigravity CLI.

2026-07-0743

tmux

sfc-gh-eraigosa/dotfiles

A powerful, Go-based management tool for tmux, providing structured session management, window arrangements, layout persistence, and autonomous AI Agent Team Orchestration.

2026-07-0743

name	team
description	Route a task to the right AI team + member (two-level team→member selection)

Route a development task to the best-fit specialist agent from the AI teams.

Members (team-role: use when)

web-api: Designing or changing backend HTTP/GraphQL APIs, OpenAPI/GraphQL schemas, request validation, route handlers, auth middleware, or database migrations that shape the frontend contract.
web-fe: Building or modifying UI components, styling, accessibility (ARIA/axe), client-side routing, Storybook stories, or data-bound views against an API contract
web-webarch: Delegate for framework selection/upgrades, rendering-strategy decisions (SSR/SSG/ISR/CSR), monorepo package boundaries, cache-control and CDN topology, design-system governance, or any cross-cutting architectural trade-off requiring an RFC/ADR.
web-webqa: End-to-end/cross-browser test authoring or review, Playwright/Cypress suites, Lighthouse performance/accessibility budgets, visual-regression diffing, or filing/triaging bug reports for web features marked ready for QA.
web-websec: Auditing web code, configs, or dependencies for vulnerabilities — OWASP Top 10 checks, security header/CSP validation, npm/pnpm dependency audits, secret scanning, auth/session/token review, or CORS policy enforcement before merge or release.
go-goarch: Designing or reviewing service boundaries, defining Go interfaces before implementation, governing .proto/RPC contracts, modeling goroutine lifecycles, or planning cross-service refactors and distributed tracing topology.
go-godev: Writing or modifying Go source — implementing services, CLIs (cobra), libraries, concurrency, error handling, or module hygiene in cmd/, internal/, or pkg/.
go-goqa: Validating a Go implementation marked Ready for QA — running the race detector, writing fuzz/benchmark/integration tests, enforcing coverage gates, or chasing goroutine leaks and flaky tests.
go-gosec: A Go change needs a security review: gosec/govulncheck findings, new go.mod dependencies, CVE/SBOM auditing, secret handling, TLS/mTLS config, or container privilege hardening before staging promotion.
terraform-aws-cloudarch: Designing AWS account topology, landing zones, VPC/network tiers, multi-region RPO/RTO strategy, ADRs, or evaluating designs against the Well-Architected pillars and cost governance.
terraform-aws-cloudsec: Static policy scanning of Terraform (checkov/tfsec), IAM role and policy audits, encryption-at-rest enforcement, CloudTrail/VPC Flow Log verification, S3 public access blocks, or SCP guardrail authoring.
terraform-aws-infra: Authoring or refactoring Terraform modules, composing root modules in environments/, writing variable blocks, configuring remote state, reviewing terraform plan output, or applying tagging and lifecycle rules to AWS resources
terraform-aws-platform: Setting up or fixing CI/CD pipelines, GitHub Actions workflows, Atlantis configs, ECR lifecycle policies, ECS/EKS rollouts, container build automation, or CI secret handling via OIDC for AWS workloads.
ai-ci-aiarch: Designing or reviewing agentic workflows, RAG/retrieval architecture, multi-model chains, model tier policies, eval harnesses, or LLMOps system design and ADRs
ai-ci-aidev: Building or modifying LLM-backed features — prompt pipelines, RAG, embeddings, structured-output parsing, model-abstraction wrappers, or eval suites under evals/
ai-ci-ci: Authoring or fixing CI pipelines — GitHub Actions YAML, Makefile targets, caching strategy, build matrices, runner provisioning, concurrency controls, or speeding up lint/test jobs.
ai-ci-modelops: The session needs to deploy, configure, or scale model-serving stacks (Ollama/LiteLLM/vLLM), manage GPU resource limits and VRAM, maintain the model registry, set inference latency SLOs, or design canary rollouts and air-gap model mirrors.
architecture-adversary: Independently verifying or refuting a claim, finding, or another agent's answer before it is trusted — adversarial second-opinion on audit/review output, fact-checking a conclusion against the actual source, calibrating severity, and filtering false positives out of a set of findings.
architecture-em: The main session needs cross-team conflict resolution among architects, translation of business goals into engineering objectives, roadmap or risk-register updates, priority arbitration, plain-language stakeholder summaries of architectural decisions, or organizing a new objective (a GitHub issue or a gss draft PR) into the docs/mbo design→spec→plan pipeline via the mbo-plan skill.
architecture-principal: A change touches auth, data migrations, public APIs, or core infrastructure and needs a mandatory critical review; engineering standards, linter configs, or the design pattern library must be defined or enforced; tech debt must be cataloged or prioritized for sprint allocation.
architecture-secarch: Designing or reviewing security architecture — STRIDE threat models, zero-trust enforcement, identity/OAuth2/OIDC flows, secrets management strategy, compliance mapping (SOC 2, GDPR, HIPAA), or blast-radius analysis of a new service or major feature.
architecture-sysarch: Significant design decisions, service-boundary or data-store choices, multi-team/multi-service changes, cross-cutting contracts (observability/auth/error propagation), dependency-graph review, or capacity modeling before production.

Squads (cross-team)

fullstack-feature: web/fe, web/api, go/godev, architecture/sysarch
secure-release: go/gosec, web/websec, architecture/secarch
infra-rollout: terraform-aws/infra, terraform-aws/platform, terraform-aws/cloudsec
adversarial-review: architecture/adversary, architecture/principal