devskill 2.0.6 → 2.0.8

package/skills/automate-this/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: automate-this
+description: 'Analyze a screen recording of a manual process and produce targeted, working automation scripts. Extracts frames and audio narration from video files, reconstructs the step-by-step workflow, and proposes automation at multiple complexity levels using tools already installed on the user machine.'
+---
+
+# Automate This
+
+Analyze a screen recording of a manual process and build working automation for it.
+
+The user records themselves doing something repetitive or tedious, hands you the video file, and you figure out what they're doing, why, and how to script it away.
+
+## Prerequisites Check
+
+Before analyzing any recording, verify the required tools are available. Run these checks silently and only surface problems:
+
+```bash
+command -v ffmpeg >/dev/null 2>&1 && ffmpeg -version 2>/dev/null | head -1 || echo "NO_FFMPEG"
+command -v whisper >/dev/null 2>&1 || command -v whisper-cpp >/dev/null 2>&1 || echo "NO_WHISPER"
+```
+
+- **ffmpeg is required.** If missing, tell the user: `brew install ffmpeg` (macOS) or the equivalent for their OS.
+- **Whisper is optional.** Only needed if the recording has narration. If missing AND the recording has an audio track, suggest: `pip install openai-whisper` or `brew install whisper-cpp`. If the user declines, proceed with visual analysis only.
+
+## Phase 1: Extract Content from the Recording
+
+Given a video file path (typically on `~/Desktop/`), extract both visual frames and audio:
+
+### Frame Extraction
+
+Extract frames at one frame every 2 seconds. This balances coverage with context window limits.
+
+```bash
+WORK_DIR=$(mktemp -d "${TMPDIR:-/tmp}/automate-this-XXXXXX")
+chmod 700 "$WORK_DIR"
+mkdir -p "$WORK_DIR/frames"
+ffmpeg -y -i "<VIDEO_PATH>" -vf "fps=0.5" -q:v 2 -loglevel warning "$WORK_DIR/frames/frame_%04d.jpg"
+ls "$WORK_DIR/frames/" | wc -l
+```
+
+Use `$WORK_DIR` for all subsequent temp file paths in the session. The per-run directory with mode 0700 ensures extracted frames are only readable by the current user.
+
+If the recording is longer than 5 minutes (more than 150 frames), increase the interval to one frame every 4 seconds to stay within context limits. Tell the user you're sampling less frequently for longer recordings.
+
+### Audio Extraction and Transcription
+
+Check if the video has an audio track:
+
+```bash
+ffprobe -i "<VIDEO_PATH>" -show_streams -select_streams a -loglevel error | head -5
+```
+
+If audio exists:
+
+```bash
+ffmpeg -y -i "<VIDEO_PATH>" -ac 1 -ar 16000 -loglevel warning "$WORK_DIR/audio.wav"
+
+# Use whichever whisper binary is available
+if command -v whisper >/dev/null 2>&1; then
+  whisper "$WORK_DIR/audio.wav" --model small --language en --output_format txt --output_dir "$WORK_DIR/"
+  cat "$WORK_DIR/audio.txt"
+elif command -v whisper-cpp >/dev/null 2>&1; then
+  whisper-cpp -m "$(brew --prefix 2>/dev/null)/share/whisper-cpp/models/ggml-small.bin" -l en -f "$WORK_DIR/audio.wav" -otxt -of "$WORK_DIR/audio"
+  cat "$WORK_DIR/audio.txt"
+else
+  echo "NO_WHISPER"
+fi
+```
+
+If neither whisper binary is available and the recording has audio, inform the user they're missing narration context and ask if they want to install Whisper (`pip install openai-whisper` or `brew install whisper-cpp`) or proceed with visual-only analysis.
+
+## Phase 2: Reconstruct the Process
+
+Analyze the extracted frames (and transcript, if available) to build a structured understanding of what the user did. Work through the frames sequentially and identify:
+
+1. **Applications used** — Which apps appear in the recording? (browser, terminal, Finder, mail client, spreadsheet, IDE, etc.)
+2. **Sequence of actions** — What did the user do, in order? Click-by-click, step-by-step.
+3. **Data flow** — What information moved between steps? (copied text, downloaded files, form inputs, etc.)
+4. **Decision points** — Were there moments where the user paused, checked something, or made a choice?
+5. **Repetition patterns** — Did the user do the same thing multiple times with different inputs?
+6. **Pain points** — Where did the process look slow, error-prone, or tedious? The narration often reveals this directly ("I hate this part," "this always takes forever," "I have to do this for every single one").
+
+Present this reconstruction to the user as a numbered step list and ask them to confirm it's accurate before proposing automation. This is critical — a wrong understanding leads to useless automation.
+
+Format:
+
+```
+Here's what I see you doing in this recording:
+
+1. Open Chrome and navigate to [specific URL]
+2. Log in with credentials
+3. Click through to the reporting dashboard
+4. Download a CSV export
+5. Open the CSV in Excel
+6. Filter rows where column B is "pending"
+7. Copy those rows into a new spreadsheet
+8. Email the new spreadsheet to [recipient]
+
+You repeated steps 3-8 three times for different report types.
+
+[If narration was present]: You mentioned that the export step is the slowest
+part and that you do this every Monday morning.
+
+Does this match what you were doing? Anything I got wrong or missed?
+```
+
+Do NOT proceed to Phase 3 until the user confirms the reconstruction is accurate.
+
+## Phase 3: Environment Fingerprint
+
+Before proposing automation, understand what the user actually has to work with. Run these checks:
+
+```bash
+echo "=== OS ===" && uname -a
+echo "=== Shell ===" && echo $SHELL
+echo "=== Python ===" && { command -v python3 && python3 --version 2>&1; } || echo "not installed"
+echo "=== Node ===" && { command -v node && node --version 2>&1; } || echo "not installed"
+echo "=== Homebrew ===" && { command -v brew && echo "installed"; } || echo "not installed"
+echo "=== Common Tools ===" && for cmd in curl jq playwright selenium osascript automator crontab; do command -v $cmd >/dev/null 2>&1 && echo "$cmd: yes" || echo "$cmd: no"; done
+```
+
+Use this to constrain proposals to tools the user already has. Never propose automation that requires installing five new things unless the simpler path genuinely doesn't work.
+
+## Phase 4: Propose Automation
+
+Based on the reconstructed process and the user's environment, propose automation at up to three tiers. Not every process needs three tiers — use judgment.
+
+### Tier Structure
+
+**Tier 1 — Quick Win (under 5 minutes to set up)**
+The smallest useful automation. A shell alias, a one-liner, a keyboard shortcut, an AppleScript snippet. Automates the single most painful step, not the whole process.
+
+**Tier 2 — Script (under 30 minutes to set up)**
+A standalone script (bash, Python, or Node — whichever the user has) that automates the full process end-to-end. Handles common errors. Can be run manually when needed.
+
+**Tier 3 — Full Automation (under 2 hours to set up)**
+The script from Tier 2, plus: scheduled execution (cron, launchd, or GitHub Actions), logging, error notifications, and any necessary integration scaffolding (API keys, auth tokens, etc.).
+
+### Proposal Format
+
+For each tier, provide:
+
+```
+## Tier [N]: [Name]
+
+**What it automates:** [Which steps from the reconstruction]
+**What stays manual:** [Which steps still need a human]
+**Time savings:** [Estimated time saved per run, based on the recording length and repetition count]
+**Prerequisites:** [Anything needed that isn't already installed — ideally nothing]
+
+**How it works:**
+[2-3 sentence plain-English explanation]
+
+**The code:**
+[Complete, working, commented code — not pseudocode]
+
+**How to test it:**
+[Exact steps to verify it works, starting with a dry run if possible]
+
+**How to undo:**
+[How to reverse any changes if something goes wrong]
+```
+
+### Application-Specific Automation Strategies
+
+Use these strategies based on which applications appear in the recording:
+
+**Browser-based workflows:**
+- First choice: Check if the website has a public API. API calls are 10x more reliable than browser automation. Search for API documentation.
+- Second choice: `curl` or `wget` for simple HTTP requests with known endpoints.
+- Third choice: Playwright or Selenium for workflows that require clicking through UI. Prefer Playwright — it's faster and less flaky.
+- Look for patterns: if the user is downloading the same report from a dashboard repeatedly, it's almost certainly available via API or direct URL with query parameters.
+
+**Spreadsheet and data workflows:**
+- Python with pandas for data filtering, transformation, and aggregation.
+- If the user is doing simple column operations in Excel, a 5-line Python script replaces the entire manual process.
+- `csvkit` for quick command-line CSV manipulation without writing code.
+- If the output needs to stay in Excel format, use openpyxl.
+
+**Email workflows:**
+- macOS: `osascript` can control Mail.app to send emails with attachments.
+- Cross-platform: Python `smtplib` for sending, `imaplib` for reading.
+- If the email follows a template, generate the body from a template file with variable substitution.
+
+**File management workflows:**
+- Shell scripts for move/copy/rename patterns.
+- `find` + `xargs` for batch operations.
+- `fswatch` or `watchman` for triggered-on-change automation.
+- If the user is organizing files into folders by date or type, that's a 3-line shell script.
+
+**Terminal/CLI workflows:**
+- Shell aliases for frequently typed commands.
+- Shell functions for multi-step sequences.
+- Makefiles for project-specific task sets.
+- If the user ran the same command with different arguments, that's a loop.
+
+**macOS-specific workflows:**
+- AppleScript/JXA for controlling native apps (Mail, Calendar, Finder, Preview, etc.).
+- Shortcuts.app for simple multi-app workflows that don't need code.
+- `automator` for file-based workflows.
+- `launchd` plist files for scheduled tasks (prefer over cron on macOS).
+
+**Cross-application workflows (data moves between apps):**
+- Identify the data transfer points. Each transfer is an automation opportunity.
+- Clipboard-based transfers in the recording suggest the apps don't talk to each other — look for APIs, file-based handoffs, or direct integrations instead.
+- If the user copies from App A and pastes into App B, the automation should read from A's data source and write to B's input format directly.
+
+### Making Proposals Targeted
+
+Apply these principles to every proposal:
+
+1. **Automate the bottleneck first.** The narration and timing in the recording reveal which step is actually painful. A 30-second automation of the worst step beats a 2-hour automation of the whole process.
+
+2. **Match the user's skill level.** If the recording shows someone comfortable in a terminal, propose shell scripts. If it shows someone navigating GUIs, propose something with a simple trigger (double-click a script, run a Shortcut, or type one command).
+
+3. **Estimate real time savings.** Count the recording duration and multiply by how often they do it. "This recording is 4 minutes. You said you do this daily. That's 17 hours per year. Tier 1 cuts it to 30 seconds each time — you get 16 hours back."
+
+4. **Handle the 80% case.** The first version of the automation should cover the common path perfectly. Edge cases can be handled in Tier 3 or flagged for manual intervention.
+
+5. **Preserve human checkpoints.** If the recording shows the user reviewing or approving something mid-process, keep that as a manual step. Don't automate judgment calls.
+
+6. **Propose dry runs.** Every script should have a mode where it shows what it *would* do without doing it. `--dry-run` flags, preview output, or confirmation prompts before destructive actions.
+
+7. **Account for auth and secrets.** If the process involves logging in or using credentials, never hardcode them. Use environment variables, keychain access (macOS `security` command), or prompt for them at runtime.
+
+8. **Consider failure modes.** What happens if the website is down? If the file doesn't exist? If the format changes? Good proposals mention this and handle it.
+
+## Phase 5: Build and Test
+
+When the user picks a tier:
+
+1. Write the complete automation code to a file (suggest a sensible location — the user's project directory if one exists, or `~/Desktop/` otherwise).
+2. Walk through a dry run or test with the user watching.
+3. If the test works, show how to run it for real.
+4. If it fails, diagnose and fix — don't give up after one attempt.
+
+## Cleanup
+
+After analysis is complete (regardless of outcome), clean up extracted frames and audio:
+
+```bash
+rm -rf "$WORK_DIR"
+```
+
+Tell the user you're cleaning up temporary files so they know nothing is left behind.

package/skills/automate-this/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/automate-this`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/autoresearch/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/autoresearch/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: autoresearch
+description: 'Autonomous iterative experimentation loop for any programming task. Guides the user through defining goals, measurable metrics, and scope constraints, then runs an autonomous loop of code changes, testing, measuring, and keeping/discarding results. Inspired by Karpathy''s autoresearch. USE FOR: autonomous improvement, iterative optimization, experiment loop, auto research, performance tuning, automated experimentation, hill climbing, try things automatically, optimize code, run experiments, autonomous coding loop. DO NOT USE FOR: one-shot tasks, simple bug fixes, code review, or tasks without a measurable metric.'
+license: MIT
+compatibility: Requires git. The project must be a git repository. Requires terminal access to run commands.
+metadata:
+  author: luiscantero
+  inspired-by: https://github.com/karpathy/autoresearch
+---
+
+# Autoresearch: Autonomous Iterative Experimentation
+
+An autonomous experimentation loop for any programming task. You define the goal and how to measure it; the agent iterates autonomously -- modifying code, running experiments, measuring results, and keeping or discarding changes -- until interrupted.
+
+This skill is inspired by [Karpathy's autoresearch](https://github.com/karpathy/autoresearch), generalized from ML training to **any programming task with a measurable outcome**.
+
+---
+
+## Agent Behavior Rules
+
+1. **DO** guide the user through the Setup phase interactively before starting the loop.
+2. **DO** establish a baseline measurement before making any changes.
+3. **DO** commit every experiment attempt before running it (so it can be reverted cleanly).
+4. **DO** keep a results log (TSV) tracking every experiment.
+5. **DO** revert changes that do not improve the metric (git reset to last known good).
+6. **DO** run autonomously once the loop starts -- never pause to ask "should I continue?".
+7. **DO NOT** modify files the user marked as out-of-scope.
+8. **DO NOT** skip the measurement step -- every experiment must be measured.
+9. **DO NOT** keep changes that regress the metric unless the user explicitly allowed trade-offs.
+10. **DO NOT** install new dependencies or make environment changes unless the user approved it.
+
+---
+
+## Phase 1: Setup (Interactive)
+
+Before any experimentation begins, work with the user to establish these parameters.
+Ask the user directly for each item. Do not assume or skip any.
+
+### 1.1 Define the Goal
+
+Ask the user:
+
+> **What are you trying to improve or optimize?**
+>
+> Examples: execution time, memory usage, binary size, test pass rate, code coverage,
+> API response latency, throughput, error rate, benchmark score, build time, bundle size,
+> lines of code, cyclomatic complexity, etc.
+
+Record the user's answer as the **goal**.
+
+### 1.2 Define the Metric
+
+Ask the user:
+
+> **How do we measure success? What exact command produces the metric?**
+>
+> I need:
+> 1. **The command** to run (e.g., `dotnet test`, `npm run benchmark`, `time ./build.sh`, `pytest --tb=short`)
+> 2. **How to extract the metric** from the output (e.g., a regex pattern, a specific line, a JSON field)
+> 3. **Direction**: Is lower better or higher better?
+>
+> Example: "Run `dotnet test --logger trx`, count passing tests. Higher is better."
+> Example: "Run `hyperfine './my-program'`, extract mean time. Lower is better."
+
+Record:
+- `METRIC_COMMAND`: the command to run
+- `METRIC_EXTRACTION`: how to extract the numeric metric from output
+- `METRIC_DIRECTION`: `lower_is_better` or `higher_is_better`
+
+### 1.3 Define the Scope
+
+Ask the user:
+
+> **Which files or directories am I allowed to modify?**
+>
+> And which files are OFF LIMITS (read-only)?
+
+Record:
+- `IN_SCOPE_FILES`: files/dirs the agent may edit
+- `OUT_OF_SCOPE_FILES`: files/dirs that must not be modified
+
+### 1.4 Define Constraints
+
+Ask the user:
+
+> **Are there any constraints I should respect?**
+>
+> Examples:
+> - Time budget per experiment (e.g., "each run should take < 2 minutes")
+> - No new dependencies
+> - Must keep all existing tests passing
+> - Must not change the public API
+> - Must maintain backward compatibility
+> - VRAM/memory limit
+> - Code complexity limits (prefer simpler solutions)
+
+Record as `CONSTRAINTS`.
+
+### 1.5 Define the Experiment Budget (Optional)
+
+Ask the user:
+
+> **How many experiments should I run, or should I just keep going until you stop me?**
+>
+> You can say a number (e.g., "try 20 experiments") or "unlimited" (I'll run until you interrupt).
+
+Record as `MAX_EXPERIMENTS` (number or `unlimited`).
+
+### 1.6 Simplicity Criterion
+
+Inform the user of the default simplicity policy:
+
+> **Simplicity policy (default):** All else being equal, simpler is better. A small improvement
+> that adds ugly complexity is not worth it. Removing code while maintaining or improving
+> the metric is a great outcome. I'll weigh the complexity cost against the improvement
+> magnitude. Does this policy work for you, or do you want to adjust it?
+
+Record any adjustments as `SIMPLICITY_POLICY`.
+
+### 1.7 Confirm Setup
+
+Summarize all parameters back to the user in a clear table:
+
+| Parameter          | Value                        |
+| ------------------ | ---------------------------- |
+| Goal               | ...                          |
+| Metric command     | ...                          |
+| Metric extraction  | ...                          |
+| Direction          | lower is better / higher ... |
+| In-scope files     | ...                          |
+| Out-of-scope files | ...                          |
+| Constraints        | ...                          |
+| Max experiments    | ...                          |
+| Simplicity policy  | ...                          |
+
+Ask the user to confirm. Do not proceed until confirmed.
+
+---
+
+## Phase 2: Branch & Baseline
+
+Once the user confirms:
+
+1. **Create a branch**: Propose a tag based on today's date (e.g., `autoresearch/mar17`).
+   Create the branch: `git checkout -b autoresearch/<tag>`.
+
+2. **Read in-scope files**: Read all files that are in scope to build full context of the current state.
+
+3. **Initialize results.tsv**: Create `results.tsv` in the repo root with the header row:
+   ```
+   experiment	commit	metric	status	description
+   ```
+   Add `results.tsv` and `run.log` to `.git/info/exclude` (append if not already present) so they stay untracked without modifying any tracked files.
+
+4. **Run the baseline**: Execute the metric command on the current unmodified code.
+   Record the result as experiment `0` with status `baseline` in `results.tsv`.
+
+5. **Report baseline** to the user:
+   > Baseline established: **[metric_name] = [value]**
+   > Starting autonomous experimentation loop.
+
+---
+
+## Phase 3: Experiment Loop
+
+Run this loop continuously. Do not stop to ask the user. Run until:
+- `MAX_EXPERIMENTS` is reached, OR
+- The user manually interrupts
+
+### For each experiment:
+
+```
+LOOP:
+  1. THINK   - Analyze previous results and the current code.
+               Generate an experiment hypothesis.
+               Consider: what worked, what didn't, what hasn't been tried.
+
+  2. EDIT    - Modify the in-scope file(s) to implement the idea.
+               Keep changes focused and minimal per experiment.
+
+  3. COMMIT  - git add + git commit with a short descriptive message.
+               Format: "experiment: <short description of what changed>"
+
+  4. RUN     - Execute the metric command.
+               Redirect output to run.log so it does not flood the context window.
+               Use shell-appropriate redirection:
+               - Bash/Zsh: `<command> > run.log 2>&1`
+               - PowerShell: `<command> *> run.log`
+
+  5. MEASURE - Extract the metric from run.log.
+               If extraction fails (crash/error), read the last 50 lines
+               of run.log for the error.
+
+  6. DECIDE  - Compare metric to the current best:
+               - IMPROVED: Keep the commit. Update the "best" baseline.
+                 Log status = "keep".
+               - SAME OR WORSE: Revert. `git reset --hard HEAD~1`.
+                 Log status = "discard".
+               - CRASH: Attempt a quick fix (typo, import, simple error).
+                 Amend the experiment commit (`git commit --amend`) with the fix
+                 and rerun. The experiment keeps its original number.
+                 If unfixable after 2 attempts, revert the entire experiment
+                 (`git reset --hard HEAD~1`) and log status = "crash".
+
+  7. LOG     - Append a row to results.tsv:
+               experiment_number  commit_hash  metric_value  status  description
+
+  8. CONTINUE - Go to step 1.
+```
+
+### Experiment Strategy
+
+When generating experiment ideas, follow this priority order:
+
+1. **Low-hanging fruit first**: Simple parameter tweaks, obvious inefficiencies.
+2. **Informed by results**: If a direction showed promise, explore further in that direction.
+3. **Diversify after plateaus**: If the last 3-5 experiments all failed, try a different approach entirely.
+4. **Combine winners**: If experiments A and B each improved independently, try combining them.
+5. **Simplification passes**: Periodically try removing code/complexity to see if the metric holds.
+6. **Radical changes**: After exhausting incremental ideas, try larger architectural changes.
+
+### Handling Constraints
+
+- **Time budget**: If a run exceeds 2x the expected duration, kill it and treat as a crash.
+- **Existing tests**: If constraints require tests to pass, run them before/after and revert if they break.
+- **Memory/resources**: Monitor and revert if resource usage exceeds stated limits.
+
+---
+
+## Phase 4: Reporting
+
+When the loop ends (budget reached or user interrupts):
+
+1. **Print the full results.tsv** as a formatted table.
+2. **Summarize**:
+   - Total experiments run
+   - Experiments kept / discarded / crashed
+   - Starting metric (baseline) vs. final metric
+   - Improvement percentage
+   - Top 3 most impactful changes
+3. **Show the cumulative git log** of kept experiments:
+   `git log --oneline <start_commit>..HEAD`
+4. **Recommend next steps**: Based on the results, suggest what a human researcher might try next (ideas that were too risky/complex for automated experimentation).
+
+---
+
+## Quick Reference
+
+### Results TSV Format
+
+Tab-separated, 5 columns:
+
+```
+experiment	commit	metric	status	description
+0	a1b2c3d	0.997900	baseline	unmodified code
+1	b2c3d4e	0.993200	keep	increase learning rate to 0.04
+2	c3d4e5f	1.005000	discard	switch to GeLU activation
+3	d4e5f6g	0.000000	crash	double model width (OOM)
+```
+
+### Git Workflow
+
+- All experiments happen on the `autoresearch/<tag>` branch
+- Each experiment is committed before running
+- Failed experiments are reverted with `git reset --hard HEAD~1`
+- Successful experiments advance the branch
+- `results.tsv` and `run.log` stay untracked (added to `.git/info/exclude`)
+
+### Key Principles
+
+1. **Measure everything**: No experiment without a measurement.
+2. **Revert failures**: The branch only advances on improvements.
+3. **Stay autonomous**: Never stop to ask. Think harder if stuck.
+4. **Keep it simple**: Complexity is a cost. Weigh it against gains.
+5. **Log everything**: The TSV is the research journal.

package/skills/autoresearch/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/autoresearch`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/aws-cdk-python-setup/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/aws-cdk-python-setup/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: aws-cdk-python-setup
+description: Setup and initialization guide for developing AWS CDK (Cloud Development Kit) applications in Python. This skill enables users to configure environment prerequisites, create new CDK projects, manage dependencies, and deploy to AWS.
+---
+# AWS CDK Python Setup Instructions
+
+This skill provides setup guidance for working with **AWS CDK (Cloud Development Kit)** projects using **Python**.
+
+---
+
+## Prerequisites
+
+Before starting, ensure the following tools are installed:
+
+- **Node.js** ≥ 14.15.0 — Required for the AWS CDK CLI
+- **Python** ≥ 3.7 — Used for writing CDK code
+- **AWS CLI** — Manages credentials and resources
+- **Git** — Version control and project management
+
+---
+
+## Installation Steps
+
+### 1. Install AWS CDK CLI
+```bash
+npm install -g aws-cdk
+cdk --version
+```
+
+### 2. Configure AWS Credentials
+```bash
+# Install AWS CLI (if not installed)
+brew install awscli
+
+# Configure credentials
+aws configure
+```
+Enter your AWS Access Key, Secret Access Key, default region, and output format when prompted.
+
+### 3. Create a New CDK Project
+```bash
+mkdir my-cdk-project
+cd my-cdk-project
+cdk init app --language python
+```
+
+Your project will include:
+- `app.py` — Main application entry point
+- `my_cdk_project/` — CDK stack definitions
+- `requirements.txt` — Python dependencies
+- `cdk.json` — Configuration file
+
+### 4. Set Up Python Virtual Environment
+```bash
+# macOS/Linux
+source .venv/bin/activate
+
+# Windows
+.venv\Scripts\activate
+```
+
+### 5. Install Python Dependencies
+```bash
+pip install -r requirements.txt
+```
+Primary dependencies:
+- `aws-cdk-lib` — Core CDK constructs
+- `constructs` — Base construct library
+
+---
+
+## Development Workflow
+
+### Synthesize CloudFormation Templates
+```bash
+cdk synth
+```
+Generates `cdk.out/` containing CloudFormation templates.
+
+### Deploy Stacks to AWS
+```bash
+cdk deploy
+```
+Reviews and confirms deployment to the configured AWS account.
+
+### Bootstrap (First Deployment Only)
+```bash
+cdk bootstrap
+```
+Prepares environment resources like S3 buckets for asset storage.
+
+---
+
+## Best Practices
+
+- Always activate the virtual environment before working.
+- Run `cdk diff` before deployment to preview changes.
+- Use development accounts for testing.
+- Follow Pythonic naming and directory conventions.
+- Keep `requirements.txt` pinned for consistent builds.
+
+---
+
+## Troubleshooting Tips
+
+If issues occur, check:
+
+- AWS credentials are correctly configured.
+- Default region is set properly.
+- Node.js and Python versions meet minimum requirements.
+- Run `cdk doctor` to diagnose environment issues.