Skip to content

Project Manifests

project.yaml describes metadata, roles, permissions, and integrations for a project. The manifest is optional but recommended for teams that want to keep configuration close to code.

Basic Structure

version: 1
project:
  name: "Customer Portal"
  key: "PORTAL"
  description: "Customer-facing portal"
  visibility: private

team:
  lead: alex@example.com
  roles:
    - name: developer
      permissions:
        - issues:*
        - code:push
      members:
        - dev1@example.com
        - dev2@example.com
    - name: product_manager
      permissions:
        - issues:create
        - analytics:read

workflows:
  - workflows/development.yaml
  - workflows/support.yaml

boards:
  - boards/development.yaml
  - boards/support.yaml

integrations:
  - type: slack
    enabled: true
    config:
      channel: "#support"

Supported Sections

  • project – Name, key, description, visibility, tags.
  • team – Leads, roles, permissions, onboarding checklists.
  • permissions – Default role, restricted actions, custom scopes.
  • integrations – Slack, GitHub Apps, custom webhooks.
  • labels – Name/color/description definitions.
  • custom_fields – Define new fields for issues with type (string, integer, enum, user, date).
  • automations – Project-wide hooks triggered by events (issue.created, sprint.start).
  • environments – (optional) describe deployment environments and approval flows.

Precedence

  • Repository manifests override project-level defaults.
  • Organization manifests (if provided) seed new projects so you can standardize naming, labels, and permissions.

Validation Tips

  • Keep manifests under 500 KB to avoid GitHub API limits.
  • Use anchors for shared role definitions across repositories.
  • Run kiket workflows lint to validate configuration files locally before committing.

Manifests help you bootstrap consistent projects and document expectations for every team member.