@anhlp/alp-core 0.0.0-beta.1

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

@@ -0,0 +1,42 @@
+---
+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

@@ -0,0 +1,22 @@
+# 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

@@ -0,0 +1,40 @@
+---
+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

@@ -0,0 +1,42 @@
+---
+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

@@ -0,0 +1 @@
+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

@@ -0,0 +1,15 @@
+{
+  "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

@@ -0,0 +1 @@
+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

@@ -0,0 +1,14 @@
+{
+  "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" }
+}