soba-agent 0.4.0

package/skills/pr-description/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: pr-description
+description: Generate structured pull request descriptions from branch changes.
+soba:
+  version: 1
+  triggers:
+    - pull request description
+    - pr body
+    - merge request summary
+  memory-policy: none
+---
+
+# Pull Request Description
+
+## Purpose
+
+Create a reviewer-ready pull request description from branch commits, diffs, and project-specific requirements.
+
+## Triggers
+
+Use this skill when the user asks for a PR description, merge request body, release-oriented change summary, or reviewer checklist.
+
+## Inputs To Inspect
+
+- Project instructions for PR format.
+- Current branch name.
+- Comparison base requested by the user or the repository default.
+- Commit log for the branch.
+- Changed files, diff stat, and relevant detailed diffs.
+- Test or verification evidence from the current task when available.
+
+## Procedure
+
+1. Determine the base branch or comparison range.
+2. Inspect branch commits and changed file statistics.
+3. Read detailed diffs for files that define the main behavior change.
+4. Group changes by purpose and user impact.
+5. List verification that actually ran, preserving command names.
+6. Call out breaking changes, migrations, risks, or follow-up work only when supported by evidence.
+7. Format the PR body using project instructions or a compact default structure: Summary, Changes, Verification, Risk.
+
+## Verification Contract
+
+The PR description must match the inspected branch diff and must not claim tests, screenshots, migrations, issues, or breaking changes that were not observed.
+
+## Failure Recovery
+
+If the base branch cannot be determined, inspect local branches and ask for the intended base only if the ambiguity changes the result. If the branch has many unrelated changes, group by directory and make the scope visible.
+
+## Memory Policy
+
+Do not write project memory. Read memory only if it was already injected and contains a PR template or reviewer convention.
+
+## Stop Conditions
+
+Stop after producing the requested PR description or after identifying that a missing comparison base prevents a correct description.
+
+## Anti-Patterns
+
+- Do not invent verification results.
+- Do not include boilerplate checklists unless the project expects them.
+- Do not hide unreviewed or high-risk areas.

package/skills/test-authoring/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: test-authoring
+description: Add focused tests from use cases, regressions, or behavior contracts.
+soba:
+  version: 1
+  triggers:
+    - write tests
+    - add coverage
+    - regression test
+  memory-policy: read
+---
+
+# Test Authoring
+
+## Purpose
+
+Create tests that prove behavior through realistic inputs, clear assertions, and project-native tooling.
+
+## Triggers
+
+Use this skill when the user asks to add tests, improve coverage, capture a regression, or turn use cases into automated checks.
+
+## Inputs To Inspect
+
+- Project instructions for test framework and runtime.
+- Use cases, bug reports, or acceptance criteria.
+- Existing tests near the target module.
+- Public APIs and fixtures already used by the project.
+- Commands for targeted and full verification.
+
+## Procedure
+
+1. Read project instructions and nearby test style.
+2. Map each requested behavior or edge case to a test case.
+3. Prefer integration-style tests with real files or processes when the project pattern supports it.
+4. Keep mocks minimal and explicit.
+5. Make the test fail for the intended reason when practical, then implement or adjust code only if the user requested a fix too.
+6. Run the targeted test file, then broader checks when production code changed.
+
+## Verification Contract
+
+New or updated tests must pass with the project test command. If production code changed, verification must include tests that exercise the changed behavior.
+
+## Failure Recovery
+
+If the test is flaky or over-specified, reduce the assertion to the behavior contract. If setup is too expensive, reuse existing fixtures or build a smaller deterministic fixture.
+
+## Memory Policy
+
+Read memory for known test conventions. Write memory only for stable, verified test patterns that recur across the project.
+
+## Stop Conditions
+
+Stop when the requested tests pass and accurately cover the behavior, or when missing requirements prevent a meaningful assertion.
+
+## Anti-Patterns
+
+- Do not assert implementation details unless they are the contract.
+- Do not add tests that only duplicate type checks.
+- Do not hide failures by weakening assertions unrelated to the requested behavior.

package/skills/version-bump/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: version-bump
+description: Bump project version files and prepare the matching release commit.
+soba:
+  version: 1
+  triggers:
+    - version bump
+    - release version
+    - bump package
+  memory-policy: read
+---
+
+# Version Bump
+
+## Purpose
+
+Update project version references consistently and verify the release-ready change.
+
+## Triggers
+
+Use this skill when the user asks to bump a version, prepare a release version, or update version references before a release commit.
+
+## Inputs To Inspect
+
+- Project instructions for release workflow.
+- Version fields in package manifests.
+- CLI or source constants that print the version.
+- Tests that assert the version string.
+- Recent commits or the exact version requested by the user.
+
+## Procedure
+
+1. Prefer the exact version or bump type specified by the user.
+2. If the user did not specify a bump, inspect recent commits and choose patch unless features or breaking changes clearly require minor or major.
+3. Locate every authoritative version reference used by runtime code and tests.
+4. Update only those version references and any directly required snapshots or tests.
+5. Run the project-required verification commands for version changes.
+6. Prepare a release commit only when the user asked for a commit and verification passes.
+
+## Verification Contract
+
+The manifest version, runtime version output, and version assertions must agree. Required tests, linting, type checks, and build commands for the project must pass before reporting completion.
+
+## Failure Recovery
+
+If version references disagree before the change, report the mismatch and update the authoritative set consistently. If verification fails after the bump, fix version-related failures first and avoid unrelated refactors.
+
+## Memory Policy
+
+Read project memory for known release conventions if available. Write memory only after a verified, repeated release convention is discovered and it contains no secrets.
+
+## Stop Conditions
+
+Stop when all version references are updated and verification passes, or when the requested target version conflicts with project constraints.
+
+## Anti-Patterns
+
+- Do not bump versions opportunistically during unrelated work.
+- Do not create tags or publish packages unless explicitly requested.
+- Do not infer a major release without concrete breaking-change evidence.