asdm-cli 0.1.0

package/registry/profiles/fullstack-engineer/profile.yaml

@@ -0,0 +1,38 @@
+name: fullstack-engineer
+description: "Full-stack web development profile"
+extends:
+  - base
+
+agents:
+  - code-reviewer
+  - documentation-writer
+  - architect
+  - test-engineer
+
+skills:
+  - plan-protocol
+  - code-review
+  - frontend-design
+  - api-design
+
+commands:
+  - check-file
+  - summarize
+  - generate-types
+  - scaffold-component
+
+providers:
+  - opencode
+  - claude-code
+  - copilot
+
+provider_config:
+  opencode:
+    theme: dark
+  claude-code:
+    permissions:
+      allow:
+        - "Read(**)"
+        - "Write(src/**)"
+        - "Bash(npm test)"
+        - "Bash(npm run build)"

package/registry/profiles/mobile/profile.yaml

@@ -0,0 +1,24 @@
+name: mobile
+description: "Mobile development profile (React Native / Flutter)"
+extends:
+  - base
+
+agents:
+  - code-reviewer
+  - documentation-writer
+  - mobile-engineer
+
+skills:
+  - plan-protocol
+  - code-review
+  - mobile-patterns
+
+commands:
+  - check-file
+  - summarize
+  - scaffold-component
+
+providers:
+  - opencode
+  - claude-code
+  - copilot

package/registry/profiles/security/profile.yaml

@@ -0,0 +1,24 @@
+name: security
+description: "Security-focused development profile"
+extends:
+  - base
+
+agents:
+  - code-reviewer
+  - security-auditor
+  - documentation-writer
+
+skills:
+  - plan-protocol
+  - code-review
+  - threat-modeling
+
+commands:
+  - check-file
+  - summarize
+  - audit-deps
+
+providers:
+  - opencode
+  - claude-code
+  - copilot

package/registry/skills/api-design/SKILL.asdm.md

@@ -0,0 +1,101 @@
+---
+name: api-design
+type: skill
+description: "RESTful and GraphQL API design principles for consistent, developer-friendly interfaces"
+version: 1.0.0
+tags: [api, rest, graphql, design, openapi]
+trigger: "When designing or reviewing API endpoints, schemas, or contracts"
+
+providers:
+  opencode:
+    location: skills/api-design/
+  claude-code:
+    location: skills/api-design/
+  copilot:
+    applyTo: "**/*.{ts,js,yaml,json}"
+---
+
+# API Design Skill
+
+## Core Principles
+
+A good API is a product. Its consumers are developers, and their experience — discoverability, predictability, error clarity, and ease of evolution — is the measure of quality. Design APIs for the caller, not the implementation.
+
+## RESTful API Standards
+
+### Resource Naming
+- Use plural nouns for collections: `/users`, `/orders`, `/products`
+- Nest resources only when the child cannot exist without the parent: `/users/{id}/addresses`
+- Avoid verbs in URLs — use HTTP methods to express actions: `POST /orders` not `POST /createOrder`
+- Use kebab-case for multi-word resources: `/shipping-addresses`
+
+### HTTP Methods
+| Method | Semantics | Idempotent | Safe |
+|--------|-----------|-----------|------|
+| GET | Retrieve resource(s) | Yes | Yes |
+| POST | Create new resource | No | No |
+| PUT | Replace entire resource | Yes | No |
+| PATCH | Partial update | No | No |
+| DELETE | Remove resource | Yes | No |
+
+### Status Codes
+- `200 OK` — successful retrieval or update
+- `201 Created` — resource created; include `Location` header
+- `204 No Content` — successful delete or no body to return
+- `400 Bad Request` — client sent invalid input; include error details
+- `401 Unauthorized` — authentication required
+- `403 Forbidden` — authenticated but not authorized
+- `404 Not Found` — resource does not exist
+- `409 Conflict` — state conflict (duplicate, stale update)
+- `422 Unprocessable Entity` — validation failed; include field-level errors
+- `429 Too Many Requests` — rate limit exceeded; include `Retry-After`
+- `500 Internal Server Error` — server fault; never expose internals
+
+### Error Response Format
+```json
+{
+  "error": {
+    "code": "VALIDATION_FAILED",
+    "message": "Request validation failed",
+    "details": [
+      { "field": "email", "message": "must be a valid email address" }
+    ]
+  }
+}
+```
+
+## Pagination
+
+For collection endpoints returning potentially large result sets:
+```json
+{
+  "data": [...],
+  "pagination": {
+    "cursor": "eyJpZCI6MTAwfQ==",
+    "hasNext": true,
+    "pageSize": 20
+  }
+}
+```
+Prefer cursor-based pagination over offset for large or frequently-updated datasets.
+
+## Versioning
+
+- Version via URL path prefix: `/v1/`, `/v2/`
+- Never break backward compatibility within a version
+- Deprecate with `Deprecation` and `Sunset` response headers before removing
+
+## GraphQL Guidelines
+
+- Queries should be colocated with their consuming component (fragment colocation)
+- Never expose raw database IDs — use opaque global IDs
+- Use DataLoader for all resolver-level data fetching to avoid N+1
+- Mutations return the mutated resource — callers should not need a follow-up query
+- Rate limit by query complexity, not just request count
+
+## Rules
+
+- ALWAYS document every endpoint with request schema, response schema, and error conditions
+- NEVER change the meaning of an existing field — add a new field instead
+- Include an `X-Request-Id` header in every response for distributed tracing
+- Validate all inputs at the API boundary; reject before processing

package/registry/skills/code-review/SKILL.asdm.md

@@ -0,0 +1,83 @@
+---
+name: code-review
+type: skill
+description: "Comprehensive code review methodology with severity classification and structured feedback"
+version: 1.0.0
+tags: [review, quality, methodology, feedback]
+trigger: "When performing a code review, reviewing a PR, or auditing a file for quality issues"
+
+providers:
+  opencode:
+    location: skills/code-review/
+  claude-code:
+    location: skills/code-review/
+  copilot:
+    applyTo: "**/*.{ts,tsx,js,jsx,py,go,java,rs}"
+---
+
+# Code Review Skill
+
+## Purpose
+
+This skill provides a systematic methodology for code review that produces consistent, actionable feedback. Apply it during PR reviews, pair sessions, or self-review before submitting work.
+
+## Severity Levels
+
+Every finding is classified at one of five levels:
+
+| Level | Definition | Response Required |
+|-------|-----------|-------------------|
+| **CRITICAL** | Security vulnerability, data loss risk, or production outage potential | Block merge; fix before approval |
+| **HIGH** | Logic error, missing error handling, or significant performance regression | Block merge; fix or explicitly accept risk |
+| **MEDIUM** | Code quality issue that increases maintenance cost or reduces reliability | Fix preferred; must be tracked if deferred |
+| **LOW** | Style inconsistency, naming issue, or minor inefficiency | Fix encouraged; not a merge blocker |
+| **INFO** | Observation, question, or suggestion without a required action | No action required |
+
+## Review Checklist
+
+Work through each category systematically:
+
+### Correctness
+- Does the code do what the author claims?
+- Are all edge cases handled: null/undefined, empty collections, zero/negative numbers?
+- Are concurrency and ordering assumptions documented and enforced?
+
+### Security
+- Is all user input validated and sanitized before use?
+- Are secrets managed externally — no hardcoded credentials?
+- Are authorization checks applied at every entry point?
+- Are dependencies pinned to known-safe versions?
+
+### Performance
+- Are there N+1 queries or loops that scale quadratically?
+- Is expensive work computed lazily or cached appropriately?
+- Are large payloads paginated or streamed?
+
+### Maintainability
+- Is the code readable without needing to reference the PR description?
+- Are functions named for what they do, not how they do it?
+- Is complexity isolated behind clean interfaces?
+- Is test coverage adequate for the new behavior?
+
+### Consistency
+- Does the change follow existing project conventions?
+- Are new abstractions consistent with existing ones?
+- Is error handling style uniform with the rest of the codebase?
+
+## Feedback Format
+
+Each finding:
+```
+[SEVERITY] file.ts:42
+Issue: <concise description of the problem>
+Suggestion: <specific fix or recommendation>
+```
+
+End each review with a summary verdict:
+- `APPROVE` — Ready to merge
+- `REQUEST_CHANGES` — Requires changes before merge
+- `COMMENT` — Observations only; author decides next steps
+
+## Confidence Threshold
+
+If you are uncertain whether something is a bug or intentional design, mark it `INFO` and ask a question. Do not block a merge on uncertainty.

package/registry/skills/data-pipeline/SKILL.asdm.md

@@ -0,0 +1,95 @@
+---
+name: data-pipeline
+type: skill
+description: "Data ingestion, transformation, and pipeline patterns for reliable data engineering"
+version: 1.0.0
+tags: [data, pipeline, etl, elt, airflow, dbt, streaming]
+trigger: "When designing data pipelines, ETL/ELT jobs, transformations, or data engineering workflows"
+
+providers:
+  opencode:
+    location: skills/data-pipeline/
+  claude-code:
+    location: skills/data-pipeline/
+  copilot:
+    applyTo: "**/*.{py,sql,yaml}"
+---
+
+# Data Pipeline Skill
+
+## Core Pipeline Principles
+
+Data pipelines fail silently more often than they fail loudly. A pipeline that produces wrong results without alerting is more dangerous than one that crashes. Build in correctness guarantees, observability, and recovery mechanisms from the start.
+
+## Pipeline Properties
+
+Every production data pipeline must guarantee:
+
+### Idempotency
+Re-running a pipeline job for the same time window must produce identical output. Achieve this by:
+- Using `INSERT OVERWRITE` or `MERGE` instead of raw `INSERT`
+- Partitioning output tables by the event time of the source data
+- Making the job aware of its own run ID to detect and skip duplicate processing
+
+### Backfill Safety
+Historical reprocessing must not double-count, corrupt, or miss data. Design for:
+- Explicit time range parameters: every job accepts `start_date` and `end_date`
+- Deterministic partitioning: data for a given time range always lands in the same partition
+- Atomicity: write to a staging table, then swap; never append-then-fail
+
+### Observability
+- Log row counts at every transformation stage
+- Emit metrics: records processed, records rejected, processing duration, lag
+- Alert on anomalies: row count drops >20%, null rate increases, schema drift
+
+## Transformation Patterns
+
+### Source Layer (Bronze)
+- Ingest raw data with minimal transformation — preserve source fidelity
+- Add ingestion metadata: `_ingested_at`, `_source_system`, `_batch_id`
+- Schema-on-read for semi-structured sources (JSON, Avro)
+
+### Cleansing Layer (Silver)
+- Apply type casting, null handling, and deduplication
+- Validate referential integrity against dimension tables
+- Flag invalid records — route to a dead-letter table for investigation, do not silently drop
+
+### Aggregation Layer (Gold)
+- Build business-level aggregates designed for query patterns
+- Optimize partition and clustering keys for consumer query shapes
+- Document freshness SLA and update frequency
+
+## SQL Transformation Best Practices
+
+```sql
+-- Always filter before aggregating
+WITH filtered_events AS (
+  SELECT user_id, event_type, occurred_at
+  FROM raw.events
+  WHERE occurred_at >= '{{ start_date }}'
+    AND occurred_at <  '{{ end_date }}'
+    AND event_type IS NOT NULL
+),
+-- Aggregate on already-filtered data
+event_counts AS (
+  SELECT user_id, event_type, COUNT(*) AS event_count
+  FROM filtered_events
+  GROUP BY 1, 2
+)
+SELECT * FROM event_counts
+```
+
+## dbt Guidelines
+
+- One model per transformation step — don't chain multiple heavy transformations in one model
+- Use `ref()` for all model dependencies; never hardcode database/schema names
+- Document every model with a YAML schema file: column descriptions and data tests
+- Run `not_null` and `unique` tests on primary keys for every model
+- Tag models by layer (`bronze`, `silver`, `gold`) and schedule accordingly
+
+## Rules
+
+- NEVER use `SELECT *` in production pipeline queries — explicit columns only
+- ALWAYS test a pipeline on a small time slice before running against full history
+- Log every schema change to source tables and alert downstream pipeline owners
+- Treat schema evolution as a first-class concern: `COALESCE(new_col, default_val)` before backfill

package/registry/skills/frontend-design/SKILL.asdm.md

@@ -0,0 +1,73 @@
+---
+name: frontend-design
+type: skill
+description: "Frontend UI design patterns and best practices for production-grade web interfaces"
+version: 1.0.0
+tags: [frontend, ui, design, react, css, accessibility]
+trigger: "When building UI components, pages, layouts, or styling web interfaces"
+
+providers:
+  opencode:
+    location: skills/frontend-design/
+  claude-code:
+    location: skills/frontend-design/
+  copilot:
+    applyTo: "**/*.{tsx,jsx,css,scss,html}"
+---
+
+# Frontend Design Skill
+
+## Philosophy
+
+Production-grade frontend is not generic. Every UI decision — typography, color, spacing, motion — should be intentional. Avoid defaults that make interfaces look AI-generated. Aim for distinctive, purposeful design that serves the user's task.
+
+## Typography
+
+- Use a specific, non-system font stack for branded interfaces; system fonts only for utility/admin UIs
+- Establish a type scale with meaningful semantic names: `text-body`, `text-heading-lg`, `text-caption`
+- Line length: 60–80 characters for body text; wider for data-dense displays
+- Contrast ratio minimum: 4.5:1 for body text (WCAG AA), 3:1 for large text
+
+## Color System
+
+- Define a palette with intentional roles: `color-primary`, `color-surface`, `color-danger`, `color-success`
+- Avoid using raw hex values in components — reference design tokens only
+- Use color to communicate meaning, not just aesthetics: errors are always destructive red, success is green
+- Support both light and dark mode from the start — retrofitting is expensive
+
+## Component Patterns
+
+### Composition over Configuration
+Prefer small, composable primitives over large components with many props. A `Button` component should not have 20 variants — compose `Icon + Button` and `Badge + Button` instead.
+
+### State Ownership
+- Lift state only as high as necessary
+- Co-locate state with the component that owns it
+- Use server state (React Query / SWR) for remote data; local state for UI-only concerns
+
+### Accessibility
+- Every interactive element must be keyboard-navigable and have a visible focus indicator
+- Use semantic HTML: `<button>` not `<div onClick>`, `<nav>` not `<div className="nav">`
+- Every image needs descriptive `alt` text; decorative images get `alt=""`
+- Form fields need associated labels — `aria-label` is a last resort
+
+## Motion Guidelines
+
+- Animate with purpose: motion should guide attention, not decorate
+- Duration: micro-interactions 100–200ms; page transitions 250–400ms
+- Use `prefers-reduced-motion` media query to disable animations for users who need it
+- Prefer `transform` and `opacity` for performance; avoid animating layout properties
+
+## Performance
+
+- Code-split at the route level; lazy-load heavy components
+- Optimize images: correct format (WebP/AVIF), correct size, lazy loading below the fold
+- Avoid layout shift: reserve space for dynamic content with placeholder dimensions
+- Measure with Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
+
+## Rules
+
+- NEVER use inline styles for layout — CSS modules, utility classes, or styled components only
+- ALWAYS define focus styles explicitly — do not rely on browser defaults
+- Test on mobile viewport sizes before marking any UI work complete
+- Review rendered output in both light and dark mode

package/registry/skills/mobile-patterns/SKILL.asdm.md

@@ -0,0 +1,102 @@
+---
+name: mobile-patterns
+type: skill
+description: "Mobile UI/UX patterns and best practices for React Native and Flutter development"
+version: 1.0.0
+tags: [mobile, react-native, flutter, ux, patterns, performance]
+trigger: "When building mobile UI components, screens, or navigation flows in React Native or Flutter"
+
+providers:
+  opencode:
+    location: skills/mobile-patterns/
+  claude-code:
+    location: skills/mobile-patterns/
+  copilot:
+    applyTo: "**/*.{tsx,jsx,dart}"
+---
+
+# Mobile Patterns Skill
+
+## Mobile-First Mindset
+
+Mobile UI is not a smaller desktop UI. Users interact with fingers, not cursors. Network is unreliable. Battery and CPU are constrained. Memory is limited. Every pattern in this skill accounts for these realities.
+
+## Navigation Patterns
+
+### Stack Navigation
+Use for linear flows with a clear back destination: onboarding, checkout, detail views.
+- Always provide an obvious back affordance
+- Preserve scroll position when navigating back
+- Deep link support: every screen should be reachable by URL/route
+
+### Tab Navigation
+Use for top-level sections of the application. 5 tabs maximum.
+- Active tab must be visually distinct
+- Preserve each tab's navigation stack when switching
+- Badge tabs for unread counts or notifications
+
+### Modal Navigation
+Use for tasks that interrupt the primary flow: confirmation dialogs, pickers, quick actions.
+- Modals must always have a dismiss gesture (swipe down or tap outside)
+- Full-screen modals for multi-step flows; sheets for single-step
+
+## List Performance
+
+### React Native
+```tsx
+// Always use FlatList for dynamic lists
+<FlatList
+  data={items}
+  keyExtractor={(item) => item.id}
+  renderItem={({ item }) => <ItemRow item={item} />}
+  getItemLayout={(_, index) => ({
+    length: ITEM_HEIGHT,
+    offset: ITEM_HEIGHT * index,
+    index,
+  })}
+  removeClippedSubviews={true}
+  maxToRenderPerBatch={10}
+  windowSize={10}
+/>
+```
+
+### Flutter
+```dart
+// Use ListView.builder for dynamic lists
+ListView.builder(
+  itemCount: items.length,
+  itemBuilder: (context, index) {
+    return ItemTile(item: items[index]);
+  },
+)
+```
+
+## Offline-First Pattern
+
+1. **Optimistic updates**: Apply the change locally immediately; sync to server in background
+2. **Conflict resolution**: Last-write-wins for simple fields; merge strategies for collaborative data
+3. **Sync queue**: Persist pending mutations to local storage; retry on reconnect
+4. **Connectivity awareness**: Show a subtle banner when offline; never block the UI
+
+## Touch Interaction Standards
+
+- Minimum touch target: 44×44 points (iOS) / 48×48dp (Android)
+- Provide visual feedback for every tap: pressed state, loading state, success/error state
+- Debounce rapid taps on destructive actions (delete, submit)
+- Long press for secondary actions on list items; expose via context menu
+
+## Platform Conventions
+
+| Pattern | iOS | Android |
+|---------|-----|---------|
+| Back navigation | Swipe right, back button in nav bar | System back button / gesture |
+| Destructive action | Red text, confirmation sheet | Snackbar with undo |
+| Pull to refresh | `UIRefreshControl` pattern | `SwipeRefreshLayout` pattern |
+| Loading state | Activity indicator centered | Circular progress indicator |
+
+## Rules
+
+- NEVER block the main thread — all I/O and heavy computation must be async
+- ALWAYS handle the keyboard: inputs scroll into view, dismiss on tap-outside
+- Test every screen with Dynamic Type (iOS) and Font Scale (Android) at maximum size
+- Respect `prefers-reduced-motion` / `ANIMATOR_DURATION_SCALE = 0` in all animations

package/registry/skills/plan-protocol/SKILL.asdm.md

@@ -0,0 +1,66 @@
+---
+name: plan-protocol
+type: skill
+description: "Structured implementation planning methodology with citations and quality gates"
+version: 1.0.0
+tags: [planning, methodology, implementation, documentation]
+trigger: "When asked to plan, design, or implement a feature, task, or system change"
+
+providers:
+  opencode:
+    location: skills/plan-protocol/
+  claude-code:
+    location: skills/plan-protocol/
+  copilot:
+    applyTo: "**/*"
+---
+
+# Plan Protocol
+
+## Overview
+
+Before implementing any non-trivial change, produce a structured plan that can be reviewed, approved, and referenced throughout execution. A plan is not a to-do list — it is a contract between what you intend to do and why, enabling collaborators to catch mistakes before they become code.
+
+## When to Write a Plan
+
+Apply this skill whenever:
+- The task spans more than one file or component
+- The approach involves a non-obvious technical choice
+- The implementation has dependencies on external systems or contracts
+- Another person needs to understand what you are about to do
+
+For trivial, single-file changes that implement obvious logic, proceed without a formal plan.
+
+## Plan Structure
+
+A well-formed implementation plan contains the following sections:
+
+### 1. Problem Statement
+One paragraph describing the current state, why it is insufficient, and what success looks like. Be specific: "users cannot reset their password" is better than "improve auth."
+
+### 2. Approach
+A narrative description of the chosen solution. Explain the key design decisions and why this approach was selected over alternatives. Reference any research, prior art, or constraints that shaped the decision.
+
+### 3. Implementation Steps
+An ordered list of concrete steps. Each step should be independently verifiable and small enough to complete in a single session. Number the steps; do not use bullets.
+
+### 4. Affected Components
+An explicit list of files, services, schemas, or APIs that will change. This prevents scope creep and helps reviewers understand blast radius.
+
+### 5. Risk and Rollback
+What could go wrong, and how to undo the change if it must be reverted. Every plan should have a rollback path.
+
+### 6. Open Questions
+Unresolved decisions that require input before or during implementation. If a plan has no open questions, it was written too quickly.
+
+## Citations
+
+When a decision is informed by research, link the source inline using `(ref:<delegation-id>)` notation. This creates an audit trail from decision to evidence.
+
+## Quality Gates
+
+Before marking a plan as final:
+- [ ] Every implementation step is atomic and independently reviewable
+- [ ] Affected components list is complete
+- [ ] Rollback procedure is defined
+- [ ] Open questions are either answered or explicitly deferred with a reason