The difference? Protocol.

The Problem:

You've got Cursor, Claude Code, or Copilot running. They write code, sure. They generate tests, refactor functions, explain regex. But who handles sprint planning? Who triages incoming issues, estimates story points, coordinates releases, enforces branch strategy? Still you. Still manual. Still context-switching hell.

I watched teams burn cycles on this friction. Smart engineers tabbing between IDE and GitHub, copying issue numbers, manually linking PRs, arguing about commit message format in Slack threads. The AI writes the code, but you herd the process.

The gap isn't intelligence—it's protocol. AI assistants need structured playbooks to actually operate like team members. Without it, they're brilliant interns with no onboarding.

The Solution:

I built agile-workflow as a first-class skill for AI coding assistants. Not a CLI tool you run. Not a SaaS dashboard. A skill your AI knows—embedded protocol it can execute.

Install it once:

npx skills add yabasha/agile-workflow

From that point, your AI assistant becomes your entire agile operation.

What You Can Ask:

The interface is natural language. No flags, no config files, no YAML ceremonies:

> fix all open github issues
> plan the next sprint
> estimate story points for ungroomed issues
> set up conventional commits with husky
> create a release for v2.0.0
> review PR #42
> clean up stale branches

Your AI understands intent, maps to the right protocol phase, executes. You focus on direction, not mechanics.

The Issue Resolution Pipeline:

This isn't cowboy coding. It's a five-phase workflow your AI executes end-to-end:

Phase 1: Discovery & Triage

The AI fetches open issues across your repos. Auto-categorizes by labels using keyword-to-label mapping—"bug" in title lands on the bug label, "performance" tags accordingly. Detects stale issues (30+ days no activity) and surfaces them for priority boost or closure.

Issues get sorted into four priority tiers: Critical, High, Medium, Low. Dependencies are mapped visually—if Issue A blocks Issue B, the AI tracks that. Finally, issues are grouped by file area. Two PRs touching src/auth/ get batched to the same developer queue to avoid merge conflict carnage.

Phase 2: Parallel Development

The AI spawns up to 3–5 parallel developer sessions using isolated git worktrees. Each issue gets its own clean workspace—no branch pollution, no "oops, committed to main" disasters.

Developer prompts include specialty matching. Backend-heavy issue? Assign to the backend specialist configuration. DevOps changes? Route to the ops-aware agent. Each gets context: issue description, acceptance criteria, relevant file paths.

The worktree approach is clean. git worktree add ../feature-branch feature-branch creates an isolated directory your AI can work in independently. When done, it's git worktree remove and gone.

Phase 3: PR Review Management

Human or AI-created PRs both get the same treatment. The AI fetches review comments, classifies them via decision tree: suggestion (nice-to-have), required (blocking), nitpick (style), question (clarification needed).

For required changes, it spawns fix agents on existing branches. Every comment gets a reply with commit reference. Threads are resolved via GitHub's GraphQL API—no orphaned conversations.

The review checklist is standardized: security check, test coverage, breaking change assessment, documentation update verification. Your AI runs the same checklist on every PR, every time.

Phase 4: Dependency-Aware Merge

PRs don't merge randomly. The AI respects dependency order—if PR B depends on PR A, B waits. It handles rebase conflicts automatically when possible, escalating to human review only when the conflict crosses semantic boundaries.

After merge, it verifies all linked issues are actually closed. No "merged PR, forgotten issue" drift.

Phase 5: Cleanup

The AI prunes remote refs, deletes local branches, cleans worktrees. Your repo stays lean. No git branch -a scroll-fests. No "which branches are safe to delete?" Slack polls.

Sprint Planning That Actually Works:

Your AI doesn't just estimate—it explains its math.

The algorithm: count files to change + estimate LOC + dependency factor + test requirement + risk/uncertainty → sum → map to nearest Fibonacci (1, 2, 3, 5, 8, 13, 21).

Five files, moderate LOC, one dependency, needs tests, some uncertainty? That's an 8. Three files, low LOC, no deps, straightforward? That's a 3. The reasoning is transparent, not black-box.

Kanban with WIP Limits:

The AI maintains flow state across columns: Backlog → Ready → In Progress (3 per developer max) → In Review (5 total max) → Done. It enforces limits. Try to start a fourth "In Progress" item and your AI will push back—"Finish #147 first or explain why this jumps the queue."

Definition of Done, Per-Type:

Different work needs different validation. Bugs require reproduction verification. Features need documentation updates. Chores just need CI green. The AI tracks the checklist appropriate to the issue type—no one-size-fits-none approach.

Git Hygiene & Recovery:

Mistakes happen. Force-pushed the wrong branch? git reflog recovery is documented. Detached HEAD state? Step-by-step exit path. Lost a branch? Recovery commands ready.

The skill includes a cheat sheet covering 20+ common git disasters: detached HEAD recovery, force push reversal, lost branch resurrection, stash recovery, merge conflict abort strategies, rebasing gone wrong. Your AI carries the institutional knowledge so you don't have to Stack Overflow at midnight.

Release Management:

Semantic versioning, conventional commits, automated changelogs.

The skill covers 11 conventional commit types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. Commitlint enforcement via Husky hooks means no malformed commits slip through.

Releases follow SemVer strictly. Breaking changes → major. Features → minor. Fixes → patch. Changelogs generate from commit history, categorized by type, linked to PRs and issues.

Monorepo Support:

Changesets handle versioning across packages. Selective CI triggers—only packages with changes run tests. The AI understands workspace boundaries, respects dependency graphs between packages, updates internal references automatically.

Security & Maintenance:

The skill includes Dependabot configuration for automated dependency updates. Gitleaks for secret scanning—catch AWS keys, API tokens, private keys before they hit remote. NPM audit integration flags vulnerabilities in package.json.

GitHub Actions templates cover four scenarios: CI with multi-node version matrices, PR checks with issue reference verification (no "fixes #" in your PR body? blocked), automated release note generation, and weekly dependency update runs (Mondays at 9 AM).

Branch Strategy Decision Tree:

Not every project needs GitFlow. The AI evaluates your release pattern and recommends:

• GitFlow: Scheduled releases, versioning discipline, hotfix lanes
• GitHub Flow: Continuous deployment, small batches, fast feedback
• Trunk-Based: Experienced teams, feature flags, daily merges

It enforces the chosen model. Wrong branch name format? Caught pre-commit. Missing release branch for hotfix? Flagged.

Legacy Support:

Still on SVN? The skill includes reference workflows for SVN-to-Git migration. Your AI can guide the transition, preserve history, set up new remotes, validate the full transfer.

Who It's For:

Teams using Claude Code, Cursor, Windsurf, Copilot, Codex, OpenClaw, Aider—any AI assistant with shell access. Requirements are minimal: git 2.20+, gh CLI 2.0+, and a repository.

This works for solo developers who want AI project management. It works for 20-person teams who need coordination without hiring another PM. It works for agencies juggling client repos.

What's Next:

I'm extending this into multi-agent orchestration. Imagine: three AI developers working the same feature, each handling a vertical—frontend, API, infrastructure—with dependency-aware merging and conflict resolution. The skill layer is the foundation; the orchestration layer is where it gets interesting.

Why This Matters:

AI assistants are only as useful as the protocols you give them. Without structure, they're faster juniors. With structure, they're autonomous team members.

This skill turns "write me a function" into "ship me a feature." It closes the gap between code generation and code delivery.

MIT licensed. Use it, break it, improve it.

Most AI copy sounds the same. It rhymes. It tries too hard. It feels like a template someone else chewed up and spat out.

I built Copywrite Skill to fix that. It's a structured prompt framework that turns any AI assistant into a disciplined copywriter that follows proven advertising principles instead of drifting into generic fluff.

GitHub: https://github.com/yabasha/copywrite-skill

Works with Claude Code, Cursor, Windsurf, Cline, and GitHub Copilot.

The Problem

Language models are capable writers, but they lack guardrails. Left alone, they:

• Default to "revolutionize" and "game-changing" clichés.
• Write for everyone and no one.
• Chase awareness-stage hooks when the reader is already solution-aware.
• Confuse platform tone (LinkedIn vs. landing page vs. email) as optional.

The output isn't technically wrong. It's just invisible.

The Solution

Copywrite Skill is a structured enforcement system that wires Eugene Schwartz's prospect awareness levels and Claude Hopkins' scientific advertising into every phase of AI-assisted copy generation.

Instead of asking an LLM to "write better copy," you feed it a constrained protocol. The output improves because the inputs are specific, layered, and compulsory.

How It Works: The 8-Step Workflow

1. Discovery / Intake
   Lock down the offer, audience, and objections before writing a word.

2. Positioning
   Define the competitive frame: what problem do you solve, and for whom?

3. Awareness + Sophistication
   Map the prospect's awareness level and market saturation to avoid preaching to the choir or overwhelming the uninitiated.

4. Hook A (The Mechanism)
   What makes this work? Why should anyone believe the promise?

5. Hook B (The Consequence)
   What happens if they don't act? Pain, loss, or missed opportunity.

6. Hook C (The Transformation)
   What does life look like after they say yes?

7. Body + CTA
   Evidence, proof elements, and a single clear ask.

8. Platform / SEO + Tighten
   Adapt tone for the channel (email, landing page, social), optimize for keywords if needed, then strip every word that doesn't pull weight.

Each step has a prompt. Each prompt enforces a specific constraint. The chain produces copy that sounds assembled by a human who understands the craft.

Why Schwartz and Hopkins Matter

Eugene Schwartz's Breakthrough Advertising defined five stages of prospect awareness. Most AI copy assumes everyone is problem-unaware (the widest audience). That's expensive and ineffective. Schwartz teaches you to match your message to the prospect's existing knowledge, not reinvent it.

Claude Hopkins wrote Scientific Advertising in 1923. His principle still stands: advertising is salesmanship in print. Every claim needs a reason why. Every headline must earn the reader's attention. Every test must be measured.

Copywrite Skill bakes both into the workflow so you don't have to remember them mid-prompt.

What You Get

• A markdown prompt framework you can drop into any AI coding assistant
• 8 sequential prompt templates with explicit constraints
• Platform-specific adaptation guides (LinkedIn, email, landing page)
• Built-in reasoning steps so the AI shows its work before delivering copy
• No proprietary lock-in. Plain text. Your control.

Who It's For

• Founders writing their own landing pages without a budget for an agency.
• Marketers who want consistent output across team members.
• Developers building AI-assisted tools who need copy as a structured output, not black-box magic.
• Anyone tired of AI copy that smells like AI.

How to Use: Example Prompts

Drop any of these into your AI assistant:

Discovery prompt:

You are a copy strategist. The offer is [describe offer]. The audience is [describe audience]. 

List the top 3 objections this audience has to the offer, and the one belief they must hold to convert.

Awareness mapping:

Based on the offer above, state the prospect's current awareness level using Schwartz's framework: 
Unaware, Problem-Aware, Solution-Aware, Product-Aware, or Most Aware. 

Justify your choice in one sentence.

Hook A (Mechanism):

Write a headline that answers: "How does this actually work?" 

Include a specific mechanism or proprietary element. No adjectives without proof.

Hook B (Consequence):

Write a headline that emphasizes the cost of inaction. 

Use concrete loss, not vague fear.

Tighten command:

Review the copy above. Remove any sentence that does not advance the argument or support the CTA. 

Return only the revised copy, no commentary.

Design Decisions

Specificity over cleverness.
Prompts demand concrete details: numbers, timeframes, mechanisms. Clever wordplay without proof is stripped.

Reason-why everywhere.
Every claim must back itself. If the AI can't explain why, the claim gets cut.

Variants as first-class outputs.
At each step, the framework generates multiple angles. You choose. The AI doesn't decide for you.

Interview-first inputs.
The Discovery phase simulates a client interview. Without this, the rest of the workflow drifts.

What's Next

• Case studies measuring conversion lift against baseline AI copy
• Optional JSON output mode for programmatic integration
• Language-specific variants (currently English-optimized)

Try It

Copywrite Skill is free, open-source, and protocol-first.

Star the repo: https://github.com/yabasha/copywrite-skill

If you use it, open an issue. Tell me what worked, what didn't, and what you'd add.

Good copy is built, not generated. This framework is the scaffolding.

Start with step one. Don't skip the discovery.

That's how wasansart.com was born—not just as a website, but as a digital sanctuary for Wasan's creativity.

The Spark of Inspiration

Wasan doesn't just paint; she builds each piece in soft layers, inviting you to linger in the glow of gentle color. Her process is ritualistic: tea, music, and that single, decisive brushstroke that begins every collection. Watching her work reminded me of what photo2painting.com celebrates—watercolor's unique ability to create stunning blends and soft washes that capture pure emotion.

My Wasan, she is my young artist, she loves drawing, painting, and sharing her art with everyone!

But crayon drawings on the fridge only reach so far. Friends asked to see her work. Teachers wanted to share her progress. Grandparents living far away missed her daily artistic discoveries. We needed something permanent, beautiful, and entirely her own.

Building Her Digital Canvas

The Technical Foundation

I built Wasan's gallery on a robust stack that could grow with her:

• Ubuntu VPS: A reliable, cost-effective server I could manage myself
• Laravel + MySQL: The backbone for handling artwork uploads, categorization, and user management
• NextJS: A React framework that delivers lightning-fast page loads and smooth interactions—essential for keeping young visitors engaged

The architecture is simple but scalable. Laravel powers the API, managing the heavy lifting of image processing and database operations. NextJS handles the front-end, creating a snappy, app-like experience perfect for tablet-toting kids and proud parents showing off on their phones.

Design With Heart

The aesthetic was non-negotiable: children and girly theme. This meant:

• Soft, watercolor-inspired UI elements that mirror Wasan's actual work
• Rounded corners and gentle animations—no sharp edges in this digital playground
• Pastel color palette drawn directly from her favorite pieces
• Large, tappable buttons perfect for tiny fingers
• Playful typography that's both readable and whimsical

Every design decision asked: "Would this make Wasan smile?" The result is an interface that feels like stepping into one of her paintings—warm, welcoming, and full of wonder.

Why This Matters: Celebrating Children's Art

Creating this space made me appreciate the broader world of children's art and illustration. Artists like those featured on wabbasi.com dedicate their careers to visual storytelling for young audiences, while ingridsanchez.com shows how watercolor workshops can nurture creativity in artists of all ages.

But here's the secret: children don't need professional training to create meaningful art. Wasan's work—her wonky lines, unexpected color choices, and unfiltered joy—captures something professionals often chase. Her painting of "sliced watermelons" might not be photorealistic, but it bursts with the same vibrant energy celebrated in photo2painting.com's easy watercolor ideas.

Features That Make It Special

For Wasan (The Artist)

• Drag-and-drop uploads from her iPad
• Simple categorization: "Animals," "Flowers," "Abstract," "My Feelings"
• A "studio" dashboard where she can see all her work at a glance
• Lightbox view that makes each piece feel like it's hanging in a real gallery

For Her Audience

• Paginated data that mimics flipping through a sketchbook
• Shareable links for individual pieces (perfect for sending to teachers)
• Print-on-demand integration so grandparents can order mugs and cards
• Mobile-first design because that's how other kids browse

Lessons Learned & Reflections

Building for a seven-year-old user is humbling. She doesn't care about my elegant code structure or fancy animations. She cares that "the pink button makes my painting big." She taught me that simplicity is the ultimate sophistication in children's design.

The project also reinforced what naturalearthpaint.ca emphasizes: art should be about expression, not perfection. Wasan's gallery isn't curated for perfection—it's curated for authenticity. Every piece stays, even the "mistakes," because in her words, "happy accidents are still happy."

What's Next

Wasan already has plans: "Dad, can my friends upload their art too?" So yes, multi-user support is coming. She wants "rainbow stickers" for her favorite pieces—gamification features are in development. And she's requested a "dark mode" because "sometimes I paint at night and the white screen is too bright."

I'm building a roadmap driven entirely by a first-grader's imagination. It's the most exciting product management I've ever done.

A Personal Note

This wasn't just a coding project—it was a love letter to my daughter's creativity. In a world where children's art too often gets relegated to scrap books and shoe boxes, Wasan now has a permanent, professional gallery. When she's older, she'll see her artistic journey from its very first steps. When she applies to art school, she'll have a portfolio spanning decades.

But more importantly, today, she can show her teacher the watermelons she painted yesterday. She can text her aunt the cat portrait that made her proud. She can lay in bed at night, tablet in hand, scrolling through her own growing legacy.

And she can know, with absolute certainty, that what she creates matters enough to have its own home on the internet.

Visit the gallery: wasansart.com

Follow her journey: Updates posted as she adds new collections

Commission a piece: Yes, she takes requests (terms: must include at least one rainbow)

To all the parents of young artists: Their creativity deserves a stage. Whether it's a simple Instagram account or a custom-built gallery like Wasan's, give them a way to share their vision. The confidence it builds is worth every line of code.

Overview

GEX solves a common friction point for JavaScript developers: losing track of dependencies when switching Node.js versions or machines. Instead of manually inventorying global CLIs and local packages before an environment migration, GEX generates structured, version-controlled reports of your entire dependency landscape—instantly.

Built as a focused CLI tool, it audits both npm and bun ecosystems, outputting machine-readable JSON for automation or human-friendly Markdown for documentation and handovers.

Key Features

• Dual Runtime Support: Seamlessly works with both Node.js/npm and Bun ecosystems
• Interactive Launcher: gex command provides a menu-driven interface to choose runtime and operation
• Multi-Format Output: JSON (default) for scripting, Markdown for documentation
• Global & Local Auditing: Report on globally installed packages or per-project dependencies
• Outdated Package Management: Built-in commands to check and update outdated dependencies
• Reproducible Reports: Deterministic output with sorted packages and stable timestamps
• CI/CD Ready: Zero-dependency execution via npx or bunx for pipeline integration
• Version Controlled: Reports are designed to be committed, enabling diffable dependency history

Installation

Global Install (Recommended)

Via npm:

npm i -g @yabasha/gex

Via Bun:

bun add -g @yabasha/gex

Local Build / Development

# Clone the repository
git clone <https://github.com/yabasha/yabasha-gex.git>
cd yabasha-gex

# Using npm
npm i
npm run build
node dist/cli.cjs --help

# Using Bun
bun install
bun run build
bun dist/cli-bun.mjs --help

Usage

Interactive Launcher: gex

Starting with v1.3.6, the primary gex binary is an interactive launcher:

$ gex

GEX interactive launcher
Choose a runtime and command to run:

  1) gex-node local  – Node (npm) local project report
  2) gex-node global – Node (npm) global packages report
  3) gex-node read   – Node (npm) read existing report
  4) gex-bun local   – Bun local project report
  5) gex-bun global  – Bun global packages report
  6) gex-bun read    – Bun read existing report
  q) Quit without running anything

Selected: gex-node local
Enter extra flags/arguments for "gex-node local" (or press Enter for none):

You can pass additional flags (e.g., -full-tree -f md -o report.md) which get forwarded to the underlying command.

Direct Mode: If you run gex with arguments (e.g., gex local --check-outdated), it behaves as gex-node for backward compatibility.

Direct Runtimes: gex-node & gex-bun

For scriptability or CI/CD, call runtimes directly:

# Node.js/npm runtime
gex-node [command] [options]    # Alias: gn

# Bun runtime
gex-bun [command] [options]     # Alias: gb

Available Commands:

• local - Audit local project dependencies (default)
• global - Audit globally installed packages
• read - Read and optionally install from an existing report

Common Flags:

• f, --output-format <md|json> - Output format (default: json)
• o, --out-file <path> - Write output to file instead of stdout
• full-tree - Include full npm ls JSON under tree key
• omit-dev - Exclude devDependencies (local only)
• c, --check-outdated - Show outdated packages as a table
• u, --update-outdated [pkg...] - Update outdated packages

Examples

# Local reports - JSON (default)
gex-node                                    # Print to console
gex-node -o report.json                     # Write to file
gex-bun local -o report.json                # Bun runtime

# Local reports - Markdown
gex-node -f md                              # Print to console
gex-node -f md -o report.md                 # Write to file

# Exclude devDependencies
gex-node local --omit-dev -o deps.json

# Global packages
gex-node global -o global.json
gex-bun global -f md -o global.md

# Read existing reports
gex-node read -r path/to/report.json        # JSON report
gex-node read global.md                     # Markdown report
gex-node read -i                            # Install packages from report

# Pipeline processing
gex-node global | jq '.global_packages'     # Use with jq
gex-bun local > report.json                 # Shell redirection

# Outdated package management
gex-node local --check-outdated             # Show outdated table
gex-node local -u axios react               # Update specific packages
gex-bun global --update-outdated            # Update all global Bun packages

Output Formats

JSON Schema

Reports include metadata and dependency arrays:

{
  "report_version": "1.0",
  "timestamp": "2025-01-01T12:00:00.000Z",
  "tool_version": "0.1.0",
  "project_name": "my-app",
  "project_version": "1.2.3",
  "global_packages": [
    {
      "name": "@yabasha/gex",
      "version": "1.3.6",
      "resolved_path": "/usr/local/lib/node_modules/@yabasha/gex"
    }
  ],
  "local_dependencies": [
    {
      "name": "commander",
      "version": "12.1.0",
      "resolved_path": "/path/to/project/node_modules/commander"
    }
  ],
  "local_dev_dependencies": [
    {
      "name": "vitest",
      "version": "2.1.1",
      "resolved_path": "/path/to/project/node_modules/vitest"
    }
  ],
  "tree": { /* Full npm ls JSON when --full-tree is used */}
}

Markdown Example

# Dependency Report: my-app v1.2.3
Generated: 2025-01-01T12:00:00.000Z

## Global Packages (3)
- `@yabasha/gex@1.3.6`
- `bun@1.1.0`
- `npm@10.0.0`

## Local Dependencies (5)
- `commander@12.1.0`
- `express@4.18.2`

## Dev Dependencies (4)
- `vitest@2.1.1`
- `typescript@5.3.3`

Outdated Package Management

GEX integrates directly with package managers to handle outdated dependencies:

Check Outdated:

gex-node local --check-outdated
# Shows: Name | Current | Wanted | Latest | Type

Update Outdated:

gex-node local --update-outdated          # Update all
gex-node local -u axios react             # Update specific packages
gex-bun global --update-outdated          # Bun reinstalls globals at latest

After updating, rerun with --check-outdated to verify, and generate a new report with -o to capture the updated state.

CI/CD Integration

GEX is designed for zero-config CI/CD pipelines:

# GitHub Actions (Node.js)
- name: Generate dependency report
  run: npx -y @yabasha/gex@latest -f json -o gex-report.json

# GitHub Actions (Bun)
- name: Generate dependency report
  run: bunx @yabasha/gex@latest -f json -o gex-report.json

# Commit report for diffing
- name: Commit dependency report
  run: |
    git add gex-report.json
    git commit -m "chore: update dependency report" || echo "No changes"

Development & Contributing

# Initial setup
npm install
npm run build

# Development loop
npm run dev      # Watch mode + CLI help on success

# Quality checks
npm test         # Vitest
npm run lint
npm run format

# Contributing workflow
# 1. Create branch: feat/my-feature
# 2. Make changes + add tests
# 3. Add changeset: npx changeset
# 4. Open PR: gh pr create --fill

We welcome contributions! The repository is open-source to allow community-driven expansion and adaptation.

License: MIT

Built to solve real developer friction—open-sourced to help the community manage dependencies across Node.js and Bun ecosystems with confidence.