Compare commits
8 commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 2427d36e7e | |||
| ea8ec84a1e | |||
| 46fe54d818 | |||
| 02136eac12 | |||
| 524554d430 | |||
| 77bcdba0ce | |||
| a4b55fc168 | |||
| 9ed12426bf |
5 changed files with 150 additions and 159 deletions
12
.gitignore
vendored
Normal file
12
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
|
||||
# --- session/local state (gitignored per ~/.claude polyrepo-konvensjon) ---
|
||||
STATE.md
|
||||
REMEMBER.md
|
||||
ROADMAP.md
|
||||
TODO.md
|
||||
NEXT-SESSION-PROMPT*.local.md
|
||||
*.local.md
|
||||
*.local.json
|
||||
*.local.sh
|
||||
.DS_Store
|
||||
.claude/
|
||||
118
GOVERNANCE.md
118
GOVERNANCE.md
|
|
@ -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.
|
||||
119
README.md
119
README.md
|
|
@ -1,22 +1,69 @@
|
|||
# Human-Friendly Output Style for Claude Code
|
||||
# human-friendly-style
|
||||
Shared Claude Code output style for the ktg-plugin-marketplace. Plain-language tone — explains what and why, hides paths/JSON/stack traces by default, matches the user's language.
|
||||
|
||||
> A shared output style that gives every plugin in this marketplace a consistent, plain-language tone. Install it once, activate it via `/config`, and Claude Code starts explaining work the way a person would — not the way a console dump does.
|
||||
One Markdown file that changes how Claude *talks about* the work, not how the
|
||||
work is done. For anyone whose Claude Code sessions are read by someone other
|
||||
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. [Full disclosure →](../../README.md#ai-generated-code-disclosure)*
|
||||
*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.*
|
||||
|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||
|
||||
A Claude Code plugin that ships a single [output style](https://code.claude.com/docs/en/output-styles) used across the [ktg-plugin-marketplace](https://git.fromaitochitta.com/open/ktg-plugin-marketplace). The style modifies Claude Code's system prompt so responses default to prose instead of bullet lists, hide noisy details (long file paths, raw shell commands, JSON blobs, stack traces) until the user asks for them, match the user's language, and stay honest about uncertainty. Claude Code's built-in coding instructions stay intact (`keep-coding-instructions: true`), so testing discipline, careful edits, and verification still apply — only the way Claude *talks about* the work changes.
|
||||
## Install
|
||||
|
||||
Use the `https://` form. The forge UI's clone button hands out an `ssh://` URL,
|
||||
and `marketplace add` answers it with `Invalid git URL`.
|
||||
|
||||
```bash
|
||||
claude plugin marketplace add https://git.fromaitochitta.com/open/ktg-plugin-marketplace.git
|
||||
claude plugin install human-friendly-style@ktg-plugin-marketplace
|
||||
```
|
||||
|
||||
Inside a running session, `/plugin install human-friendly-style@ktg-plugin-marketplace` does the same thing. Or enable it directly in `~/.claude/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"enabledPlugins": {
|
||||
"human-friendly-style@ktg-plugin-marketplace": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Installing does not activate it — see [Activate](#activate).
|
||||
|
||||
## Requirements
|
||||
|
||||
| Requirement | Version |
|
||||
|-------------|---------|
|
||||
| Claude Code | recent versions with output style support |
|
||||
| Platform | macOS, Linux, Windows |
|
||||
| Network | None — output styles are local Markdown files |
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [The problem](#the-problem)
|
||||
- [What it does](#what-it-does)
|
||||
- [Before / after](#before--after)
|
||||
- [Getting more detail](#getting-more-detail)
|
||||
- [Activate](#activate)
|
||||
- [How it works](#how-it-works)
|
||||
- [Non-goals](#non-goals)
|
||||
- [Cross-plugin use](#cross-plugin-use)
|
||||
- [Compatibility](#compatibility)
|
||||
- [Forking this](#forking-this)
|
||||
- [Versioning and stability](#versioning-and-stability)
|
||||
- [Changelog](#changelog)
|
||||
- [License](#license)
|
||||
|
||||
## The problem
|
||||
|
||||
Default Claude Code output is engineering output. Long absolute paths. Raw `git` invocations. JSON dumps. Stack traces. Bullet lists for everything. That is fine for a developer running terminal commands — it is the lingua franca of CLI work. It is also the wrong register when:
|
||||
|
|
@ -34,6 +81,8 @@ This plugin solves that with one short Markdown file and the official Claude Cod
|
|||
|
||||
## What it does
|
||||
|
||||
This plugin ships a single [output style](https://code.claude.com/docs/en/output-styles) used across the [ktg-plugin-marketplace](https://git.fromaitochitta.com/open/ktg-plugin-marketplace). The style modifies Claude Code's system prompt so responses default to prose instead of bullet lists, hide noisy details (long file paths, raw shell commands, JSON blobs, stack traces) until the user asks for them, match the user's language, and stay honest about uncertainty. Claude Code's built-in coding instructions stay intact (`keep-coding-instructions: true`), so testing discipline, careful edits, and verification still apply — only the way Claude *talks about* the work changes.
|
||||
|
||||
The style file at `output-styles/human-friendly.md` declares nine directives that ride on top of Claude Code's normal system prompt:
|
||||
|
||||
| # | Directive | What it changes |
|
||||
|
|
@ -105,33 +154,7 @@ One thing the style does *not* hide, even unprompted: **irreversible actions**.
|
|||
|
||||
---
|
||||
|
||||
## Quick start
|
||||
|
||||
### Install
|
||||
|
||||
Add the marketplace once, then install the plugin:
|
||||
|
||||
```bash
|
||||
claude plugin marketplace add https://git.fromaitochitta.com/open/ktg-plugin-marketplace.git
|
||||
```
|
||||
|
||||
In Claude Code:
|
||||
|
||||
```
|
||||
/plugin install human-friendly-style@ktg-plugin-marketplace
|
||||
```
|
||||
|
||||
Or enable directly in `~/.claude/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"enabledPlugins": {
|
||||
"human-friendly-style@ktg-plugin-marketplace": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Activate
|
||||
## Activate
|
||||
|
||||
```
|
||||
/config
|
||||
|
|
@ -177,7 +200,7 @@ Removing the style is as simple: `/config` → **Output style** → **(default)*
|
|||
|
||||
---
|
||||
|
||||
## What this plugin does *not* do
|
||||
## Non-goals
|
||||
|
||||
By design, this plugin contains no commands, no agents, no hooks, no skills, no MCP servers. It ships exactly one file plus a manifest. That is the whole point — a shared conversational style should be a small, predictable thing that adds zero runtime overhead and zero surface area to audit.
|
||||
|
||||
|
|
@ -202,16 +225,24 @@ The style is **optional**. Every plugin in the marketplace works without it. Thi
|
|||
|
||||
## Compatibility
|
||||
|
||||
| Requirement | Version |
|
||||
|-------------|---------|
|
||||
| Claude Code | recent versions with output style support |
|
||||
| Platform | macOS, Linux, Windows |
|
||||
| Network | None — output styles are local Markdown files |
|
||||
|
||||
Output styles are a first-class feature in Claude Code's plugin system. Older Claude Code releases without `/config` → Output style support will install the plugin without errors but will not apply the style. See [Claude Code Output Styles documentation](https://code.claude.com/docs/en/output-styles) for the canonical reference.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
|
@ -220,6 +251,12 @@ Output styles are a first-class feature in Claude Code's plugin system. Older Cl
|
|||
|
||||
---
|
||||
|
||||
## Changelog
|
||||
|
||||
See [CHANGELOG.md](CHANGELOG.md).
|
||||
|
||||
---
|
||||
|
||||
## License
|
||||
|
||||
[MIT](LICENSE). Fork it, modify it, ship your own version under your own name.
|
||||
|
|
|
|||
31
SECURITY.md
Normal file
31
SECURITY.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# Security policy
|
||||
|
||||
## Reporting a vulnerability
|
||||
|
||||
Report privately to <security@fromaitochitta.com> - do not open a
|
||||
public issue.
|
||||
Canonical repository: https://git.fromaitochitta.com/open/human-friendly-style
|
||||
|
||||
Please include the affected version or commit, a minimal reproduction,
|
||||
and the impact you see. We acknowledge every report within 5 working
|
||||
days, agree a fix and disclosure timeline with the reporter, and aim to
|
||||
disclose within 90 days of the initial report.
|
||||
|
||||
## Response process
|
||||
|
||||
1. Acknowledge within 5 working days.
|
||||
2. Triage and confirm severity within 10 working days.
|
||||
3. Develop and test a fix.
|
||||
4. Publish an advisory and credit the reporter unless they prefer
|
||||
to remain anonymous.
|
||||
|
||||
## Supported versions
|
||||
|
||||
| Version | Supported |
|
||||
|---------|-----------|
|
||||
| 1.x | Yes |
|
||||
| < 1.0 | No |
|
||||
|
||||
## Advisories
|
||||
|
||||
Security-relevant changes are noted in [CHANGELOG.md](CHANGELOG.md).
|
||||
29
docs/review-2026-06-20.md
Normal file
29
docs/review-2026-06-20.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Plugin review — human-friendly-style (2026-06-20)
|
||||
|
||||
> Full-depth review (part of the marketplace-wide sweep; pilot was okr). Tooling: config-audit
|
||||
> v5.4.0 scanners (from source) + llm-security posture assessor + structure/version checks.
|
||||
> Read-only; this file is the only artifact.
|
||||
|
||||
## Verdict
|
||||
|
||||
**Clean, grade A — essentially no attack surface.** A metadata-only manifest plus one output-style
|
||||
markdown; no commands, agents, skills, hooks, MCP, or dependencies. Nothing actionable.
|
||||
|
||||
## Results by dimension
|
||||
|
||||
| Dimension | Result |
|
||||
|-----------|--------|
|
||||
| config-audit posture | **A** (Feature Coverage F 17 — expected: an output-style uses almost no CC features; opportunity, not a defect) |
|
||||
| config-audit plugin-health | **0 findings** |
|
||||
| llm-security posture | **A** — no findings (1 INFO). The only real vector (an output-style edits the system prompt) was reviewed line-by-line + byte-scanned: tone-only, `keep-coding-instructions: true`, no hidden/encoded/scope-expanding directives. Hidden-char scan clean (only em-dashes). |
|
||||
| structure / hygiene | README ✓, CHANGELOG ✓, CLAUDE.md ✓, LICENSE ✓ |
|
||||
| version consistency | **OK** (gate) |
|
||||
|
||||
## Findings
|
||||
|
||||
- **INFO** — `output-styles/human-friendly.md:21-27` — hide-by-default directives reduce visibility
|
||||
into routine tool output. This is the stated purpose, reversible on request (L29), and carved out
|
||||
for irreversible actions (L32-33). Not a defect; no remediation.
|
||||
|
||||
The irreversible-action carve-out (forces verbatim display of destructive commands) is a net
|
||||
security positive.
|
||||
Loading…
Add table
Add a link
Reference in a new issue