Implement Pm

Implement PM

Summary

Implement PM tasks in the current checkout.

Required information can be supplied in any prompt shape.

The first action after loading this skill is always:

skills/implement-pm/scripts/create-pm-branch.sh "$pm_tool" "$task_ids"

That script checks out and pushes branch $pm_tool/$task_ids.

Diagram

flowchart TD
  A[Read pm_tool and task_ids] --> B[Run create-pm-branch.sh]
  B --> C[Retrieve PM tasks]
  C --> D[Analyze repository with Serena]
  D --> E[Implement focused changes]
  E --> F[Run relevant existing checks]
  F --> G[Report implementation and next create-pr step]

Inputs

Required inputs:

• $pm_tool: PM system name, for example github, jira, notion, linear.
• $task_ids: exact task IDs joined exactly as they should appear in the branch name.

Do not guess missing inputs. Ask for the missing information if either value is missing.

References

Load only what is needed:

• references/pm-task-retrieval.md for PM task retrieval.
• references/implementation-git.md for branch-script behavior and implementation Git commands.
• references/development-rules.md before editing and before the final diff review.

Workflow

First Action

Before retrieving PM tasks, analyzing code, or editing files, run:

skills/implement-pm/scripts/create-pm-branch.sh "$pm_tool" "$task_ids"

The branch name must be exactly:

$pm_tool/$task_ids

Rules

• Use Serena before implementing. If Serena is unavailable, stop instead of implementing from text search alone.
• Load and follow references/development-rules.md; treat missed existing-code reuse, duplicated implementation logic, dead code, unsafe boundary handling, unrelated edits, or skipped relevant checks as implementation bugs to fix before finishing.
• Reuse existing components, hooks, services, schemas, validators, DTOs, repositories, utilities, and design-system primitives before creating anything new.
• Keep business logic centralized, handlers/controllers thin, boundary validation explicit, and server-side authorization enforced.
• Preserve unrelated local work. Do not stash, reset, delete, unstage, or commit unrelated changes unless explicitly requested.
• Do not create PRs, PR descriptions, PR task links, review comments, or PM status updates.
• Do not add dependencies, logs, broad refactors, or new tests by default.
• During implementation and final diff review, minimize added lines relative to deleted lines. Prefer deletion, reuse, and extension over parallel code; if a small product or implementation concession would materially reduce added lines, stop and ask for user approval before taking it.
• Use the repository's existing check commands that are relevant to the touched area.

Expected Response Format

Response

## Implement PM

Branch: `$pm_tool/$task_ids`

Implemented:

- <concise change>
- <concise change>

Checks:

- `<command>`: <passed|failed|not run> - <short note>

Remaining:

- <risk/blocker or "none">

Diff discipline:

- <how added lines were minimized relative to deleted lines, or concession approval needed>

Next:

<Run `create-pr`>

Development Rules Reference

Use this reference during implement-pm before editing and final diff review, during fix-pr before remediation edits and replies, and during review-pr before judging concrete implementation hygiene, local change safety, checks, and finalization readiness.

This file covers implementation mechanics. Use governing project instruction files (AGENTS.md, CLAUDE.md, GEMINI.md, and equivalents) for architecture, ownership, boundaries, and project conventions.

Before Editing

• Load governing project instruction files.
• Use Serena to inspect the affected code path and nearby ownership before changing files.
• Search for an existing equivalent before adding any component, hook, utility, type, schema, decorator, service, repository, validator, query key, or abstraction.
• If an existing owner is close but incomplete, extend it, compose it, add a variant, or make a focused refactor instead of creating a parallel implementation.
• Before choosing an additive solution, check whether deletion, reuse, extension, or a small user-approved concession would reduce added lines relative to deleted lines. In fix-pr, only use a concession when the PR feedback explicitly requests it.
• Preserve unrelated local work. Do not stash, reset, unstage, delete, overwrite, force-delete, or commit unrelated changes unless the user explicitly asks.

Focused Implementation

• Keep changes scoped to the PM task, PR feedback remediation, or explicit user request.
• Prefer the smallest correct change that fits the existing architecture and local conventions.
• Optimize for the fewest added lines after accounting for deleted lines. Do not treat a large net addition as acceptable when a small approved concession, reuse path, or deletion would preserve the core outcome with much less code. In fix-pr, report unrequested concessions as blockers instead of applying them.
• Follow existing data-fetching, validation, typing, component, backend, security, and error-handling patterns.
• Keep code clear, explicitly named, consistently organized, strictly typed where useful, and free of dead code, unused imports, unused variables, obsolete files, and hidden behavior.
• Do not weaken types to silence errors.
• Do not add dependencies, broad abstractions, broad refactors, logs, or new tests by default.
• If a requested fix would require broad architecture changes, stop and report the mismatch instead of expanding scope silently.
• If a small product or implementation concession could materially reduce added lines, ask for explicit user approval before applying that concession.

Frontend Details

• Consume APIs through the existing data layer. If the project uses TanStack Query, components use custom hooks, hooks use Query, and raw network calls stay in client/API functions.
• Disable actions that cannot safely run twice while pending.
• Use spinners for user-triggered async actions and skeletons for initial async data display.
• Surface errors intentionally, with retry affordances for data-display failures when relevant.
• Keep meaningful components in separate files when the implementation creates or substantially changes component structure.
• Reuse design-system primitives before local styling.

Backend And Security Details

• Keep handlers/controllers thin.
• Validate inputs at boundaries.
• Never trust client-provided data.
• Enforce authorization on the server side.
• Use existing security utilities and middleware.
• Keep database queries intentional and avoid obvious N+1 patterns.
• Use transactions for multi-step writes that must stay consistent.
• Treat file uploads, redirects, dynamic queries, and user-generated content as high-risk areas.

Tests And Logs

• Do not create new tests by default.
• Update existing tests only when directly affected by the implementation or remediation.
• If test creation is explicitly requested, prefer the dedicated journey-test workflow from write-tests instead of narrow implementation-detail tests.
• Do not add logs by default.

Checks

Discover relevant existing checks:

scripts/discover-checks.sh [repo-root]

Do not start dev servers, watch commands, containers, or browser automation by default.

Report commands as not run when no relevant existing command exists or when the only available check requires an excluded long-running tool.

Before Finishing

• Review the diff for scope, duplication, dead code, inconsistent naming, missed reuse, and regressions.
• Review the added/deleted line balance. Explain any large net addition, or revise toward deletion/reuse unless a user-approved concession or explicit requirement justifies the added surface.
• Update README files only when setup, commands, environment variables, architecture, or project conventions changed.
• Follow the owning skill's Git behavior: implement-pm commits without pushing, fix-pr commits and pushes after focused remediation, and review-pr does not implement fixes.

Implementation Git Reference

Use this reference for technical Git mechanics during implement-pm.

Mandatory Branch Script

Run before any task retrieval or code analysis:

skills/implement-pm/scripts/create-pm-branch.sh <pm-tool> <task-ids>

The script:

• resolves the current Git root;
• records the source branch in local Git config as branch.<pm-tool>/<task-ids>.pbaw-base;
• creates or switches to branch <pm-tool>/<task-ids>;
• pushes the branch to origin;
• sets upstream tracking.

Status Commands

Use these commands when checking local state:

git rev-parse --show-toplevel
git status --short --branch
git branch --show-current
git remote -v
git config --get branch.$(git branch --show-current).pbaw-base

Do not stash, reset, unstage, or delete unrelated local changes.

Commit

When the implementation is ready to publish for create-pr, stage only task changes:

git status --short
git diff --stat
git diff
git add <paths>
git status --short
git commit -m "<repo-style commit message>"

Do not push. Leave unrelated concurrent user edits unstaged unless the user explicitly included them.

PM Task Retrieval Reference

Use this reference after the branch script has completed.

GitHub Issues

Discover the repository:

git remote get-url origin
gh repo view --json nameWithOwner,url,defaultBranchRef

Retrieve each issue:

gh issue view <number-or-url> --repo <owner/repo> --json number,title,body,state,labels,assignees,milestone,comments,url,closed

Reject ambiguous search results. Ask for exact IDs only when the provided task IDs cannot be resolved.

Jira, Notion, Linear, And Other PM Tools

Use the installed MCP or CLI for the selected pm-tool.

Retrieve:

• title and stable URL;
• body/content;
• comments or discussion that change scope;
• current status;
• dependencies and linked tasks;
• acceptance criteria.

If the selected PM tool cannot provide complete task content and the user did not include the full task body, stop before implementation.

Dependency Check

If a requested task depends on another unresolved task that is not included in <task-ids>, ask whether to include it before implementation.

Do not update PM status or create PR task links from implement-pm.