@swiftwind0405/pi-project-workflow0.1.0
Explicit, resumable issue-to-MR workflow for the Pi coding agent.
Untested on omp
This is a pi package. No one has reported whether it works on omp yet. If you try it, add your result below.
Reports 0
No reports yet.
Readme
pi-project-workflow
@swiftwind0405/pi-project-workflow is a user-scoped Pi package for explicit, resumable
issue-to-MR workflows. It keeps Pi orchestration policy and runtime state out of
business repositories.
Install
Install the subagent runtime once:
pi install npm:@tintinweb/pi-subagents
Once published to npm, install this package globally:
pi install npm:@swiftwind0405/pi-project-workflow
Before the first npm release, install globally from GitHub:
pi install git:github.com/swiftwind0405/pi-project-workflow
Do not use -l; project-local installation would write Pi configuration into
the target repository.
For local package development, install a checkout by absolute path instead.
Pi supplies its SDK and typebox at runtime. Keep them in peerDependencies
with "*" ranges; pinned devDependencies support local tests and typechecking.
Run pnpm install --frozen-lockfile followed by pnpm check for development.
Publishing
For the first public release, run these commands from this checkout using the
swiftwind0405 npm account:
pnpm install --frozen-lockfile
pnpm check
npm pack --dry-run
npm login
npm publish
publishConfig selects the public npm registry and public access. Publishing
exposes the packaged source even while the GitHub repository is private.
After the first release, open the npm package's Settings → Trusted publishing and add GitHub Actions with these values:
| Field | Value |
|---|---|
| Organization or user | swiftwind0405 |
| Repository | pi-project-workflow |
| Workflow filename | publish.yml |
| Environment name | Leave empty |
| Allowed actions | Enable direct publishing with npm publish |
Commit and push .github/workflows/publish.yml before configuring the publisher.
The workflow uses OIDC and does not require an NPM_TOKEN secret. It works with
this private GitHub repository; npm provenance is available only for public
repositories. See the npm trusted publishing documentation.
For subsequent releases, update package.json's version, commit and push the
change, then publish a non-prerelease GitHub Release with a matching v<version>
tag (for example, v0.1.1). The workflow checks the tag against the package
version, installs the locked dependencies, runs pnpm check, and publishes to
npm. Draft releases and prereleases do not publish this package.
Commands
/project_setup [--repo <path>]/project_oneshot <requirement-or-issue>/project_issue_execute <issue-id> [--repo <path>]/project_issue_plan <issue-id> [--repo <path>]/project_issue_from_vikunja_task <task-id> [--repo <path>] [--dry-run]/project-ready/project-status
Workflow execution starts only from an explicit command or bundled
/skill:project-* invocation.
Storage
Profiles and state live under:
${PI_CODING_AGENT_DIR:-~/.pi/agent}/project-workflow/projects/<repo-key>/
Set PI_PROJECT_WORKFLOW_HOME to override the plugin storage root.
Repository identity uses the normalized origin remote. Repositories without
an origin fall back to their Git common directory.
On first use, the package can import an old
docs/agents/project-workflow.md profile and copy legacy
.pi-project-workflow state. It never deletes the legacy source automatically.
Vikunja is treated as an optional human inbox. Promotion is always an explicit command; after promotion, the repository issue is the engineering source of truth.