prone-dc302/alterlab-fc-skills

This repository is a content pack for Claude “skills,” not a traditional application. Its architecture is mostly a curated file hierarchy that Claude Code or Claude can load as task-specific instruction modules.

1. Root layer: repository metadata and user-facing docs

- The root contains project governance files (LICENSE, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md), a top-level README.md, and a CLAUDE.md guide.

- These files define how the pack is maintained, distributed, and used, but they do not implement runtime behavior.

2. Primary functional units: individual skill folders

- The real product lives under skills/.

- Each skill is isolated in its own folder and appears to be represented by a single SKILL.md file.

- That makes each skill a self-contained prompt/instruction module that Claude can activate independently.

3. Top-level skill domains as the main architecture boundary

- Skills are grouped into six domain families: cdm, genai, nmc, pra, rma, and vcd.

- These domains act as the coarse-grained architecture layer, separating media-production workflows from research, PR/advertising, visual communication, and new-media tasks.

4. Fine-grained specialization inside each domain

- Within each domain, every subfolder is a specific role or task type.

- Examples include screenwriting, postproduction, media planning, research design, brand identity, podcast production, and voice cloning.

- The architecture is modular: one folder equals one skill, which keeps responsibilities narrowly scoped.

5. Skill content format

- The repeated SKILL.md naming strongly suggests a standardized document format for Claude instructions.

- This means the repository is largely declarative content rather than executable code: the skill files encode behavior through structured guidance, not functions or services.

6. Validation and quality control

- scripts/validate.js is the main automation entrypoint visible in the tree.

- Its role is likely to check repository structure and skill-file consistency before release, acting as a build/QA gate for the content pack.

7. Node-based tooling boundary

- package.json indicates the repo uses a JavaScript/Node toolchain for maintenance tasks.

- The codebase itself is not a JS app; Node appears to support validation or release tooling around the skill files.

8. Distribution model

- The README points users to a GitHub release ZIP, and the tree includes one ZIP artifact in skills/pra/....

- That suggests the repository serves both as source-of-truth and as packaging source for downloadable skill bundles.

9. Runtime consumption boundary

- The intended consumer is Claude / Claude Code, which reads these skill folders from a local skills directory.

- So the execution boundary is external: the repo stores content, while Claude is the runtime that interprets it.

10. Data flow from authoring to use

- Authors edit skill markdown in the domain folders.

- Validation scripts can check the pack.

- A release artifact is published on GitHub.

- Users download, extract, and place folders into Claude’s expected skills location.

- Claude then uses the selected skill when prompted.

11. No backend or database tier

- There is no sign of servers, APIs, persistent state, or data stores in the tree.

- The architecture is file-centric and distribution-centric rather than service-centric.

12. How to diagram it

- Show a root “documentation + governance” layer.

- Show a “tooling/validation” layer around scripts/validate.js and package.json.

- Show six domain clusters under skills/, each containing many independent SKILL.md units.

- Show GitHub release packaging as the distribution path.

- Show Claude/Claude Code as the external runtime consumer.

Overall, this repo is best understood as a modular skill library: organized by media/communications discipline, validated by lightweight Node tooling, and consumed by Claude as local instruction content.