oleksandromelchenko/stackfoundry
Casts a repo-grounded swarm of specialists per stack (language x app model): code writers, verifiers, test designers/writers/reviewers/fixers, bug hunters, fix verifiers, security and performance reviewers, dependency bumpers and a scheduled tech radar.
Act on the newest tech-radar report — ask once, then route each item to a plan, spike, bump, pack refresh or recorded rejection. Never edits product code. Only when asked. Use for "act on the radar", after tech-radar.
Act on the latest dependency report — bumps to bump-all, migrations to plan-feature, deferrals, decisions, watch items — ask once, then dispatch. Only when asked. Use for "act on the updates", after check-updates.
Turn what this session left open — choices made for the user, follow-ups, open questions, assumptions, unverified steps — into AskUserQuestion prompts, then act on the answers. Use for "ask me".
Categorized list of everything pending — backlog plans, spec follow-ups, open bug-report findings and test-design rows, code TODOs. Use for "what's open", "what's left", or /stackfoundry:backlog [plans|bugs|todos] [category]. Read-only.
Multi-agent bug hunt over one target — one hunter per bug category, every 🔴/🟡 finding refuted before it counts — saved as a tracked bug report. Use for "find bugs in X", a deep sweep, or a pre-commit diff hunt.
Bump one ecosystem's pins (packages, SDK, CI actions, images) from ecosystems.json — discover, classify, apply patches and minors, stop on majors, regenerate lock files, run every gate it reaches. Use to update or patch dependencies.
Bump every ecosystem in one sweep — discover all, one table with majors flagged, apply what the user approves in apply order with each ecosystem's gate, record declined majors. Use for "bump everything".
Map a change set (uncommitted tree, branch, commit range or a list of paths) to the repo's targets and the specialist reviewers it calls in. Use before fanning out over a diff, or for "which targets does this touch".
Find format and tooling migrations no version number tracks (project and solution formats, test and lint stacks, framework conventions), source-verified and classified breaking or additive. Use for "what modernization is available".
Report-only sweep for updates in every ecosystem the repo pins — runs each ecosystem's read-only discover commands, re-checks deferred upgrades, writes one dated report. Never edits or applies. Use for "what's outdated".
Clean up after merged work — local branches and worktrees left by landed or closed PRs and local merges, proven free of local-only commits. Report, one confirmation, then remove. Use after a PR merge.
View and edit the guard hook's rules in .stackfoundry/guards.json — generated-file globs, denied or ask-first commands, the git write policy — tested on sample events before saving. Use for "block edits to X" or "show the guards".
Change what a stackfoundry skill or agent does in this repo without losing it on upgrade — add a step, a rule or a category, or replace it outright. Use for "change how bug-hunt works", "add a step to review-changes".
Find the root cause of an error, stack trace, log excerpt, failing command or "X stopped working" — reproduce, hypothesize, bisect, fix with your yes, pin a regression test. Use when something broke and you don't know why.
Design tests before writing them — a risk-ranked test list for one target, every expected value citing a source, saved as a tracker under the docs root. Read-only on code. Use for "what should we test", or before write-tests.
Sweep the docs (specs, plans, bug reports, test designs, skills, agents, instruction files, rules, profiles) against the code and the documentation rulebook, fixing mechanical drift and flagging judgment calls. Use for "are the docs stale".
The full cycle for a change that matters — plan mode with targets and a test design, implement the repo's way, then a quality sweep. Never commits. Only when asked. Use for "elaborate plan", "plan thoroughly", "full cycle".
Read a failing CI run, classify each failure (flaky, infrastructure, real defect, workflow config) and fix it by its cause, reproducing locally first. Use when CI is red, a check failed on a PR, or for "why is the build failing".
Fix failing, flaky or weak tests for one target by their cause — classify first, edit only tests and harness, never loosen or skip. Product defects stay red and go to a bug report. Use for red tests, flaky tests or review-tests findings.
Adversarially verify landed bug fixes, one verdict per fix (does it resolve its bug without regression?), and flip the bug report's markers. Use after fixing, for "did my fix hold", or to audit a report's ✅ items.
Scheduled flaky-test watch — runs each target's suites several times in shuffled order, records every test that both passed and failed with its runs and seeds, one dated report. Never edits tests. Use for "find flaky tests".
Land the open pull requests — a read-only merge report with conflicts and a landing order, one confirmation, then land in order and hand off to cleanup-merged. Only when asked. Use for "merge all PRs" or "land the open PRs".
Make a code change WITHOUT building, testing, running, regenerating, migrating or starting services, so a parallel session on the same tree is not clobbered. Use for "just implement it", "don't build or test", "code only".
Build a feature plan from the docs plans backlog, then retire it — delete the plan, record a living spec, sync affected instructions. Use when asked to build or execute a backlog plan.
Set up stackfoundry in this repo — survey it, agree the target map, research each technology from current sources, write grounded rulebooks, profiles, code-writer skills, trackers and guards. Only when asked. Use for "set up stackfoundry".
Write a team-owned copy of a generic role agent for one target, in each assistant's format, to hand-tune it; orchestrators then dispatch it and upgrades skip it. Only when asked. Use for "customize the bug hunter for X".
Runtime and infrastructure performance review of one target (backend, web front end, worker, desktop) or all, checked against current guidance from the web, saved as a dated report. Use for "is X fast enough" or a perf audit.
Plan first, then execute immediately without plan mode or approval; still asks about genuine open decisions. Use for "plan execute", "plan and execute", "inline plan", "plan it out then just do it".
Capture a future feature as a standalone plan file in the docs plans backlog, without implementing it. Use to plan or park a feature for later, or add something to the roadmap or backlog.
Delete comments that are no longer true or useful and shorten wordy ones; edits comments only, never code. Defaults to the uncommitted tree. Use for "prune the comments"; harsh mode for "drop most of the comments".
Fan the convention reviewers (duplication and naming, markup semantics and styles, the repo's convention specialists) over a change into one verified, ranked report. Use to review conventions, not bugs.
Harden a finished change end to end — tests designed, written and reviewed, bug hunts, fixes verified, conventions, docs, full gate — into one bug report, never committing. Use for "harden this" or a full quality pass.
Digest of the last few radar and dependency reports plus the radar decisions — what was acted on, what is still open, what keeps recurring. Read-only, answered in chat. Use for "radar summary" or "what keeps coming up".
Research or refresh one technology pack (a language, app model, capability or tool) from current official sources, ground it in this repo and regenerate its rulebook. Use when a pack is stale, missing or wrong.
Check a backlog plan or spec against what is actually built and act — retire a fully built plan, re-scope a partly built one, or leave it and say why. Use to ask whether a plan is done, or to retire a plan.
Review uncommitted work, unpushed commits or a GitHub PR with independent reviewer agents in fresh sessions, then verify every finding against the code. Use to review a change or a PR before committing or merging.
Review whether tests would actually catch a bug — one verdict per test for one target, backed by shuffled runs and mutation testing, with a skeptical second vote on high-stakes oracles. Read-only. Use after write-tests.
Measure benchmarks on a quiet machine — preflight, repeated runs, before/after compare, independent results review, dated report with a verdict per decision rule. Micro or load, per the target's harness. Use for "run the benchmarks" or "measure it".
Run the tests a change needs instead of whole suites — selected per target from targets.json, with Uncovered code reported; --full/--affected override. Use for "run the tests", "test my change" or a target's gate.
Set up a minimal test harness for a target with none or a thin one — framework from its tooling pack, base fixture, network-edge fake, shuffle and coverage commands — proven by one test that can fail. Asks first. Use for "X has no tests".
Register the unattended report-only skills (tech-radar, check-updates, whats-next, flaky-watch and more) as scheduled tasks; shows headless and CI alternatives. Asks first. Use for "schedule background checks", "run the radar weekly".
Security-weighted review of one target or a diff — reviewers per trust boundary, secrets in the tree, dependency advisories — weighted by exposure and stakes, saved as a tracked bug report. Use for a security audit of X.
Add a mutation-testing lane to one target's suite — tool from its tooling pack, scoped to domain logic, proven by a small run with killed mutants — recorded in targets.json. Asks first. Use for "set up mutation testing".
Author or restructure a skill, subagent or path-scoped rule in this repo — one file each, its frontmatter and description cap, and where a rule belongs. Only when asked. Use to create, rename or split one.
Audit skill, agent and rulebook plumbing — frontmatter, description caps, tool grants, path references, rules' globs, instruction-file shape, orphans, volatile facts — plus a live load probe. Use after adding, renaming or removing one.
Scheduled read-only check of stackfoundry itself — installed plugin vs the marketplace's latest, repo files generated by an older version, Claude Code releases — with the update, upgrade or sync step each calls for. Use for "is stackfoundry current".
Re-survey the repo and update the stackfoundry profile — new or removed projects, frameworks and tools, pinned majors that moved, new generated folders. Shows one diff, asks once, applies. Use for "resync stackfoundry" or "I added a project".
Scheduled read-only radar over every researched pack — new releases, deprecations hitting code in use, advisories, new tools and practices, stale packs — cited, in one dated report. Use for "what's new" or "news about our stack".
Build or refresh the living threat model of one target — assets, actors, entry points, trust boundaries, threats with their mitigations in code, and open gaps. Use for "threat model X" or before a security review.
Take a new stackfoundry version's template changes into the files init generated here — replace untouched files, ask about edited ones, skip materialized and deleted ones. Only when asked. Use for "update stackfoundry's files in this repo".
Guided tour by questions — finds out what you want to do and whether this repo is set up, explains the matching skill in two lines and runs it with your yes. Use for "walk me through stackfoundry", "where do I start", "what can you do".
Suggest the next product and technical steps — what a product of this kind is expected to have and lacks, present weaknesses, where its domain and stack are moving. Ranked, cited, routed. Use for "what's next" or "what should we build next".
Force plan mode and user approval before any implementation, even for a trivial-looking task. Use when the user says "plan first", "with plan", "plan before executing", or "don't just start coding".
Write benchmarks for a performance question — micro or load, per the target's harness — pre-register a decision rule, write, independent review, fix, dry run. Use for "benchmark X", "prove it is faster" or "measure the locking".
Write or change code the repo's way — maps the files you will edit to their targets, then follows each app model's generated code-writer skill and rulebooks. Use when implementing a feature or fix in any target.
Write real behavioural tests for one target on its existing harness, every expected value cited, keeping only tests that pass the assurance gate; --full runs the design-write-review-fix loop. Use for "write tests for X".