Init My Project

Document rules

PROJECT_PLAN.md should answer:

• What is the product?
• Who uses it?
• What problem does it solve?
• What is in scope now?
• What is out of scope?
• What architecture and stack are expected?
• Which business or domain rules are fixed unless the plan changes?

RULES.md should include:

• Product invariants.
• Architecture boundaries.
• Naming and vocabulary.
• Frontend rules, if the repo has a frontend.
• Backend rules, if the repo has a backend.
• Database rules, if the repo has persistence.
• Documentation rules.
• Rule activation scope so agents do not waste context on unrelated checks.
• Optional external tool or skill rules, only if the repo already needs them.

EXECUTE_PLAN.md should include:

• Current project status.
• Each delivery phase in order.
• Goal and exit criteria for every phase.
• Task groups for every phase.
• Cross-phase dependencies.
• Cross-phase verification expectations.
• Near-term backlog.

AGENTS.md should include:

• Fast start.
• Project map.
• Task routing.
• AI programming workflow.
• Source of truth.
• Vocabulary.
• Stack-specific guidance.
• Business or domain checks.
• Verification.
• Do-not list.

CLAUDE.md should include:

• Read-first index.
• Short rules.
• Touched areas.
• When to use the project skill.
• Optional external tool or skill policy, only when present.
• Verification hints.

CONTRIBUTING.md should include:

• Read order.
• Conduct summary.
• AI programming workflow.
• Commit message format.
• Terminology.
• Verification.
• Domain-sensitive change process.

CODE_OF_CONDUCT.md should be short and direct:

• Respectful, technical communication.
• Evidence-based review.
• No hidden uncertainty.
• No reverting someone else's work without explicit instruction.
• No secrets or private data in commits.

Project-specific skill recipe

Create skills/{project-slug}/SKILL.md with:

---
name: project-slug
description: Guides work that changes or reviews Example Project domain behavior. Use for permissions, data ownership, lifecycle state, integrations, or other domain-sensitive areas, not ordinary docs-only edits.
---

# Example Project

## Quick start

1. Read `PROJECT_PLAN.md`.
2. Read `RULES.md`.
3. Declare touched areas.
4. Use this skill only for domain-sensitive changes.
5. Preserve the invariants below.

## Invariants

- User-owned records must not be reassigned without an audited operation.
- Permission changes must preserve the documented role hierarchy.

## Task recipes

**Permissions.** Read `PROJECT_PLAN.md`, preserve role boundaries, and add behavior tests when executable code exists.

**Data ownership.** Preserve ownership and audit rules. Do not move records between owners without an explicit product rule.

## Red flags

- A frontend-only check becomes authoritative for permissions, ownership, or lifecycle state.
- Domain vocabulary changes without updating `PROJECT_PLAN.md` and `RULES.md`.

## Verification

- Docs: inspect Markdown and run terminology searches.
- Code: run the smallest relevant test or build.

## Commits

Use `type(scope): subject`.

Keep this skill under 100 lines when possible. Move details back into PROJECT_PLAN.md or RULES.md instead of bloating the skill.

Execution rules to include

Every initialized project should get these working norms unless the user opts out:

• Start AI programming tasks by declaring touched areas.
• Apply only global rules plus rules for touched areas.
• Implement requested changes directly; keep scope tight.
• Do not create or update docs/superpowers/plans history files or plan changelogs unless the user explicitly asks.
• Use concise Conventional Commits: type(scope): subject.

Only include external tool or skill installation rules when the project explicitly depends on installable external skills. If included, require user review before installation and prevent duplicate installs.

Verification

Pick checks from touched areas:

• Docs: inspect changed Markdown and run rg for changed terminology.
• Package metadata: parse changed package files with the native tool, such as Node for package.json.
• Frontend: run lint, typecheck, build, and file-type scans when relevant.
• Backend: run module listing, vet, test, or build based on the stack.
• Database: run migration checks or schema validation when available.
• Dependencies: run install or lockfile checks and peer checks when available.

Before finishing, run git diff --check and inspect git status --short. Report user-owned or generated files that were intentionally left out.

Handoff

End with:

• Files created or changed.
• Verification run and result.
• Any unresolved risk.
• Whether commits were created.

Never claim work is complete before fresh verification supports that claim.