## Why
agent-author produces agents/sources.md at plugin scope to record which
research sources informed which agent files. agent-audit had no way to
validate this chain, leaving stale or missing provenance undetected.
## Implementation Notes
Validation is per-pair (the given agent file + its counterpart) rather
than plugin-wide, keeping the scope consistent with validate.sh. The
script exits 0 silently for non-plugin-scope agents.
source_keys is top-level in both CC .md and Copilot .agent.md files
(not under metadata:) to avoid conflict with Copilot's own metadata
field semantics. Checks 0, 1, 2, 4, 5, 6 mirror the skill provenance
set; upstream research-doc cross-reference checks (7, 8) are deferred.
agent-author Steps 2, 3, and 4 updated to formally specify the
agents/sources.md format and instruct authors to add source_keys to
both files when research sources are in context.
Refs: #60
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147vXtL5sP6vorDdqXGJJU9
## Why
The last acceptance criterion from #11: agent-author's close step should
reference agent-audit so authors are prompted to validate the pair before
shipping, matching the pattern skill-author uses with skill-audit.
Refs: #11
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147vXtL5sP6vorDdqXGJJU9
## Why
agent-author produces paired agent definition files (Claude Code .md +
Copilot .agent.md) but had no companion audit skill to validate them.
agent-audit fills that gap, giving the same structured PASS/FAIL report
that skill-audit provides for SKILL.md files.
## Implementation Notes
- validate.sh uses scope detection (walk up for plugin.json / .git) to
locate the counterpart file and determine whether plugin-silently-ignored
fields (hooks, mcpServers, permissionMode) should be flagged
- CC-only and silently-ignored field lists are read from
references/field-inventory.md at runtime rather than hardcoded —
provenance back to the research corpus; see ADR-0019
- Single-file invocation (pass either file, counterpart derived) chosen
over directory or name+root — see ADR-0018
- 12 bats tests cover provider detection, scope detection, all FAIL paths,
and clean-pair pass
## Impact
- kyberforge bumped to v1.1.2
- agent-author close step should be updated to reference agent-audit (#11)
- Provenance/sources chain check deferred to #60
ADR: docs/adr/0018-agent-audit-single-file-invocation.md
ADR: docs/adr/0019-agent-audit-field-inventory-reference.md
Refs: #11
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147vXtL5sP6vorDdqXGJJU9
## Why
The existing kyberforge research covered skills vs agents (ADR-0010),
Copilot track selection, and agent scope hierarchy — but had no documented
basis for three practical decisions: when to use MCP servers vs skills vs
agents, when hooks are the right tool vs skills, and when bin/ is
appropriate vs scripts/ inside a skill directory. Without this, the
plugin-author and agent-author skills have no research backing for those
choices.
## Implementation Notes
Sourced from official Claude Code plugin docs (code.claude.com), official
GitHub Copilot CLI docs (docs.github.com), and the Copilot
customization-cheat-sheet and comparing-cli-features pages — the latter
containing the only official "putting it together" decision table across
components. Context7 MCP was the primary retrieval mechanism; web reads
deepened the hooks and bin/ content.
Three files produced:
- overview.md — mental model, component roles, cross-provider portability
- decision-guide.md — explicit decision tables for all three gaps,
including anti-patterns and Copilot surface support matrix
- hooks.md — full lifecycle event reference, stdin/stdout schema,
hookSpecificOutput per event, plugin scope restriction
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0147vXtL5sP6vorDdqXGJJU9
## Why
The repo moved from a chunk-based delivery model with `.agents/skills/`
as the canonical skill source to a plugin model. Several files retained
references to the old model that were either dead code or misleading
framing.
## Impact
- `tests/test-install.sh`: dead `.agents/skills/` test blocks removed;
suite now tests only what `install.sh` actually deploys
- `scripts/deploy-manifest.sh`: `DEPLOY_SKILLS_SRC` variable and stale
`sync.sh (Chunk 6)` comment removed
- `tests/test-git-hooks-install.sh`: fixture stub no longer declares
the removed `DEPLOY_SKILLS_SRC` variable
- `docs/VISION.md`: chunk delivery framing replaced with plugin model
language throughout; manual test plan date updated
- `tests/test-instructions-and-docs.sh`: stale test plan date flagged
as pre-refactor so readers know a re-run is needed
Refs: #15
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
overview.md described the chunk-based delivery model, which is superseded
by the marketplace/plugin pivot. architecture.md was equally stale: it
described .agents/skills/ as the canonical skills source (directory does not
exist), a provider-manifest.sh symlink mechanism (never built), and sync.sh /
init-project.sh as existing scripts (Chunk 6, not yet built).
## Implementation Notes
- overview.md deleted; all cross-references scrubbed from AGENTS.md, CONTEXT.md,
and three notes/research files
- architecture.md fully rewritten: content deployment model reflects actual
install.sh behaviour (DEPLOY_FILES / DEPLOY_EXECUTABLES / DEPLOY_DIRS);
plugin model section added listing all 5 plugins; directory structure section
removed (was describing a layout that no longer exists)
- "Chunk 6" phase label → "planned"; "chunk workflow" removed from AGENTS.md
description
- Fixed broken path docs/HUMANS.md → docs/wiki/HUMANS.md in governance layer
and core/instructions/governance.md
Refs: #15
## Why
ROADMAP.md was a static file that duplicated tracking information now
owned by Gitea milestones and issues. Keeping it created a maintenance
burden — references drifted out of sync with the actual state of work,
and agents were directed to read it when the source of truth had moved.
## Implementation Notes
All inbound references replaced with either the relevant Gitea milestone
("Skills & Agents") or removed where the context made them redundant.
Test assertions that verified ROADMAP.md content removed; test output
strings updated to drop the ROADMAP cross-reference instruction.
## Impact
Agents no longer read docs/ROADMAP.md at session start. Gitea milestones
and issues are the canonical source for roadmap and open-question tracking.
---
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
The ## Key rules section was intentionally removed from AGENTS.md as
redundant. Two test assertions — one requiring its presence in AGENTS.md
and one confirming it was absent from CLAUDE.md — are now stale and block
pushes.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
The WARNING admonition blocks in CLAUDE.md and providers/claude-code/CLAUDE.md
added noise without adding clarity — the file paths already communicate which
config is which. The "Key rules" block in AGENTS.md duplicated guidance already
present in the content index above it.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
Structure section listed .claude-plugin/, docs/, scripts/, tests/ —
all either obvious or carrying stale annotations (Chunk 6, sync.sh).
HUMANS.md path updated to docs/wiki/ after the wiki move. sync.sh
key rule removed since the script doesn't exist yet.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
CONTEXT.md had grown stale and noisy after the plugin/Gitea pivot.
Working context section duplicated AGENTS.md verbatim; Skills entry
still described the defunct .agents/skills/ direct path; several
glossary entries carried stale "Chunk 4" / "Chunk 6" framing from the
superseded delivery model.
## Impact
- Working context principle removed (live copy is in AGENTS.md)
- Skills glossary is plugin-only (direct path confirmed absent from repo)
- Skill composition, AGENTS.md glossary, and Bidirectional reference
principle no longer reference chunk numbers
Refs: #15
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
Part of issue #15 (refactor: align repo with marketplace/plugin model).
docs/issues/ and docs/prd/ are gone; Gitea is now the canonical tracker
(ADR-0017). LESSONS.md glossary entry needed to survive the upcoming
ROADMAP.md slim-down.
## Impact
- Docs convention no longer lists docs/prd/ or docs/issues/ naming entries
- NNNN explanation scoped to ADRs only
- Provider-agnostic issue tracker entry drops file-based-phase language
- LESSONS.md has a first-class glossary entry
Refs: #15
ADR: docs/adr/0017-gitea-canonical-issue-tracker.md
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Issues 0001–0018 migrated as closed; 0019–0028 as open. All assigned to
the Legacy / Triage milestone (ID 5). Closes item 1 of issue #15.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
Two test suites were asserting on paths that were intentionally changed:
- docs/HUMANS.md moved to docs/wiki/HUMANS.md (wiki submodule)
- docs/prd/ deleted after migrating all PRDs to Gitea (#16–#19)
Updated checks to assert the new locations and confirm the old
directories are gone.
---
Refs: #15
## Why
HUMANS.md is practitioner-facing reference material, not a file agents
read from the repo. It belongs in the Gitea wiki where it is browsable
via the wiki UI. Removing it from docs/ keeps the repo tree clean.
## Impact
docs/HUMANS.md is gone from the main repo. The file is accessible at
the Gitea wiki (docs/wiki submodule, commit 5c29e79).
---
Refs: #15
## Why
All four PRD files (chunk-1, chunk-2-instructions, chunk-3-skills-library,
governance-instruction-layer) have been migrated to Gitea as closed issues
(#16–#19) in the Legacy / Triage milestone. The local directory is
superseded as an artifact store.
## Impact
docs/prd/ is gone. Gitea issues #16–#19 are the canonical record.
---
Refs: #15
## Why
Without this guard, the agent could bypass the skill and call Gitea MCP
tools directly, skipping owner/repo resolution and label-ID normalization.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Supersedes ADR-0011 (provider-agnostic issue tracker with file-based
default). Gitea MCP is now configured and in active use; the file-based
fallback is removed. All local docs/issues/ files will be migrated to
Gitea as part of the great refactoring (issue #15).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add --autofix to pretty-format-json so the hook rewrites files in place
rather than requiring manual intervention. Also applies the resulting key
ordering fixes to settings.json files.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
The hook was treating all source values as local directory paths. Remote
sources (github/git/npm objects) have no local directory — the jq -r of
a JSON object produced garbage, causing the hook to fail on push after
adding the mattpocock-skills remote plugin.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
The UPDATE flow only bumped version when the version field itself was the
target. Metadata changes (description, keywords, author) went out without a
version bump, making them invisible to consumers with a cached copy.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
Same gap as skill-author: no instruction to bump the plugin version after
creating or modifying an agent inside a plugin.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
README "What it does" didn't reflect the plugin version bump step added
to both create and improve flows.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
The skill had no instruction to bump the catalog version after ADD, REMOVE, or UPDATE operations. Clients cache the marketplace catalog and use the version field to detect changes — without a bump, the new state is invisible until a forced refresh.
## Implementation Notes
Added a Gotcha explaining the rule and semver convention (ADD/REMOVE → minor, UPDATE → patch). Added a dedicated "Bump catalog version" step to each mutating flow. Updated README to match.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
Register mattpocock/skills as an installable plugin in the holocron marketplace so users can install it with `claude plugin install mattpocock-skills@holocron`.
## Impact
Marketplace bumped from 0.1.1 → 0.2.0 (minor; new plugin entry is a backward-compatible addition).
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
check-manifests.sh requires all paths declared in plugin.json to exist.
Adds empty hook and MCP server stubs matching kyberforge convention.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
The Obsidian MCP server config was living at the repo root, making it
a repo-level concern rather than part of the plugin it belongs to.
Moving it into plugins/bin/ means the plugin is self-contained and the
server travels with it on install.
## Implementation Notes
mcpServers is declared in the Copilot manifest (plugin.json) because
Copilot requires explicit path declarations. CC auto-discovers .mcp.json
from the plugin root so no change to the CC manifest is needed.
Bumps version to 1.0.3 in both manifests.
---
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Both skills are now part of the kyberforge plugin. Updated the Plugin
marketplace workstream Phase 1 skill list and the Skills pipeline
housekeeping note (count 4 → 6) to reflect the addition.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Both skills exist on disk but were missing from the plugin README and the
skills/ directory README. Adding them so the listings stay consistent with
the actual skill set.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
Several small quality issues accumulated across plugin-author and
marketplace-author: the plugin-author description was ambiguous about
scope, the ADD flow asked an unnecessary clarifying question when local
path is the obvious default, VALIDATE had redundant wording already
captured inline, the keywords field was missing from the validation
checklist, and tests/README.md was a placeholder with nothing to test.
## Implementation Notes
- plugin-author: tightened description scope to "inside those
directories"; added `keywords` identical-in-both-manifests check to
VALIDATE checklist.
- marketplace-author: moved reserved-prefix constraint from gotchas
into the ADD checklist item; replaced the four-option prompt with a
default+escape-hatch ("I'll treat this as local path — is that right?");
folded the validate-from-root note inline and removed trailing padding;
deleted tests/README.md — no scripts/ directory exists, so the
placeholder was noise.
- README.md: removed the tests/README.md row from the file table.
## Why
The original rule said "prefer subagents" but gave no guidance on when to
run them in parallel vs. sequentially, or when to invoke a relevant skill.
This closes the ambiguity so agents make correct scheduling decisions without
having to reason it out from first principles each time.
## Why
Version sync across all plugin manifest locations so the CC plugin loader,
the .github marketplace mirror, and the canonical plugin.json files all
report the same version.
## Impact
Consumers fetching the plugin via the marketplace will see the updated
version entry.
## Why
The manifest-fields tables in both skills used imprecise labels ("CC-only",
"Copilot-only") that conflated two distinct reasons a field appears in only
one manifest: platform constraint (the other tool does not support the field
at all) versus repo convention (both tools support it, but the scaffold places
it in one manifest by design). This caused agents to treat convention
boundaries as hard platform constraints, producing unnecessary errors when
updating manifests for dual-tool repos.
Provenance was also incomplete: sources.md files were missing entries for
sources that had been consulted and were already contributing to SKILL.md
and manifest-fields.md content, making the evidence chain unverifiable.
## Implementation Notes
Field classification now uses three explicit categories — shared, platform
(one tool does not support the field), and convention (both tools support it;
scaffold places it in one manifest by design). The distinction matters because
convention fields may legitimately appear in the other manifest when there is
a deliberate reason; platform fields may not.
New gotchas added to plugin-author: agent files silently ignore hooks,
mcpServers, and permissionMode frontmatter; claude plugin tag --push requires
a clean working tree; --dry-run preview before tagging; --strict flag on
validate. New gotchas in marketplace-author: metadata object as Copilot CLI
canonical location for top-level fields; strict: false for dual-tool plugins;
sha takes precedence over ref for pinning; --strict flag on validate.
tests/ removed from plugin-author because new-plugin.sh has no branching
logic warranting a bats suite at this stage.
## Impact
Skill prompt changes only — no runtime code affected. Agents using these
skills will now correctly distinguish convention from constraint when deciding
which manifest to update for a given field.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
Plugin and marketplace management had no governed authoring path. Creating or
updating a plugin required knowing the dual-manifest convention, version parity
rules, and directory skeleton by memory — nothing enforced consistency or guided
the process.
`/plugin-author` closes that gap by owning the full plugin scaffold lifecycle:
create, update, rename, and release. `/marketplace-author` handles the
marketplace-facing side: register, deregister, and update plugin entries in
`marketplace.json`.
ADR-0016 codifies the version parity convention (identical `version` in both
`plugin.json` and `.claude-plugin/plugin.json`) that `/plugin-author` now
enforces. The two plugin.json files in this repo are backfilled to comply
(keys also sorted to pass the pretty-format-json hook). CONTEXT.md gains
glossary entries for "plugin scaffold" and "version parity" so future agents
have shared vocabulary for these concepts.
## Implementation Notes
`/plugin-author` ships a `scripts/new-plugin.sh` scaffold script that generates
the directory skeleton and both manifests in one shot; the skill calls the script
rather than generating files ad hoc so the scaffold is reviewable and repeatable.
Version parity is an invariant, not a suggestion — the skill will fail loudly
on create/update if the two versions would diverge.
ADR: docs/adr/0016-plugin-version-parity.md
## Why
Five gap areas were identified when auditing the config against tracked file extensions and the hooks reference:
- No TOML validator despite 2 `.toml` files tracked
- No Python AST check despite 10 `.py` files tracked
- No merge-conflict marker detection
- No PEM private key block detection (gitleaks covers high-entropy strings but not raw PEM)
- No meta-validation to catch hooks that match no files or useless exclude patterns
## Impact
All five new hooks pass on `--all-files` run.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P87CiC58Ru2PPWYTeXtjHT
Installing kyberforge via the holocron marketplace caches the plugin at a
specific version. After every push, the marketplace clone and plugin cache
need to be refreshed manually — otherwise new skills added since the last
install are invisible until the user runs `claude plugin update` manually.
Adds a post-push git hook that pulls the holocron marketplace clone and
updates the kyberforge cache automatically after every push, eliminating
the manual refresh step.
## Implementation Notes
- `scripts/git-hooks/post-push` is the canonical source; `install.sh` now
copies all files in `scripts/git-hooks/` into `.git/hooks/` on fresh
checkouts, making the pattern extensible for future hooks.
- Hook exits 0 on all failures (warns to stderr) — a stale cache refresh
never blocks a completed push.
- 11 bats tests cover both the hook and the install.sh copy block, using
mocked binaries and a temp-tree fixture to avoid touching real state.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P87CiC58Ru2PPWYTeXtjHT
## Why
Plugin cache is keyed by version string. Adding pc-author and pc-run
skills requires a version bump so claude plugin update resolves a new
cache directory and picks up the new skills.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P87CiC58Ru2PPWYTeXtjHT
## Why
Pre-commit config management was entirely manual — no skill existed to
help create, modify, or validate `.pre-commit-config.yaml`, or to run,
install, and maintain the pre-commit setup. These two skills close that
gap with clear scope separation: authoring vs. execution.
## Implementation Notes
- `pc-author` owns `.pre-commit-config.yaml` only (no hook publishing,
no install). Runs `pre-commit validate-config` after every write.
Shallow file-extension scan drives proactive hook recommendations;
rev staleness is flagged against `references/hooks-by-language.md`
rather than hardcoded versions. Remove path reverts on failure.
- `pc-run` owns install, run, autoupdate, gc, and clean. Defaults to
`--all-files`. Install warns about existing `.git/hooks/` files being
overwritten by `-f`. Clean requires HITL confirmation. Failure
interpretation delegates to `references/failure-patterns.md`.
- Provenance wired to `plugins/kyberforge/docs/research/docs/pre-commit/`.
- Both skills resolve via the existing `"skills/"` glob in `plugin.json`.
## Impact
Two new slash commands available after `claude plugin install kyberforge@holocron`:
`/pc-author` and `/pc-run`.
Refs: #12
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P87CiC58Ru2PPWYTeXtjHT
## Why
The root marketplace.json is the index that ties all plugins together.
claude plugin validate --strict covers schema-level checks that
check-manifests.sh does not, so it warrants its own hook alongside
validate-plugins.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Why
`claude plugin validate --strict` catches structural issues in plugin
manifests that `check-manifests.sh` does not cover (e.g. schema
violations, unrecognised fields). Running it at pre-push ensures all
plugins in `plugins/*/` stay valid before reaching the remote.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
