cycle-render

A read-only reporting tool for a YAML file that records development cycles. It turns the recorded history into a timeline chart and a pie chart showing outcome distribution, with optional text or JSON output.

In plain words
What is it for?
Visualising cycle dates, outcomes, lessons, and related corrections from a Mycelium project history file.
Why use it?
It makes cycle history easier to inspect and compare without changing the recorded data.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/haabe/mycelium/cycle-render
Any agent
npx skills add haabe/mycelium --skill cycle-render
Clone the repo
git clone --depth 1 https://github.com/haabe/mycelium

Made for: Claude Code, Codex.

Per session 63 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 4,338 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00063 $0.04338
Opus 5 $0.00032 $0.02169
Sonnet 5 $0.00013 $0.00868
Haiku 4.5 $0.00006 $0.00434

Measured 2d ago against content hash 923d62feddb7, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

cycle-render scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/mycelium/skills/cycle-render/SKILL.md · 294 lines

How it starts

The opening of the file, as written. The whole thing — 294 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Cycle Render

Read-only render of .claude/canvas/cycle-history.yml as gantt + pie + (optionally) json. Third specialist in the render fleet. See ${CLAUDE_PLUGIN_ROOT}/engine/render-conventions.md for shared conventions.

When NOT to use

  • For cross-cutting opportunity→solution→cycle traceability view → dispatcher's /mycelium:render --view traceability (deferred to Phase 4a–4d research-first methodology).
  • To RECORD a new cycle outcome → /mycelium:retrospective, /mycelium:ice-score (on discard), or /mycelium:launch-tier (on launch). This skill is read-only.
  • For framework-health full assessment → /mycelium:framework-health. cycle-render emits one visualization piece; framework-health is the broader audit.

Identifier exposure

Declared: YES

Scope (canvas surfaces touched)

Canvas file Identifier-bearing fields Frequency
.claude/canvas/cycle-history.yml learnings.process prose; learnings.framework prose; related_corrections references mid (cohort-related observation cycles directly reference participants)
$MYCELIUM_ATTRIBUTION_REGISTRY env var (canonical) or .claude/memory/attribution-registry.yml (fallback) people: block with name+consent+note per entry read-only consultation; never rendered

Rationale

Cycle history is reflection-shaped: learnings.process is prose-heavy and often names testers whose feedback drove the cycle (e.g., a cycle entry with leaf_id: ht-014-alex-first-week-observation carries an identifier in the leaf_id itself). Identifier exposure is structural to the learnings narrative, not incidental. Consent state for named cohort testers can shift over time per the consent-state-change-skip cluster (anti-pattern #7 sub-shape #15) — cycle-render re-consults the registry on every invocation, never caches.

Anon-label convention

Per engine/render-conventions.md#anon-label-convention. Numbering shared across the render-fleet session (cohort-tester-N in cycle-003 IS cohort-tester-N in opp-004 evidence if both rendered in one session).

Read the full file on GitHub · 294 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 294 lines · 63 tokens per session scan A 923d62feddb7

Subscribe to this mod's changes

cycle-render is a skill published in the GitHub repository haabe/mycelium (45 stars, last pushed 2d ago), licensed MIT. It adds 63 tokens to every session and 4,338 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

context-manager

Context management skill providing discovery, fetching, harvesting, extraction, compression, organization, cleanup, and guided workflows for project context.

darrenhinde/OpenAgentsControl · 27 tokens

prd-v05-technical-stack-selection

Determine technologies needed to build the product, making build/buy/integrate decisions during PRD v0.5 Red Team Review. Handles both greenfield and brownfield contexts. Triggers on requests to select tech stack, evaluate technologies, make build vs. buy decisions, discover existing assets, or when user asks "what…

mattgierhart/PRD-driven-context-engineering · 151 tokens

prd-v06-architecture-design

Define how system components connect, establishing boundaries, patterns, and integration approaches during PRD v0.6 Architecture. Triggers on requests to design architecture, create system design, define component relationships, or when user asks "design architecture", "system design", "how do components connect?"…

mattgierhart/PRD-driven-context-engineering · 115 tokens

prd-v08-monitoring-setup

Define monitoring strategy, metrics collection, and alerting thresholds during PRD v0.8 Deployment & Ops. Triggers on requests to set up monitoring, define alerts, or when user asks "what should we monitor?", "alerting strategy", "observability", "metrics", "SLOs", "dashboards", "monitoring setup". Outputs MON…

mattgierhart/PRD-driven-context-engineering · 89 tokens

prd-v08-runbook-creation

Create operational playbooks for incident response, deployments, and maintenance during PRD v0.8 Deployment & Ops. Triggers on requests to create runbooks, document procedures, or when user asks "how do we handle incidents?", "runbook", "operational procedures", "on-call guide", "incident response", "maintenance…

mattgierhart/PRD-driven-context-engineering · 87 tokens

prd-v09-feedback-loop-setup

Establish channels and processes for capturing and processing post-launch feedback during PRD v0.9 Go-to-Market. Triggers on requests to set up feedback systems, capture user input, or when user asks "how do we collect feedback?", "feedback loop", "user research", "post-launch feedback", "customer feedback", "NPS"…

mattgierhart/PRD-driven-context-engineering · 94 tokens