feat: establish plugin architecture and add tinystruct developer skill

[m0ver]

What problem are you trying to solve?

I wanted to add comprehensive developer expertise for the tinystruct Java framework to the repository. However, a "flat" one-file approach in the skills/ directory was problematic because:

1. Clutter: Domain-specific skills (like Java frameworks) mixed with core process skills (like TDD) make the library harder to navigate.
2. Inefficiency: A single 370+ line document burns excessive context tokens and can cause models to "shortcut" the documentation.
3. Missing Pattern: The project lacked a standardized location for technology-specific extensions.

What does this PR change?

This PR introduces a Modular Plugin Architecture and adds the Tinystruct Development Skill as its first reference implementation:

• Infrastructure: Created a plugins/ directory and updated .cursor-plugin/plugin.json and .claude-plugin/marketplace.json to support auto-discovery of plugin-based skills.
• Modular Skill Design: Instead of a "mega-file," the core SKILL.md is focused on triggers and high-level rules, while detailed technical guides (Routing, JSON, Testing) are contained in a references/ subdirectory.
• Governance: Established the architectural split in the README.md: skills/ for methodology (Process) and plugins/ for tech-stacks (Technology).

Is this change appropriate for the core library?

Yes. It provides a scalable way to grow the library's technical expertise (Java, Backend, etc.) while keeping the Core Methodology clean and focused. It follows the guidance in CLAUDE.md that domain-specific skills belong in standalone structures.

What alternatives did you consider?

• Adding tinystruct-development.md to skills/: Rejected. It becomes too large to be effective and dilutes the core process-oriented focus of the skills/ folder.
• Creating a separate repository: Considered, but keeping the technology plugins alongside the core processes allows for tighter integration and easier maintenance for contributors.

Does this PR contain multiple unrelated changes?

No. The infrastructural changes (Plugin folder) were created specifically to enable the scalable addition of the tinystruct skill.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: "none found"

Environment tested

Harness (e.g. Claude Code, Cursor)	Harness version	Model	Model version/ID
Gemini CLI	N/A	Gemini	3 Flash

Evaluation

• Outcome: By using the references/ split, the agent only loads heavy technical documentation when explicitly mapping routes or handling JSON, saving ~300 lines of context per turn during general conversation.
• Discovery: Verified that the new plugins/ path is correctly recognized by the agent's skill activation tool.

Rigor

• I used superpowers:writing-skills patterns to ensure the new skill uses "Use when..." triggers.
• Added "Red Flags" and "Pitfalls" tables to ensure the skill enforces framework-specific discipline (e.g., using the framework-native JSON Builder).

Human review

• A human has reviewed the COMPLETE proposed diff before submission