Feat/new

.agents/skills/company-creator/SKILL.md

@@ -1,15 +1,9 @@
 ---
 name: company-creator
 description: >
-  Create agent company packages conforming to the Agent Companies specification
-  (agentcompanies/v1). Use when a user wants to create a new agent company from
-  scratch, build a company around an existing git repo or skills collection, or
-  scaffold a team/department of agents. Triggers on: "create a company", "make me
-  a company", "build a company from this repo", "set up an agent company",
-  "create a team of agents", "hire some agents", or when given a repo URL and
-  asked to turn it into a company. Do NOT use for importing an existing company
-  package (use the CLI import command instead) or for modifying a company that
-  is already running in Taskcore.
+  Create agent company packages that conform to agentcompanies/v1. Use when asked
+  to create a company, scaffold an agent team, hire agents, or turn a repo/skills
+  collection into a company package.
 ---
 
 # Company Creator

.agents/skills/create-agent-adapter/SKILL.md

@@ -1,11 +1,9 @@
 ---
 name: create-agent-adapter
 description: >
-  Technical guide for creating a new Taskcore agent adapter. Use when building
-  a new adapter package, adding support for a new AI coding tool (e.g. a new
-  CLI agent, API-based agent, or custom process), or when modifying the adapter
-  system. Covers the required interfaces, module structure, registration points,
-  and conventions derived from the existing claude-local and codex-local adapters.
+  Create or modify Taskcore agent adapters across server, UI, and CLI surfaces.
+  Use when adding support for a new CLI agent, API agent, custom process, or
+  adapter package.
 ---
 
 # Creating a Taskcore Agent Adapter
@@ -158,7 +156,7 @@ Guidelines:
 - Use `info` for successful checks and context.
 
 Severity policy is product-critical: warnings are not save blockers.  
-Example: for `claude_local`, detected `ANTHROPIC_API_KEY` must be a `warn`, not an `error`, because Claude can still run (it just uses API-key auth instead of subscription auth).
+Example: for `claude_local`, an explicitly configured `ANTHROPIC_API_KEY` or selected managed API connection is `info`: the user chose that authentication. An ambient server key overriding subscription login remains `warn`, not `error`.
 
 ---
 

.agents/skills/deal-with-security-advisory/SKILL.md

@@ -1,10 +1,9 @@
 ---
 name: deal-with-security-advisory
 description: >
-  Handle a GitHub Security Advisory response for Taskcore, including
-  confidential fix development in a temporary private fork, human coordination
-  on advisory-thread comments, CVE request, synchronized advisory publication,
-  and immediate security release steps.
+  Handle confidential GitHub Security Advisory response for Taskcore. Use when
+  coordinating advisory triage, private-fork fixes, CVE/publication steps, and
+  immediate security releases.
 ---
 
 # Security Vulnerability Response Instructions
@@ -196,7 +195,7 @@ This release fixes a critical security vulnerability.
 {{briefDescription}} (e.g., Remote code execution via DNS rebinding in \`local_trusted\` mode)
 
 ### Advisory
-https://github.com/taskcore/taskcore/security/advisories/{{ghsaId}}
+https://github.com/khulnasoft/taskcore/security/advisories/{{ghsaId}}
 
 ### Credit
 Thanks to @{{reporterHandle}} for responsibly disclosing this vulnerability.
@@ -224,7 +223,7 @@ If the CVE hasn't been assigned yet, that's normal — it can take a few hours.
 
 Tell the human operator what you did by posting a comment to this task, including:
 
-* The published advisory URL: `https://github.com/taskcore/taskcore/security/advisories/{{ghsaId}}`
+* The published advisory URL: `https://github.com/khulnasoft/taskcore/security/advisories/{{ghsaId}}`
 * The release URL
 * Whether the CVE has been assigned yet
 * All URLs to any pull requests or branches

.agents/skills/doc-maintenance/SKILL.md

@@ -1,11 +1,9 @@
 ---
 name: doc-maintenance
 description: >
-  Audit top-level documentation (README, SPEC, PRODUCT) against recent git
-  history to find drift — shipped features missing from docs or features
-  listed as upcoming that already landed. Proposes minimal edits, creates
-  a branch, and opens a PR. Use when asked to review docs for accuracy,
-  after major feature merges, or on a periodic schedule.
+  Audit README, SPEC, and PRODUCT docs against recent git history for drift and
+  make minimal PR-ready edits. Use when asked to review docs for accuracy, after
+  major feature merges, or on a schedule.
 ---
 
 # Doc Maintenance Skill

.agents/skills/pr-report/SKILL.md

@@ -1,10 +1,9 @@
 ---
 name: pr-report
 description: >
-  Review a pull request or contribution deeply, explain it tutorial-style for a
-  maintainer, and produce a polished report artifact such as HTML or Markdown.
-  Use when asked to analyze a PR, explain a contributor's design decisions,
-  compare it with similar systems, or prepare a merge recommendation.
+  Produce a maintainer-grade PR or contribution report as HTML or Markdown. Use
+  when asked to deeply review a PR, explain a design, compare systems, or prepare
+  a merge recommendation.
 ---
 
 # PR Report Skill

.agents/skills/prcheckloop/SKILL.md

@@ -1,12 +1,9 @@
 ---
 name: prcheckloop
 description: >
-  Iteratively gets a GitHub pull request's checks green. Detects the PR for the
-  current branch or uses a provided PR number, waits for every check on the
-  latest head SHA to appear and finish, investigates failing checks, fixes
-  actionable code or test issues, pushes, and repeats. Escalates with a precise
-  blocker when failures are external, flaky, or not safely fixable. Use when a
-  PR still has unsuccessful checks after review fixes, including after greploop.
+  Iterate on a GitHub PR until latest-head checks are green or a precise blocker
+  is named. Use when a PR still has failing or pending checks after review fixes,
+  including after greploop.
 ---
 
 # PRCheckloop

.agents/skills/release-changelog/SKILL.md

@@ -23,21 +23,66 @@ intended release date (UTC) plus the next same-day stable patch slot.
 Output:
 
 - `releases/vYYYY.MDD.P.md`
+- a `release` Case, upserted by `(caseType, key)` when Cases are enabled, with a
+  `body` document revision containing the changelog body
 
 Important rules:
 
 - even if there are canary releases such as `2026.318.1-canary.0`, the changelog file stays `releases/v2026.318.1.md`
 - do not derive versions from semver bump types
 - do not create canary changelog files
 
+## Channel Process — Source Commit and File Location
+
+Stables promote a **soaked beta**, so the changelog describes the beta's
+source commit, not the tip of `master`:
+
+- The release **source** is the commit the newest `beta/v<beta-version>`
+  tag points at (`{beta-src}` below). Resolve it with:
+
+  ```bash
+  git fetch origin --tags
+  npm view taskcore dist-tags   # the beta dist-tag names the version
+  git rev-parse 'beta/v{beta-version}^{commit}'
+  ```
+
+- Commits on `master` after `{beta-src}` ship in the **next** release.
+  Never include them; they are input for a "what's next" section, not the
+  changelog.
+- During the soak, the file lives at `releases/beta/v{beta-version}.md`
+  on the branch `release-notes/v{beta-version}` (PR to `master`). The
+  release workflow pushes that branch with a generated skeleton when the
+  beta publishes; work on it and rewrite the skeleton in place. If the
+  branch does not exist (a beta cut before the automation), create it
+  from `origin/master` and seed the skeleton:
+
+  ```bash
+  ./scripts/draft-stable-notes.sh {beta-version}
+  ```
+
+- The PR must merge to `master` **before** the stable is dispatched: the
+  stable preflight reads the file from `master` and fails without it.
+- Never create `releases/vYYYY.MDD.P.md` yourself on this path — after
+  the stable ships, the workflow opens a canonicalization PR that renames
+  the beta-keyed file to it.
+- **Fix path exception** (patch releases from a `candidate/release-*`
+  branch): there the notes *do* go directly on the candidate branch as
+  `releases/vYYYY.MDD.P.md`, committed alongside the cherry-picked fixes.
+
 ## Step 0 — Idempotency Check
 
-Before generating anything, check whether the file already exists:
+Before generating anything, check whether the changelog already exists:
 
 ```bash
-ls releases/vYYYY.MDD.P.md 2>/dev/null
+ls releases/beta/v{beta-version}.md 2>/dev/null   # soak-window home
+ls releases/vYYYY.MDD.P.md 2>/dev/null            # canonicalized / fix path
+git ls-remote origin 'refs/heads/release-notes/v{beta-version}'
 ```
 
+A `release-notes/v{beta-version}` branch holding only the generated
+skeleton is the normal starting state, not a conflict — rewrite it in
+place.
+
 If it exists:
 
 1. read it first
@@ -47,13 +92,17 @@ If it exists:
 
 ## Step 1 — Determine the Stable Range
 
-Find the last stable tag:
+Find the last stable tag and the beta source commit:
 
 ```bash
 git tag --list 'v*' --sort=-version:refname | head -1
-git log v{last}..HEAD --oneline --no-merges
+beta_src="$(git rev-parse 'beta/v{beta-version}^{commit}')"
+git log v{last}..${beta_src} --oneline --no-merges
 ```
 
+The changelog range is always `v{last}..{beta-src}` — never `..HEAD` and
+never `..origin/master`.
+
 The stable version comes from one of:
 
 - an explicit maintainer request
@@ -74,8 +123,8 @@ Collect release data from:
 Useful commands:
 
 ```bash
-git log v{last}..HEAD --oneline --no-merges
-git log v{last}..HEAD --format="%H %s" --no-merges
+git log v{last}..{beta-src} --oneline --no-merges
+git log v{last}..{beta-src} --format="%H %s" --no-merges
 ls .changeset/*.md | grep -v README.md
 gh pr list --state merged --search "merged:>={last-tag-date}" --json number,title,body,labels
 ```
@@ -92,10 +141,10 @@ Look for:
 Key commands:
 
 ```bash
-git diff --name-only v{last}..HEAD -- packages/db/src/migrations/
-git diff v{last}..HEAD -- packages/db/src/schema/
-git diff v{last}..HEAD -- server/src/routes/ server/src/api/
-git log v{last}..HEAD --format="%s" | rg -n 'BREAKING CHANGE|BREAKING:|^[a-z]+!:' || true
+git diff --name-only v{last}..{beta-src} -- packages/db/src/migrations/
+git diff v{last}..{beta-src} -- packages/db/src/schema/
+git diff v{last}..{beta-src} -- server/src/routes/ server/src/api/
+git log v{last}..{beta-src} --format="%s" | rg -n 'BREAKING CHANGE|BREAKING:|^[a-z]+!:' || true
 ```
 
 If breaking changes are detected, flag them prominently — they must appear in the
@@ -119,14 +168,27 @@ Guidelines:
 - write from the user perspective
 - keep highlights short and concrete
 - spell out upgrade actions for breaking changes
+- **write at full stable depth from the first pass**: the beta-keyed
+  draft ships verbatim as the stable's notes, so the previous stable's
+  file is the density bar the moment the draft is first written — never
+  leave it at generated-skeleton density for the soak. The skeleton's
+  nested PR summaries are raw material to rewrite, not a format to keep.
+- **describe deltas, not repeats**: read the previous stable's notes
+  (`releases/v<last-stable>.md`) before writing. When they already
+  introduced a feature, this release's entry covers only what changed —
+  a default flip, a hardening, a completion — phrased against the prior
+  release ("last release introduced X; this release makes it the
+  default"), never re-describing the feature as if it debuted. A theme
+  that headlined the previous release does not headline again for
+  follow-through work; demote it to Improvements.
 
 ### Inline PR and contributor attribution
 
 When a bullet item clearly maps to a merged pull request, add inline attribution at the
 end of the entry in this format:
 
 ```
-- **Feature name** — Description. ([#123](https://github.com/taskcore/taskcore/pull/123), @contributor1, @contributor2)
+- **Feature name** — Description. ([#123](https://github.com/khulnasoft/taskcore/pull/123), @contributor1, @contributor2)
 ```
 
 Rules:
@@ -141,10 +203,22 @@ Rules:
 
 ## Step 5 — Write the File
 
+The **file path** is the beta-keyed one from the Channel Process section
+(`releases/beta/v{beta-version}.md`), but the **content** is titled with
+the planned stable version. Resolve it with
+`./scripts/release.sh stable --date {planned-promotion-date} --print-version`
+(promotion is normally the beta publish date plus the 3-day soak). If the
+promotion date slips, the version re-resolves at dispatch — the beta-keyed
+filename makes that harmless; refresh the title when it happens.
+
+The opening line of the changelog must be an H1 of the format `# Taskcore {version}`
+(no braces), e.g. `# Taskcore v2026.618.0`. Always include the `Taskcore ` prefix and
+the `v` on the version.
+
 Template:
 
 ```markdown
-# vYYYY.MDD.P
+# Taskcore vYYYY.MDD.P
 
 > Released: YYYY-MM-DD
 
@@ -171,22 +245,91 @@ The `Contributors` section should always be included. List every person who auth
 commits in the release range, @-mentioning them by their **GitHub username** (not their
 real name or email). To find GitHub usernames:
 
-1. Extract usernames from merge commit messages: `git log v{last}..HEAD --oneline --merges` — the branch prefix (e.g. `from username/branch`) gives the GitHub username.
+1. Extract usernames from merge commit messages: `git log v{last}..{beta-src} --oneline --merges` — the branch prefix (e.g. `from username/branch`) gives the GitHub username.
 2. For noreply emails like `user@users.noreply.github.com`, the username is the part before `@`.
 3. For contributors whose username is ambiguous, check `gh api users/{guess}` or the PR page.
 
 **Never expose contributor email addresses.** Use `@username` only.
 
-Exclude bot accounts (e.g. `lockfile-bot`, `dependabot`) from the list. List contributors
-in alphabetical order by GitHub username (case-insensitive).
+Exclude bot accounts (e.g. `lockfile-bot`, `dependabot`) from the list.
+Exclude specific folks from the list — the Contributors section credits
+community contributors only. The canonical exclusion list (keep it here;
+the Discord skill defers to it):
+`cryppadotta`, `forgottendev`, `devinfoley`, `sockmonster`, `scotttong`,
+`nguyenm7`, `nickyleach`, `tonio-alucema`
+
+List contributors in alphabetical order by GitHub username (case-insensitive).
+
+If there are no contributors left after exclusions, then just skip this section and don't mention it.
+
+## Step 5b — Upsert The Release Case
+
+After writing `releases/vYYYY.MDD.P.md`, emit or refresh the top-level release
+case when the run has Taskcore API context. Use `skills/taskcore/references/cases.md`
+as the API contract. If the API returns `403 Cases are disabled`, report that
+Cases must be enabled and continue with the changelog file only.
+
+Request:
+
+```http
+POST /api/companies/:companyId/cases
+{
+  "caseType": "release",
+  "key": "taskcore-release:vYYYY.MDD.P",
+  "title": "Taskcore vYYYY.MDD.P release",
+  "summary": "Stable Taskcore release notes for vYYYY.MDD.P.",
+  "status": "in_progress",
+  "fields": {
+    "schema_version": 1,
+    "version": "vYYYY.MDD.P",
+    "release_date": "YYYY-MM-DD",
+    "release_patch": 0,
+    "stable": true,
+    "channels": ["changelog", "blog_post", "tweet_storm"],
+    "artifacts": {
+      "changelog_path": "releases/vYYYY.MDD.P.md",
+      "github_release_url": null
+    },
+    "verification": {
+      "typecheck": "unknown",
+      "tests": "unknown",
+      "build": "unknown",
+      "smoke": "unknown"
+    },
+    "notes": null
+  }
+}
+```
+
+This fields schema deliberately exercises every generic field value type:
+string, number, boolean, array, object, and null. Keep the keys stable across
+runs and send the full object on every upsert because fields are replaced, not
+deep-merged.
+
+Then write the changelog into the case body document:
+
+```http
+PUT /api/cases/:releaseCaseId/documents/body
+{
+  "title": "Taskcore vYYYY.MDD.P changelog",
+  "format": "markdown",
+  "body": "<contents of releases/vYYYY.MDD.P.md>",
+  "changeSummary": "Initial stable changelog"
+}
+```
+
+If updating an existing body document, fetch the case first and pass the latest
+`baseRevisionId`. On `409 stale_base_revision`, refetch, merge intentionally,
+and retry once.
 
 ## Step 6 — Review Before Release
 
 Before handing it off:
 
-1. confirm the heading is the stable version only
+1. confirm the H1 heading is `# Taskcore {version}` (e.g. `# Taskcore v2026.618.0`) with the stable version only
 2. confirm there is no `-canary` language in the title or filename
 3. confirm any breaking changes have an upgrade path
-4. present the draft for human sign-off
+4. confirm the `release` case exists or explain why Cases were unavailable
+5. present the draft for human sign-off
 
 This skill never publishes anything. It only prepares the stable changelog artifact.