kendex-issues
Skill76 starsChanged 2 months agoMITView on GitHub
Load to monitor kendex's issue queue continuously or to run one fix-and-propagate cycle.
In this repository38 other files it gives its agents.
- AGENTS.mdAGENTS.md
- crates/AGENTS.mdAGENTS.md
- .github/AGENTS.mdAGENTS.md
- hooks/AGENTS.mdAGENTS.md
- pi-extensions/AGENTS.mdAGENTS.md
- skills/AGENTS.mdAGENTS.md
- tools/AGENTS.mdAGENTS.md
- ui/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- crates/CLAUDE.mdCLAUDE.md
- .github/CLAUDE.mdCLAUDE.md
- hooks/CLAUDE.mdCLAUDE.md
- pi-extensions/CLAUDE.mdCLAUDE.md
- skills/CLAUDE.mdCLAUDE.md
- tools/CLAUDE.mdCLAUDE.md
- ui/CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- app-deploySkill
- bot-instructionsSkill
- code-qualitySkill
- commit-guardsSkill
- deciderSkill
- deep-researchSkill
- dep-radarSkill
- devSkill
- doc-limitsSkill
- docs-writingSkill
- githubSkill
- iced-rsSkill
- linearSkill
- orchSkill
- preflightSkill
- price-handlingSkill
- project-managementSkill
- reviewerSkill
- review-gateSkill
- second-opinionSkill
- worktreeSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
After any merge, propagate.
- Distinctive: line 54
Document size: follow doc-limits policy.
- Distinctive: line 56
Review the diff yourself: before submit, finding the actual root cause, not a plausible one.
- Very specific: line 63
Only from a change merged on origin/main.
- Very specific: line 78
Never pipe a state-changing or guard command through tail/head/grep in a && chain.
- Very specific: line 81
Branch safety: Never switch or commit on a checkout mid-work.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- kendex:project-instructions:start -->Project Instructions
<!-- kendex:shared-instructions:start -->Problems with a kendex-owned skill go through kendex report; check ownership in the file first.
<!-- kendex:shared-instructions:end --><!-- kendex:project-instructions:end -->kendex Issue Steward
watch → poll → triage → fix → merge → propagate → reschedule. One cycle per turn.
| Concern | Owning skill |
| Fix cycle (prepare → delegate → review → submit → merge) | orch |
| PR threads, replies, reviews, merges, CI logs | github |
| Watching open PRs | review-gate pr-watch.sh |
| Linear reads and writes | linear |
Hand-rolled PR mechanics (raw gh api where a github.sh command exists) are a defect.
Loop (one turn)
- PR watch:
GH_REPO=vanillagreencom/kendex .agents/skills/review-gate/scripts/pr-watch.sh. Silence + exit 0 = nothing needs you. Attention lines → act through the github skill. After a gate-green, also checkisInMergeQueue+autoMergeRequest(GraphQL). Queue ejection is silent: re-arm once; a second ejection is a flaky required suite. Quarantine, never re-arm loops. - Poll Linear:
linear.sh sync --reconcile, thenlinear.sh cache issues list --state "Triage,Backlog,Todo,In Progress" --max. Linear is the complete queue (GitHub→Linear sync is one-way); Triage holds the GitHub-synced arrivals. Cross-checkgh issue list --repo vanillagreencom/kendex --state open: an open GH issue whose Linear mirror is Done is residue, so close it naming the PR; one with no mirror means the sync broke, so triage it from GitHub and say so. Nothing on either surface → reschedule. - Triage each issue (below); run the fix cycle for each valid defect. Mutate on the issue's home surface: GH-mirrored issues (Linear body links the GH issue) are closed/commented on GitHub; Linear-native ones through the linear skill. PR body carries
Closes KEN-<n>plusCloses #<n>when a mirror exists. - After any merge, propagate.
- Reschedule (Cadence). Stop only if the user asked.
Triage
- Already fixed → compare the marker's
source=<repo>@<commit7>to the fix commit before investigating. - Duplicate → close, name the canonical issue.
- Not a kendex asset → ownership is the asset's SKILL.md frontmatter (
source: kendex), never its install path. Close with the reason; repost project-local items to the owning repo, cross-link, notify that repo's overseer (tmux window 1 ofmemsira,drovr,hyprtrade). Never fix a consuming repo's defect. - Edge case (<1% of users), contrived layout, race between two local processes, or reviewer hypothetical with no report → cancel with the reason. The bar for a kendex issue is a reported symptom.
- Over-built proposal → cancel; state the simpler approach in one line if one exists.
- Genuine kendex defect (skills/, agents/, hooks/, pi-extensions/, crates/, ui/) → fix cycle.
- Unfindable reference →
git log -S '<name>' --allfirst. A name that never existed is a typo: close with the evidence; never ship a shim. - Empty body → ask for the concrete repro; leave open.
Fix cycle: load orch
orch owns every step. kendex-specific parameters:
- Delegate to:
generalist(shell/docs/skills),rust(crates/),iced(iced-rs). Tests required; relevant suite green (bash skills/orch/tests/run-all.sh, per-skilltests/*.sh,cargo test --workspace). - Scope is the reported symptom (dev skill § Engineering Rules, plus its two exceptions: mechanical enablers ride, an armed defect is in scope). Expect the fix to be about the size of its first commit.
- Fix direction: determinism and tooling first, meaning a deletion, a short-circuit, or a script. Added prose last. Skills are instructions, not explanations;
tools/guardrefuses history and reasons in them. - Document size: follow doc-limits policy.
- Review must converge (orch SKILL.md): a recurring defect class is fixed at its source, never per comment. A round that is only scope, test-coverage, or wording asks ends the review: reply, resolve, push nothing, merge through the gate. Replies are
Fixed in <sha>,Declined: <reason>, orTracked: KEN-<n>(issue created first, since the gate rejects a tracking claim naming no issue). Never--admin. - Review the diff yourself before submit, finding the actual root cause, not a plausible one. A stalled delegate: inspect its worktree, nudge once.
- Findings and coupled defects disposition per orch
references/finding-disposition.md. The excluded classes come ahead of the defect fork, one reply form per thread. - Disjoint files → parallel; same file → sequence or bundle.
- A required check that cannot be rerun gets a fresh head (
commit --amend --no-edit+push --force-with-lease, never-shared heads only); never a merge past red.
Propagate
Only from a change merged on origin/main. Batch: if open items would force another re-vendor soon, hold and run one train; an immediate train is for a fail-open defect in a consumer gate or an owner ask.
git checkout main && git pull --ff-only; confirm the source consumers read sits at theorigin/maintip containing the merge.- Skill/agent/hook changes →
kendex refresh(all scopes, never--scope project; Pi packages are global) +kendex verifyin each consumer. CLI-only changes → binary rebuild, no skill refresh. - Consumer commits:
git check-ignore -q <path>first (ignored = nothing to commit). Stage kendex paths only, never-A; revert no-op.kendex-refreshedand template-default churn. Branch → PR →gh pr merge --auto. Reply to and resolve bot threads. Confirm each push landed and carries only kendex files. While propagation PRs are open,GH_REPO=vanillagreencom/<repo> pr-watch.sh --healeach cycle. - New skills do not propagate by refresh:
kendex add --skill <name> -yper consumer, commit itskendex.tomlentry through that repo's queue. - Bot findings on propagation PRs: a real defect in vendored content is fixed upstream first (issue → fix → merge → refresh on the branch → resolve citing the fix). Nits on the PR's own payload: fix on the branch.
- Capability changes consumers must wire into CI/branch protection: ship the spec in the owning skill, coordinate repo-side through each overseer, verify on each consumer's
origin/main. Security-relevant capabilities need the user's sign-off first.
This skill's home
Source: .agents/skills/kendex-issues/SKILL.md in the kendex checkout, the real directory, declared source = "in-place" and installed project-scoped only. git rev-parse --show-toplevel prints that checkout's root from anywhere inside it. Edit it there; the per-harness links already point at it. Then run kendex apply from the root so the install record matches the edit; until you do, kendex verify reports the skill as changed since install. A ~/.agents/skills/kendex-issues link is a collision. Delete it.
Guardrails
- Never pipe a state-changing or guard command through
tail/head/grepin a&&chain. Run bare, read the result, then trim. Readworktree create's full output before entering it; an ownership refusal means another session owns the work. - Ownership. Before a fix cycle, check for a remote branch, open PR, or foreign worktree for the issue. Active peer → hands off. A PR with unresolved threads and no pushes or replies for ~2 h whose session is idle is abandoned: take it over, answer every thread, note the takeover.
- Consumer boundary. The only write lane into consumers is kendex propagation plus hygiene on those PRs. Coordinate everything else over tmux; verify delivery with capture-pane after ~5 s; read a composer's full content before pressing Enter.
- Branch safety. Never switch or commit on a checkout mid-work; use a worktree off
origin/main. Nevergit stashin a shared checkout. - Scoped commits, verified pushes. Inspect diffs,
kendex verify, confirm it landed. - Box load poisons suites. A red suite under load: check uptime, rerun in isolation, A/B against clean HEAD.
- Clean up merged worktrees and stale branches; keep local and remote main in sync.
Cadence
Widen toward ~60 min when quiet; tighten toward ~15–20 min after a new issue or a burst.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

