Skills on human - The AI dev rig for AI coding agents

/human-brainstorm

Mon, 01 Jan 0001 00:00:00 +0000

Explores the codebase, asks clarifying questions, and generates 2-3 implementation approaches with trade-offs before you commit to a plan.

Usage

/human-brainstorm <ticket-key or topic>

Accepts either a ticket key (e.g. KAN-1, ENG-123) or a freeform topic (e.g. "add caching layer for API responses").

How it works

Phase 1 — Context gathering: Fetches the ticket (if a key was given), explores the codebase for relevant code, patterns, and existing .human/ artifacts
Presents a context summary and asks 3-5 clarifying questions one at a time
Phase 2 — Generate approaches: Incorporates your answers and generates 2-3 distinct implementation approaches
Presents the approaches with trade-offs, pros/cons, complexity estimates, and a recommendation
Asks you which approach to proceed with
Writes the complete brainstorm to .human/brainstorms/<identifier>.md

Output format

## Problem Statement
<what needs to be solved>

## Context
<summary of relevant codebase areas, patterns, and constraints>

## Clarifications
| Question | Answer |
|----------|--------|
| <q1>     | <a1>   |

## Approaches

### Approach 1: <name>
<description>

**Affected files:** <list>

| Pros | Cons |
|------|------|
| <pro> | <con> |

**Complexity:** small / medium / large
**Risks:** <risks and mitigations>

### Approach 2: <name>
...

## Recommendation
<which approach and why>

## Chosen approach
<the approach you selected>

Output location

.human/brainstorms/<identifier>.md

/human-ready

Mon, 01 Jan 0001 00:00:00 +0000

Fetches a ticket from your issue tracker and evaluates it against a Definition of Ready checklist. Identifies gaps before development starts.

Usage

/human-ready <ticket-key>

How it works

Fetches the ticket via human <tracker> issue get <key>
Evaluates the ticket against 6 Definition of Ready criteria
Presents the assessment and asks you to fill in any gaps
Writes the completed assessment to .human/ready/<key>.md

Criteria

Each criterion is marked as present, partially present, or missing:

/human-plan

Mon, 01 Jan 0001 00:00:00 +0000

Fetches a ticket, explores the codebase, and produces a structured implementation plan.

Usage

/human-plan <ticket-key>

How it works

Fetches the ticket via human <tracker> issue get <key>
Explores the codebase with Grep, Glob, and Read to understand affected areas
Identifies existing patterns, conventions, and related code
Produces a structured plan with context, changes, and verification steps
Verifies that every file, function, and type referenced in the plan actually exists
Writes the plan to .human/plans/<key>.md
Creates a tracker ticket with the plan as its description

Output format

# Plan: <TICKET_KEY>

## Context
<ticket summary and acceptance criteria>

## Changes
1. `path/to/file.go` — <rationale for change>
2. `path/to/other.go` — <rationale>
...

## Verification
- <test commands to run>
- <manual checks>
- <edge cases to verify>

Output location

.human/plans/<key>.md

/human-execute

Mon, 01 Jan 0001 00:00:00 +0000

Loads an implementation plan and executes it step by step, then runs a review checkpoint.

Usage

/human-execute <ticket-key>

How it works

Loads the plan from .human/plans/<key>.md (falls back to .human/bugs/<key>.md for bug fix plans)
Fetches the ticket via human <tracker> issue get <key> for original context
Parses the plan’s changes section into ordered tasks
Executes each task sequentially:
- Reads the target file before modifying it
- Makes the change described in the plan
- Verifies the change compiles/parses correctly
Runs a review checkpoint by invoking the /human-review agent
Runs a done checkpoint internally to verify completion
Reports: files created, files modified, review outcome, done verdict

Prerequisites

A plan must exist at .human/plans/<key>.md or .human/bugs/<key>.md. If neither exists, run /human-plan or /human-bug-plan first.

/human-review

Mon, 01 Jan 0001 00:00:00 +0000

Reviews the current branch’s changes against the ticket’s acceptance criteria.

Usage

/human-review <ticket-key>

How it works

Fetches the ticket via human <tracker> issue get <key>
Loads the plan from .human/plans/<key>.md if it exists (for additional context)
Diffs the current branch against the default branch (git diff <default>...HEAD)
Evaluates the diff against each acceptance criterion from the ticket
Flags missing criteria, scope creep, and unhandled edge cases
Writes the review to .human/reviews/<key>.md

Output format

# Review: <TICKET_KEY>

## Summary
<one-line verdict: pass, pass with notes, or fail>

## Acceptance Criteria

| # | Criterion | Status | Evidence |
|---|-----------|--------|----------|
| 1 | <criterion from ticket> | PASS/FAIL | <file:line references> |

## Findings

### Missing criteria
- <acceptance criteria not addressed in the diff>

### Scope creep
- <changes in the diff not related to the ticket>

### Edge cases
- <unhandled edge cases>

## Test Results
<output of test run>

Output location

.human/reviews/<key>.md

/human-autofix

Mon, 01 Jan 0001 00:00:00 +0000

Runs the full bug-fix pipeline autonomously, end to end, pointed at a bug ticket — triage, plan, test-first fix, verify, and open a pull request. No user interaction.

Usage

/human-autofix <BUG_KEY>

How it works

Triage & reproduce — fetches the bug ticket, reproduces it, and reaches a verdict: confirmed, not-a-bug, or undetermined.
Verdict gate — only confirmed bugs proceed. not-a-bug and undetermined are closed or left as-is and produce no code changes.
Plan — writes a regression-test-first implementation plan and creates a linked engineering ticket.
Test-first fix — opens a feature branch autofix/<eng-key>, adds a failing regression test, then makes the root-cause fix until the suite is green, and pushes.
Verify — confirms the regression test fails before the fix and passes after, with the full suite green — a “done done” gate.
Open PR & hand off — runs human pr create (forge and repo derived from the git origin remote) and posts a [human:ready-for-review] handoff comment on the tracker carrying the PR URL.

Only bugs that are both confirmed and verified ever open a pull request.

/human-bug-plan

Mon, 01 Jan 0001 00:00:00 +0000

Analyzes a bug ticket for root cause, traces affected code, and produces a structured fix plan.

Usage

/human-bug-plan <ticket-key>

How it works

Fetches the bug ticket via human <tracker> issue get <key>
Fetches ticket comments via human <tracker> issue comment list <key> (comments often contain stack traces and error logs)
Identifies symptoms — error messages, stack traces, failing inputs, reproduction steps
Locates code via Grep and Glob — functions in stack traces, error message strings, related code paths, test files
Reads and traces the code flow to identify root cause
Writes the analysis to .human/bugs/<key>.md

Output format

# Bug Analysis: <TICKET_KEY>

## Summary
<one-line description of the bug>

## Symptoms
- <observable behaviors, error messages, failing conditions>

## Root Cause
<explanation referencing specific files and line numbers>

## Affected Code
| File | Lines | Role |
|------|-------|------|
| path/to/file.go | 42-58 | <what this code does in context> |

## Fix Plan
1. <ordered steps, each referencing specific files/functions>

## Test Plan
- <existing tests to update, new tests to add, manual checks>

## Related Code
- <other areas that may be affected>

Output location

.human/bugs/<key>.md

/human-findbugs

Mon, 01 Jan 0001 00:00:00 +0000

Scans the codebase for bugs using a multi-agent pipeline. Auto-detects technologies and finds semantic bugs that static analysis tools miss.

Usage

/human-findbugs

No ticket or arguments needed. Run it in any codebase.

How it works

The skill runs a 3-phase agent pipeline:

Phase 1: Reconnaissance

A recon agent maps the codebase:

Detects technologies via marker files (go.mod, package.json, Cargo.toml, etc.)
Runs available lightweight static analysis (go vet, npm audit, etc.)
Identifies high-risk files via heuristics: recent git changes, large files, TODO/FIXME/HACK comments, concurrency primitives, error-heavy code, external I/O
Partitions files into 4 analysis domains

Phase 2: Deep Analysis (4 parallel agents)

Four specialized agents run in parallel, each focused on a different concern:

/human-security

Mon, 01 Jan 0001 00:00:00 +0000

Deep security audit of the codebase using a 4-phase multi-agent pipeline. Auto-detects technologies, maps the attack surface, scans for vulnerabilities, and chains findings into exploitable attack paths.

Usage

/human-security

No ticket or arguments needed. Run it in any codebase.

How it works

The skill runs a 4-phase agent pipeline:

Phase 1: Attack Surface Mapping

A surface mapping agent performs attacker-style reconnaissance:

Detects technologies and frameworks (including security-relevant version details)
Maps all entry points: HTTP endpoints, CLI args, file inputs, message handlers, WebSockets
Identifies trust boundaries: which routes require auth, which are public
Traces sensitive data flows: passwords, tokens, PII, financial data
Catalogs cryptographic usage and dependency manifests
Partitions files into 5 scanning domains

Phase 2: Specialized Scanning (5 parallel agents)

Five specialized agents run in parallel, each focused on a different security domain:

/human-gardening

Mon, 01 Jan 0001 00:00:00 +0000

Analyzes codebase health using a multi-agent pipeline. Identifies structural debt, duplication, complexity hotspots, and hygiene issues, then produces a health scorecard with optional auto-fix.

Usage

/human-gardening

No ticket or arguments needed. Run it in any codebase.

How it works

The skill runs a 4-phase agent pipeline:

Phase 1: Survey

A survey agent maps the codebase:

Detects technologies via marker files (go.mod, package.json, Cargo.toml, etc.)
Measures package sizes, exported symbols, and code:test ratios
Maps coupling via fan-in/fan-out analysis on import statements
Runs available static analysis tools (go vet, gocyclo, etc.)
Analyzes git churn: hot files and co-changing file pairs
Collects naming conventions and inconsistencies across packages
Partitions files into 4 analysis domains

Phase 2: Deep Analysis (4 parallel agents)

Four specialized agents run in parallel, each focused on a different health dimension:

/human-ideate

Mon, 01 Jan 0001 00:00:00 +0000

Challenges your idea with forcing questions, refines the scope, and creates a ready PM ticket in your chosen tracker. The ticket creation process itself ensures quality — no separate readiness check needed.

Usage

/human-ideate <rough idea or topic>

Accepts a freeform idea (e.g. "add webhook support for tracker events").

How it works

Phase 1 — Context & challenge: Explores the codebase for relevant code, existing tickets, and recent changes. Returns a context summary and tailored forcing questions.
Asks 5 forcing questions one at a time:
- What is the actual pain? (not the feature request)
- Who has this pain? (specific, not hypothetical)
- What is the status quo? (how people cope today)
- What is the narrowest wedge? (smallest version that delivers value)
- What would make this 10-star? (dream big, then scope back)
Asks you to choose scope: Expand / Hold / Reduce
Asks which tracker to create the ticket in (Shortcut, Linear, Jira, etc.)
Phase 2 — Generate ticket content: Creates a structured ticket with problem statement, user story, acceptance criteria, and scope decisions
Creates the PM ticket on your chosen tracker
Adds a challenge record as a ticket comment (rejected alternatives, premise challenges, scope rationale)
Writes ideation record to .human/ideation/<slug>.md

Output format

The created PM ticket contains:

/human-sprint

Mon, 01 Jan 0001 00:00:00 +0000

One command from rough idea to shipped code. Chains the full human pipeline — ideate, plan, execute, review — auto-deciding mechanical questions and surfacing only genuine taste decisions.

Usage

/human-sprint <rough idea or topic>

Accepts a freeform idea (e.g. "add webhook support for tracker events").

How it works

Pipeline depth: Asks how far to go:
- Tickets only — create PM ticket + engineering plan, then stop
- Plan + execute — create tickets and implement
- Full pipeline — create tickets, implement, and review
Phase 1 — Ideate: Runs the /human-ideate flow (forcing questions, scope decision, tracker choice), creates PM ticket