woliveiras/baseline

Explore a software problem space deeply before choosing a direction. Use when the user explicitly asks to explore materially different alternatives, hidden assumptions, or opportunity discovery before selecting a design, even without naming this skill. This owns the divergent phase over refine; security and domain concerns may stress the options but do not replace exploration. Do not trigger for ordinary clarification or implementation.

Diagnose and repair an existing software defect through bug report, reproduction, fail-first regression test, causal fix, and focused review. Use for reported incorrect, regressed, or intermittent existing behavior; this workflow owns its regression check, so do not also invoke tdd unless separately approved new behavior is required. Do not use for new features disguised as bugs.

Create, review, or repair CI pipelines and workflows, including GitHub Actions, that produce traceable quality evidence with least privilege. Use for test, lint, build, cache, artifact, release, deploy, fork, secret, or workflow-permission automation; compose with security-review for untrusted input or sensitive authority boundaries, and do not bypass protected production authority.

Make a material software decision with explicit options, evidence types, uncertainty, dependencies, reversibility, and validation. Use when several viable paths remain after refinement; do not use to add ceremony to routine reversible choices.

Design or compare concrete high-leverage module boundaries with small stable interfaces, hidden complexity, explicit seams, adapters, locality, and reversible migration. Use when the request asks for boundary or interface design; not for whole-architecture audits or requests that explicitly defer new module-boundary design.

Maintain the smallest durable software documentation surface for shipped behavior, architecture, decisions, operations, incidents, and non-obvious code reasons. Use when knowledge must outlive the current task; do not create documentation for routine reversible work or narrate self-explanatory code.

Create a safe atomic local Git commit from a verified task-owned slice using Conventional Commits. Use only when the user explicitly requests a local commit or explicitly asks to follow a repository contract that requires one; do not use when the request says not to commit, or for push, amend, rebase, merge, tag, release, or history rewriting.

Audit a codebase for evidence-backed architecture improvements, leverage, seams, locality, and reversibility. Use when the user explicitly requests an assessment of the existing architecture, including when the request defers new module-boundary design; do not implement changes, create a refactor spec, or infer broad authority from the audit.

Classify software work by risk, boundaries, reversibility, ambiguity, validation difficulty, and rollout exposure, then route only the proportional refinement, documentation, and review depth. Use implicitly at the start of software implementation, repair, review, or delivery work; do not use line count as a size proxy or create persistent planning artifacts.

Anticipate plausible failure modes for a proposed software change and convert them into proportional mitigations, expected checks, detection, and rollback. Use before committing to medium or high-risk work; do not use to generate generic risk lists for trivial changes.

Resolve material ambiguity in a software request with a proportional decision tree. Invoke from incompatible interpretations even without naming this skill; do not use because a task is large or when repository evidence already makes the path clear.

Review a software change or CI workflow for technology-neutral security, privacy, data-loss, and authority risks using verifiable evidence. Use for trust boundaries, untrusted or fork-controlled input, secrets, sensitive data, permissions, privileges, or destructive and external actions. This owns requests limited to security risks. When security is secondary to broader work, compose with the owning workflow; defer stack-specific remediation to dedicated skills.

Create a truthful compact continuation that lets another software-engineering session resume from governing inputs, current artifacts, and real results. Use whenever the user explicitly asks to pause ongoing work or hand it to another session, even without naming this skill; do not claim to measure context-window health or replace project documentation.

Create, audit, or safely reconcile a repository-root AGENTS.md with the Baseline engineering contract and observed project facts. Use only when the user explicitly asks to initialize, set up, adopt, audit, or update Baseline project instructions; do not activate for ordinary software work or general questions about AGENTS.md.

Continuously align domain language, invariants, scenarios, bounded contexts, integration translations, governing inputs, tests, and code. Invoke for semantic reconciliation even without naming this skill when conflicting or overlapping terms across APIs, persistence, tests, and product language need reconciliation, or when vocabulary and ownership boundaries affect behavior or design. This owns semantic reconciliation over refine until a concrete incompatible decision remains; do not use for cosmetic wording changes.

Implement approved new or changed behavior directly from a governing request, issue, contract, decision, or other sufficient input through a fail-first executable check. Use for clear testable behavior; do not invoke for a reported existing defect because bugfix owns its regression test and repair. Do not use to invent requirements from current implementation or maximize test count.

Investigate a technical engineering question with primary sources, repository evidence, reproducible searches, and explicit limitations. Use whenever the user asks to determine what a current standard, API, tool, or official implementation guidance guarantees, or the answer depends on empirical studies or another unstable technical claim, even without naming this skill. This owns current external evidence over docs even when evidence access is unavailable, in which case report the gap; do not use for simple facts already established locally.

Review a software change proportionally against its governing input, expected behavior, tests, complete diff, relevant risks, fresh results, unrelated changes, and limitations. Use at review or completion boundaries; do not also invoke for a request limited to security risks, which security-review owns.