diff --git a/CLAUDE.md b/CLAUDE.md index a14d093..1ebce4a 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -30,7 +30,7 @@ Hvert plugin er selvstendig med egen CLAUDE.md, README, hooks, agents og command - **Git:** Forgejo (`git.fromaitochitta.com/open/ktg-plugin-marketplace`). Aldri GitHub. - **Hooks:** Alltid Node.js (.mjs), aldri bash. Cross-platform. - **Avhengigheter:** Null npm dependencies i hooks/scannere. `node:test` for tester. -- **PRs:** Aksepteres ikke. Issues velkommen. +- **Bidrag:** Issues velkommen som signaler. PRs ikke akseptert. Fork-and-own er anbefalt adopsjonsmodell — se `GOVERNANCE.md`. - **Lisens:** MIT, alle plugins - **Docs ved endring (OBLIGATORISK):** Enhver feature-endring som pusher til Forgejo MÅ oppdatere alle tre doc-nivåer i SAMME commit eller umiddelbart etter: 1. Plugin `README.md` — detaljert dokumentasjon av endringen diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/README.md b/README.md index 6dea521..397ab7c 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Open-source Claude Code plugins for AI-assisted development, security, and planning. -Built for my own Claude Code workflow and shared openly for anyone who finds them useful. Solo project — bug reports and feature requests are welcome, pull requests are not accepted. +Built for my own Claude Code workflow and shared openly for anyone who finds them useful. Solo-maintained, AI-assisted, fork-and-own. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for what upstream provides and how this is meant to be used. ## AI-generated code disclosure diff --git a/plugins/ai-psychosis/GOVERNANCE.md b/plugins/ai-psychosis/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/ai-psychosis/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/ai-psychosis/README.md b/plugins/ai-psychosis/README.md index 15d2a3c..3c9370a 100644 --- a/plugins/ai-psychosis/README.md +++ b/plugins/ai-psychosis/README.md @@ -7,7 +7,7 @@ # Interaction Awareness -*Built for my own Claude Code workflow and shared openly for anyone who finds it useful. This is a solo project — bug reports and feature requests are welcome, but pull requests are not accepted.* +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* diff --git a/plugins/config-audit/GOVERNANCE.md b/plugins/config-audit/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/config-audit/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/config-audit/README.md b/plugins/config-audit/README.md index 5a54731..d4a2f41 100644 --- a/plugins/config-audit/README.md +++ b/plugins/config-audit/README.md @@ -2,7 +2,7 @@ > Know if your configuration is correct. Find what could improve it. Fix it automatically. -*Built for my own Claude Code workflow and shared openly for anyone who finds it useful. This is a solo project — bug reports and feature requests are welcome, but pull requests are not accepted.* +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* diff --git a/plugins/graceful-handoff/GOVERNANCE.md b/plugins/graceful-handoff/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/graceful-handoff/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/graceful-handoff/README.md b/plugins/graceful-handoff/README.md index 6628831..2523d3a 100644 --- a/plugins/graceful-handoff/README.md +++ b/plugins/graceful-handoff/README.md @@ -2,7 +2,7 @@ > Auto-trigger session handoff at the context threshold so long-running work survives the next session boundary. Manual `/graceful-handoff` always works as a backup. -*Built for my own Claude Code workflow and shared openly for anyone who finds it useful. This is a solo project — bug reports and feature requests are welcome, but pull requests are not accepted.* +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* diff --git a/plugins/linkedin-thought-leadership/GOVERNANCE.md b/plugins/linkedin-thought-leadership/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/linkedin-thought-leadership/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/linkedin-thought-leadership/README.md b/plugins/linkedin-thought-leadership/README.md index 40856be..f8c7fa7 100644 --- a/plugins/linkedin-thought-leadership/README.md +++ b/plugins/linkedin-thought-leadership/README.md @@ -2,7 +2,7 @@ > Build authentic LinkedIn authority through algorithmic understanding, strategic consistency, and AI-assisted content creation. -*Built for my own Claude Code workflow and shared openly for anyone who finds it useful. This is a solo project — bug reports and feature requests are welcome, but pull requests are not accepted.* +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* diff --git a/plugins/llm-security/GOVERNANCE.md b/plugins/llm-security/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/llm-security/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/llm-security/README.md b/plugins/llm-security/README.md index 8cff4d9..d79ad5b 100644 --- a/plugins/llm-security/README.md +++ b/plugins/llm-security/README.md @@ -2,7 +2,7 @@ > Automated defense and advisory analysis for the agentic AI attack surface. -*Built for my own Claude Code workflow and shared openly for anyone who finds it useful. This is a solo project — bug reports and feature requests are welcome, but pull requests are not accepted.* +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* diff --git a/plugins/ms-ai-architect/GOVERNANCE.md b/plugins/ms-ai-architect/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/ms-ai-architect/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/ms-ai-architect/README.md b/plugins/ms-ai-architect/README.md index d1763d2..5187eb0 100644 --- a/plugins/ms-ai-architect/README.md +++ b/plugins/ms-ai-architect/README.md @@ -2,6 +2,8 @@ > Your virtual Microsoft AI solution architect — meet **Cosmo Skyberg**. +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. + *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* ![Version](https://img.shields.io/badge/version-1.8.0-blue) diff --git a/plugins/okr/GOVERNANCE.md b/plugins/okr/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/okr/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/okr/README.md b/plugins/okr/README.md index 6ecbecb..53163c5 100644 --- a/plugins/okr/README.md +++ b/plugins/okr/README.md @@ -2,7 +2,7 @@ > Turn strategy into measurable goals. An AI coach that learns your organization, tracks progress across cycles, and guides you from first OKR to organizational mastery. -*Solo project — bug reports welcome, PRs not accepted.* +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* diff --git a/plugins/ultra-cc-architect/GOVERNANCE.md b/plugins/ultra-cc-architect/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/ultra-cc-architect/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/ultra-cc-architect/README.md b/plugins/ultra-cc-architect/README.md index 7bb342f..647be68 100644 --- a/plugins/ultra-cc-architect/README.md +++ b/plugins/ultra-cc-architect/README.md @@ -5,6 +5,8 @@ ![License](https://img.shields.io/badge/license-MIT-green) ![Platform](https://img.shields.io/badge/platform-Claude%20Code-purple) +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. + *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* A [Claude Code](https://docs.anthropic.com/en/docs/claude-code) plugin that matches a task brief and research against available Claude Code features (Hooks, Subagents, Skills, Output Styles, MCP, Plan Mode, Worktrees, Background Agents) and produces an architecture note with brief-anchored rationale plus explicit coverage gaps. diff --git a/plugins/ultraplan-local/GOVERNANCE.md b/plugins/ultraplan-local/GOVERNANCE.md new file mode 100644 index 0000000..a1e9b52 --- /dev/null +++ b/plugins/ultraplan-local/GOVERNANCE.md @@ -0,0 +1,131 @@ +# 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](#pull-requests--no). +- 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. diff --git a/plugins/ultraplan-local/README.md b/plugins/ultraplan-local/README.md index 8e5a542..6d2a72e 100644 --- a/plugins/ultraplan-local/README.md +++ b/plugins/ultraplan-local/README.md @@ -4,6 +4,8 @@ ![License](https://img.shields.io/badge/license-MIT-green) ![Platform](https://img.shields.io/badge/platform-Claude%20Code-purple) +> **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides. + *AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)* A [Claude Code](https://docs.anthropic.com/en/docs/claude-code) plugin for deep implementation planning, multi-source research, autonomous execution, independent post-hoc review, and zero-friction multi-session resumption. Six commands, one pipeline: