human - The Dark Software Factory for Claude Code

/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:

CLI Reference

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

Global flags

Flag	Description
`--help`	Show help for any command
`--version`	Print version
`--table`	Compact table format

Issue tracker commands

All issue trackers (jira, github, gitlab, linear, azuredevops, shortcut) share the same command structure:

List issues

human <tracker> issues list --project=<PROJECT>

Get an issue

human <tracker> issue get <ID>

Create an issue

human <tracker> issue create --project=<PROJECT> "Title"
human <tracker> issue create --project=<PROJECT> "Title" --description "Detailed description"

Add a comment

human <tracker> issue comment add <ID> "Comment text"

List comments

human <tracker> issue comments <ID>

Transition an issue

human <tracker> issue transition <ID> "Status"

Shortcut commands

human get <KEY>                      # Get an issue (auto-detect tracker)
human list --project=<PROJECT>       # List issues (auto-detect tracker)
human tracker list                   # List configured trackers

These shortcut commands work when only one tracker type is configured. When multiple tracker types are configured, use the provider-specific commands.

Devcontainers

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

AI agents inside devcontainers need access to issue trackers, Notion, Figma, and Amplitude, but credentials should stay on the host. human solves this with a daemon that forwards CLI commands from the container to the host.

Architecture

[Devcontainer]                          [Host]
human jira issues list                  human daemon (:19285)
    |  TCP                                  |  (executes command with
    └───── :19285 ──────────────────────────┘    host credentials)

The daemon also runs a chrome proxy on :19286 for Chrome Bridge support, an HTTPS proxy on :19287 for outbound traffic filtering, and a FUSE .env filter that hides secrets from the agent.

Devcontainers to go --yolo

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

This tutorial walks through setting up a devcontainer where Claude Code has full access to your issue tracker, Chrome, Notion, Figma, and Amplitude — while credentials never enter the container.

What you’ll end up with

Devcontainer                        Host
                                    human daemon
human jira issues list  ------->    CLI proxy      (:19285)
claude --chrome         ------->    Chrome proxy   (:19286)
HTTPS requests          ------->    HTTPS proxy    (:19287)
human-browser           ------->    URL opener
secret files            ------->    FUSE filter    (redacted / empty)

Credentials stay on the host. The agent never sees API tokens or secrets.

Installation

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

Install script (recommended)

curl -sSfL gethuman.sh/install.sh | bash

Downloads the latest release binary for your platform and places it in your PATH.

Homebrew

brew install stephanschmidt/tap/human

mise

mise use -g github:StephanSchmidt/human

Go

go install github.com/stephanschmidt/human@latest

Requires Go 1.21 or later.

Verify

human --version

Next steps

After installing, run human init to configure your project. See Quick Start.

Jira

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

Connect to Jira Cloud or Jira Server.

Configuration

tracker: jira
jira:
  url: https://yourcompany.atlassian.net
  project: KAN
  token_env: JIRA_API_TOKEN
  email: you@example.com

Field	Description
`url`	Your Jira instance URL
`project`	Default project key
`token_env`	Environment variable containing your API token
`email`	Your Jira account email (required for Cloud)

Commands

# List issues in a project
human jira issues list --project=KAN

# Get a single issue with full details
human jira issue get KAN-1

# Create an issue
human jira issue create --project=KAN "Implement SSO"

# Add a comment
human jira issue comment add KAN-1 "This is done"

# List comments
human jira issue comments KAN-1

# Update issue status
human jira issue transition KAN-1 "In Progress"

Output format

human returns only the fields relevant for development — title, status, description, acceptance criteria, and comments. The output is structured for AI consumption with minimal token usage.

Use Chrome Inside a Devcontainer with Claude Code

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

How to fix “claude –chrome” not working in devcontainers

When you run claude --chrome inside a VS Code devcontainer, nothing happens. Chrome runs on the host machine, and its native messaging protocol can’t cross the Docker container boundary. The Chrome DevTools Protocol connection that Claude Code relies on simply doesn’t exist inside the container.

You’re forced to choose: use a devcontainer and lose browser access, or work on the host and lose isolation. Neither is acceptable for teams that need both. Chrome Bridge fixes this by tunneling the Chrome DevTools Protocol connection from inside the container to Chrome on the host.

/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

Chrome Bridge

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

The Chrome Bridge enables claude --chrome to work inside devcontainers. Claude Code’s Chrome integration uses Chrome’s native messaging protocol to communicate with the browser extension, which does not work from inside a container because Chrome runs on the host.

Architecture

[Devcontainer]                              [Host]
Claude Code --chrome                        Chrome + Extension
    |  (Unix socket)                            ^  (native messaging)
human chrome-bridge                         human daemon
    |  TCP (:19286)                             ^  (SocketRelay)
    └──────────── TCP tunnel ───────────────────┘

How it works

human daemon start on the host starts the daemon (:19285), chrome proxy (:19286), and a SocketRelay that listens on a Unix socket in /tmp/claude-mcp-browser-bridge-<username>/
human chrome-bridge in the container creates a Unix socket at the same path that Claude Code uses to discover the MCP browser bridge
When Claude Code connects to the socket, the bridge tunnels traffic over TCP to the daemon’s chrome proxy
The daemon pairs the connection with a Chrome native messaging connection via the SocketRelay

Host setup

Start the daemon on your host machine:

Connect Claude Code to Jira, Linear, GitHub, Notion, Figma and More

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

human is the intent layer of the dark software factory — the thing that feeds your Claude Code agent real context from every tool your team uses. Without it, Claude can’t see your Jira tickets, read your Notion docs, or inspect your Figma designs, and you become the bottleneck copying context between tools and the AI.

The problem with connecting AI agents to your tools

Claude Code is powerful, but it can’t see your Jira tickets, read your Notion docs, inspect your Figma designs, or check your Amplitude dashboards. Without these connections, you’re the bottleneck — copying and pasting context between tools and the AI.

GitHub

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

Connect to GitHub Issues and Projects.

Configuration

tracker: github
github:
  project: octocat/hello-world
  token_env: GITHUB_TOKEN

Commands

# List issues
human github issues list --project=octocat/hello-world

# Get a single issue
human github issue get 42

# Create an issue
human github issue create --project=octocat/hello-world "Fix login bug"

# Add a comment
human github issue comment add 42 "Fixed in PR #43"

Quick Start

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

Get up and running with human in under a minute.

Install

The fastest way to install human:

curl -sSfL gethuman.sh/install.sh | bash

See Installation for more options (Homebrew, mise, Go).

Configure

Run the interactive setup wizard:

human init

This creates a .humanconfig.yaml in your project root. The wizard will:

Ask which issue tracker you use (Jira, GitHub, GitLab, Linear, Azure DevOps, Shortcut)
Prompt for your API token or credentials
Detect your project and set defaults
Optionally install Claude Code skills

Your first command

List issues from your tracker:

Troubleshooting

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

“command not found” after install

The human binary is not in your PATH. The install script places it in ~/.local/bin/ by default.

# Add to your shell profile (~/.bashrc, ~/.zshrc, etc.)
export PATH="$HOME/.local/bin:$PATH"

Reload your shell or run source ~/.bashrc (or ~/.zshrc).

Auth failures

Wrong token or expired token:

# Regenerate the daemon token
human daemon token

Copy the new token into your HUMAN_DAEMON_TOKEN environment variable.

Wrong environment variable name:

/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.

Configuration

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

human is configured via a .humanconfig.yaml file in your project root. Run human init to create one interactively.

Example

tracker: jira
jira:
  url: https://yourcompany.atlassian.net
  project: KAN
  token_env: JIRA_API_TOKEN
  email: you@example.com

Tracker options

Field	Description
`tracker`	Default tracker: `jira`, `github`, `gitlab`, `linear`, `azuredevops`, `shortcut`, `clickup`

Each tracker has its own configuration block. See the individual connector pages for details.

Credentials

1Password (recommended)

Add a vault section and use 1pw:// references directly in your config:

vault:
  provider: 1password
  account: my-account    # 1Password account name (top-left in app sidebar)

jiras:
  - name: work
    url: https://yourcompany.atlassian.net
    user: you@example.com
    key: 1pw://Development/Jira API Key/token

The 1Password desktop app must be installed and running. It will prompt for biometric or master password authentication. Enable “Integrate with other apps” in 1Password Settings > Developer.

GitLab

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

Connect to GitLab Issues.

Configuration

tracker: gitlab
gitlab:
  project: mygroup/myproject
  url: https://gitlab.com
  token_env: GITLAB_TOKEN

Commands

# List issues
human gitlab issues list --project=mygroup/myproject

# Get a single issue
human gitlab issue get 42

# Create an issue
human gitlab issue create --project=mygroup/myproject "Add dark mode"

# Add a comment
human gitlab issue comment add 42 "Implemented in MR !15"

MCP OAuth Authentication in Devcontainers for Claude Code

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

How to fix MCP OAuth not working in devcontainers

MCP servers that require OAuth authentication need a browser redirect. The server starts a local HTTP listener, opens a browser, the user authenticates, and the OAuth provider redirects back to localhost with an authorization code.

Inside a devcontainer, this breaks at every step. There’s no browser. localhost inside the container is not the same localhost the OAuth provider redirects to. Port forwarding helps sometimes, but it’s fragile and different for every MCP server.

/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

HTTPS Proxy and Firewall for Claude Code in Devcontainers

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

How to restrict AI coding agent network access

AI agents running inside devcontainers have the same network access as any process in that container. An agent that can reach the internet can exfiltrate code, call unauthorized APIs, download untrusted packages, or communicate with arbitrary endpoints.

For teams that care about security — and every team running AI agents on proprietary code should — unrestricted outbound network access from a coding agent is an unacceptable risk.

Linear

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

Connect to Linear issues and projects.

Configuration

tracker: linear
linear:
  project: ENG
  token_env: LINEAR_API_KEY

Commands

# List issues
human linear issues list --project=ENG

# Get a single issue
human linear issue get ENG-42

# Create an issue
human linear issue create --project=ENG "Implement feature"

# Add a comment
human linear issue comment add ENG-42 "Completed implementation"

Policies

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

Policies give you fine-grained control over what AI agents can do with your issue trackers. Add a policies: section to your .humanconfig.yaml to define declarative rules that sit between the all-or-nothing --safe flag and full trust.

Configuration

policies:
  block:
    - delete
    - assign
  confirm:
    - transition:Done
    - create

Actions

Action	Behavior
`block`	The operation is rejected with an error. The inner tracker is never called.
`confirm`	A warning is logged to stderr before the operation proceeds.
(unlisted)	The operation is allowed without any warning.

Operations

Rules map to tracker provider methods:

Azure DevOps

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

Connect to Azure Boards work items.

Configuration

tracker: azuredevops
azuredevops:
  organization: myorg
  project: Human
  token_env: AZURE_DEVOPS_PAT

Commands

# List work items
human azuredevops issues list --project=Human

# Get a single work item
human azuredevops issue get 42

# Create a work item
human azuredevops issue create --project=Human "Set up CI pipeline"

# Add a comment
human azuredevops issue comment add 42 "Pipeline configured"

Open URLs on Host Browser from Claude Code Devcontainers

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

Fix xdg-open not working in devcontainers

When code inside a devcontainer tries to open a URL — whether it’s an OAuth redirect, a documentation link, a test coverage report, or a local dev server preview — nothing happens. There’s no browser inside the container. xdg-open, open, and $BROWSER all fail silently or error out.

This breaks:

OAuth flows that need to open a browser for authentication
Claude Code when it tries to open links or documentation
Dev server previews that auto-open localhost:3000
Test reports that open an HTML file in the browser
Any tool that assumes a browser is available

$BROWSER replacement for containers

human-browser is a drop-in replacement for xdg-open and the system browser inside devcontainers. Set it as $BROWSER in your container, and any tool that opens URLs will have those URLs open on your host machine instead.

Protect .env Files from AI Agents in Devcontainers

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

How to prevent AI coding agents from reading .env secrets

When AI agents run inside devcontainers, the project directory is bind-mounted into the container. This means .env files — containing API keys, database credentials, and other secrets — are fully readable by the agent. A compromised or careless agent can read and exfiltrate these credentials.

FUSE-based .env filtering for Claude Code devcontainers

The human daemon creates a FUSE mount that mirrors your entire workspace. The container mounts this filtered view instead of the real directory. Regular files pass through at native speed. .env files appear in directory listings but return empty content when read. Writes to .env files are blocked.

/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

Built-in Development Skills for Claude Code

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

How to create a Definition of Ready for Claude Code

Claude Code is great at writing code. But code is the easy part. The hard part is everything around it: Is the ticket ready? What’s the implementation approach? Does the code match the acceptance criteria? Are there edge cases? Security issues?

human’s built-in Claude Code skills cover the full development lifecycle as slash commands. Each skill fetches the ticket from your configured issue tracker, performs its analysis, and writes a structured report to the .human/ directory. /human-ready in particular enforces a Definition of Ready checklist before any code is written — stopping the “build the wrong thing” failure mode at the source.

Shortcut

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

Connect to Shortcut stories.

Configuration

tracker: shortcut
shortcut:
  project: MyProject
  token_env: SHORTCUT_API_TOKEN

Commands

# List stories
human shortcut issues list --project=MyProject

# Get a single story
human shortcut issue get 42

# Create a story
human shortcut issue create --project=MyProject "Add user onboarding"

# Add a comment
human shortcut issue comment add 42 "Onboarding flow complete"

/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:

ClickUp

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

Connect to ClickUp tasks.

Configuration

Add a clickups: section to your .humanconfig.yaml:

clickups:
  - name: work
    token: pk_12345678_ABCDEFG
    team_id: "1234567"  # optional, for custom task IDs
    projects:
      - "901234567"     # List IDs

Field	Description
`name`	Instance name, used with `--tracker=<name>` when multiple trackers are configured
`token`	ClickUp personal API token (`pk_...`). Can also be set via `CLICKUP_TOKEN` or `CLICKUP_{NAME}_TOKEN` env var
`team_id`	Optional. Workspace ID, required when using custom task IDs (e.g. `PREFIX-123`)
`projects`	Optional. List of ClickUp List IDs to index
`url`	Optional. API base URL, defaults to `https://api.clickup.com/api`
`safe`	Optional. When `true`, blocks destructive operations (deletes)

ClickUp organizes work as Workspace > Space > Folder > List > Task. The --project flag maps to a List ID.

Live Dashboard for Claude Code Token Usage and Tracker Issues

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

How to monitor Claude Code token consumption

Claude Code shows no easy way to see how many tokens you’ve consumed in the current billing window. You’re flying blind until you hit the rate limit. With multiple instances running — one on your host, others inside devcontainers — it’s even worse. Each instance burns through tokens independently, and you have no aggregate view.

One command, full visibility

human tui

Notion

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

Connect to Notion workspaces — search pages, read content, query databases.

Configuration

notion:
  token_env: NOTION_TOKEN

Commands

# Search workspace
human notion search "quarterly report"

# Get a page
human notion page get <page-id>

Notion integration requires an internal integration token. Create one at notion.so/my-integrations and share the relevant pages with it.

/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:

Figma

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

Connect to Figma — browse files, inspect components, read comments, export assets.

Configuration

figma:
  token_env: FIGMA_TOKEN

Commands

# Get a file
human figma file get <file-key>

# List comments
human figma file comments <file-key>

# List components
human figma file components <file-key>

The output includes component structure, styles, and design tokens in a text format that AI agents can consume directly.

Telegram Bot Messages for Claude Code

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

Use Telegram as a task inbox for Claude Code

You set up a Telegram bot for your team or users. Messages come in — feature requests, bug reports, questions. Someone has to read them, triage them, and act on them.

With human, Claude Code can do that. It polls the bot for pending messages, reads them, acts on them, and acknowledges them when done.

Three commands

# See what's waiting
human telegram list --table

# Read a specific message
human telegram get 123456

# Mark as handled
human telegram ack 123456

That’s the full API. List, read, acknowledge.

/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:

Amplitude

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

Connect to Amplitude — product analytics, events, funnels, retention, and cohorts.

Configuration

amplitude:
  token_env: AMPLITUDE_API_KEY
  secret_env: AMPLITUDE_SECRET_KEY

Commands

# List events
human amplitude events list

# List cohorts
human amplitude cohorts list

AI agents can query analytics data to inform implementation decisions.

Sentry

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

Connect to Sentry — error tracking, issue management, and event monitoring.

Configuration

sentry:
  organization: your-org-slug
  token_env: SENTRY_AUTH_TOKEN

Commands

# List issues in a project
human sentry issues list --project=your-project

# Get a single issue with details
human sentry issue get 12345

# List events for an issue
human sentry issue events 12345

# Resolve an issue
human sentry issue resolve 12345

# Unresolve an issue
human sentry issue unresolve 12345

AI agents can query Sentry issues to investigate errors and triage bugs during development.

Getting to the Dark Software Factory

Mon, 25 May 2026 00:00:00 +0000

TL;DR

A dark software factory ships work from intent to production with no developer touching it on the way. Darkness is per-unit — about which stages run unattended, not how much AI you use overall — and it needs three things from the infrastructure, not the agent: machine-derivable intent, machine-observable outcomes, and a machine-bounded blast radius. A qualifier routes each unit into a dark lane or leaves it to humans; lanes are defined by intent source and capability (maintenance, bug autofix, telemetry-driven, transformation, gardening), while concerns like passing tests and stable APIs are the floor every lane must clear. Run continuously, the qualifier becomes a forager that cherry-picks work, and that scoring function — not the agents — is the real product. As shipping costs collapse, the bottleneck moves from what you can build to positioning and attention, so the factory's real value is throughput plus restraint.

Yes, You Can Run a Dark Factory on Your Codebase

Sat, 23 May 2026 00:00:00 +0000

TL;DR

Yes, you can run a dark software factory on your own codebase today, and the recipe is lighter than the writeups make it look. Six categories already ship good results against the test infrastructure most teams already have — integrations and SDKs, migrations and refactors, CRUD on well-typed schemas, codegen from formal specs, infrastructure-as-code, and bug fixes with a reproducing test — together roughly 40–60% of what a typical SaaS team ships. The near edge (feature-flagged work, benchmark-driven performance) arrives within a year; the rings beyond it need Level 6 self-optimisation and more mature telemetry. Start by running one ticket end to end and shipping it, because the harness tuning and intent-writing compound with every ticket. human is the harness for that today-list.

Beyond the Dark Factory

Sat, 11 Apr 2026 00:00:00 +0000

What is a Dark Software Factory?

Wed, 08 Apr 2026 00:00:00 +0000

/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

Impressum

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

Angaben gemäß § 5 TMG

SJS Holding GmbH Zeppelinstraße 1A 12529 Schönefeld Deutschland

Telefon: 0157 33918386 Mail: stephan@amazingcto.com

Geschäftsführerin: Stefanie Jarantowski-Schmidt

Handelsregister: Amtsgericht Cottbus, HRB 19488 CB Umsatzsteuer-Identifikationsnummer: DE323718512

Verantwortlich gemäß § 55 RStV

Stephan Schmidt SJS Holding GmbH Zeppelinstraße 1A 12529 Schönefeld