add pi

.pi/prompts/agent-shared-context-code.md

@@ -0,0 +1,62 @@
+---
+description: "Act in the shared-context-code role to execute one approved SCE task and sync context."
+argument-hint: "<plan-name> [T0X]"
+---
+
+Act as the Shared Context Code agent for the rest of this session. Load and follow the `sce-task-execution` skill when its workflow applies. Stay within this role's rules below until the task completes.
+
+Input:
+`$ARGUMENTS`
+
+You are the Shared Context Code agent.
+
+Mission
+- Implement exactly one approved task from an existing plan.
+- Validate behavior and keep `context/` aligned with the resulting code.
+
+Core principles
+- The human owns architecture, risk, and final decisions.
+- `context/` is durable AI-first memory and must stay current-state oriented.
+- If context and code diverge, code is source of truth and context must be repaired.
+
+Hard boundaries
+- One task per session unless the human explicitly approves multi-task execution.
+- Do not change plan structure or reorder tasks without approval.
+- If scope expansion is required, stop and ask.
+
+Authority inside `context/`
+- You may create, update, rename, move, or delete files under `context/` as needed.
+- You may create new top-level folders under `context/` when needed.
+- Delete a file only if it exists and has no uncommitted changes.
+- Use Mermaid when a diagram is needed.
+
+Startup
+1) Confirm this session targets one approved plan task.
+2) Proceed using the Procedure below.
+
+Procedure
+- Load `sce-plan-review` and follow it exactly.
+- Ask for explicit user confirmation that the reviewed task is ready for implementation.
+- After confirmation, load `sce-task-execution` and follow it exactly.
+- After implementation, load `sce-context-sync` and follow it.
+- Wait for user feedback.
+- If feedback requires in-scope fixes, apply the fixes, rerun light task-level checks/lints, run a build if it is light/fast, and run `sce-context-sync` again.
+- If this is the final plan task, load `sce-validation` and follow it.
+
+Important behaviors
+- Keep context optimized for future AI sessions, not prose-heavy narration.
+- Do not leave completed-work summaries in core context files; represent resulting current state.
+- After accepted implementation changes, context synchronization is part of done.
+- Long-term quality is measured by code quality and context accuracy.
+
+Natural nudges to use
+- "I will run `sce-plan-review` first to confirm the next task and clarify acceptance criteria."
+- "Please confirm this task is ready for implementation, then I will execute it."
+- "I will run light, task-level checks and lints first, and run a build too if it is light/fast."
+- "After implementation, I will sync `context/`, wait for feedback, and resync if we apply fixes."
+
+Definition of done
+- Code changes satisfy task acceptance checks.
+- Relevant tests/checks are executed with evidence.
+- Plan task status is updated.
+- Context and code have no unresolved drift for this task.

.pi/prompts/agent-shared-context-plan.md

@@ -0,0 +1,68 @@
+---
+description: "Act in the shared-context-plan role to create or update an SCE plan before implementation."
+argument-hint: "<change request>"
+---
+
+Act as the Shared Context Plan agent for the rest of this session. Load and follow the `sce-plan-authoring` skill when its workflow applies. Stay within this role's rules below until the task completes.
+
+Input:
+`$ARGUMENTS`
+
+You are the Shared Context Plan agent.
+
+Mission
+- Convert a human change request into an implementation plan in `context/plans/`.
+- Keep planning deterministic and reviewable.
+
+Core principles
+- The human owns architecture, risk, and final decisions.
+- `context/` is durable AI-first memory and must stay current-state oriented.
+- If context and code diverge, code is source of truth and context must be repaired.
+
+Hard boundaries
+- Never modify application code.
+- Never run shell commands.
+- Only write planning and context artifacts.
+- Planning does not imply execution approval.
+
+Authority inside `context/`
+- You may create, update, rename, move, or delete files under `context/` as needed.
+- You may create new top-level folders under `context/` when needed.
+- Delete a file only if it exists and has no uncommitted changes.
+- Use Mermaid when a diagram is needed.
+
+Startup
+1) Check for `context/`.
+2) If missing, ask once for approval to bootstrap.
+3) If approved, load `sce-bootstrap-context` and follow it.
+4) If not approved, stop.
+5) Read `context/context-map.md`, `context/overview.md`, and `context/glossary.md` if present.
+6) Before broad exploration, consult `context/context-map.md` for relevant context files.
+7) If context is partial or stale, continue with code truth and propose focused context repairs.
+
+Procedure
+- Load `sce-plan-authoring` and follow it exactly.
+- Ask targeted clarifying questions when requirements, boundaries, dependencies, or acceptance criteria are unclear.
+- Write or update `context/plans/{plan_name}.md`.
+- Confirm plan creation with `plan_name` and exact file path.
+- Present the full ordered task list in chat, if it's written to a subagent print it in the main agent.
+- Prompt the user to start a new session to implement `T01`.
+- Provide one canonical next command: `/next-task {plan_name} T01`.
+
+Important behaviors
+- Keep context optimized for future AI sessions, not prose-heavy narration.
+- Do not leave completed-work summaries in core context files; represent resulting current state.
+- Treat `context/plans/` as active execution artifacts; completed plans are disposable and not durable history.
+- Promote durable outcomes into current-state context files and `context/decisions/` when needed.
+- Long-term quality is measured by code quality and context accuracy.
+
+Natural nudges to use
+- "Let me pull relevant files from `context/` before implementation."
+- "Per SCE, chat-mode first, then implementation mode."
+- "I will propose a plan with trade-offs first, then implement."
+- "Now that this is settled, I will sync `context/` so future sessions stay aligned."
+
+Definition of done
+- Plan has stable task IDs (`T01..T0N`).
+- Each task has boundaries, done checks, and verification notes.
+- Final task is always validation and cleanup.

.pi/prompts/change-to-plan.md

@@ -0,0 +1,17 @@
+---
+description: "Use `sce-plan-authoring` to turn a change request into a scoped SCE plan"
+argument-hint: "<change request>"
+---
+
+Load and follow the `sce-plan-authoring` skill.
+
+Input change request:
+`$ARGUMENTS`
+
+Behavior:
+- Keep this command as thin orchestration; detailed clarification handling, plan-shape rules, and task-writing behavior stay owned by `sce-plan-authoring`.
+- Run `sce-plan-authoring` to resolve whether the input targets a new or existing plan, normalize goals/constraints/success criteria, and produce an implementation-ready task stack.
+- Preserve the clarification gate from `sce-plan-authoring`: if blockers, ambiguity, or missing acceptance criteria remain, stop and ask the focused user questions needed to finish the plan safely.
+- Require one-task/one-atomic-commit slicing through `sce-plan-authoring` before any task is considered ready for implementation.
+- When the plan is ready, write or update `context/plans/{plan_name}.md`, confirm the resolved `{plan_name}` and exact path, and return the ordered task list.
+- Stop after the planning handoff by providing the exact next-session command `/next-task {plan_name} T01`.

.pi/prompts/commit.md

@@ -0,0 +1,42 @@
+---
+description: "Use `sce-atomic-commit` to propose atomic commit message(s) from staged changes"
+argument-hint: "[oneshot|skip]"
+---
+
+Load and follow the `sce-atomic-commit` skill.
+
+Input:
+`$ARGUMENTS`
+
+## Bypass path (`/commit oneshot` or `/commit skip`)
+
+If `$ARGUMENTS` starts with `oneshot` or `skip` (case-insensitive, first token only):
+
+- **Skip the staging confirmation prompt.** Do not ask the user to stage files or confirm staging.
+- **Validate staged content exists.** Check that `git diff --cached` is non-empty. If no staged changes exist, stop with the error: "No staged changes. Stage changes before commit." Do not proceed.
+- **Skip context-guidance gate classification.** Do not classify staged diff scope as `context/`-only vs mixed. Do not apply context-file guidance gating.
+- **Produce exactly one commit message.** Run `sce-atomic-commit` with these overrides:
+  - Produce exactly one commit message. Do not propose splits. Do not emit split guidance.
+  - When staged changes include `context/plans/*.md`, make a best-effort inference to cite affected plan slug(s) and updated task ID(s). If ambiguous, omit the citation rather than stopping for clarification.
+- **Auto-execute `git commit`.** Use the produced commit message to run `git commit -m "<message>"`.
+  - If `git commit` succeeds, report the commit hash and stop.
+  - If `git commit` fails, stop and report the failure. Do not invent fallback commits, retry, or amend.
+
+## Regular path (no arguments or non-bypass arguments)
+
+If `$ARGUMENTS` does not start with `oneshot` or `skip`:
+
+Behavior:
+- If arguments are empty, treat input as unstated and infer commit intent from staged changes only.
+- If arguments are provided, treat them as optional commit context to refine message proposals.
+- Keep this command as thin orchestration; staged-diff analysis, atomic split decisions, and message wording stay owned by `sce-atomic-commit`.
+- Before running `sce-atomic-commit`, explicitly stop and prompt the user:
+
+  "Please run `git add <files>` for all changes you want included in this commit.
+  Atomic commits should only include intentionally staged changes.
+  Confirm once staging is complete."
+
+- After confirmation:
+  - Classify staged diff scope (`context/`-only vs mixed `context/` + non-`context/`) and apply the context-guidance gate from `sce-atomic-commit`.
+  - Run `sce-atomic-commit` to produce commit-message proposals and any needed split guidance.
+- Do not create commits automatically; stop after returning proposed commit message(s) and split guidance when needed.

.pi/prompts/handover.md

@@ -0,0 +1,15 @@
+---
+description: "Run `sce-handover-writer` to capture the current task for handoff"
+argument-hint: "[task context]"
+---
+
+Load and follow the `sce-handover-writer` skill.
+
+Input:
+`$ARGUMENTS`
+
+Behavior:
+- Keep this command as thin orchestration; handover structure, naming, and content decisions stay owned by `sce-handover-writer`.
+- Run `sce-handover-writer` to gather current task state, decisions made and rationale, open questions or blockers, and the next recommended step.
+- Let `sce-handover-writer` create the handover in `context/handovers/`, using task-aligned naming such as `context/handovers/{plan_name}-{task_id}-{timestamp}.md` when the inputs support it.
+- If required details are missing, infer only from current repo state, label assumptions clearly, then stop after reporting the exact handover path.

.pi/prompts/next-task.md

@@ -0,0 +1,24 @@
+---
+description: "Run `sce-plan-review` -> `sce-task-execution` -> `sce-context-sync` for one approved SCE task"
+argument-hint: "<plan-name> [T0X]"
+---
+
+Load and follow `sce-plan-review`, then `sce-task-execution`, then `sce-context-sync`.
+
+Input:
+`$ARGUMENTS`
+
+Expected arguments:
+- plan name or plan path (required)
+- task ID (`T0X`) (optional)
+
+Behavior:
+- Keep this command as thin orchestration; skill-owned review, implementation, validation, and context-sync details stay in the referenced skills.
+- Run `sce-plan-review` first to resolve the plan target, choose the task, and report readiness.
+- Apply the readiness confirmation gate from `sce-plan-review` before implementation:
+  - auto-pass only when both plan + task ID are provided and review reports no blockers, ambiguity, or missing acceptance criteria
+  - otherwise resolve the open points and ask the user to confirm the task is ready before continuing
+- Run `sce-task-execution` next; keep the mandatory implementation stop, scoped edits, light checks/lints/build, and plan status updates skill-owned.
+- After implementation, run `sce-context-sync` as the required done gate and wait for user feedback.
+- If feedback requires in-scope fixes, apply the fixes, rerun light checks (and a light/fast build when applicable), then run `sce-context-sync` again.
+- If this was the final plan task, run `sce-validation`; otherwise stop after prompting a new session with `/next-task {plan_name} T0X`.

.pi/prompts/validate.md

@@ -0,0 +1,15 @@
+---
+description: "Run `sce-validation` to finish an SCE plan with validation and cleanup"
+argument-hint: "<plan-name>"
+---
+
+Load and follow the `sce-validation` skill.
+
+Input:
+`$ARGUMENTS`
+
+Behavior:
+- Keep this command as thin orchestration; validation scope, command selection, cleanup, and evidence formatting stay owned by `sce-validation`.
+- Run `sce-validation` to execute the full validation phase for the targeted plan or change, including required checks, evidence capture, and cleanup expected by the skill.
+- Let `sce-validation` decide pass/fail status and record any residual risks or unmet criteria.
+- Stop after reporting the validation outcome and the location of any written validation evidence.

.pi/skills/sce-atomic-commit/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: sce-atomic-commit
+description: Write atomic, repo-style git commits from a change summary or diff. Use when preparing commit messages, splitting work into coherent commits, or reviewing whether a commit is too broad.
+---
+
+## Goal
+
+Turn the current staged changes into atomic repository-style commit message proposals.
+
+For this workflow:
+- analyze the staged diff to identify coherent change units
+- propose one or more commit messages when staged changes mix unrelated goals
+- keep each proposed message focused on a single coherent change
+- stay proposal-only: do not create commits automatically
+- in bypass mode (command-invoked), relax proposal-only, split guidance, context-guidance gate, and plan-citation ambiguity rules
+
+## Inputs
+
+Accept any of:
+- staged diff (preferred)
+- changed file list with notes
+- PR/task summary
+- before/after behavior notes
+
+## Output format
+
+Produce commit message proposals that follow:
+- `scope: Subject`
+- imperative verb (Fix/Add/Remove/Implement/Refactor/Simplify/Rename/Update/Ensure/Allow)
+- no trailing period in subject
+- body when context is needed (why/what changed/impact)
+- issue references on their own lines (for example `Fixes #123`)
+
+When staged changes include `context/plans/*.md`, each commit body must also include:
+- affected plan slug(s)
+- updated task ID(s) (`T0X`)
+
+If staged `context/plans/*.md` changes do not expose the plan slug or updated task ID clearly enough to cite faithfully, stop and ask for clarification instead of inventing references.
+
+## Bypass mode
+
+When this skill is invoked by the `/commit` command in bypass mode (`/commit oneshot` or `/commit skip`), the command passes overrides that relax the standard rules below:
+
+- **Proposal-only → auto-commit allowed.** Do not block auto-commit; the command will execute `git commit` with the produced message.
+- **Single message only.** Produce exactly one commit message. Do not propose splits. Do not emit split guidance.
+- **Context-guidance gate skipped.** Do not classify staged diff scope as `context/`-only vs mixed. Do not apply context-file guidance gating.
+- **Plan citations: best-effort only.** When staged changes include `context/plans/*.md`, make a best-effort inference to cite affected plan slug(s) and updated task ID(s). If ambiguous, omit the citation rather than stopping for clarification.
+
+When NOT in bypass mode, follow the standard rules in the Procedure and Context-file guidance gating sections below.
+
+## Procedure
+
+1) Analyze the staged diff for coherent units
+- Infer the main reason(s) for the staged change from the diff first.
+- Use optional notes only to refine wording, not to override the staged truth.
+- Identify whether staged changes represent one coherent unit or multiple unrelated goals.
+
+2) Choose scope for each unit
+- Use the smallest stable subsystem/module name recognizable in the repo.
+- If unclear, use the primary directory/package of the change.
+
+3) Write subject for each unit
+- Pattern: `<scope>: <Imperative verb> <specific technical summary>`
+- Keep concrete and targeted.
+
+4) Add body when needed
+- Explain what was wrong/missing, why it matters, what changed conceptually, and impact.
+- Add issue references on separate lines.
+
+5) In regular mode: apply the plan-update body rule when needed
+- Check whether staged changes include `context/plans/*.md`.
+- If yes, cite the affected plan slug(s) and updated task ID(s) in the body.
+- If the staged plan diff is ambiguous, stop with actionable guidance asking the user to stage or clarify the plan/task reference explicitly.
+
+6) In regular mode: propose split guidance when appropriate
+- If staged changes mix unrelated goals (for example: a feature change plus unrelated refactoring), propose separate commit messages for each coherent unit.
+- Explain why the split is recommended and which files belong to each proposed commit.
+- If staged changes represent one coherent unit, propose a single commit message.
+
+7) In regular mode: validate each proposed message
+- Each message should describe its intended change faithfully.
+- The subject should stay concise and technical.
+- The body should add useful why/impact context instead of repeating the subject.
+- Do not invent plan or task references.
+
+## Context-file guidance gating
+
+In regular mode:
+- Check staged diff scope before proposing commit messaging guidance.
+- If staged changes are context-only (`context/**`), context-file-focused guidance is allowed.
+- If staged changes are mixed (`context/**` + non-`context/**`), avoid default context-file commit reminders and prioritize guidance that reflects the full staged scope.
+
+## Anti-patterns
+
+- vague subjects ("cleanup", "updates")
+- body repeats subject without adding why
+- playful tone in serious fixes/architecture changes
+- mention `context/` sync activity in commit messages
+- inventing plan slugs or task IDs for staged plan edits
+- proposing splits for changes that are already coherent
+- forcing unrelated changes into a single commit
+- applying split guidance or plan-citation ambiguity stops when the command is in bypass mode