How do I install the Faasjs Project Workflow skill?

Run npx skillmds@latest add faasjs/faasjs-project-workflow in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Faasjs Project Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Faasjs Project Workflow?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Faasjs Project Workflow free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Faasjs Project Workflow?

faasjs (@faasjs) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Faasjs Project Workflow by faasjs — Agent Skill

Name: Faasjs Project Workflow
Rating: 4.666666666666667 (3 reviews)
Author: faasjs

Faasjs Project Workflow

Use when creating, configuring, reviewing, or onboarding a FaasJS project; working with create-faas-app, vp CLI, TypeScript or Vite config, feature folders, file and naming conventions, test placement, JSDoc/comments, or complete application slice workflow.

faasjs 2189b6c 10 files · 79.5 KB Updated Sep 10, 2026

File contents

FaasJS Project Workflow

Default Workflow

Read the project config and file layout before adding or moving files.
Keep features as vertical slices with UI, API, database changes, and tests close together.
Follow existing tsconfig.json aliases and Vite/Vitest configuration; do not invent new aliases without matching runtime config.
Place tests in __tests__/ inside the feature or package area they protect.
Use public JSDoc only for package entrypoints or shared exports with non-obvious caller contracts.

Load These References

New project setup or onboarding: references/guidelines/getting-started.md.
Supported stack and framework boundaries: references/guidelines/curated-stack.md.
Complete vertical feature layout: references/guidelines/application-slices.md.
File placement and extraction rules: references/guidelines/file-conventions.md.
TypeScript, Vite, and shared tooling config: references/guidelines/project-config.md.
CLI commands, type generation, migrations, test commands, and environment variables: references/guidelines/cli-and-tooling.md.
Identifier, file, and directory names: references/guidelines/naming-convention.md.
JSDoc and inline comment policy: references/guidelines/code-comments.md.
Shared test-level and mock-boundary rules: references/guidelines/testing.md.

Gotchas

Tests, fixtures, and mocks belong under the relevant __tests__/ directory, not as siblings.
Extract components, hooks, helpers, or abstractions only for reuse, real boundaries, or large bodies.
Do not add comments to untouched code; delete confirmed-dead code instead of leaving markers.
Regenerate derived docs from source rather than editing generated docs directly.

Validation

Run vp check --fix after code or docs source edits when feasible.
Run vp test or a focused vp test <pattern> for behavior changes.
Run npm run doc when guides, source docs, API JSDoc, or docs navigation are affected.

---name: faasjs-project-workflowdescription: Use when creating, configuring, reviewing, or onboarding a FaasJS project; working with create-faas-app, vp CLI, TypeScript or Vite config, feature folders, file and naming conventions, test placement, JSDoc/comments, or complete application slice workflow.---# FaasJS Project Workflow## Default Workflow1. Read the project config and file layout before adding or moving files.2. Keep features as vertical slices with UI, API, database changes, and tests close together.3. Follow existing `tsconfig.json` aliases and Vite/Vitest configuration; do not invent new aliases without matching runtime config.4. Place tests in `__tests__/` inside the feature or package area they protect.5. Use public JSDoc only for package entrypoints or shared exports with non-obvious caller contracts.## Load These References- New project setup or onboarding: `references/guidelines/getting-started.md`.- Supported stack and framework boundaries: `references/guidelines/curated-stack.md`.- Complete vertical feature layout: `references/guidelines/application-slices.md`.- File placement and extraction rules: `references/guidelines/file-conventions.md`.- TypeScript, Vite, and shared tooling config: `references/guidelines/project-config.md`.- CLI commands, type generation, migrations, test commands, and environment variables: `references/guidelines/cli-and-tooling.md`.- Identifier, file, and directory names: `references/guidelines/naming-convention.md`.- JSDoc and inline comment policy: `references/guidelines/code-comments.md`.- Shared test-level and mock-boundary rules: `references/guidelines/testing.md`.## Gotchas- Tests, fixtures, and mocks belong under the relevant `__tests__/` directory, not as siblings.- Extract components, hooks, helpers, or abstractions only for reuse, real boundaries, or large bodies.- Do not add comments to untouched code; delete confirmed-dead code instead of leaving markers.- Regenerate derived docs from source rather than editing generated docs directly.## Validation- Run `vp check --fix` after code or docs source edits when feasible.- Run `vp test` or a focused `vp test <pattern>` for behavior changes.- Run `npm run doc` when guides, source docs, API JSDoc, or docs navigation are affected.

Frequently asked questions