@anhlp/alp 0.0.1-beta.3 → 0.0.1-beta.6

package/templates/skills/prompt-leverage/SKILL.md

@@ -1,37 +0,0 @@
----
-name: prompt-leverage
-description: Convert a task into a self-contained delegation brief without changing user intent or predetermining the solution. Use before Main assigns Lead or Lead assigns Peer, or when asked to improve an execution prompt.
----
-
-# Prepare an actionable brief
-
-Identify the requested result and the recipient's responsibility. Preserve actual
-user constraints, but distinguish them from current design choices the recipient
-may question. Do not seed a reviewer's verdict or turn a preferred implementation
-into an invented requirement.
-
-A useful brief supplies the root, outcome, relevant context, owned/excluded paths,
-authority, important dependencies, resources, verification, and expected handoff.
-Use [the brief format](references/brief-template.md) for substantial assignments;
-combine fields for a small task. A real base SHA is useful in a Git repository but
-is not required for a plain file project. Never fabricate one.
-
-Verification must describe the observable behavior and, when known, its executable
-check. If a command still needs discovery, state how it should be established from
-the repository. Do not invent a test command just to fill a field.
-
-Choose the relevant installed skill by task type and mention it in the brief:
-research -> xia; diagnosis/regression -> bug-loop; an authorized commit handoff ->
-smart-commits. Do not require skills absent from the recipient's package. A reviewer
-can inspect an existing candidate without additional skill ceremonies.
-
-On current Paseo, pass the full brief as alp_delegate.task with an authorized agent
-and optional mode. Model and reasoning inherit from the parent; there is no model
-argument on this tool. Request read-only for research/review where appropriate.
-Implementation requires workspace-write on the parent and child. The call waits
-for a final handoff, so include everything needed to work without a live Q&A channel.
-
-This skill grants no new authority and never bypasses the configured routing graph.
-If asked only to improve a prompt, return the prompt. If assignment is authorized,
-send it using the actual runtime tool after preparing it. Missing capabilities
-must be reported, not simulated.

package/templates/skills/prompt-leverage/references/brief-template.md

@@ -1,27 +0,0 @@
-# Brief and handoff format
-
-Use enough detail to make an independent worker effective, without prescribing an
-unverified solution. Available context includes ALP.md and the selected agent's own
-instructions; the parent's full transcript is not automatically available.
-
-```text
-Task and recipient:
-Root:
-Outcome:
-Context / prior decisions:
-Required constraints + sources:
-Current technical choices (open to evidence):
-Owned paths / excluded paths:
-Authority and permission mode:
-Dependencies / writer ownership / resource allocation:
-Verification commands or expected observable checks:
-Relevant installed skill, if needed:
-Candidate/base revision, if applicable:
-Return: outcome, artifact, scope, actual checks/results, risks, ownership status.
-```
-
-For read-only review, supply the candidate/artifact and independent acceptance
-criteria. For a correction, include the concrete finding and prior evidence. For
-a resumed assignment, include the findings needed from the previous handoff because
-the next child is a new session. A blocked recipient should return its blocker and
-completed independent work rather than waiting for a nonexistent mailbox.

package/templates/skills/sequence-execution-plan/SKILL.md

@@ -1,42 +0,0 @@
----
-name: sequence-execution-plan
-description: Order multiple ALP work items by real dependencies, verification, and writer ownership. Use when Main or Lead coordinates several outcomes or must replan after a blocker, changed premise, or rejection.
----
-
-# Order executable work
-
-Use the task contract and available evidence. Planning authority comes from the
-current assignment: main coordinates the overall outcome; lead plans technical
-execution within its assigned scope. A peer reports dependencies instead of
-reassigning ownership or widening the plan.
-
-Separate urgency from dependency order. A lower-priority prerequisite may need to
-run first, but it does not close the higher-priority outcome. A mitigation reduces
-current impact; it is not proof of a durable fix.
-
-Build small work items that each deliver observable progress. Keep implementation
-and its direct verification together. Split when an unresolved decision blocks one
-part, separate outcomes need independent acceptance, or a resource/human wait would
-stall unrelated work. Do not impose a fixed task count on a simple change.
-
-For each item identify the result, owner, owned/excluded paths, true prerequisites,
-verification seam, completion evidence, and current state. Distinguish necessary
-foundations from optional improvements and speculative future abstractions.
-
-Arrange Now, Next, and Later using causal explanations: which prerequisite blocks
-which outcome, which check validates it, and which decision opens the next branch.
-Read [the plan format](references/plan-template.md) when a durable multi-item plan
-helps. Use the project's existing plan location; do not create unrelated ignore
-rules or a new planning hierarchy just to satisfy this skill.
-
-Current Paseo delegation is sequential: each parent waits for one child's result.
-Do not promise parallel workers or live upstream mailboxes. A shared checkout has
-one writer at a time; main intervention requires ownership to be released first.
-Allocate ports, scratch paths, and other exclusive resources if the assignment uses
-them. Separate worktrees alone do not isolate ports or a shared database.
-
-Replan when evidence changes a premise, a dependency blocks work, the user changes
-scope, or repeated rejection reveals that the assignment needs restructuring.
-Update the facts and constraints before issuing a revised brief. Preserve unfinished
-acceptance criteria when merging items. Candidate remains candidate until the
-responsible reviewer has evaluated the actual evidence.

package/templates/skills/sequence-execution-plan/references/plan-template.md

@@ -1,22 +0,0 @@
-# Proportional plan format
-
-Use the relevant fields; a plan is a decision aid, not a form-completion exercise.
-
-```text
-Outcome and acceptance evidence:
-User constraints and their sources:
-Current facts / technical assumptions:
-
-ID | Result | Owner | Owned/excluded scope | Prerequisites | Verification | State
-
-Now:
-Next (and what unlocks it):
-Later:
-Writer/resource allocation:
-Open decisions and blockers:
-Replan reason, when applicable:
-```
-
-States can be ready, blocked, running, candidate, accepted, or rejected. An item is
-accepted based on artifacts and verification; a successful process exit is not an
-acceptance criterion by itself. Omit branch/SHA fields in non-Git projects.

package/templates/skills/smart-commits/SKILL.md

@@ -1,40 +0,0 @@
----
-name: smart-commits
-description: Package existing owned changes into focused local Git commits with verification evidence. Use when commits are requested or part of the assigned handoff; do not activate merely because a file was edited.
----
-
-# Package the authorized changes
-
-Confirm this is a Git repository and that local commits belong to the requested
-deliverable. A non-Git task returns file artifacts; do not initialize Git merely to
-produce a SHA. A read-only task cannot commit. Existing user authorization remains
-valid; the skill adds no confirmation gate or permission to push.
-
-Inspect the root, branch, status, unresolved merges, staged paths, and staged/unstaged
-diffs with Git commands. Verify any supplied base revision. Preserve work outside
-the assignment. If unrelated staged changes would enter the commit, stop packaging
-and report the conflict without resetting or unstaging someone else's work.
-
-Group changes by behavior and intent. Keep implementation and its direct tests
-together where useful. Read each included diff and stage only the owned paths or
-hunks. Avoid whole-tree staging in a shared checkout. Do not add unrelated fixes or
-formatting to make a commit easier.
-
-Run the relevant checks from the project/brief, reusing recent results when still
-applicable. State failures and omissions accurately. If hooks may cause external
-side effects, inspect their configured behavior before invoking them and stay within
-the task's authorization. Do not bypass hooks or protections to get a green commit.
-
-Create focused messages explaining the change and its purpose, following the
-repository's convention. Check commit success before reading the candidate SHA.
-Verify that the candidate contains only the intended scope and that the base
-relationship is valid when a base was supplied. A failed commit produces no new
-candidate, and an already-clean tree needs no empty commit.
-
-Do not rewrite a candidate already handed off for review. Corrections should be
-new commits unless rewriting was specifically agreed. Push requires existing explicit
-authorization for the intended remote/branch; a configured remote does not provide it.
-
-Return root, branch, actual base/candidate SHAs, commit summary, owned scope, checks
-and results, remaining work, and push status. Lead/main still review the artifact;
-the writer does not self-accept its work.

package/templates/skills/xia/SKILL.md

@@ -1,42 +0,0 @@
----
-name: xia
-description: Research an unfamiliar implementation, reuse opportunity, or version-sensitive integration using local artifacts and primary sources. Return an evidence-backed recommendation before implementation; do not expand the assigned scope.
----
-
-# Research before building
-
-Start with a named question that affects a decision. Use a short local inspection
-when the relevant seam is clear; broaden to upstream sources only when the question
-requires it. Research is read-only with respect to project artifacts. Temporary
-experiments require an available isolated scratch location and appropriate authority.
-
-1. Establish the actual stack from manifests, lockfiles, configuration, and commands.
-   Read ALP.md and relevant project guidance. Do not infer a stack from folder names.
-2. Search nearby code, tests, configuration, scripts, and docs for existing behavior
-   and reusable parts. Record the scope searched before saying something is absent.
-3. For external behavior, inspect primary upstream source/examples and official
-   documentation matching the installed version. Distinguish current guidance from
-   the version this project actually uses.
-4. Compare viable approaches only where the choice matters. Prefer an existing
-   local capability, then a supported dependency capability, then a small adaptation.
-   Explain what evidence would change the recommendation.
-
-Label significant findings by evidence type:
-
-- Local: file path, command output, test, or repository revision.
-- Upstream: repository URL and revision when available.
-- Docs: official source and applicable version.
-- Inference: a conclusion drawn from the cited evidence, with uncertainty stated.
-
-If browsing is unavailable, return the local findings and the unresolved external
-question. Do not invent a source or claim version compatibility without evidence.
-Research does not authorize installing dependencies, editing code, or deploying.
-
-Return the question, findings/sources, reuse candidates, recommendation, alternatives
-if material, unknowns, and the next decision. Include actual inspection commands and
-results in the handoff. A peer returns this to lead; lead returns unresolved scope
-decisions to main. Main can decide technical matters within the user's authorization.
-
-Use available synchronous delegation for a separate research assignment only when
-helpful. Do not assume a Scout role or parallel session exists; research is a peer
-disposition. An agent can inspect evidence itself without spawning another agent.

package/templates/teams/cafe/HOUSE_RULES.md

@@ -1 +0,0 @@
-In Phở (pho), main implements or directly delegates to peer; do not create lead. In Cafe (cafe), main supervises lead; lead may implement or delegate to peer. The technical coordinator chooses each peer's model and effort. Use oracle for significant uncertainty; use reviewer for logic changes and risky changes, not mandatory for typo/format fixes. Advisors return only to their requesting coordinator.

package/templates/teams/cafe/team.json

@@ -1,15 +0,0 @@
-{
-  "label": "Cafe",
-  "description": "Main supervises lead, who implements or delegates to peer; a supervisor reviews the process.",
-  "main": "main",
-  "members": {
-    "main": { "model": "claude:claude-opus-5-5", "thinking": "high" },
-    "lead": { "role": "lead" },
-    "peer": { "role": "peer" },
-    "oracle": { "role": "advisor" },
-    "reviewer": { "role": "reviewer" }
-  },
-  "delegation": { "main": ["lead", "oracle", "reviewer"], "lead": ["peer", "oracle", "reviewer"] },
-  "maxPeers": 2,
-  "supervisor": { "agent": "supervisor", "model": "claude:claude-sonnet-5", "thinking": "medium" }
-}

package/templates/teams/pho/HOUSE_RULES.md

@@ -1 +0,0 @@
-In Phở (pho), main implements or directly delegates to peer; do not create lead. In Cafe (cafe), main supervises lead; lead may implement or delegate to peer. The technical coordinator chooses each peer's model and effort. Use oracle for significant uncertainty; use reviewer for logic changes and risky changes, not mandatory for typo/format fixes. Advisors return only to their requesting coordinator.

package/templates/teams/pho/team.json

@@ -1,14 +0,0 @@
-{
-  "label": "Phở",
-  "description": "Main implements or delegates to peer; a supervisor reviews the process.",
-  "main": "main",
-  "members": {
-    "main": { "model": "claude:claude-opus-5-5", "thinking": "high" },
-    "peer": { "role": "peer" },
-    "oracle": { "role": "advisor" },
-    "reviewer": { "role": "reviewer" }
-  },
-  "delegation": { "main": ["peer", "oracle", "reviewer"] },
-  "maxPeers": 2,
-  "supervisor": { "agent": "supervisor", "model": "claude:claude-sonnet-5", "thinking": "medium" }
-}