@piagent/platform 1.2.10 → 1.2.12

package/packages/piagent-core/prompts/be-to-fe.md

@@ -18,52 +18,45 @@ Use this for tasks like:
 - FE needs to map validation/errors/state from backend contract.
 - Backend source must be scouted but not edited.
 
-Mandatory flow:
+Flow:
 
-0. Call `piagent_context_preflight` with `workflow=be-to-fe`. If it recommends `fresh-session`, stop loading context in this session and tell the user to use `/piagent-session fresh be-to-fe <request>` unless this command already runs in a fresh session.
-1. Call `piagent_context` with `detail=full` and confirm profile/protected backend paths.
-2. Call `piagent_orchestration_policy`; keep the workflow solo-first unless bounded BE/FE scouting or review is worth the extra token/tool cost.
-3. Call `piagent_memory_status`; search memory or Field Guide for prior BE/FE mapping decisions if relevant, record citations with `piagent_memory_citation_record`, then verify against current BE/FE files.
-4. Read `.pi/project-context.md`. If pending, stop and ask for `/onboard-project run`.
-5. Read required context from the active profile and call `piagent_context_budget` for BE/FE files that look large.
-6. Classify the task:
+1. Read the current backend contract and narrow frontend touchpoints. Runtime hooks enforce backend read-only paths and inject bounded navigation context when useful.
+2. Treat project memory and generated context as advisory; verify decisions against current BE/FE files.
+3. Classify the task:
    - BE scout: read-only.
    - FE implementation: source-write.
    - Auth/data migration/external provider: high-risk, ask before implementation.
-7. Decide whether bounded subagents are useful. If the bundled `pi-subagents` parent skill is available, use it for delegation patterns and safety boundaries. If `pi-subagents`/`subagent(...)` is available, prefer read-only delegation only when BE/FE mapping has independent lanes:
+4. Use bounded read-only subagents only when BE/FE mapping has independent lanes worth the extra token/tool cost:
    - `piagent-scout` maps backend contract read-only;
    - `piagent-scout` maps frontend touchpoints read-only;
    - builtin `context-builder` may create handoff context when the BE→FE mapping touches multiple journeys/forms/contracts;
    - `piagent-planner` produces the FE implementation plan when the contract touches multiple layers;
    - `piagent-reviewer` reviews diff/verification after implementation.
    Continue single-agent if subagents are unavailable, the task is tiny, or requirements are unresolved.
-8. Scout backend contract read-only:
+5. Scout backend contract read-only:
    - controller/route/handler;
    - request/response DTO/schema;
    - validation/error model;
    - backend tests;
    - OpenAPI/spec/docs if available;
    - migration/schema only when it affects API shape or UI constraints.
-9. Produce a contract snapshot before FE writes:
+6. Produce a contract snapshot before FE writes:
 
    | Contract area | Backend evidence | FE implication |
    |---|---|---|
 
-10. If backend contract is missing/contradictory, do not guess and do not edit BE. Record the gap in the final response or a project report if requested.
-11. Map FE touchpoints:
+7. If backend contract is missing/contradictory, do not guess and do not edit BE. Record the gap in the final response or a project report if requested.
+8. Map FE touchpoints:
    - API client/query/mutation layer;
    - types/decoders;
    - state/cache invalidation;
    - route/page/component/form;
    - tests/e2e.
-12. Before source writes, create a Task Implementation Contract with `piagent_task_start`, including review lenses and a compact workPlan.
-13. Record BE/FE context files with `piagent_context_record`.
-14. Before shell commands beyond simple read/list/test, call `piagent_exec_policy_check`.
-15. Implement FE only.
-16. Run the exact FE verify command from the profile/task through Pi bash and record the observed result with `piagent_verify_record`. Ad-hoc commands are advisory only and will not satisfy the passing gate.
-17. Record handoff with `piagent_trace_record`.
-18. Call `piagent_task_gate_check`; if it fails, report blocked/partial instead of done.
-19. Do not paste full test/build/tool logs into chat or final output. Summarize the signal, quote only relevant failing lines, and use `/piagent-logs` or a narrower command when oversized output has been compacted.
+9. Call `piagent_task_start` exactly once before FE source writes and reuse an active contract.
+10. Implement FE only with one writer by default.
+11. Run every exact command returned in `task.verifyCommands` after the latest mutation. For a normal default plan, review the final diff and mark only its review step done with `piagent_task_progress`.
+12. Let runtime hooks record context, verification, trace, and final-gate state. Use recovery tools only if the runtime reports missing evidence.
+13. Do not paste full test/build/tool logs into chat or final output. Summarize the signal and quote only relevant failing lines.
 
 For generic projects, use profile `be-readonly-fe` when the repo policy is “BE scout only, FE write allowed”.
 
@@ -77,7 +70,6 @@ Final output:
 - Verify command/result.
 - Subagents used/not used and why.
 - Review lenses applied.
-- Task gate result.
 - Memory cited, if any.
 - Backend gaps, if any.
 - Residual risk.

package/packages/piagent-core/prompts/platform-improve.md

@@ -18,31 +18,27 @@ Use this workflow for platform-level work such as:
 - tightening runtime policy, task gates, or verification behavior;
 - adding project-agnostic workflow support for teams.
 
-Mandatory flow:
+Flow:
 
-1. Call `piagent_context` with `detail=full` and inspect the active project profile.
-2. Call `piagent_orchestration_policy`; keep the platform change solo-first unless bounded scout/planning/review lanes are useful.
-3. Call `piagent_memory_status`; if prior decisions or Field Guide notes are relevant, search memory and record citations with `piagent_memory_citation_record`.
-4. Read `.pi/project-context.md`. If pending, stop and ask the user to run `/onboard-project run`.
-5. Read the required context declared by the active profile. Before loading large files, call `piagent_context_budget`.
-6. Classify the task risk lane and create a task contract with `piagent_task_start`, including review lenses and a compact workPlan, before source edits.
-7. Decide whether bounded subagents are useful enough to justify extra token/tool cost:
+1. Use runtime automatic intake for a bounded platform change. If runtime pauses for broad, high-risk, or ambiguous scope, call `piagent_task_start` exactly once with project-relative path/glob scope and reuse an active contract.
+2. Read the narrow current implementation, its tests, and the relevant policy/schema/docs. Runtime hooks inject bounded navigation context when useful.
+3. Treat memory and generated context as advisory; verify against current files.
+4. Use bounded subagents only when independent lanes justify their extra token/tool cost:
    - use `piagent-scout` for read-only code/package mapping;
    - use `piagent-planner` for a plan when multiple modules are affected;
    - use `piagent-reviewer` for diff, docs, and verification review;
    - continue single-agent for small, localized edits.
-8. If the task needs external repository context provided by the user, use `piagent_source_checkout` when available and read only targeted files.
-9. Before shell commands that fetch, build, publish, or mutate package state, call `piagent_exec_policy_check`.
-10. Before non-piagent MCP/app tools, call `piagent_tool_policy_check`.
-11. Produce an implementation matrix:
+5. If the task needs external repository context provided by the user, use a targeted read-only checkout when available.
+6. Produce an implementation matrix only when multiple platform areas are affected:
 
     | Area | Current behavior | Target behavior | Files/config | Verification |
     |---|---|---|---|---|
 
-12. Implement only the bounded target behavior.
-13. If runtime behavior changes, update README/docs and add/adjust a decision note when appropriate.
-14. For source-changing tasks, run the exact verify command from `task.verifyCommands` through Pi bash, record observed verify evidence, trace, then call `piagent_task_gate_check` before final.
-15. Do not paste full test/build/tool logs into chat or final output. Summarize the signal, quote only relevant failing lines, and use `/piagent-logs` or a narrower command when oversized output has been compacted.
+7. Implement only the bounded target behavior with one writer by default.
+8. If runtime behavior changes, update README/docs and add or adjust a decision note when appropriate.
+9. Run every exact command returned in `task.verifyCommands` after the latest mutation. For a normal default plan, review the final diff and mark only its review step done with `piagent_task_progress`.
+10. Let runtime hooks record context, verification, trace, and final-gate state. Use recovery tools only if the runtime reports missing evidence.
+11. Do not paste full test/build/tool logs into chat or final output. Summarize the signal and quote only relevant failing lines.
 
 Default verification:
 
@@ -66,5 +62,4 @@ Final output:
 - Subagents used/not used and why.
 - Review lenses applied.
 - Memory cited, if any.
-- Task gate result.
 - Remaining risks or follow-up.

package/packages/piagent-core/prompts/review.md

@@ -11,22 +11,18 @@ $ARGUMENTS
 
 Rules:
 
-0. Call `piagent_context_preflight` with `workflow=review` for large diffs or long requests. If it recommends `fresh-session`, prefer `/piagent-session fresh scout` for read-only evidence gathering or ask the user to resume in a fresh session.
-1. Call `piagent_context`.
-2. Call `piagent_orchestration_policy` and select explicit review lenses before reading the diff deeply.
-3. Read `.pi/project-context.md` if available.
-4. Stay read-only unless explicitly asked to write a report.
-5. Check protected path violations.
-6. Check missing required context.
-7. Check verify command coverage.
-8. Decide whether subagents are useful. If the bundled `pi-subagents` parent skill is available, use it for delegation patterns and safety boundaries. If `pi-subagents`/`subagent(...)` is available and the diff is non-trivial, use bounded `piagent-reviewer` agents for independent read-only review lanes:
+1. Read the current diff and the narrow surrounding source/tests. Runtime hooks inject bounded navigation context when useful.
+2. Select review lenses from the actual change risk; do not load orchestration or diagnostic tools just to choose them.
+3. Stay read-only unless explicitly asked to write a report.
+4. Check protected paths, scope drift, acceptance behavior, and verify-command coverage.
+5. For a non-trivial diff, use bounded read-only reviewers only when independent lanes justify their token cost:
    - correctness/edge cases;
    - tests/verification;
    - scope drift/protected paths;
    - security/high-risk only when relevant.
    If the user asks for a loop, use `/review-loop` semantics or equivalent parent-controlled max-round loop. Continue single-agent for tiny diffs or unavailable subagent tooling.
-9. Report findings by severity.
-10. Do not paste full diff/test/tool logs into chat or final output. Summarize the signal, quote only relevant lines, and use `/piagent-logs` or narrower commands when oversized output has been compacted.
+6. Report findings by severity.
+7. Do not call diagnostic Piagent tools for routine review and do not paste full diff/test/tool logs. Summarize the signal and quote only relevant lines.
 
 Output:
 

package/packages/piagent-core/prompts/scout.md

@@ -13,25 +13,21 @@ Use this when the user needs evidence before deciding whether to implement. Do n
 
 Lean scouting flow:
 
-1. For a narrow lookup, call `piagent_context` with concise detail, read targeted files, and return cited evidence. Do not create a task contract or load memory/index/orchestration policy automatically.
-2. For a broad, cross-module, or high-risk scout, run `piagent_context_preflight` once. Stop if it recommends a fresh session.
-3. Create a read-only contract with `piagent_task_start` only for a broad governed scout that needs a persisted scope, verification evidence, or handoff.
-4. For an unfamiliar or cross-module area, call `piagent_context_engine` once with `action=pack` before manual search. Use memory, Context7, or a read-only subagent only when the pack is insufficient or the work has independent lanes. Verify every advisory hit against current files.
-5. Call `piagent_context_budget` only for large files and `piagent_exec_policy_check` only for complex or unfamiliar shell commands. Simple read/list commands do not need proactive policy calls.
-6. Record the files that materially support the conclusion. For a governed scout, record verification, trace, and task gate; for a narrow lookup, provide the evidence directly.
-7. A low-confidence pack may trigger one bounded finder pass. Do not loop broad search after the requested evidence is covered.
-8. Do not edit source and do not paste full command output. Summarize relevant evidence and unknowns.
+1. Read targeted current files and return cited evidence. Runtime hooks inject bounded navigation context when useful and enforce read boundaries.
+2. Create a read-only contract with `piagent_task_start` only for a broad governed scout that needs persisted scope or handoff. Tiny default scouts complete from observed reads; for a normal default scout, review the evidence and mark only the returned review step done with `piagent_task_progress`.
+3. Use memory, vendor documentation, or a read-only subagent only when current source is insufficient or the work has independent lanes. Verify advisory material against current files.
+4. A low-confidence search may trigger one bounded finder pass. Stop broad search when the requested evidence is covered.
+5. Do not call diagnostic Piagent tools for a routine scout. Load them only when the runtime reports a recovery need or the operator explicitly asks for diagnostics.
+6. Do not edit source or paste full command output. Summarize relevant evidence and unknowns.
 
 Output:
 
 - Changed files: none.
 - Verify command/result.
-- Context manifest.
 - Extra workflow tools or subagents used, if any, and why.
 - Review lenses applied.
 - Memory cited, if any.
 - Evidence matrix.
 - Gaps/mismatches/unknowns.
 - Transaction/security/data risks if relevant.
-- Task gate result.
 - Recommended next step.

package/packages/piagent-core/prompts/task.md

@@ -11,28 +11,26 @@ $ARGUMENTS
 
 Core flow:
 
-1. Run `piagent_context_preflight` once with `workflow=task`, then call `piagent_context` with concise detail. Stop if preflight recommends a fresh session or onboarding context is missing.
-2. Classify the request as `tiny`, `normal`, or `high-risk`, then create the Task Implementation Contract with `piagent_task_start` before source edits. Keep the contract compact and include acceptance criteria, scope, verify command, review lenses, and a short work plan.
-3. Read only files required for the task and record them with `piagent_context_record`. Call `piagent_context_budget` only before reading a large or unfamiliar file; do not call it for ordinary targeted files.
-4. Make a short plan before source writes. Keep one writer unless the user explicitly requests otherwise.
-5. Call `piagent_exec_policy_check` only for complex, generated, unfamiliar, destructive, or externally acting shell commands. Simple read/list and configured test commands do not need a proactive check because runtime guards still apply.
-6. Call `piagent_tool_policy_check` only before a non-piagent MCP/app tool whose capability is not already clear from concise project context.
-7. Run the exact configured verify command through Pi bash, record observed evidence with `piagent_verify_record`, record the final handoff with `piagent_trace_record`, then call `piagent_task_gate_check`.
+1. Use the runtime-created contract for a bounded source task; do not call task-management tools during automatic intake. If runtime pauses for broad, high-risk, or ambiguous scope, call `piagent_task_start` exactly once with project-relative path/glob scope and reuse an active contract.
+2. Read the likely target and nearest relevant test. The runtime injects bounded navigation context when useful.
+3. Make the smallest in-scope change with ordinary tools and one writer.
+4. Run every exact command returned in `task.verifyCommands` after the latest mutation.
+5. Automatic tasks need no lifecycle calls. Manual high-risk and explicitly requested custom plans keep their returned checkpoints.
+6. Let runtime hooks record context, changed files, verification, trace, and final-gate state. Load recovery tools only if the runtime reports missing evidence.
 
 Risk-adaptive enrichment:
 
-- `tiny`: use only the core flow. Do not call orchestration, memory, context-index, tech-context, or subagent tools unless the task actually depends on them.
-- `normal`: for unfamiliar or cross-module work, call `piagent_context_engine` once with `action=pack`; read the ranked current files and stop broad searching when confidence/evidence is sufficient. Use memory only for a known project decision. Call `piagent_orchestration_policy` only when bounded read-only delegation may save context.
-- `high-risk`: use a bounded Context Engine pack, inspect orchestration policy, relevant memory/context-index evidence, and current vendor documentation when needed. Apply explicit security/data/release review lenses before the final gate.
+- `tiny`: stay targeted; no diagnostic Piagent tools or subagents.
+- `normal`: stop searching once current-file evidence is sufficient. Use a read-only subagent only for a genuinely independent lane.
+- `high-risk`: inspect current source, relevant vendor documentation, and explicit security/data/release review lenses; keep required human confirmations.
 
 Always:
 
 - Treat memory, context-index, and generated tech snapshots as advisory; verify against current files.
-- If a Context Engine pack reports low confidence, run at most one bounded read-only finder pass and return paths/symbols/evidence; do not start an open-ended scout loop.
+- If navigation confidence is low, run at most one bounded read-only finder pass; do not start an open-ended scout loop.
 - Do not touch protected paths or use undeclared capabilities.
-- If verification cannot run or the task gate fails, report `blocked` or `partial`, never done.
+- If verification cannot run, report `blocked` or `partial`, never done. If runtime schedules a continuation, keep working in the same task and do not repeat management tools.
 - Do not paste full test/build/tool logs. Summarize the signal and quote only relevant failures.
-- Call `piagent_usage_snapshot` only when the user asks about usage; exact totals remain available through `/usage`.
 
 Do not ask the user to paste this mandatory flow. The platform prompt already contains it. If the user pasted the full flow, treat it as boilerplate and extract only the task request.
 
@@ -40,11 +38,7 @@ Output format:
 
 - Changed files.
 - Verify command/result.
-- Context manifest.
 - Extra workflow tools or subagents used, if any, and why.
 - Review lenses applied.
-- Memory cited, if any.
-- Context index used/updated, if any.
-- Task gate result.
 - Residual risks.
 - Next step if human action is needed.

package/packages/piagent-core/skills/piagent-ops/SKILL.md

@@ -1,25 +1,23 @@
 ---
 name: piagent-ops
-description: Piagent operating policy for Pi tasks across projects.
+description: Operator-invoked reference for Piagent manual intake, recovery, and high-risk task controls.
+disable-model-invocation: true
 ---
 
 # Piagent Ops Skill
 
-Use this skill for every implementation, review, planning, MCP, or tooling task in a project using Pi Agent Platform.
+Invoke this reference explicitly for manual intake, recovery, or high-risk task controls. Routine bounded source tasks already receive the required flow from runtime and must not load this file.
 
-## Mandatory steps
+## Source-task flow
 
-1. Load active project profile with `piagent_context`.
-2. Read required context before planning or editing; use `piagent_context_budget` for large files.
-3. Start source-changing work with `piagent_task_start`.
-4. Respect `protectedPaths`.
-5. Check complex/high-impact shell with `piagent_exec_policy_check`.
-6. Check non-piagent MCP/app tools with `piagent_tool_policy_check`.
-7. Use MCP only when capability is declared.
-8. Prefer small diffs with explicit verification.
-9. Run the exact command from `task.verifyCommands` for passing evidence; ad-hoc commands are advisory only.
-10. Record context, verify, and trace with `piagent_context_record`, `piagent_verify_record`, and `piagent_trace_record`.
-11. Before DONE, call `piagent_task_gate_check`.
+1. Let runtime create the task contract automatically for a bounded source-changing request. Do not call management tools for routine intake.
+2. If runtime pauses for broad, high-risk, or ambiguous scope, call `piagent_task_start` exactly once with project-relative path/glob scope and reuse an active contract.
+3. Inspect the narrow target and nearest relevant test, then make the smallest in-scope change with ordinary tools.
+4. Complete intended source and focused regression-test edits, then run every exact verifier supplied by runtime after the latest mutation. Rerun only after another mutation.
+5. Follow explicit checkpoints only for manual high-risk or operator-requested custom plans.
+6. Report changed files, exact verification, and residual risk concisely.
+
+Runtime hooks automatically enforce policy and record context, changes, current-tree verification, trace, and final-gate evidence. Do not spend calls on Piagent context/status/policy/evidence/trace/gate tools during ordinary work. Load a diagnostic or recovery group only when the runtime asks for it or the operator requests it.
 
 ## Risk gates
 
@@ -40,5 +38,4 @@ Always include:
 - what changed
 - where
 - exact verification result
-- task gate result
 - what remains manual