agent-plugin-builder

Links

• github.com/pproenca/dot-plugins
• plugins/agent-plugin-builder/plugin.json (manifest)

Skills · 1

agent-plugin-builder

Build plugins that conform to the Agent Plugins Specification v1.0.0: a plugin.json manifest plus skills/ and mcp.json components: and verify them with a bundled conformance validator. Use this skill whenever the user wants to create, scaffold, package, or fix an agent plugin; mentions plugin.jso…

Descriptions come from the frontmatter of each SKILL.md, punctuation lightly normalized.

Category

Agent Tooling. Assigned by this directory. Agent Plugins 1.0.0 has no category field, so no manifest declares one.

Keywords

agent-plugins · specification · conformance · validator · scaffolding

Related by publisher and keywords

• domain-mappingpproenca

  Discover business domains through EventStorming, evidence, recursive questions, and conformance checks.

• ontology-forgepproenca

  Design and extend a Palantir Foundry ontology the domain-driven way: interview the domain, shape object types, links, interfaces and actions, then map source data and logic onto them.

• swarm-forgepproenca

  Disciplined tmux-based agent orchestration: pick a pack of specialist agents, give each its own git worktree, and drive them from a local web cockpit.

• swarm-forge-squadpproenca

  The SwarmForge squad workflow: a persistent squad leader that spawns short-lived specialist workers on demand, each bound by a capability contract.

• macstack-devAgents-Store

  Turns what a client says into documents they can correct, a machine spec an agent can build from, and a work list somebody can pick up. Keeps the macstack/ folder of a project: macstack.json, the standardized business + technical stack specification, always English, and the six client documents it is written from. OVERVIEW says what the product is and who it is for; USER-CASES carries each case with its UX bar and an addressable acceptance list; UX-UI states what each screen shows and what must never appear on it; AUTOMATION is the trigger -> task -> workflow -> role model; HANDBOOK is how a person actually uses the thing; OPEN-QUESTIONS splits what the client owes from what the team deferred. v3 makes those six pure markdown: headings and bullet lists, nothing else. No YAML blocks, no tables, no change-log sections: the only machine markup is an HTML comment the reader never sees, pointing each entity at its place in the spec. A client can edit the document in any editor and hand it back. Around them: an immutable inbox for anything a client sends, a gated delta/rulings loop that merges it, generated requirements, architecture, test cases and index that carry every id the client documents carry, an append-only ledger with one row per edit and per client comment, tasks reconciled with the team's own tracker, and a review package that shows each statement with its own history and reads the client's answers back into the ledger. Eight commands, one job each: including one that reconciles the whole folder against the source tree in a direction you have to declare: the code is master and every document is corrected through a gate that never silently overrules an answer the client gave, or the documents are master and the gaps become tasks. Every edit is journalled, every finished task sweeps the client documents and not only the generated ones, task statuses move to what the audit actually found, closing what is built and reopening what is not, and every document carries the date it was last checked against the code, so a document that reads perfectly cannot quietly describe a system that no longer exists.

• agentic-bundle-aas-accessibility-inclusive-uxsickn33

  Portable skills-only "AAS Accessibility & Inclusive UX" plugin from Agentic Awesome Skills.