本文へ移動
cccskills
無料GitHub で公開

storytelling-ethics-lifecycle

Steward public stories about any work — creation ethics, application ethics, and maintenance of the story plus its disclosures (generated, drafted, curated, authored). Use when writing a public article, origin story, talk, README narrative, or showcase about how work was made; when publishing ethics and decisions; or when asked who generated vs curated a text. Do not use for ADRs, FAQs, skill citations, or marketing hype.

インストール方法を見る

含まれるファイル(7)

  • SKILL.md10.6 KB
  • evals/cases/adr-not-story.yaml389 B
  • evals/cases/public-story-trigger.yaml729 B
  • references/disclosure-template.md1.5 KB
  • references/evals.md916 B
  • references/role-ledger.md2.2 KB
  • references/sources.md2.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Storytelling Ethics Lifecycle

Steward the public story of work — not the product behavior, and not a writing workshop.

A story here is any public narrative about how and why something was made: an article, talk, origin note, showcase, or README section. It may sit next to code, ethics, and decisions. It must not replace them.

This skill is domain-agnostic. It applies to a repository, a paper, a talk, a design, a game, or a test project. It owns three loops that must stay together:

  1. Ethics of creation — who may be named, what may be invented, whose voice is used.
  2. Ethics of application — what the story is used to claim, sell, teach, or hide.
  3. Maintenance of the art and its ethics — keep the story true, short, and disclosed as facts change.

Philosophy is not enough. The mechanics are a role ledger, a disclosure block, and a hygiene pass. Role vocabulary lives in references/role-ledger.md. The public block lives in references/disclosure-template.md.

Trigger examples

  • Should trigger: "Write a public story of how this repository was created."
  • Should trigger: "Disclose what was generated vs curated in this article."
  • Should trigger: "We are publishing our ethics and decisions — tell that story honestly."
  • Should not trigger: "Write an ADR for this accepted decision." Use repository-governance-lifecycle.
  • Should not trigger: "Add citations to this skill." Use skill-source-citations.
  • Should not trigger: "Write launch copy to grow signups." This skill refuses hype.

Do not own

NeedOwner
Lock a product or architecture decisionrepository-governance-lifecycle (ADR/FAQ)
Cite research inside a skillskill-source-citations
Steward personality vs tool-modesteward-continuity-boundary-lifecycle · ADR 0020
Vision still worth buildingvision-alignment-foresight
Behavior of the productCode, tests, schemas in the owning project

A story may point at those surfaces. It must not become a second implementation.

Workflow

1. Decide whether a story should exist

Ask, in order:

  1. What public job does this narrative do (teach a process, disclose collaboration, show a test, record a refusal)?
  2. Is the durable fact already an ADR, FAQ, test, or evidence record? If yes, the story links there.
  3. Who is the audience (future maintainer, stranger on DEV, student, client)?
  4. What must remain unpublished (private threads, unconsented names, secrets, unearned claims)?

Refuse a public story when the only motive is unearned credit, hiding model work, inflating a test into "production success", or paraphrasing code as if the story were SSOT.

If the user wants a decision locked, stop and route to repository-governance-lifecycle.

2. Name purpose, audience, and non-claims

Write four lines before any prose:

  • Purpose — one sentence.
  • Audience — who it is for.
  • Vehicle — what the work is (a shortener, a library, a talk) vs what the story shows (a process, a test, a refusal).
  • Non-claims — what this story will not say.

Example non-claim: "This is not 'AI built a production product in a day'."

3. Build the role ledger

For every public artifact in the story (words, images, diagrams, code excerpts, quotes), assign one role from role-ledger.md.

Minimum roles:

RoleMeaning
authoredA named human wrote these words as their own
draftedA model produced a first text from given sources
curatedA named human reviewed, corrected, accepted, or refused
generatedA model produced a published artifact (text, image, code)
transcribedExisting speech or text recorded without new invention
quotedSomeone else's words, attributed
refusedAsked for and not done, or done then withdrawn
unknownCannot honestly assign a role — say so

Do not collapse drafted + curated into authored. Do not collapse a human lock ("we refuse multi-tenancy") into "the model decided".

If the story is itself drafted by a model in a human's article style, the ledger must say that in those words.

4. Creation-ethics gate

Run all of these before drafting:

  1. Consent to be named. Living people, teams, and clients appear only with permission or from already-public work they chose to publish.
  2. No invented biography. Do not give the human motives, feelings, or a childhood they did not state.
  3. Private threads stay private unless the human points at a public share or asks to publish a specific excerpt.
  4. Voice. Writing "in someone's style" is allowed only when that person asked for it and the disclosure says so. It is not the same as them having written it.
  5. Others' work. Quotes and prior articles are quoted, with links. Do not absorb them as the new story's original insight.
  6. Secrets. No keys, private URLs that were not meant to be public, unreleased client names, or raw dumps of private chats.

Fail any item → stop, ask, or omit. Do not write around a failed gate.

5. Draft the story (the art)

Keep the art small and durable:

  1. Open with purpose and honesty, not suspense that hides authorship.
  2. Tell how and why, in time order of decisions, not a feature tour.
  3. Prefer one concrete incident (a first real use, a refused feature, a changed ADR) over slogans.
  4. Link to behavior and decisions. Do not re-implement them in prose.
  5. Match the host form (DEV post, talk script, repo docs/articles/) without changing the ledger.
  6. Banned tone: marketing hype ("unlock", "revolutionary", "ultimate", "supercharge"). See governance brand rules when the host is a Skill Steward–governed repo.

The art is restraint: enough scene to be human, not enough invention to become false.

6. Application-ethics gate

After a draft exists, ask what the story will do in the world:

  1. Use. Teaching, disclosure, and process-sharing are in scope. Growth hacking, unearned authority, and "we are the future of X" are not.
  2. Test vs product. If the work is a test, showcase, or dogfood, say so in the first screen of the story.
  3. Credit. Human curation is credit. Model draft is credit. Neither may steal the other's.
  4. Decisions. Publishing ethics and ADRs is good. Publishing them as if they were universally proven law is not.
  5. Audience harm. Do not expose a person, community, or client to risk for a better anecdote.
  6. Host rules. Follow the publication platform's disclosure norms and this ledger. The stricter rule wins.

7. Attach the disclosure block

Put the disclosure template at the start (preferred) or end of every public story. Minimum fields: who drafted, who curated, what was generated, what sources were used, what the story is not.

If the story later changes, update the ledger and the block in the same edit.

8. Place the story without replacing SSOT

PlaceAllowed
docs/articles/, talks, DEV, a showcase pageYes — mark as story, not SSOT
README / AGENTS mapOne link, not the full narrative
ADR / FAQOnly a pointer: "the public story is X"
Product behavior docsNo — those stay why/how/code

In a governed repo, add a short FAQ ("Why is there a story?") via repository-governance-lifecycle. Do not copy the article into the FAQ.

9. Maintain the art and the ethics

Stories are operational knowledge. They rot.

On any later pass (new fact, new publish, new language):

  1. Walk the claims. Every factual sentence must still be true or become a dated historical sentence.
  2. Walk the ledger. Roles change when a human rewrites a section by hand, or when a new image is generated.
  3. Keep it from becoming a spec. If the story starts teaching encoder details, move that to FAQ/code and shrink the story.
  4. Keep it from becoming a diary. Delete scenes that no longer serve the purpose.
  5. Re-run both ethics gates when audience or use changes (internal note → public DEV post).
  6. Archive or unpublish when the story is no longer honestly tellable.

This is the same hygiene as deleting a finished plan: extract what is durable, then stop growing the narrative.

Output format

## Story decision
{tell | do not tell | route to ADR/FAQ/evidence}

## Purpose / audience / vehicle / non-claims
...

## Role ledger
| Artifact | Role | Who | Notes |
|----------|------|-----|-------|

## Creation-ethics
{pass | blocked: reason}

## Application-ethics
{pass | blocked: reason}

## Disclosure block
{filled template}

## Story
{draft, or "not written — blocked"}

## Placement
{path or host}

## Maintenance
{what would make this story false; when to walk it again}

Anti-patterns

Anti-patternCorrection
"I wrote this" when a model drafted itdrafted + curated
"The AI decided we refuse tenants"Human lock; model executed
Story as second specLink ADR/FAQ/code
Private chat pasted as "transparency"Consent + public share only
Style imitation presented as authorshipDisclose style + curator
Test project told as production triumphName the test in paragraph one
Hype words to carry a weak processCut the words; keep the incident
Disclosure once, then silent editsLedger and block update together
Separate "ethics essay" with no ledgerThis skill is invalid without mechanics

Related skills

TaskSkill
Lock decisions, FAQs, charterrepository-governance-lifecycle
Skill research citationsskill-source-citations
Steward vs tool identitysteward-continuity-boundary-lifecycle
Vision still worth the storyvision-alignment-foresight
Multi-lens critique of a draftmixture-of-experts

Install

npx skills add arenukvern/skill_steward --skill storytelling-ethics-lifecycle

Sources

See references/sources.md. When researching, follow skill-source-citations.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design, implement, and integrate generalized validation harnesses across a producer-consumer boundary after a local harness contract exists. Use when refactoring custom validation CLIs/MCPs for large polyrepos, extending Steward across sibling repos, or deploying a local tool to a consumer project for dogfooding and testing; use mcp-harness-repo-maintainer first for initial steward.yaml adoption and cold-start proof.

日本語の概要は準備中です。原文の説明を表示しています。

Arenukvern/skill_steward112026年9月24日 更新

Maintains repo-local action contracts and harness repositories where product CLI and MCP adapters stay thin over core libraries. Use when adopting or improving steward.yaml actions, capability-level adoption evidence, cold-start proof loops, probes, benchmarks, CLI/MCP/core parity, adapter refactors, packages/core boundaries, or sibling harness layout; use repo-quality-system-lifecycle first for general app/library/tool stewardship baselines.

日本語の概要は準備中です。原文の説明を表示しています。

Arenukvern/skill_steward112026年9月24日 更新

Run a Mixture of Experts (MoE) audit on any topic, plan, codebase, evidence archive, or process. Dynamically spawns specialized subagents with different critical lenses to cross-reference findings and detect flaws, overlap, retention issues, or drift. Use when designing architectures, analyzing complex code, verifying multi-step plans, classifying evidence artifacts, or looking for duplicated intent in a repo.

日本語の概要は準備中です。原文の説明を表示しています。

Arenukvern/skill_steward112026年9月24日 更新

Plan and document handoffs, parent lane contracts, and parallel batch contracts between specialized AI agents (foreman, workers, reviewers). Use for multi-agent workflows, subagents, original goal preservation, native gates, claim ceilings, terminal states, baton passes, or guild-style agent coordination.

日本語の概要は準備中です。原文の説明を表示しています。

Arenukvern/skill_steward112026年9月24日 更新

Designs public or private Agent Skill and plugin marketplaces for Cursor, Claude Code, Codex, Zed, Open Plugin, and npx skills—manifest layout, install matrix, and Skill Steward vs product boundaries. Use when setting up a marketplace, distributing skills/plugins to a team, private registry, .cursor-plugin, .codex-plugin, .plugin, .claude-plugin, or skills.sh publishing.

日本語の概要は準備中です。原文の説明を表示しています。

Arenukvern/skill_steward112026年9月24日 更新

Chooses ecosystem-native release and changelog tooling (Changesets, Melos, release-plz) plus binary distribution (GitHub Release tarballs, install.sh) when the product is an executable. Use for release CI, install.sh, versioning, CHANGELOGs, shipping MCP/CLI without clone, or meta repos that only ship skills via npx skills—not domain app tutorials.

日本語の概要は準備中です。原文の説明を表示しています。

Arenukvern/skill_steward112026年9月24日 更新

Arenukvern のスキルをすべて見る

このスキルの問題を報告する