p7

Overview of p7 skill

What p7 is for

The p7 skill is a senior-engineer execution mode for code work: it is meant to take a scoped implementation task, design a solution first, assess impact, then write code and finish with a short self-review. In plain terms, p7 is for Code Generation when you do not want a raw “just write code” answer and instead want a more disciplined build sequence.

Who should use p7

p7 fits users who already have a task owner, architectural direction, or parent agent and need a reliable executor for a defined subtask. It is especially relevant if you work in a multi-agent workflow, or if you want code generation with an explicit plan before edits.

The real job-to-be-done

Most users considering p7 are trying to reduce guesswork during implementation. The value is not just code output. The job is: turn a bounded request into a proposed approach, think through likely impact, implement, and then pressure-test the result with a compact self-check.

What makes p7 different from a normal coding prompt

The main differentiator is workflow shape. p7 is not described as a broad autonomous architect. It is an execution role under P8 supervision, with a solution-driven pattern and a required completion format. That makes it more structured than a generic “build this feature” prompt, but narrower than a top-level planning agent.

What the repository actually gives you

The repository evidence is minimal but clear: SKILL.md defines the role, trigger phrases, output expectations, and references an external protocol file. For install decisions, that means p7 is easy to understand quickly, but some operational detail depends on the wider /pua system and the referenced protocol.

Best-fit and misfit at a glance

Use p7 when:

• you want implementation plus reasoning in a fixed sequence
• the task can be delegated as a subtask
• you care about impact analysis before code changes

Skip p7 when:

• you need product scoping or architecture ownership first
• you want a broad exploratory brainstorm
• you do not have enough context to define the subtask clearly

How to Use p7 skill

Install p7 skill

A practical install path is:

npx skills add tanweai/pua --skill p7

After installation, open skills/p7/SKILL.md if your environment mirrors the repo layout, or inspect the upstream file at skills/p7/SKILL.md in the GitHub repository.

Read these files first

For p7, the highest-value reading order is:

1. skills/p7/SKILL.md
2. the repository-level /pua core skill if available in your environment
3. references/p7-protocol.md if present locally after install

Why this matters: SKILL.md is short and delegates key behavior to the protocol and the core /pua rules. If you only skim the top file, you may miss important execution constraints.

How p7 is triggered in practice

The source explicitly says p7 is used when the user says phrases like P7模式 or 方案驱动, or when p7 is spawned by P8 as a sub-task executor. In practice, that means you should invoke p7 by naming the mode and giving it a bounded implementation assignment, not an open-ended strategy problem.

What input p7 needs to work well

p7 works best when your request includes:

• the target repository or code area
• the exact feature, fix, or refactor goal
• constraints such as language, framework, style, or no-go areas
• expected output shape
• any risks to check during impact analysis

If you omit these, p7 can still respond, but the “solution-driven” step becomes generic and less useful.

Turn a rough goal into a strong p7 prompt

Weak input:

• “Use p7 to improve auth.”

Stronger input:

• “Use p7 for Code Generation on the login flow. In a Next.js app, add refresh-token rotation for existing JWT auth. Do not change database schema unless necessary. First propose the implementation plan and impact analysis, then implement server and client changes, then finish with a 3-question self-review.”

The stronger version improves p7 usage because it gives scope, stack, limits, and output order.

A practical p7 workflow

A good operating sequence is:

1. define the subtask narrowly
2. ask p7 for the implementation plan first
3. review the impact analysis for risky assumptions
4. confirm or adjust scope
5. let p7 generate code
6. inspect the final self-review for gaps, regressions, and unresolved questions

This matches the skill’s intended value better than asking for code immediately.

Expected output pattern

The repository description says p7 produces:

• implementation plan
• code
• 3-question self-review
• delivered via [P7-COMPLETION]

If your tooling supports structured agent handoff, preserve that completion marker. If not, still ask for the same content blocks so the skill stays aligned with its intended protocol.

How to use p7 for Code Generation

For Code Generation, p7 is strongest on tasks where design choices affect implementation quality: multi-file edits, behavior changes with downstream impact, or refactors that can break adjacent modules. It is less compelling for tiny one-line fixes where the overhead of planning may not pay off.

What to watch before adopting p7

Two adoption blockers stand out:

• some protocol detail is referenced rather than fully embedded in SKILL.md
• p7 depends on the wider /pua ecosystem language, including core guardrails and narration protocol

So if you want a totally self-contained skill, p7 may feel under-documented unless you also load the parent system context.

How to evaluate first-run quality

On the first run, check whether p7:

• separated planning from implementation
• identified impacted files, modules, or interfaces
• respected your constraints
• ended with a meaningful self-review rather than a ceremonial checklist

If those pieces are missing, your invocation or environment likely did not load the skill as intended.

p7 skill FAQ

Is p7 beginner-friendly?

Moderately. The p7 skill itself is simple to grasp, but it is not optimized for teaching absolute beginners. It assumes you can frame a task, review an implementation plan, and judge whether impact analysis makes sense.

Is p7 useful without P8?

Yes, but with limits. The source positions p7 under P8 supervision, so its ideal use is as a delegated executor. You can still use p7 standalone by simulating that role: give it a clearly bounded subtask and explicit constraints. Just do not expect top-level orchestration behavior.

When is p7 better than a normal prompt?

p7 is better when you need disciplined execution for a defined engineering task. If the work benefits from “plan first, code second, review third,” p7 adds structure a normal prompt often skips.

When should I not use p7?

Do not use p7 for:

• vague product ideation
• broad architecture selection without clear requirements
• tasks that need heavy repo-specific protocol knowledge you have not loaded
• trivial edits where structured planning adds delay but little quality

Does p7 include install scripts or extra resources?

Based on the available repository evidence, no extra scripts or bundled support files are surfaced in the skill directory view. The key file is SKILL.md, and it references references/p7-protocol.md, so check whether that file is available in your installed environment.

Is p7 opinionated about output format?

Yes. The skill description points to a defined completion wrapper and a specific sequence of deliverables. That is a good fit for teams that want consistent agent outputs, but less ideal if you prefer free-form conversational coding.

How to Improve p7 skill

Give p7 a sharper subtask boundary

The fastest way to improve p7 results is to narrow the task. Instead of “refactor payments,” specify the endpoint, component, module, or failure mode involved. p7 is an executor; the clearer the boundary, the better the code generation quality.

Ask for explicit impact analysis targets

Do not just ask for “impact analysis.” Name what should be checked:

• API compatibility
• schema changes
• test impact
• performance risk
• migration needs
• rollback concerns

This makes p7’s planning stage materially more useful.

Provide repository clues up front

If you know likely files, say so. Example:

• src/auth/session.ts
• app/api/login/route.ts
• tests/auth.spec.ts

This reduces wandering and improves p7 usage in larger repositories where code generation quality depends on touching the right surfaces.

Request assumptions before code if context is thin

A common failure mode is premature implementation on weak context. If your brief is incomplete, tell p7: “List assumptions and blockers before coding.” That preserves the solution-driven nature of the skill instead of forcing low-confidence output.

Use the self-review as a revision tool

The 3-question self-review should not be treated as decoration. Read it for:

• hidden assumptions
• incomplete edge-case handling
• missing tests or validation steps

Then feed those gaps back into a second p7 pass. This is one of the simplest ways to improve p7 without changing the skill itself.

Strengthen p7 prompts with acceptance criteria

For better p7 for Code Generation results, include success conditions such as:

• “existing tests must still pass”
• “no breaking API changes”
• “support both mobile and desktop UI”
• “keep public function signatures stable”

Acceptance criteria turn p7 from a capable coder into a more reliable executor.

Common failure modes to catch early

Watch for:

• a plan that is too generic to drive implementation
• code that skips stated constraints
• self-review that does not mention real tradeoffs
• solutions that assume parent-system context you did not provide

These are usually prompt-quality or context-loading issues, not proof that p7 is unusable.

How p7 could be improved as a skill

The p7 skill would be easier to adopt if the repository exposed more of the protocol inline or linked more directly to the supporting files in the skill folder. Concrete examples of invocation, expected completion structure, and standalone usage would also lower setup friction for new users.