Installing the skills

Install the Neenja skills with:

npx skills add MesonWarrior/Neenja --all

neenja-init

/neenja-init is the technical project planning skill. Use it at the start of a project after the user describes what they want to build.

The skill writes .neenja/project-plan.md in the structured ## Plan: format and .neenja/task-tree.yaml as a nested YAML tree. The plan should capture architecture, module boundaries, contracts, integrations, constraints, and explicit user technical decisions rather than product strategy prose. It may store one optional single-line technical preferences value in each document. After writing both files, the skill asks the user to review what must be corrected before the plan and task tree are treated as final.

neenja-bootstrap

/neenja-bootstrap is the one-time documentation generation skill. It tells the agent to inspect the repository, classify each concept by visibility and type, and write or refresh .neenja/documentation.md.

The skill accepts one optional single-line preferences argument. When present, the agent writes that value into documentation frontmatter as preferences:.

neenja-sync

neenja-sync is the ongoing maintenance skill. It tells working agents to read .neenja/documentation.md at the start of each task, read .neenja/project-plan.md and .neenja/task-tree.yaml when present, and update documentation before finishing when documentable behavior changed.

The sync skill uses the technical plan for architecture constraints, module boundaries, data contracts, and user-specified implementation details. It uses the task tree to orient work around relevant task status, parent tasks, and dependsOn: relationships. When work changes task progress, the agent should update the task status in .neenja/task-tree.yaml. The plan should change only when approved architecture or durable technical constraints change.

The sync skill reads saved preferences: frontmatter values when they exist and uses that guidance while changing canonical documents.

Maintenance rules

• keep canonical Neenja documents inside .neenja/
• preserve stable concept IDs, plan section IDs, plan detail headings, and task IDs
• update the relevant frontmatter updated field whenever a document changes
• prefer editing existing concepts, plan sections, or tasks over creating duplicates
• keep public concepts usable as external-facing reference material
• keep private concepts implementation-grounded and useful to maintainers and agents