Skip to content
Back to skills

Dygo App Development

ASecurity

Build or extend a dygo Business App using the supported project layout, generators, metadata, SDK, and validation workflow. Use for general app work that is not primarily Entity modeling, access, hooks, Jobs, fixtures, or patches.

  • 16 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added August 31, 2026
developmentgodocumentation

Security analysis

A100/100

Scanned August 31, 2026

npx -y skills add hapyco/dygo --skill dygo-app-development --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Dygo App Development?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Dygo App Development
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/hapyco-dygo-app-development/badge)](https://www.skillsdirectory.com/skills/hapyco-dygo-app-development)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: dygo-app-development
description: Build or extend a dygo Business App using the supported project layout, generators, metadata, SDK, and validation workflow. Use for general app work that is not primarily Entity modeling, access, hooks, Jobs, fixtures, or patches.
---

# dygo App Development

Build business behavior in an App and let dygo provide the platform foundation.

## Start

1. Find the project root from `dygo.yml`.
2. Read `docs/doctrine.md`, `docs/app-model.md`, and `docs/dir.md` when they exist in the checkout.
3. Inspect the target App and nearby examples before you choose a structure.
4. Confirm that the requested behavior is business-specific. Put reusable platform behavior in the framework instead.

## Rules

- Use the terms in `docs/nomenclature.md`.
- Prefer an App manifest, Entity metadata, access metadata, Hooks, Fixtures, Jobs, Schedules, and Patches over one-off infrastructure.
- Use `pkg/dygo` from App-owned Go code. Do not import framework `internal/` packages.
- Start with the smallest valid App shape. Add Pages, reports, or custom behavior only when metadata-driven Studio rendering is insufficient.
- Keep generated files predictable. Do not overwrite developer-owned Hook or Job logic.
- Treat server-side permissions and observable failure behavior as part of the feature.
- Do not implement behavior that current documentation marks as proposed or coming soon unless the task is to develop that framework capability.

## Check

Use focused commands such as `dygo app validate`, `dygo entity validate`, `dygo hook validate`, and `dygo doctor`. Use broader tests only when the change risk justifies them.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…