@zzci/pma
Project development lifecycle management with a strict three-phase workflow (investigate, proposal, implement), file-based plan tracking in docs/plan/, task tracking in docs/task/, and claim-before-work multi-agent coordination. Use when handling feature development, bug fixes, refactors, planning, progress tracking, or multi-agent execution in an existing codebase. English-first for repository docs and remote-visible metadata; use Chinese docs only when the user explicitly requests a specific document in Chinese.
| name | pma |
| description | Project development lifecycle management with a strict three-phase workflow (investigate, proposal, implement), file-based plan tracking in docs/plan/, task tracking in docs/task/, and claim-before-work multi-agent coordination. Use when handling feature development, bug fixes, refactors, planning, progress tracking, or multi-agent execution in an existing codebase. English-first for repository docs and remote-visible metadata; use Chinese docs only when the user explicitly requests a specific document in Chinese. |
PMA - Project Management Assistant
Run delivery work with clear gates, minimal diffs, and explicit file-based tracking.
Keep this entry file small. Load only the references needed for the current turn.
Always-On Rules
- Follow the three-phase workflow strictly: investigate -> proposal -> implement.
- Do not implement before explicit approval such as
proceed. - Read before write: inspect call chains, config, tests, and recent changelog context first.
- Keep repository docs, code comments, commits, PR text, and other remote-visible metadata in English by default.
- Do not use plan mode. Track plans only in
docs/plan/. - Update task and plan files immediately; do not defer state sync.
- Apply the Coding Principles below to every code change.
- When introducing or upgrading a dependency, default to the latest stable version verified at the registry (crates.io / npmjs.com / pkg.go.dev / PyPI), not at a version that came from a tutorial, prior PR, or model recall. Pin to a non-latest version only with a recorded reason. See
references/workflow.mdDependency Freshness for the full rule and the stack skill's baseline for the verification command. - Every repository carries a baseline set of project-level configuration files (
.gitignore,.gitattributes,.editorconfig,LICENSE,README.md,.env.example, plus stack-pinned toolchain files). Seereferences/delivery.mdRepository Hygiene. - Use the project's migration tool and follow its migration model. Schema-diff tools generate operations from declared schema; template-based tools create a versioned stub that the developer must fill in. Never edit a migration already applied to a shared environment. See
references/delivery.mdDatabase Migrations. - For new behavior and bug fixes, follow RED -> GREEN -> IMPROVE: write a failing test first, implement the smallest passing change, then refactor without changing behavior. Documentation-only and non-executable configuration changes are exempt. Target 80% or higher coverage unless the project defines a stricter threshold.
Coding Principles
Behavioral guardrails for every edit. Bias toward caution over speed; for trivial tasks, use judgment.
- Think Before Coding: state assumptions explicitly, surface tradeoffs and simpler alternatives; when unclear, stop and ask instead of guessing.
- Simplicity First: minimum code that solves the problem — no speculative features, abstractions, or configurability.
- Surgical Changes: touch only what the request requires, match existing style, and clean up only what your own change made unused.
- Goal-Driven Execution: convert vague tasks into verifiable success criteria, then loop until verified.
Core Workflow
Three phases with hard gates. Step-by-step detail lives in references/workflow.md; load it for any non-trivial task.
- Phase 1: Investigation — entry: a chosen task. Claim the task in
docs/task/index.md([ ]->[-], owner set) when investigation starts; investigate impact, related code, tests, config, and recent changelog; create a plan file for non-trivial work. Exit: findings recorded. - Phase 2: Proposal — output current state, proposal, risks, scope, and alternatives, then stop. Exit gate: explicit approval such as
proceed. - Phase 3: Test -> Implement -> Verify -> Record — entry: approval. Set the plan status/marker to in-progress (the task is already claimed since Phase 1), establish a failing test for behavior changes, implement the approved scope, run focused and relevant-suite verification, mark task and plan completed, update changelog when needed.
Reference Packs
Load only what the current task needs:
references/workflow.mdUse for the detailed three-phase flow, claim-before-work, sync rules, and session checklist.references/docs-and-tracking.mdUse for task and plan file structure, canonical docs layout, changelog format, and project initialization.references/delivery.mdUse for shell and tmux rules, git and PR workflow, CI expectations, and security/tooling constraints.references/dev-environment.mdUse for nsl-based dev URL routing — install, mental model, run patterns,--stripsemantics,NSL_PORTplaceholder, fallback. Cross-cutting; loaded alongside any stack skill that needs to wire up dev-time URLs.
Canonical Format References
Use these format files instead of redefining schemas inline:
- docs/task-format.md
- docs/plan-format.md
- docs/monorepo-example.md — concrete Bun workspaces + nsl walkthrough; consult when laying out (or auditing) a multi-app repo.
- docs/project-injection.md —
AGENTS.mdtemplate (withCLAUDE.mdas a symlink) for activating PMA in a new (or audited) project. Load when bootstrapping a repo or when an existing project'sAGENTS.mdlooks thin compared to the current rule set.
Quick Routing
Choose references by intent:
- New feature, bug fix, or refactor: load
references/workflow.mdandreferences/docs-and-tracking.md. - Task claiming, ownership, or status sync: load
references/workflow.md. - Task or plan file creation: load
references/docs-and-tracking.md. - PR preparation, CI, shell usage, or security review: load
references/delivery.md. - Repository initialization or hygiene audit (
.gitignore,.gitattributes,.editorconfig,LICENSE,README.md,.env.example, toolchain pinning): loadreferences/delivery.mdRepository Hygiene. - Any database schema change or migration: load
references/delivery.mdDatabase Migrations. - Bootstrapping a new project, or auditing an existing project's
AGENTS.mdinjection (and verifyingCLAUDE.mdis a symlink to it): loaddocs/project-injection.md. - Introducing or upgrading a dependency: load
references/workflow.mdDependency Freshness, then the stack skill's baseline for the registry-check command. - Dev URL routing setup, debugging nsl behavior, or wiring a new app into the local URL map: load
references/dev-environment.md. - Designing or restructuring a multi-app repo: read
docs/monorepo-example.mdtogether with the relevant stack skill's Monorepo section.
If the repository also uses a stack skill such as /pma-web, /pma-bun, /pma-go, or /pma-rust, load /pma first for workflow control, then load only the relevant stack references for implementation details.
Loading...
Select a file to preview
Analyzing security...
Checking scan reports and verification data.
Bill of Materials
Everything this skill can do — files, network, commands, and more.