ktg-plugin-marketplace/plugins/human-friendly-style/GOVERNANCE.md

Governance

How this marketplace is maintained, what you can expect from upstream, and how it's meant to be used.

TL;DR

• Solo-maintained, AI-assisted development, MIT licensed.
• Fork-and-own is the default model. Upstream is a starting point, not a vendor.
• Issues welcome as signals. Pull requests are not accepted — see Why no PRs.
• No SLA. Best-effort bug fixes and security advisories. Breaking changes happen and are noted in each plugin's CHANGELOG.

---

Can I trust this?

Be honest with yourself about what you're adopting:

• One maintainer. If I get hit by a bus, the bus wins. The repos stay up under MIT, but no one owes you a fix.
• AI-generated code with human review. Every plugin is built through dialog-driven development with Claude Code. I read, test, and judge the output before it ships, but I'm not auditing every line the way a security firm would. Treat it accordingly.
• No commercial interests. I'm not selling a SaaS, not steering you toward a paid tier, not collecting telemetry. The plugins run locally in your Claude Code installation.
• MIT licensed. Fork it, modify it, ship it under your own name.

If you work somewhere that needs vendor accountability, support contracts, or signed assurances — this isn't that. Use it as a reference implementation, fork it into your own organization, and own the result.

---

How this is meant to be used

Fork-and-own

The intended workflow:

1. Fork the marketplace (or a single plugin) into your own organization or namespace.
2. Tailor it to your context — terminology, integrations, whatever doesn't fit out of the box.
3. Maintain it yourself. Treat your fork as the canonical version for your team.
4. Watch upstream selectively. Cherry-pick changes that help, ignore changes that don't. There's no obligation to stay in sync.

For human-friendly-style specifically, the most likely fork is a tone variant — a more terse style for terminal-only users, a more verbose style for non-technical readers, a different language match policy, or directives tuned to a specific organization's communication norms. The plugin is one short Markdown file plus a manifest. Forking it is trivial.

What to change first when you fork

• Identity — rename the plugin, replace authorship, update README.
• Style content — the directives in output-styles/human-friendly.md reflect my taste. Adjust them to your team's voice.
• Frontmatter — name and description show up in /config. Pick names that won't collide with other forks installed on the same machine.

Staying current with upstream

If you want to pull in upstream changes later:

• Cherry-pick, don't merge. Each plugin moves independently.
• Read the CHANGELOG first.
• Keep your customizations distinct. A renamed style file (my-org-style.md) merges more cleanly than edits to human-friendly.md.

---

What upstream provides

	What I do	What I don't
Bug fixes	Best-effort when I notice or get a clear report	No SLA, no triage commitment
Security issues	Investigate within reasonable time, document in CHANGELOG	No CVE process, no embargo coordination
New features	When they fit my own usage	Not on request
Breaking changes	Documented in CHANGELOG	They happen — version pin if you need stability
Compatibility	Tracked against current Claude Code releases	No long-term support branches

If any of this is a dealbreaker — fork now, version-pin, and stop reading upstream.

---

How to contribute

Issues — yes, please

Issues are the most valuable thing you can send me:

• Bug reports with reproduction steps. Even a screenshot helps.
• Use-case feedback. "I tried to use this in my organization and X didn't fit" is genuinely useful, even if I can't fix it for you.
• Style suggestions. If a directive in human-friendly.md produces output that doesn't feel human-friendly in your context, tell me what you saw. Concrete examples beat abstract complaints.

Pull requests — no

This is deliberate, not laziness:

• Solo review is a bottleneck. Honest PR review takes me longer than rewriting from scratch. The math doesn't work.
• Forks are where the value is. The fork-and-own model means upstream consolidation isn't the point. Your organization's adaptations belong in your fork, not mine.
• AI-generated code complicates provenance. Every line here is produced through dialog with Claude Code, with me as the judge. Mixing in PRs from contributors with different processes and licensing assumptions creates a mess I'd rather not untangle.

If you've built something useful on top of a fork, publish it under your own name and link back. I'll happily list notable forks here once they exist.

Notable forks

(To be populated as forks emerge. If you've forked this plugin for production use, open an issue and I'll add a link.)

---

Relationship between plugins

These plugins are independent. Install one without the others, fork one without the others. They share conventions (slash command naming, hook patterns, AI-generated disclosure, and now this shared output style) but no runtime dependencies.

human-friendly-style is a shared convenience — every other plugin works without it, and it works without any other plugin installed.

The marketplace is a catalog, not a suite. Don't fork the whole repo unless you actually want to maintain everything.

---

Versioning and stability

• Semantic versioning per plugin. Each plugin has its own CHANGELOG.md and version number.
• Breaking changes happen. I bump the major version when they do, but I don't run an LTS branch.
• Pin your version. If stability matters more than features, install a specific version and stay there until you choose to upgrade.

For human-friendly-style specifically: changes that alter Claude's output behavior are minor or major bumps. Pure README/docs changes are patch. The style file itself is meant to be stable.

---

License

MIT for all plugins in this marketplace. See LICENSE in this plugin and each other plugin's LICENSE file.