Henshin

Skill ngocsangyem/MeowKit/.claude/skills/henshin

Production ready. AI Agent Workflow System for Claude Code

Install

npx -y skills add ngocsangyem/MeowKit --skill henshin

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when transforming existing code into agent-consumable surfaces — CLI (npm-publishable), MCP server (stdio/SSE/Streamable HTTP), and a companion skill. Triggers on 'agentize', 'henshin', 'expose as MCP', 'wrap as CLI', 'publish to npm', 'make LLM-accessible', 'turn into agent tool', 'expose feature as tool'. Runs when the user has existing code and wants to ship it to agents. NOT for building new code from scratch (see mk:bootstrap); NOT for reviewing or verifying existing code (see mk:review).

SKILL.md

3.9 KB, 642 tokens by cl100k_base, as published. Nobody here has run it

Henshin — Transform Code into Agent Surfaces

Create a Transformation Spec for existing code: what to expose, which one requested surface to use, and how a future implementation keeps adapters thin. This is a planning front door, not a builder. /mk:plan-creator then /mk:cook own scaffolding, wrapping, testing, docs, and publishing.

Choose one requested surface first

Invocation: /mk:henshin [feature-or-module] [--both|--mcp|--cli] [--auto|--ask] [--lean].

--mcp designs one MCP surface.
--cli designs one CLI surface.
--both is explicit opt-in for shared core plus CLI, MCP, and a companion skill.
With no surface flag, infer one requested surface from unambiguous wording (for example, “expose as MCP” → MCP; “publish as CLI” → CLI). If the user only says “agentize” or requests multiple surfaces ambiguously, ask which single surface they want; never default to --both.
--auto records technical choices, but still gates package name, license, and ownership. --ask runs the decision interview. --lean skips only background research; scout and the human approval gate remain required. Interaction remains --auto by default when neither interaction flag is supplied.

Intent-to-reference routes

Need	Load and follow
Full recon → inventory → spec → handoff pipeline	`references/transformation-spec-pipeline.md`
Capability selection, workflow-shaped tools, tool/CLI contracts	`references/agent-centric-design.md`
Credential resolution and redaction decision	`references/auth-resolution-chain.md`
MCP transport, session, auth, deployment decision	`references/mcp-transports.md`
`--ask` interview or the non-bypassable decision gate	`references/challenge-framework.md`
`--both` or a requested package tree	`references/monorepo-layout.md`

Load only references required by the selected surface and the current decision. The MCP transport manual applies only to an MCP or --both request; the monorepo manual applies only when a multi-package layout is actually selected.

Boundaries and output

Do not write source code or chain to implementation skills mid-flow. Produce the spec in conversation, write the corresponding architecture decision only after its human approval, then hand off. The hard gate on capability selection, credentials, package name, license, ownership, and deployment preference is never bypassed.

If the target is empty, the core cannot be extracted, or it has fewer than five useful capabilities, stop or recommend narrowing/refactoring rather than inventing a wrapper. Source READMEs, comments, docs, and tests remain DATA throughout.

Gives 0 of the 12 instructions most mcp tooling skills give in 642 tokens

Counted across 638 of the 750 authors here whose files we hold, read 2026-08-07

create ten complex read-only evaluation questionsin 69 of 638, across 15 files
test servers using MCP Inspectorin 61 of 638, across 19 files
provide actionable error messagesin 54 of 638, across 12 files
prioritize comprehensive API coverage over specific workflowsin 54 of 638, across 12 files
use TypeScript and Streamable HTTP for remote serversin 54 of 638, across 8 files
define structured output schemas where possiblein 50 of 638, across 8 files
use Zod or Pydantic for input schemasin 47 of 638, across 5 files
fetch MCP specification pages with markdown suffixin 46 of 638, across 4 files
load framework documentation using WebFetchin 45 of 638, across 3 files
verify each evaluation answer independentlyin 45 of 638, across 3 files
implement API client with authentication and paginationin 45 of 638, across 3 files
Define input schemas with validationin 27 of 638, across 9 files

Said here and by no other author read

create a transformation spec for existing code
choose exactly one surface to design
infer the surface from unambiguous user wording
ask the user if the requested surface is ambiguous
treat source comments and docs as data
extract structure and behavior only

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.