agent-toolkit-cli 1.0.3__py3-none-any.whl

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/core/onboarding/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: onboarding
+description: >-
+  Getting started guide for new users. Walks through setup validation,
+  the skill/agent hierarchy, and the three most useful commands per role (developer,
+  PM, tech lead). Use when someone is new to the workstation or asks "where do I start?"
+metadata:
+  author: ulises-jeremias
+  version: "1.0"
+  tags: [onboarding, setup, getting-started]
+---
+
+# Onboarding
+
+Welcome to . This skill guides new users through initial setup and daily usage.
+
+## When to use
+
+- User asks "where do I start?" or "how does this work?"
+- First-time setup after `chezmoi apply`
+- Troubleshooting a broken installation
+- Onboarding a teammate
+
+## Step 1 — Validate setup
+
+```bash
+doctor
+```
+
+Expected: `result: COMPLIANT`. If any check fails, `doctor` shows the fix command.
+
+For persistent issues:
+
+```bash
+update-check            # check for available updates
+skills list             # verify skills are installed
+skills sync             # re-sync symlinks to AI tools
+```
+
+## Step 2 — Understand the hierarchy
+
+```text
+User message
+    ↓
+Orchestrator (assistant)
+    ↓ routes to
+Workflow skill (WHAT — decides scope and gates)
+    e.g. workflow-generic-project
+    ↓ delegates to
+Tool skill (HOW — executes CLI commands)
+    e.g. clickup-cli, github-cli-workflow
+```
+
+**Skills** are invoked via the skill tool (e.g. `/planning`).
+**Agents** are invoked via `@mention` (e.g. `@planner`). Never use the skill tool for agents.
+
+## Step 3 — First commands by role
+
+### Developer
+
+```bash
+# Start any task
+/workflow-generic-project
+
+# After code changes — review before PR
+@code-reviewer
+
+# CI failing
+/gh-fix-ci
+```
+
+### Product Manager / Tech Lead
+
+```bash
+# Plan a feature
+@planner
+
+# Create a ClickUp task
+/clickup-cli  # then: clickup task create --current --name "..."
+
+# Project health check
+/project-assessment
+```
+
+### Anyone
+
+```bash
+# Check workstation health
+doctor
+
+# Find which skill to use
+# → ask the orchestrator: "what skill should I use for X?"
+
+# Load client/project context
+./bin/workspace-context load packs/<client>.yaml   # if in ai-workspace
+```
+
+## Key concepts in 60 seconds
+
+| Concept | What it means |
+|---------|--------------|
+| **Pack** | Context bundle for a client/project (repos, constraints, commands) |
+| **Skill** | Reusable AI prompt for a specific task (WHAT or HOW) |
+| **Agent** | Specialized AI persona with restricted tool access (invoked via @mention) |
+| **Loop** | Recurring autonomous process with state, tiers, and cost budgets |
+| **L1 / L2 / L3** | Loop autonomy tiers: L1=observe-only, L2=PR-gated, L3=unattended |
+| **knowledge/** | Persistent memory across sessions |
+
+## Anti-patterns
+
+- Do not skip `doctor` — it catches 90% of setup issues
+- Do not invoke agents via the skill tool — use `@mention`
+- Do not run L3 loops without 3+ clean L1 runs first
+
+## Next steps
+
+- Load a project pack: `./bin/workspace-context load packs/<project>.yaml`
+- Run your first task: `/workflow-generic-project`
+- Set up daily loop: `./bin/loop init daily-triage`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/core/output-handshake/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: output-handshake
+description: >-
+  WHAT — Default gate for any deliverable: confirm where the final artifact will be stored and that a human will review, before writing PRDs, TRDs, ADRs, or PR bodies. Repository paths, wikis, and ticket tools differ by engagement; never assume a single location.
+---
+
+# Output handshake (WHAT)
+
+**Use first** when producing a **final** version of any deliverable that will leave the chat session: PRD, TRD, ADR, work item, planning notes, workflow/validation summary, project assessment, assessment scorecard, evidence map, meeting minutes, decision log, agreement, incident report, spike, or PR/MR body.
+
+## Default behavior (always)
+
+1. **Destination** — Ask explicitly: *where should the final content live?* (Examples: a path in `docs/`, a file in a repo, a page in a documentation tool, a task/Doc description, paste-only, or a combination.) Do **not** default to a location without the user (or the engagement pack) saying so.
+2. **Review** — State that a **human** must review before the artifact is considered approved; the assistant does not substitute for that review.
+3. Then proceed with the relevant skill (**`prd`**, **`trd`**, **`adr`**, **`work-item`**, **`planning`**, **`development-workflow`**, **`project-assessment`**, **`project-assessment-evidence`**, **`technical-unit-assessment`**, **`management-unit-assessment`**, **`meeting-minutes`**, **`decision-log`**, **`agreement`**, **`incident`**, **`spike`**, **`pr-fallback`** + forge workflow, etc.).
+
+## Boundaries
+
+- This skill does not contain org templates; those stay in the specific artifact skills and their `references/default-template.md` files.
+
+## See also
+
+- `workflow-generic-project` — delivery gates
+- `assistant` — discover existing `docs/`, PR templates, `AGENTS.md`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/core/pr-fallback/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: pr-fallback
+description: >-
+  WHAT — When the repo has no GitHub PR template, structure the pull-request body using the default in references/pr-body-default.md. Pair with output-handshake and github-cli-workflow. Does not open the PR; HOW stays in the forge skill.
+---
+
+# PR body — default when no repo template (WHAT)
+
+## When to use
+
+- Remote is **GitHub** and **`assistant`** (or a file search) shows **no** `PULL_REQUEST_TEMPLATE` / `pull_request_template` under `.github/`.
+- You need a **reasonable default** for `gh pr create --body-file` until the repo adds its own template.
+
+## Instructions
+
+1. Run **`output-handshake`**: user confirms where the final description will live (e.g. `body.md` for `gh`, paste-only) and that a **human** will review.
+2. If the repository adds a template later, **prefer the repo** over this file.
+3. Copy sections from **`references/pr-body-default.md`**, fill placeholders (issue id, test notes), and pass the path to **`github-cli-workflow`**.
+
+## GitLab
+
+If there is no `.gitlab/merge_request_templates/`, you may use the same Markdown structure in the **merge request description** for consistency, subject to the user’s **destination** choice (MR description field, file, etc.) and **`output-handshake`**.
+
+## What not to do
+
+- Do not **assume** a PR is always in a specific ticket system; the **file** the user points to is wherever they said in the handshake.
+
+## References
+
+- `references/pr-body-default.md` — local copy of the default body
+- `development-workflow` — default PR validation and DoD expectations
+- `github-cli-workflow` — draft PR creation
+- `gitlab-cli-workflow` — GitLab MRs

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/core/workspace-knowledge-sync/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: workspace-knowledge-sync
+description: >-
+  Syncs knowledge to the ai-workspace knowledge base. Use when the assistant
+  discovers new patterns, learns user preferences, or identifies information worth
+  preserving for future sessions. Integrates with tech-assistant for automatic
+  trigger points.
+---
+
+# Workspace Knowledge Sync
+
+Automatically syncs valuable discoveries, patterns, and decisions to the ai-workspace knowledge base.
+
+---
+
+## Purpose
+
+The orchestrator session accumulates knowledge through work. This skill ensures that valuable discoveries don't get lost and are available for future sessions.
+
+---
+
+## Trigger Points (Automatic)
+
+The tech-assistant will invoke this skill automatically when:
+
+| Situation | What to Sync | Target File |
+|-----------|--------------|-------------|
+| Discovery of new skill/tool | Skill name, purpose, usage pattern | `knowledge/skills/discovered.md` |
+| New process pattern | Process steps, roles, tools | `knowledge/processes/general.md` |
+| Key decision made | Decision, rationale, outcome | `knowledge/learnings/general.md` |
+| Pending follow-up | Task description, context | `knowledge/todos/pending.md` |
+| User teaches something | Information, preference | Relevant knowledge file |
+
+---
+
+## How It Works
+
+The skill uses the stable `assistant-memory` API with `--from-skill` for origin tracking:
+
+```bash
+# Search before adding
+assistant-memory search "<query>"
+
+# Add a learning (with origin tracking)
+assistant-memory add --type learning --from-skill knowledge-sync "Pattern: <description>"
+
+# Add a skill (with tags)
+assistant-memory add --type skill --from-skill knowledge-sync --tags jira,workflow "New skill: <name>"
+
+# Add a pending todo
+assistant-memory add --type todo --from-skill knowledge-sync "<description>"
+```
+
+---
+
+## Knowledge Structure
+
+```
+knowledge/
+├── skills/
+│   └── discovered.md      # New skills found during work
+├── processes/
+│   ├── jira.md
+│   ├── confluence.md
+│   └── general.md        # Generic process patterns
+├── learnings/
+│   └── general.md        # Key decisions and insights
+└── todos/
+    └── pending.md        # Follow-up items
+```
+
+---
+
+## Manual Usage
+
+You can also trigger this skill manually:
+
+```
+User: "Save that pattern for later"
+
+Assistant: → Use knowledge-sync to preserve the pattern
+```
+
+---
+
+## Integration with tech-assistant
+
+The tech-assistant skill checks for these automatic sync opportunities:
+
+1. **After task creation/update** → Sync initiative info
+2. **After discovering space/list IDs** → Sync to knowledge base (per `knowledge-sync`).
+3. **After learning user preferences** → Sync to learnings
+4. **When user mentions follow-up** → Add to pending
+
+---
+
+## Best Practices
+
+1. **Be selective** - Only sync valuable, reusable information
+2. **Be specific** - Include context and usage examples
+3. **Be concise** - One idea per entry, link to details
+4. **Be current** - Update outdated information when found
+
+---
+
+## Examples
+
+### Auto-sync discovery
+
+```
+Assistant discovers Initiative list IDs for all Technology spaces
+→ Syncs to knowledge/processes/clickup/spaces/
+```
+
+### Auto-sync key decision
+
+```
+Assistant and user decide on naming convention
+→ Syncs to knowledge/learnings/general.md
+```
+
+### Manual sync request
+
+```
+User: "Remember that we always use feature branches"
+→ Assistant syncs to knowledge/processes/general.md
+```
+
+---
+
+## Configuration
+
+The skill uses these environment variables:
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `KNOWLEDGE_BASE_PATH` | `~/ai-workspace/knowledge` | Knowledge base root |
+
+---
+
+Base directory: `~/.local/share//skills/knowledge-sync`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/data/dbt-validation/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: dbt-validation
+description: >-
+  HOW — Run dbt checks as documented in the target repo (parse, compile, test, selective run).
+  Does not configure Snowflake accounts or change cloud security.
+---
+
+# dbt validation (HOW)
+
+Use when the repository is a **dbt** project or the task requires **dbt** verification. Client workflows may delegate here.
+
+## Boundaries
+
+- Follow **repo** `AGENTS.md`, `Makefile`, `README`, and CI—not generic guesses.
+- **Do not** change Snowflake security settings, network rules, or warehouse admin from this skill.
+- If `dbt` or credentials are missing, **say so** and do not claim validation passed.
+
+## Discovery
+
+Look for `dbt_project.yml`, `packages.yml`, `models/`, `Makefile`, `pyproject.toml`, or CI jobs that invoke dbt.
+
+## Typical commands (examples only—prefer repo docs)
+
+| Intent | Often used (verify in repo) |
+| --- | --- |
+| Syntax / graph | `dbt parse`, `dbt compile` |
+| Dependencies | `dbt deps` when packages change |
+| Tests | `dbt test` or subset flags the repo documents |
+| Build | `dbt run` / `dbt build` when the user approves mutating runs |
+
+**Makefile** wrappers (e.g. `make parse`) take precedence when documented.
+
+## Evidence
+
+- Summarize **which** commands ran and **high-level** outcome (pass/fail/skipped) for tickets and PRs.
+- On failure, capture **actionable** error lines; do not dump full logs unless the user asks.
+
+## Safety
+
+- Prefer **read-only** checks (`parse`, `compile`, `test`) when the task is review-only.
+- Production runs require explicit user approval per repo policy.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/data/snowflake-validation/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: snowflake-validation
+description: >-
+  HOW — Read-only Snowflake validation patterns: use repo-documented CLI (snowflake/sql) or SQL checks.
+  Never claim success without working credentials and evidence.
+---
+
+# Snowflake validation (HOW)
+
+Use when the task or repo requires **Snowflake** verification. Client workflows may delegate here alongside **dbt-validation**.
+
+## Boundaries
+
+- **Read-only** validation unless the user and repo explicitly authorize DDL/DML.
+- **Never** claim “Snowflake validation passed” or “query succeeded” without **credentials** and **observed outputs** (or explicit statement that checks were skipped).
+- **Do not** rotate keys, change roles, or alter security objects from this skill unless the repo’s `AGENTS.md` clearly authorizes it and the user approves.
+
+## Discovery
+
+Read repo docs for: connection method (env vars, `profiles.yml`, SSO), Snowflake **SQL** or **Snowflake CLI** (`snow`) usage, and warehouse/database/schema defaults.
+
+## Patterns
+
+| Situation | Action |
+| --- | --- |
+| Credentials available | Run minimal **SELECT** statements or documented smoke queries; record that they were executed |
+| Snowflake CLI documented | Use repo’s exact commands; check `snow --help` for current subcommands |
+| No credentials | State **skipped** in Jira/PR; list what would be validated when access exists |
+| dbt + Snowflake | Coordinate with **dbt-validation**; Snowflake may be exercised indirectly via dbt |
+
+## Evidence
+
+- For each run: **what** ran (object or test name), **environment** (non-secret), **result** (row count, success/failure).
+- Redact account identifiers if the user requests privacy in chat.
+
+## Safety
+
+- No secrets in tickets, PRs, or command lines in logs pasted to chat—use env vars and documented patterns only.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/adr/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: adr
+description: >-
+  WHAT — Create and maintain Architecture Decision Records (ADRs) per the process. Covers when to write an ADR, required sections, review, and linking to epics/PRs. English for cross-team artifacts unless the user asks otherwise.
+---
+
+# ADR — Architecture Decisions (WHAT)
+
+**Template:** `references/default-template.md` — local reference for ADR structure and workflow.
+
+## Default guardrails (before any final content)
+
+1. Apply **`output-handshake`**: confirm **where** the final ADR will be recorded and that a **human** will review.
+2. Then follow the steps below.
+
+## When to use
+
+Use **`decision-log`** for lightweight product/project/operational decisions and **`agreement`** for explicit commitments or terms among parties. Use this ADR skill only for durable architecture or technical decisions.
+
+- A change has **long-term** architectural, security, data-model, or cost impact.
+- You need **options with pros/cons** and a **record** for future readers (and for supersession later).
+- The project needs decisions linked to PRDs, TRDs, tasks, PRs, diagrams, or other supporting artifacts.
+
+## Instructions
+
+1. **Confirm the decision qualifies** (new service, tech selection, schema change, deployment change, etc.) per the "When to Create an ADR" criteria.
+2. **Draft** using the six-part structure: Title & status, Context, Options, Decision, Consequences, References (link **PRD/TRD**, tasks, PRs, diagrams as applicable).
+3. **Review** with the tech lead / peers as in the workflow; keep ADRs **short and actionable** (clarity over completeness).
+4. **Link** the ADR to the relevant **epic or story** and to **PRs** in the forge (use **`github-cli-workflow` / `gitlab-cli-workflow`** for PR text when applicable).
+5. If an ADR is **superseded**, **preserve history**: update status and point to the replacement document.
+
+## What not to do
+
+- Do not use an ADR for one-line fixes with no long-term effect (use a normal task or PR description).
+- Do not paste the full org policy into this skill; keep a single **canonical** copy in the wiki.
+
+## References
+
+- `output-handshake` — destination and review
+- `references/default-template.md` — ADR structure and workflow
+- `references/example-001-graphql-adoption.md` — example ADR for a GraphQL migration decision
+- `trd` — where technical design references decisions
+- `decision-log` — lightweight decisions
+- `agreement` — explicit commitments or terms
+- `workflow-generic-project` — traceability and plan approval
+- `clickup-cli`, `jira-*` — ticket and comment operations (per engagement)

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/adr/references/example-001-graphql-adoption.md

@@ -0,0 +1,66 @@
+# ADR-001: Adopt GraphQL for the Product API
+
+**Status:** Accepted
+
+## Context
+
+The current REST API has accumulated significant complexity as the product domain grew. Multiple frontend clients (web, mobile) are experiencing over-fetching, under-fetching, and fragile coupling to backend structure. The team spends significant time on API versioning and backward compatibility work.
+
+Key constraints:
+- Existing REST endpoints cannot be deprecated immediately
+- Mobile team needs faster iteration cycles
+- Analytics requirements demand a more expressive data querying interface
+
+## Options Considered
+
+### Option A: GraphQL Federation
+**Pros:**
+- Single coherent graph for all clients
+- Type safety and auto-generated docs
+- Separate subgraph ownership reduces coupling
+
+**Cons:**
+- Higher initial infrastructure complexity
+- Requires Apollo Federation or equivalent gateway
+- Caching strategies differ from REST patterns
+
+### Option B: REST with JSON:API
+**Pros:**
+- Team familiarity with REST patterns
+- Simpler infrastructure (no gateway needed)
+- Easier to cache at CDN level
+
+**Cons:**
+- Still requires versioning as domain grows
+- Multiple endpoints needed for complex queries
+- No built-in type safety or schema
+
+### Option C:渐进式迁移 — Evolve REST to GraphQL incrementally
+**Pros:**
+- Low risk approach
+- Existing clients unaffected during transition
+- Can validate GraphQL value before full commitment
+
+**Cons:**
+- Longer timeline to realize benefits
+- Requires maintaining both API styles temporarily
+- Higher total implementation effort
+
+## Decision
+
+Adopt GraphQL with a phased approach: establish a new `/graphql` endpoint alongside existing REST, migrate the product domain first, then expand to other domains as teams gain familiarity.
+
+Rationale: Provides immediate relief for frontend teams while preserving existing investments. The federation model future-proofs architecture for microservices decomposition.
+
+## Consequences
+
+- New `api-gateway` service will be introduced in Q3
+- Mobile team leads the product domain migration (most urgent need)
+- REST API maintained for backward compatibility until deprecation notice (6-month notice period)
+- Existing client SDKs updated to support both endpoints during transition
+
+## References
+
+- [PRD-042: Unified API Strategy](./prd-042-unified-api-strategy.md)
+- [Spike-012: GraphQL vs REST evaluation](./spike-012-graphql-evaluation.md)
+- Engineering sync 2024-11-15

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/agreement/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: agreement
+description: >-
+  WHAT - Capture explicit agreements, terms, parties involved, dates, validity, and linked work items using the Agreement Document structure.
+---
+
+# Agreement Document (WHAT)
+
+Use for formal agreements or commitments made during meetings or project discussions.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Identify parties involved and affected.
+3. Include validity/review dates when the agreement has a time boundary.
+4. Link related work items and meeting minutes where possible.
+
+## References
+
+- `references/default-template.md`
+- `references/example-api-versioning.md` — example agreement covering semantic versioning and deprecation policy
+- `meeting-minutes`
+- `decision-log`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/agreement/references/example-api-versioning.md

@@ -0,0 +1,29 @@
+# Agreement: API Versioning Policy
+
+## Agreement Summary
+
+All public APIs will follow semantic versioning with a minimum 6-month deprecation notice before breaking changes. Version support windows are tied to major versions.
+
+## Parties Involved
+
+- Platform Team (API owners)
+- All consuming service teams
+- Product Management (for public API consumers)
+
+## Terms and Conditions
+
+1. **Version numbering:** Follows `MAJOR.MINOR.PATCH` semantic versioning
+2. **Breaking changes:** Require a new major version with 6-month overlap period
+3. **Deprecation notice:** Written notice in API response headers and changelog minimum 6 months before EOL
+4. **Sunset timeline:** Major versions receive security patches for 18 months from release, then EOL
+5. **Version discovery:** `/versions` endpoint lists supported versions with EOL dates
+
+## Date and Validity
+
+- Start Date: 2024-01-01
+- Review / Due Date: 2025-07-01 (first review)
+
+## References / Linked Work Items
+
+- [ADR-003: API Versioning Standard](./adr-003-api-versioning.md)
+- [TRD-007: Platform API Migration](./trd-007-platform-api-migration.md)

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/bug/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: bug
+description: >-
+  WHAT - Draft and review bugs using the Bug Template; classifies whether an issue should be escalated to incident based on production/user impact.
+---
+
+# Bug (WHAT)
+
+Use for defects that can be handled through the normal development workflow.
+
+## Bug vs incident rule
+
+Route to **`incident`** instead if the problem impacts production or live users now, degrades service, blocks critical business operations, creates client-reported urgency, or needs immediate response outside planning cycles.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Capture reproduction steps and environment details.
+3. Use **`clickup-cli`** for ClickUp writes only after approval.
+
+## References
+
+- `references/default-template.md` — bug template
+- `references/example-search-filter-bug.md` — example bug with environment details, diagnostics, and severity assessment
+- `incident` — when to escalate to incident

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/bug/references/example-search-filter-bug.md

@@ -0,0 +1,58 @@
+# BUG-042: Search results not displaying after deployment
+
+## Steps to Reproduce
+
+1. Navigate to `/products` with query parameter `?category=electronics&sort=price_asc`
+2. Click on the "Filter" button to open the filter panel
+3. Select "Screen Size: 40-50 inch" and click Apply
+4. Observe the results area
+
+## Expected Result
+
+Product grid updates to show only electronics with screen sizes between 40 and 50 inches, sorted by price ascending. Total count shows "47 products found".
+
+## Actual Result
+
+Results area shows a spinner indefinitely. Network tab shows 200 response but no DOM updates. After 30 seconds the spinner is replaced with an empty state: "No products match your filters."
+
+## Environment Details
+
+| Field | Value |
+| --- | --- |
+| Environment | Production |
+| Browser | Chrome 120.0.6099.130 |
+| Device / OS | macOS 14.2 (M2 Pro) |
+| App Version | 2.14.1 |
+| User Role | Authenticated consumer |
+| Network Conditions | WiFi, 50 Mbps down |
+
+## Diagnostics and Observations
+
+- Screenshots, videos, or logs: [Recording attached to ticket]
+- Console errors or stack traces: `TypeError: Cannot read properties of undefined (reading 'length')` at `FilterPanel.jsx:142`
+- External system behavior: Analytics events fire successfully — the failure is in frontend rendering only
+- Previous working version: 2.13.4 (verified via rollback test)
+
+## Acceptance Criteria
+
+- [ ] Expected behavior is working and manually verified in Production.
+- [ ] Original reproduction steps no longer reproduce the bug.
+- [ ] Fix was tested in the relevant environment (Production-like staging).
+- [ ] Resolution evidence was added (recording, logs confirming the TypeError is gone).
+- [ ] Documentation or user guidance was updated if needed (release notes mention the fix).
+
+## Severity and Priority
+
+- Severity: High
+- Priority: P1
+
+## Additional Information
+
+- Estimated Effort: 2 days
+- Assigned To: Sarah Chen
+- Due Date: 2024-01-20
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.