feat(client): add typed DynamoClient with DI and integration tests

.agents/skills/git-workflow/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: git-workflow
+description: >-
+  Git workflow automation for committing, branching, and opening pull requests.
+  Use this whenever the user asks to commit their work, create a branch, or
+  create/open/draft a PR.
+---
+
+# Git Workflow
+
+Use this skill whenever the user asks to:
+
+- commit these changes
+- create a commit
+- save my work
+- stage and commit
+- commit current work
+- create a branch
+- start a feature branch
+- make a branch for this work
+- start working on a change
+- create a PR
+- open a PR
+- draft a PR
+- prepare a pull request
+- commit and open a PR
+- create a branch and PR
+- submit the current work
+
+______________________________________________________________________
+
+## Shared references
+
+Before executing any workflow, load all four shared references:
+
+- [Scope Detection](shared/scope-detection.md)
+- [File Inclusion Policy](shared/file-inclusion-policy.md)
+- [Safety Rules](shared/safety-rules.md)
+- [Conventional Types](shared/conventional-types.md)
+
+______________________________________________________________________
+
+## Intent routing
+
+Based on the user's request, load exactly one workflow doc:
+
+| User intent                                     | Load                             |
+| ----------------------------------------------- | -------------------------------- |
+| Commit work, save changes, stage and commit     | [docs/commit.md](docs/commit.md) |
+| Create a branch, start a feature branch         | [docs/branch.md](docs/branch.md) |
+| Create/open/draft a PR, submit the current work | [docs/pr.md](docs/pr.md)         |
+
+When intent is ambiguous, prefer the more complete workflow. If the user says "commit and open a PR", load `docs/pr.md` — it covers the full lifecycle including commit and branch.

.agents/skills/git-workflow/docs/branch.md

@@ -0,0 +1,63 @@
+# Branch Workflow
+
+## Shared references
+
+Load before executing:
+
+- [Scope Detection](../shared/scope-detection.md)
+- [Conventional Types](../shared/conventional-types.md)
+- [Safety Rules](../shared/safety-rules.md)
+
+______________________________________________________________________
+
+## Goal
+
+Create a properly named branch for the current work based on inferred change intent, then switch to it.
+
+## Branch naming format
+
+```
+<type>/<scope>-<short-description>
+```
+
+If no scope applies:
+
+```
+<type>/<short-description>
+```
+
+Rules:
+
+- lowercase only
+- hyphen-separated
+- concise and descriptive
+- remove punctuation
+
+Examples:
+
+- `feat/core-add-pr-automation`
+- `fix/github-handle-detached-head`
+- `docs/update-readme`
+- `ci/github-improve-release-workflow`
+
+## Workflow
+
+1. Inspect repository status and changed files
+2. Infer change type (see [Conventional Types](../shared/conventional-types.md))
+3. Infer optional scope (see [Scope Detection](../shared/scope-detection.md))
+4. Generate branch name
+5. Create the branch
+6. Switch to the branch
+
+## Branch-specific safety
+
+If a branch with the same name already exists, append a short numeric suffix (e.g. `-2`) rather than overwriting it.
+
+See also [Safety Rules](../shared/safety-rules.md) for general constraints.
+
+## Output
+
+Report:
+
+- branch name created
+- branch switched to

.agents/skills/git-workflow/docs/commit.md

@@ -0,0 +1,47 @@
+# Commit Workflow
+
+## Shared references
+
+Load before executing:
+
+- [Scope Detection](../shared/scope-detection.md)
+- [File Inclusion Policy](../shared/file-inclusion-policy.md)
+- [Safety Rules](../shared/safety-rules.md)
+- [Conventional Types](../shared/conventional-types.md)
+
+______________________________________________________________________
+
+## Goal
+
+Create a commit representing the user's current working changes using a conventional commit format.
+
+## Commit format
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+The description must immediately follow the colon and space. Scope is wrapped in parentheses when present: `feat(parser): add CSV support`.
+
+For breaking changes, append `!` after the type/scope and/or include a `BREAKING CHANGE:` footer. See [Conventional Types](../shared/conventional-types.md) for details.
+
+## Workflow
+
+1. Inspect repository status
+2. Identify all modified files
+3. Stage all user-modified files (see [File Inclusion Policy](../shared/file-inclusion-policy.md))
+4. Exclude only obvious junk artifacts
+5. Infer `<type>` and `<scope>` (see [Conventional Types](../shared/conventional-types.md) and [Scope Detection](../shared/scope-detection.md))
+6. Generate and create the commit
+
+## Output
+
+Report:
+
+- commit message used
+- files committed
+- any files excluded and why

.agents/skills/git-workflow/docs/pr.md

@@ -0,0 +1,123 @@
+# PR Workflow
+
+## Shared references
+
+Load before executing:
+
+- [Scope Detection](../shared/scope-detection.md)
+- [File Inclusion Policy](../shared/file-inclusion-policy.md)
+- [Safety Rules](../shared/safety-rules.md)
+- [Conventional Types](../shared/conventional-types.md)
+
+______________________________________________________________________
+
+## Goal
+
+Prepare the current work for review and create a pull request that includes:
+
+- a correctly named branch
+- a conventional commit message
+- a PR title following the required format
+- a reviewable PR body that explains what changed, why, validation, and risk
+
+Template location: `../templates/pull-request-template.md`
+
+______________________________________________________________________
+
+## PR title format
+
+```
+<type>[optional scope]: <description>
+```
+
+For breaking changes, append `!` after the type/scope: `feat(api)!: remove deprecated endpoint`
+
+Example: `feat(core): add automated PR workflow`
+
+______________________________________________________________________
+
+## Branch rules
+
+Create a new branch if:
+
+- the current branch is `main`
+- the repository is in detached `HEAD`
+
+If already on a feature branch, use the current branch.
+
+Branch naming follows `<type>/<scope>-<short-description>` (or `<type>/<short-description>` when no scope applies). See [Branch Workflow](branch.md) for full naming rules.
+
+______________________________________________________________________
+
+## Execution flow
+
+### 1 — Inspect repository
+
+Determine: current branch, whether HEAD is detached, git status, modified files, diff summary, and commit history against the base branch.
+
+### 2 — Infer metadata
+
+Determine: PR type, optional scope, short description, PR title, branch name.
+
+### 3 — Prepare branch
+
+If on `main` or detached `HEAD`, create a new branch and switch to it. Otherwise stay on the current branch.
+
+### 4 — Commit work
+
+Stage all user-modified files per [File Inclusion Policy](../shared/file-inclusion-policy.md). Exclude only obvious junk. Create commit. Skip if nothing to commit.
+
+### 5 — Push branch
+
+Push to origin. Set upstream if necessary.
+
+### 6 — Generate PR body
+
+Load `../templates/pull-request-template.md` and adapt it to the actual change.
+
+Treat the template as a default outline, not a rigid contract. Prioritize reviewer scanability and signal quality over filling every heading.
+
+Required information:
+
+- what changed
+- why it changed
+- how it was validated
+
+Default outline (adapt as needed):
+
+- Summary - 2-4 sentences covering what changed and why
+- Changes - grouped in the way that makes the diff easiest to review (for example by concern, subsystem, workflow, or user impact)
+- Validation - concrete tests, manual verification, and confidence signals
+- Breaking Changes - include only when applicable
+- Related Issues - include only when applicable; do not invent issue numbers
+- Release Notes - include only for user-visible or package-relevant changes
+- Notes for Reviewers - include when review guidance, risks, tradeoffs, follow-up context, or requested feedback focus would help; for UI changes, include screenshots/video links when useful
+
+Review mode:
+
+- open as draft when implementation is incomplete, checks are pending, or early feedback is requested
+- when draft, state what is incomplete and what feedback is being requested
+
+Rules:
+
+- omit empty sections entirely (do not include `N/A`, `None`, or `No related issues`)
+- prefer fewer, high-signal sections over boilerplate
+- use backticks for identifiers, commands, files, and code terms
+- keep the Summary concise and focused on intent, not file-by-file trivia
+
+### 7 — Create PR
+
+Create the pull request using the generated title and body, as draft or ready-for-review based on the review mode rules above.
+
+______________________________________________________________________
+
+## Output
+
+Report:
+
+- branch name and whether it was created
+- commit message and whether a commit was created
+- PR title
+- PR body
+- any files excluded and why
+- any assumptions or blockers

.agents/skills/git-workflow/examples/ci-example.md

@@ -0,0 +1,17 @@
+# Example: CI PR
+
+## Scenario
+
+Current work updates GitHub Actions and release automation for NuGet publishing.
+
+## Expected branch
+
+`ci/github-improve-nuget-release-workflow`
+
+## Expected commit
+
+`ci(github): improve NuGet release workflow`
+
+## Expected PR title
+
+`ci(github): improve NuGet release workflow`

.agents/skills/git-workflow/examples/feature-example.md

@@ -0,0 +1,52 @@
+# Example: Feature PR
+
+## Scenario
+
+Current work adds automatic PR template loading and branch creation when running from `main`.
+
+## Expected branch
+
+`feat/core-automate-pr-workflow`
+
+## Expected commit
+
+`feat(core): automate PR workflow from main`
+
+## Expected PR title
+
+`feat(core): automate PR workflow from main`
+
+## Example PR body
+
+# 🚀 Pull Request
+
+## 📋 Summary
+
+> Adds automation for branch preparation and PR generation when opening a pull request from the current repository state. This removes manual branch setup when starting from `main` and keeps PR metadata generation consistent with inferred change intent.
+
+______________________________________________________________________
+
+## 📝 Changes
+
+- Branch preparation flow
+  - Detects `main` and detached `HEAD` before PR creation
+  - Creates and switches to a generated branch only when needed
+- Metadata and PR drafting
+  - Infers PR metadata (`type`, optional `scope`, short description)
+  - Loads the local PR template and builds the PR body from current repository state
+- Workflow consistency
+  - Reuses shared scope and inclusion policy logic so commit and PR behavior stay aligned
+
+______________________________________________________________________
+
+## 🧪 Validation
+
+- Build/test status: Not explicitly verified by the agent
+- Manual verification performed: Reviewed repository status, branch behavior, and generated PR content paths
+- Edge cases checked: Existing feature branch path and detached `HEAD` path
+
+______________________________________________________________________
+
+## 💬 Notes for Reviewers
+
+> Please focus on branch creation guardrails and metadata inference fallbacks, especially when repository state is ambiguous.

.agents/skills/git-workflow/examples/fix-example.md

@@ -0,0 +1,17 @@
+# Example: Fix PR
+
+## Scenario
+
+Current work fixes a bug in GitHub workflow handling for detached HEAD repositories.
+
+## Expected branch
+
+`fix/github-handle-detached-head`
+
+## Expected commit
+
+`fix(github): handle detached HEAD when opening PRs`
+
+## Expected PR title
+
+`fix(github): handle detached HEAD when opening PRs`