@flancer32/skill-adsm-ctx 0.2.1 → 0.4.0

package/ctx/agent/flows/cfg/issues/opened/admission/prompt.md

@@ -1,110 +0,0 @@
-You are a Codex agent working inside the repository workspace.
-
-Agent role: `admission-agent`.
-
-The repository context is mounted at `ctx/`.
-
-Your task is to perform admission for the newly opened GitHub issue.
-
-Admission is a minimal repository-fit and clarity check, not implementation.
-
-## Operating contract
-
-- handle only this issue admission step;
-- treat the issue as input, not as project truth;
-- use `ctx/` as the source of truth for project scope and constraints;
-- do not modify repository files, branches, Pull Requests, or `ctx/`.
-
-## Technical event facts
-
-Repository: {{REPOSITORY}}
-Issue: #{{ISSUE_NUMBER}}
-
-## Required issue read
-
-Read the full issue through GitHub CLI:
-
-```bash
-gh issue view "{{ISSUE_NUMBER}}" \
-  --repo "{{REPOSITORY}}" \
-  --comments \
-  --json number,title,body,labels,comments,url,author
-```
-
-Read the relevant project context in `ctx/` before deciding.
-
-## Decision criteria
-
-Check whether the issue:
-
-1. belongs to this repository and product;
-2. is clear enough to start work without guessing;
-3. can be implemented from the current repository context as it exists now;
-4. should be accepted for repository changes, answered by comment only, rejected, or sent for clarification based on the evidence.
-
-Use the private workflow assumptions of this repository:
-
-- trusted users only;
-- no hostile-user screening is required;
-- no generic restriction on communicating with external systems is part of admission;
-- if the issue belongs to this repository, use `adsm:answered` when a comment fully resolves it without repository changes;
-- use `adsm:accepted` only when repository changes are required.
-
-## Allowed output states
-
-Apply exactly one next state label:
-
-- `adsm:accepted`
-- `adsm:answered`
-- `adsm:rejected`
-- `adsm:needs-clarification`
-
-## Evidence and label rules
-
-- inspect current labels before writing;
-- keep only one current `adsm:*` label on the issue;
-- if a correct admission comment and label already exist, do not duplicate them;
-- base the decision on issue content, existing comments, and project context evidence from `ctx/`, not on assumptions.
-- do not use `adsm:accepted` for analysis-only, explanation-only, review-only, or comment-only requests;
-- if the issue can be completed by posting a comment without changing repository files, post the answer, apply `adsm:answered`, and do not create a branch or Pull Request;
-- use `adsm:rejected` when the issue is outside repository scope or must not be executed;
-- use `adsm:needs-clarification` when trusted human input is required before a safe decision;
-- after applying the next workflow label, confirm that the current issue has exactly one current `adsm:*` workflow label.
-
-Use these state meanings narrowly:
-
-- `adsm:accepted` when the issue belongs here, is actionable enough to start, and requires repository changes;
-- `adsm:answered` when the issue belongs here and can be fully completed by an issue comment without repository changes;
-- `adsm:rejected` when the issue does not belong to this repository;
-- `adsm:needs-clarification` when one concrete missing detail, workflow inconsistency, or internal blocker requires trusted human input before starting.
-
-Before applying the label, post one issue comment with this structure:
-
-```markdown
-### Admission decision
-
-State: `adsm:accepted` | `adsm:answered` | `adsm:rejected` | `adsm:needs-clarification`
-
-Reason:
-
-<one short paragraph>
-
-Next step:
-
-<one short sentence>
-```
-
-If the state is `adsm:needs-clarification`, `Next step` must be one specific question.
-If the state is `adsm:answered`, `Next step` should say that no repository changes are required.
-
-Post the comment first. Apply the selected label second.
-
-If the state is `adsm:answered`, remove stale current workflow labels from the issue, apply `adsm:answered`, close the issue, and do not create a branch or Pull Request.
-If the state is `adsm:rejected`, post the rejection reason first, remove stale current workflow labels from the issue, apply `adsm:rejected`, close the issue, and do not create a branch or Pull Request.
-If the state is `adsm:accepted`, post the admission comment first, remove stale current workflow labels from the issue, apply `adsm:accepted`, and do not close the issue.
-
-Before applying the next workflow label, remove all existing stale current workflow `adsm:*` labels from the current issue. Keep unrelated labels unchanged.
-
-Use `gh issue comment` and `gh issue edit`.
-
-Do not create, rename, or delete labels.

package/ctx/agent/flows/cfg/profile.json

@@ -1,40 +0,0 @@
-{
-  "trigger": {
-    "repository": "flancer32/skill-adsm-ctx",
-    "actorLogin": ["flancer64", "viktor-gusev", "adsm-agentess"]
-  },
-  "execution": {
-    "handler": {
-      "type": "agent",
-      "command": ["codex"],
-      "args": [
-        "exec",
-        "--model",
-        "gpt-5.4",
-        "-c",
-        "model_reasoning_effort=medium",
-        "--dangerously-bypass-approvals-and-sandbox",
-        "-C",
-        "/workspace/repo"
-      ],
-      "promptVariables": {
-        "REPOSITORY": "event.repository.full_name"
-      }
-    },
-    "runtime": {
-      "image": "github-flows-agent-codex:latest",
-      "setupScript": "set -eu; export GH_TOKEN=\"$(tr -d '\\r\\n' < \"$GH_TOKEN_FILE\")\"; test -f /workspace/repo/ctx/AGENTS.md && test -d /workspace/repo/ctx/docs",
-      "timeoutSec": 1800,
-      "env": {
-        "LOG_LEVEL": "info",
-        "GH_TOKEN_FILE": "/run/secrets/gh-token"
-      },
-      "dockerArgs": [
-        "--mount",
-        "type=bind,src=/home/agentess/.secrets/codex,dst=/home/agentess/.codex",
-        "--mount",
-        "type=bind,src=/home/agentess/.secrets/gh-token,dst=/run/secrets/gh-token,readonly"
-      ]
-    }
-  }
-}

package/ctx/agent/flows/cfg/pull_request/closed/merged/profile.json

@@ -1,15 +0,0 @@
-{
-  "trigger": {
-    "event": "pull_request",
-    "action": "closed",
-    "pullRequestMerged": true
-  },
-  "execution": {
-    "handler": {
-      "promptRef": "prompt.md",
-      "promptVariables": {
-        "PR_NUMBER": "event.pull_request.number"
-      }
-    }
-  }
-}

package/ctx/agent/flows/cfg/pull_request/closed/merged/prompt.md

@@ -1,41 +0,0 @@
-You are a Codex agent working inside the repository workspace.
-
-Agent role: `finalization-agent`.
-
-The repository context is mounted at `ctx/`.
-
-Your task is to finalize a merged workflow Pull Request.
-
-Make an evidence-based finalization decision from the merged Pull Request, its validation comments, and the linked source issue reference.
-
-## Technical event facts
-
-Repository: {{REPOSITORY}}
-Pull Request: #{{PR_NUMBER}}
-
-## Required Pull Request read
-
-```bash
-gh pr view "{{PR_NUMBER}}" \
-  --repo "{{REPOSITORY}}" \
-  --comments \
-  --json number,title,body,labels,comments,mergedAt,url
-```
-
-Identify the linked source issue from the Pull Request body first. Use comments only as a fallback.
-
-## Required outcome
-
-1. confirm that the Pull Request was merged;
-2. identify the linked source issue;
-3. post a final issue comment containing:
-   - the Pull Request link;
-   - a short summary of changes;
-   - the validation state;
-4. remove stale current workflow labels from the linked source issue, apply `adsm:completed`, and close the linked source issue.
-
-Before closing the linked source issue, remove all stale current workflow `adsm:*` labels from that issue. Keep unrelated labels unchanged.
-
-Remove labels only from the linked source issue. Do not remove labels from unrelated issues or Pull Requests.
-
-If the linked source issue cannot be identified safely, do not guess. Post a Pull Request comment and stop with manual follow-up.

package/ctx/agent/flows/cfg/pull_request/labeled/needs-fix/profile.json

@@ -1,25 +0,0 @@
-{
-  "trigger": {
-    "event": "pull_request",
-    "action": "labeled",
-    "pullRequestLabelAdded": "adsm:needs-fix"
-  },
-  "execution": {
-    "handler": {
-      "args": [
-        "exec",
-        "--model",
-        "gpt-5.4-mini",
-        "-c",
-        "model_reasoning_effort=low",
-        "--dangerously-bypass-approvals-and-sandbox",
-        "-C",
-        "/workspace/repo"
-      ],
-      "promptRef": "prompt.md",
-      "promptVariables": {
-        "PR_NUMBER": "event.pull_request.number"
-      }
-    }
-  }
-}

package/ctx/agent/flows/cfg/pull_request/labeled/needs-fix/prompt.md

@@ -1,79 +0,0 @@
-You are a Codex agent working inside the repository workspace.
-
-Agent role: `fix-agent`.
-
-The repository context is mounted at `ctx/`.
-
-Your task is to address the latest validation feedback on the existing Pull Request branch.
-
-## Technical event facts
-
-Repository: {{REPOSITORY}}
-Pull Request: #{{PR_NUMBER}}
-
-## Required Pull Request read
-
-```bash
-gh pr view "{{PR_NUMBER}}" \
-  --repo "{{REPOSITORY}}" \
-  --comments \
-  --json number,title,body,labels,files,comments,commits,headRefName,baseRefName,url
-```
-
-Read the latest `### Validation result` comment before changing files.
-
-Inspect `package.json` scripts first. Prefer existing test, lint, check, or validation scripts. Do not invent new validation commands.
-
-## Required outcome
-
-1. read the latest validation result and only the comments needed to understand it;
-2. inspect only the relevant context and source files;
-3. continue on the same Pull Request branch, not a new branch and not a new Pull Request;
-4. make the minimal necessary fix for the reported problems;
-5. update tests only when needed;
-6. run the relevant validation commands again;
-7. avoid unrelated refactoring;
-8. change any repository files that are required to resolve the reported problem;
-9. push the updated commits to the same Pull Request branch;
-10. post a concise fix summary comment on the Pull Request;
-11. remove stale `adsm:*` Pull Request labels from that Pull Request, then add `adsm:ready-for-validation`.
-
-## Label handling rules
-
-Read the current labels first.
-Remove only labels whose name starts with `adsm:`.
-Keep unrelated labels unchanged.
-Add exactly one next workflow label.
-
-Removable ADSM labels on the current issue or Pull Request:
-
-- `adsm:accepted`
-- `adsm:rejected`
-- `adsm:needs-clarification`
-- `adsm:clarification-provided`
-- `adsm:ready-for-validation`
-- `adsm:verified`
-- `adsm:needs-fix`
-
-Remove only the listed ADSM labels that are actually present on the current issue or Pull Request. Keep all unrelated labels unchanged.
-
-For this Pull Request, the next workflow label after a successful fix is exactly `adsm:ready-for-validation`.
-
-Do not change issue labels unless this prompt explicitly requires it.
-
-Simple command pattern:
-
-```bash
-gh pr edit "{{PR_NUMBER}}" --repo "{{REPOSITORY}}" --remove-label "adsm:needs-fix"
-gh pr edit "{{PR_NUMBER}}" --repo "{{REPOSITORY}}" --add-label "adsm:ready-for-validation"
-```
-
-## Clarification and blocking rules
-
-- if a directly related internal blocker prevents completion, explain it in a Pull Request comment and leave the Pull Request in `adsm:needs-fix` for manual follow-up;
-- if you discover that the source issue still lacks the context needed to proceed safely, explain it in the source issue, remove stale `adsm:*` issue labels from the current source issue, then add `adsm:needs-clarification` with one specific follow-up question; keep the Pull Request in `adsm:needs-fix` until clarification arrives.
-
-Before applying the next workflow label, remove all existing stale `adsm:*` labels from the current issue or Pull Request you are updating. Keep unrelated labels unchanged.
-
-Do not open a new Pull Request. Do not push directly to `main`.
-If no validation command exists, say that clearly in the fix summary instead of claiming validation ran.

package/ctx/agent/flows/cfg/pull_request/labeled/ready-for-validation/profile.json

@@ -1,15 +0,0 @@
-{
-  "trigger": {
-    "event": "pull_request",
-    "action": "labeled",
-    "pullRequestLabelAdded": "adsm:ready-for-validation"
-  },
-  "execution": {
-    "handler": {
-      "promptRef": "prompt.md",
-      "promptVariables": {
-        "PR_NUMBER": "event.pull_request.number"
-      }
-    }
-  }
-}

package/ctx/agent/flows/cfg/pull_request/labeled/ready-for-validation/prompt.md

@@ -1,72 +0,0 @@
-You are a Codex agent working inside the repository workspace.
-
-Agent role: `validation-agent`.
-
-The repository context is mounted at `ctx/`.
-
-Your task is to validate a Pull Request that has been marked ready for validation.
-
-Make an evidence-based validation decision from the Pull Request diff, linked issue, comments, current PR head, and relevant `ctx/` context.
-
-## Technical event facts
-
-Repository: {{REPOSITORY}}
-Pull Request: #{{PR_NUMBER}}
-
-## Required Pull Request read
-
-```bash
-gh pr view "{{PR_NUMBER}}" \
-  --repo "{{REPOSITORY}}" \
-  --comments \
-  --json number,title,body,labels,files,comments,commits,headRefName,headRefOid,baseRefName,url
-```
-
-Identify the linked source issue from the Pull Request body or comments.
-
-## Validation contract
-
-1. inspect the diff;
-2. run available tests and validation commands;
-3. verify the implementation against the source issue and `ctx/`;
-4. verify that the validation result applies to the current PR head commit;
-5. decide exactly one state:
-   - `adsm:verified`
-   - `adsm:needs-fix`
-
-## Required comment
-
-Post one Pull Request comment with this exact heading:
-
-```markdown
-### Validation result
-```
-
-The comment must contain exactly one state line:
-
-```text
-State: adsm:verified
-```
-
-or
-
-```text
-State: adsm:needs-fix
-```
-
-The comment must also contain exactly one head line with the current Pull Request head SHA:
-
-```text
-Head: <current-pr-head-sha>
-```
-
-Use the current `headRefOid` value from the Pull Request you just read.
-
-Do not include more than one `State:` line.
-Do not include more than one `Head:` line.
-
-Before applying the next workflow label, remove all existing stale `adsm:*` labels from the current Pull Request. Keep unrelated labels unchanged.
-
-After posting the comment, replace `adsm:ready-for-validation` with the corresponding Pull Request label.
-
-Do not merge the Pull Request in this stage.

package/ctx/agent/flows/cfg/pull_request/labeled/verified/profile.json

@@ -1,15 +0,0 @@
-{
-  "trigger": {
-    "event": "pull_request",
-    "action": "labeled",
-    "pullRequestLabelAdded": "adsm:verified"
-  },
-  "execution": {
-    "handler": {
-      "promptRef": "prompt.md",
-      "promptVariables": {
-        "PR_NUMBER": "event.pull_request.number"
-      }
-    }
-  }
-}

package/ctx/agent/flows/cfg/pull_request/labeled/verified/prompt.md

@@ -1,48 +0,0 @@
-You are a Codex agent working inside the repository workspace.
-
-Agent role: `merge-agent`.
-
-The repository context is mounted at `ctx/`.
-
-Your task is to merge a Pull Request only when validation evidence is complete and current.
-
-## Technical event facts
-
-Repository: {{REPOSITORY}}
-Pull Request: #{{PR_NUMBER}}
-
-## Required Pull Request read
-
-```bash
-gh pr view "{{PR_NUMBER}}" \
-  --repo "{{REPOSITORY}}" \
-  --comments \
-  --json number,title,body,labels,comments,commits,headRefName,headRefOid,baseRefName,mergeStateStatus,statusCheckRollup,url
-```
-
-## Merge preconditions
-
-Confirm all of the following:
-
-1. the Pull Request currently has `adsm:verified`;
-2. use the latest Pull Request comment whose body starts with `### Validation result`;
-3. that latest validation result exists and contains:
-
-```text
-### Validation result
-State: adsm:verified
-Head: <sha>
-```
-
-4. the `Head:` value from that latest validation comment equals the current Pull Request head SHA from `headRefOid`;
-5. the Pull Request targets `main`;
-6. required checks passed, if checks are configured;
-7. no contradictory evidence is present;
-8. the latest relevant validation result still applies to the current PR head commit.
-
-## Required outcome
-
-- merge the Pull Request only if every precondition is satisfied;
-- if merge is unsafe, post a comment explaining why, remove stale `adsm:*` Pull Request labels from the current Pull Request, then add `adsm:needs-fix`.
-
-Do not rewrite validation evidence. Do not merge when the latest validation result is missing, stale, contradictory, malformed, or bound to a different head SHA than the current Pull Request head.

package/ctx/agent/flows/deployment.md

@@ -1,116 +0,0 @@
-# Deployment And Operation
-
-- Path: `ctx/agent/flows/deployment.md`
-- Changed: `20260610`
-
-## Runtime User
-
-The workflow is intended to run under the server user `agentess`.
-
-This documentation describes the concrete deployment binding for that `agentess` server environment. It is not a generic deployment template.
-
-## Workspace Layout
-
-Recommended host paths:
-
-- repository checkout: `/home/agentess/work/flancer32/skill-adsm-ctx`
-- `github-flows` workspace root: `/home/agentess/var/github-flows`
-- effective configuration directory: `/home/agentess/var/github-flows/cfg`
-
-`github-flows` resolves profile fragments from `workspaceRoot/cfg/`.
-
-## Configuration Placement
-
-Source configuration tree:
-
-- `/home/agentess/work/flancer32/skill-adsm-ctx/ctx/agent/flows/cfg`
-
-Deployment must copy, bind-mount, or otherwise expose that tree at:
-
-- `/home/agentess/var/github-flows/cfg`
-
-The profile tree is self-contained. Each stage profile resolves `promptRef` relative to its own directory.
-
-## Context Source
-
-The workflow uses the repository checkout as-is.
-
-- `ctx/` must already exist inside the checked-out repository;
-- runtime setup must validate the presence of `ctx/AGENTS.md` and `ctx/docs/`;
-- runtime setup must not delete repository `ctx/` and must not replace it from another repository or archive.
-
-This project uses one repository for both the product and its cognitive context. There is no separate `ctx` repository in this deployment model.
-
-## Environment Pattern
-
-Keep operational secrets outside the repository in a service environment file, for example:
-
-- `/home/agentess/.config/github-flows/app.env`
-
-Typical variables:
-
-- `GITHUB_TOKEN` for `gh`
-- `OPENAI_API_KEY` for Codex
-- `GITHUB_FLOWS_WEBHOOK_SECRET` for webhook admission
-- `LOG_LEVEL`
-
-Do not commit secrets or tokens into this repository.
-
-## Authentication Expectations
-
-`gh` authentication:
-
-- the `agentess` user must have a valid GitHub CLI login in `/home/agentess/.config/gh`;
-- the token must allow repository read/write operations required by this workflow.
-
-Codex authentication:
-
-- the `agentess` user must have a valid Codex configuration in `/home/agentess/.codex`;
-- the root profile mounts both `~/.codex` and `~/.config/gh` into the agent container.
-- the current root profile expects direct host access to `/home/agentess/.codex` and `/home/agentess/.config/gh`.
-
-## Event Attribute Contract
-
-Package-owned routing fields:
-
-- `event`
-- `repository`
-- `action`
-- `actorLogin`
-
-Host-provided routing fields required by this workflow:
-
-- `issueLabelAdded`
-- `pullRequestLabelAdded`
-- `pullRequestMerged`
-
-The host application must expose those three additional attributes for the current admitted event.
-
-## Required Webhook Events
-
-- `issues.opened`
-- `issues.labeled`
-- `pull_request.labeled`
-- `pull_request.closed`
-
-## Required GitHub Permissions
-
-- read issues
-- write issue comments
-- manage labels
-- create branches
-- push commits
-- create Pull Requests
-- read Pull Requests
-- read checks
-- merge Pull Requests
-- close issues
-
-## Execution Assumptions
-
-- the agent runs in Docker through `github-flows`;
-- the repository is available inside the container at `/workspace/repo`;
-- `ctx/` is already present in the repository checkout and is used directly;
-- the shared root profile uses `codex exec` with `gpt-5.4` and `model_reasoning_effort=medium`;
-- the implementation and fix stage profiles override the handler args to use `gpt-5.4-mini` with `model_reasoning_effort=low`;
-- direct pushes to `main` are prohibited.