ktg-plugin-marketplace/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, cycle lengths, regulatory framing, 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.

This isn't a workaround for not accepting PRs. It's the actual recommended adoption pattern, especially for plugins like okr and ms-ai-architect where every Norwegian public sector organization will need its own tildelingsbrev mappings, terminology, and integrations. A central "one true plugin" would be wrong for everyone.

What to change first when you fork

Each plugin differs, but the common edits are:

• Identity — rename the plugin, replace authorship, update README.
• External integrations — issue trackers, knowledge bases, dashboards, observability backends. The plugins ship as starting points, not pre-wired. Every organization must configure its own integrations.
• Norwegian-specific framing — relevant for okr and ms-ai-architect. Other plugins are jurisdiction-neutral. Rewrite for your jurisdiction if you're outside Norway.
• Reference docs — the knowledge base in each plugin reflects my reading. Replace with your organization's authoritative sources.
• Hooks and policies — security thresholds, blocked commands, and audit gates are tuned to my taste. Tune them to yours.

Staying current with upstream

If you want to pull in upstream changes later:

• Cherry-pick, don't merge. Each plugin moves independently and breaking changes land without ceremony.
• Read the CHANGELOG first. Every plugin has one.
• Keep your customizations in clearly-named files. The harder upstream is to merge cleanly, the more painful staying current becomes. A local/ directory or *.local.md convention helps.

---

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
Norwegian public sector context	Kept current as long as the project lives	If I lose interest or change jobs, the framing freezes
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.
• Pointers to better sources. If you know a DFØ veileder, an NSM guideline, or an academic paper that contradicts what's in a knowledge base, tell me.
• Security findings. See each plugin's SECURITY.md for disclosure preference where one exists; otherwise email rather than open a public issue.

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 one of these plugins 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) but no runtime dependencies.

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.

---

Public sector adoption notes

For Norwegian etater specifically:

• DPIA-relevant data flows are documented in the relevant plugin README where applicable. Read them before installation.
• No data leaves your machine beyond what Claude Code itself sends to Anthropic. The plugins themselves do not call external services unless you configure an integration.
• Drøftingsplikt and ledelsesansvar are not replaced by these tools. The okr plugin coaches; it does not decide. The ms-ai-architect plugin advises; it does not approve.
• Choose your Claude deployment carefully. claude.ai vs. API direct vs. Bedrock in EU region have different data residency profiles. The plugins don't choose for you.

---

License

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