@adi-mudi/pi-chirpi

Chirpi — architecture factory extension for Pi — generates project-specific architecture agents and skills from a bundled library or from your own input documents

Packages

Package details

extensionskill

Install @adi-mudi/pi-chirpi from npm and Pi will load the resources declared by the package manifest.

$ pi install npm:@adi-mudi/pi-chirpi
Package
@adi-mudi/pi-chirpi
Version
1.0.1
Published
Sep 12, 2026
Downloads
163/mo · 163/wk
Author
adi-mudi
License
MIT
Types
extension, skill
Size
532.9 KB
Dependencies
0 dependencies · 5 peers
Pi manifest JSON
{
  "extensions": [
    "./dist/index.js"
  ],
  "skills": [
    "./skills"
  ]
}

Security note

Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.

README

pi-chirpi

Chirpi is a Pi extension that generates a project-specific architecture for your repository: an architecture profile, human-readable docs, ADRs, and ready-to-use Pi agents and skills.

Install

pi install npm:@adi-mudi/pi-chirpi

Commands

Command Purpose
/chirpi-predefined-architect Static mode — pick an architecture from the bundled library (36 entries). No input documents needed: Chirpi scans your codebase first (deps, folders, configs), shows why each top match fits, and asks at most 1-2 targeted questions — only about things the code cannot answer.
/chirpi-generate-architect Dynamic mode — derive the architecture from your own documents and constraints listed in .pi/senai/architect-inputs.json.
/chirpi-configure-architect-inputs Configure .pi/senai/architect-inputs.json (documents + constraints) used by /chirpi-generate-architect.
/chirpi-predefined-framework Lock the framework from dependency detection — one confirm on a single match, one question on a close call, the full library list when nothing matches. Writes .pi/senai/framework.json.
/chirpi-configure-framework Lock the framework manually (id or none; picker grouped by language when no id is given). A manual lock always wins over dependency detection.

Static mode

Run /chirpi-predefined-architect. Chirpi profiles your codebase first — package.json dependencies, folder layout, deployment configs (vercel.json, Dockerfile, …) — and infers purpose, scale, deployment, and realtime needs with evidence. It scores the bundled architecture-library/ entries, shows the top matches with the reasons they matched, and asks questions only about what the code could not answer: one confirm when the winner is clear, one targeted question when two entries are close, and at most two short questions when the project has no readable signals. Pi extension projects skip questions entirely. If nothing fits, it falls back to a new-entry template.

Dynamic mode

  1. Run /chirpi-configure-architect-inputs to list your input documents and constraints (written to .pi/senai/architect-inputs.json — path kept for compatibility with pi-senai).
  2. Run /chirpi-generate-architect. Chirpi merges architectural drivers from your documents and generates the architecture artifacts.

Generated output

Location Purpose
.pi/architect/ Architect state and artifacts (drivers, profile, report, architecture.md, adrs/*.md).
.pi/agents/<project>-<architecture-id>-<role>.md Generated architecture agents.
.pi/skills/<project>-<architecture-id>-<stage>/SKILL.md Generated architecture skills.

Framework library

Beside the language-free architecture-library/, Chirpi ships a framework-library/ — one map per framework, grouped by language (typescript/: nextjs, express, nestjs, react-vite; python/: django, fastapi, flask). Each map carries frontmatter (id, language, framework, officialDocs, detectDeps), a layout map, layer fit, forbidden patterns, verification hints, and a machine-readable ## Rules section (- forbid: <importer glob> -> <target glob or pkg:module> # <reason>) that gate runners can enforce with dependency-cruiser / import-linter. Projects can override or add maps in .pi/framework-library/.

The codebase profiler detects frameworks from package.json dependencies (exact-name, all-listed against each map's detectDeps), and /chirpi-predefined-architect treats a detected framework as a confirmed signal — no question — asking one confirm question only on close calls. The loader API (discoverFrameworkLibrary, loadFrameworkMap, validateFrameworkMap, parseFrameworkRules, detectFrameworksFromDeps, …) is exported from the package for downstream tools like pi-senai.

The lock can also be set explicitly: /chirpi-predefined-framework locks a framework from dependency detection (confirm / close call / full library list), and /chirpi-configure-framework sets it by hand. Both write .pi/senai/framework.json ({ id, source, setAt }source is detected or manual; none means architecture-only). A saved config always wins over fresh detection in /chirpi-predefined-architect, and doctor verifies the lock (checkFrameworkConfig): an existing framework.json must name a valid library id.

Development

npm run build compiles pi-extension/ into dist/. After every build, sync the full package payload — dist/, skills/, README.md, architecture-library/, framework-library/ — into consumers' node_modules/@adi-mudi/pi-chirpi/ (e.g. pi-senai). Syncing only dist/ leaves stale skills and docs behind.

License

MIT