open/human-friendly-style
1
0
Fork 0
Code Issues Releases 1 Activity

docs: drop drifted GOVERNANCE.md, point README to canonical (org-ops D11)

Browse source 
This repo's copy had drifted from repo-standard's canonical GOVERNANCE.md
(118 vs 131 lines) and isn't required for the plugin repo class. Removed
it and repointed README.md's link to the canonical source. The
repo-specific fork guidance the local copy carried (tone-variant
suggestions, what to change first, style-feedback ask) moved into a new
README "Forking this" section so it isn't lost.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N1AtouNwgWaLBgRDcsNowY
This commit is contained in:
Kjell Tore Guttormsen 2026-08-13 21:23:37 +02:00
commit 46fe54d818
2 changed files with 15 additions and 119 deletions
Download patch file Download diff file Expand all files Collapse all files

118
GOVERNANCE.md
View file

@ -1,118 +0,0 @@
# 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, whatever doesn't fit out of the box.
3. **Maintain it yourself.** Treat your fork as the canonical version for your team.
4. **Watch upstream selectively.** Cherry-pick changes that help, ignore changes that don't. There's no obligation to stay in sync.
For `human-friendly-style` specifically, the most likely fork is a tone variant — a more terse style for terminal-only users, a more verbose style for non-technical readers, a different language match policy, or directives tuned to a specific organization's communication norms. The plugin is one short Markdown file plus a manifest. Forking it is trivial.
### What to change first when you fork
- **Identity** — rename the plugin, replace authorship, update README.
- **Style content** — the directives in `output-styles/human-friendly.md` reflect my taste. Adjust them to your team's voice.
- **Frontmatter** — `name` and `description` show up in `/config`. Pick names that won't collide with other forks installed on the same machine.
### Staying current with upstream
If you want to pull in upstream changes later:
- **Cherry-pick, don't merge.** Each plugin moves independently.
- **Read the CHANGELOG first.**
- **Keep your customizations distinct.** A renamed style file (`my-org-style.md`) merges more cleanly than edits to `human-friendly.md`.
---
## What upstream provides
| | What I do | What I don't |
|---|---|---|
| **Bug fixes** | Best-effort when I notice or get a clear report | No SLA, no triage commitment |
| **Security issues** | Investigate within reasonable time, document in CHANGELOG | No CVE process, no embargo coordination |
| **New features** | When they fit my own usage | Not on request |
| **Breaking changes** | Documented in CHANGELOG | They happen — version pin if you need stability |
| **Compatibility** | Tracked against current Claude Code releases | No long-term support branches |
If any of this is a dealbreaker — fork now, version-pin, and stop reading upstream.
---
## How to contribute
### Issues — yes, please
Issues are the most valuable thing you can send me:
- **Bug reports** with reproduction steps. Even a screenshot helps.
- **Use-case feedback.** "I tried to use this in my organization and X didn't fit" is genuinely useful, even if I can't fix it for you.
- **Style suggestions.** If a directive in `human-friendly.md` produces output that doesn't feel human-friendly in your context, tell me what you saw. Concrete examples beat abstract complaints.
### Pull requests — no
This is deliberate, not laziness:
- **Solo review is a bottleneck.** Honest PR review takes me longer than rewriting from scratch. The math doesn't work.
- **Forks are where the value is.** The fork-and-own model means upstream consolidation isn't the point. Your organization's adaptations belong in your fork, not mine.
- **AI-generated code complicates provenance.** Every line here is produced through dialog with Claude Code, with me as the judge. Mixing in PRs from contributors with different processes and licensing assumptions creates a mess I'd rather not untangle.
If you've built something useful on top of a fork, **publish it under your own name and link back.** I'll happily list notable forks here once they exist.
### Notable forks
*(To be populated as forks emerge. If you've forked this plugin for production use, open an issue and I'll add a link.)*
---
## Relationship between plugins
These plugins are **independent**. Install one without the others, fork one without the others. They share conventions (slash command naming, hook patterns, AI-generated disclosure, and now this shared output style) but no runtime dependencies.
`human-friendly-style` is a shared convenience — every other plugin works without it, and it works without any other plugin installed.
The marketplace is a **catalog**, not a suite. Don't fork the whole repo unless you actually want to maintain everything.
---
## Versioning and stability
- **Semantic versioning per plugin.** Each plugin has its own `CHANGELOG.md` and version number.
- **Breaking changes happen.** I bump the major version when they do, but I don't run an LTS branch.
- **Pin your version.** If stability matters more than features, install a specific version and stay there until you choose to upgrade.
For `human-friendly-style` specifically: changes that alter Claude's output behavior are minor or major bumps. Pure README/docs changes are patch. The style file itself is meant to be stable.
---
## License
MIT for all plugins in this marketplace. See [LICENSE](LICENSE) in this plugin and each other plugin's `LICENSE` file.

16
README.md
View file

@ -7,7 +7,7 @@ than a developer at a terminal — a colleague looking over your shoulder, a
session you are documenting for someone else, or non-code work where console
noise gets in the way.
> **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.
> **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](https://git.fromaitochitta.com/open/repo-standard/src/branch/main/GOVERNANCE.md) for the full model and what upstream provides.
*AI-generated: all code produced by Claude Code through dialog-driven development. Every change is human-directed, reviewed, and validated before commit. Per Anthropic Consumer Terms §4, ownership of outputs is assigned to the user.*
@ -213,6 +213,20 @@ Output styles are a first-class feature in Claude Code's plugin system. Older Cl
---
## Forking this
The most likely fork is a tone variant — a more terse style for terminal-only users, a more verbose style for non-technical readers, a different language match policy, or directives tuned to your organization's communication norms. It's one short Markdown file plus a manifest; forking is trivial.
What to change first:
- **Identity** — rename the plugin, replace authorship, update this README.
- **Style content** — the directives in `output-styles/human-friendly.md` reflect the original author's taste. Adjust them to your team's voice.
- **Frontmatter** — `name` and `description` show up in `/config`. Pick names that won't collide with other forks installed on the same machine.
If a directive produces output that doesn't feel human-friendly in your context, that's useful feedback for the upstream maintainer — concrete examples beat abstract complaints.
---
## Versioning and stability
- Semantic versioning. Style content changes that affect Claude's output are minor or major bumps; pure typo fixes in the README are patch.