anthonyposchen/apstack

Use when deciding whether to ask the user a question, make an execution choice, or continue an in-progress task. Resolve ordinary, reversible decisions that are within scope from the request and repository evidence. Ask only when intent, authority, scope, cost, or external impact is genuinely uncertain.

Create, review, or edit build files. Use for Dockerfiles and container builds: containerizing a project, multi-stage builds, scratch vs Alpine images, non-root UID/GID, and thin GitHub Actions that run the Dockerfile (dockerfile). Use for Makefiles, make targets, make recipes, task runners, or docs that tell users to run make, and always when a make target takes user-provided variables such as tokens, paths, namespaces, or environments (makefile).

ALWAYS activate for programming-language work and code-adjacent project work: implementation, refactoring, debugging, code review, tests, CI fixes, package/build files, scripts, migrations, generated-code inputs, infrastructure-as-code, PR/diff discussion, and software architecture or design planning. Also covers no-comments (auditing a diff or files for comments to delete) and type-system-discipline (designing types, reviewing function signatures, illegal states, branded IDs, parsing at boundaries). Load principles.md and only the references the request needs.

Use when a task involves large logs, long files, broad search results, screenshots, repeated reads, or fan-out planning. Keep the working context focused through targeted extraction, compact handoffs, scoped phases, and bounded delegation.

Create a project-local verification skill by reading the codebase. Use when the user asks to create a verification skill, a verification process, or a drive harness for a repo, or when a runnable app has no scripted way to launch, drive, and prove its UI, CLI, or service behavior. Writes or extends that project's verify skill and its feature map.

Build and sharpen a project's domain model. Use when pinning down domain terminology or ubiquitous language, recording an architectural decision, or when another skill (for example grill-with-docs) needs to maintain the domain model. Also use when the repo declares short living alignment docs under docs/agents/ that should stay current as terms and constraints crystallise.

Use when a correction, failure, workaround, or instruction recurs, or when a costly mistake could be prevented structurally. Encode the lesson in the smallest durable guard instead of relying on someone to remember it.

Use when product, UX, feature scope, defaults, interfaces, workflows, or consumer tradeoffs are involved. Prioritize the real user's experience over implementation convenience, and keep every addition focused on the core workflow.

Look at a rendered change the way a person would, before calling it done. Use whenever you finish, review, or debug something someone can see or operate: a page, layout, style, component, dashboard, homepage, email, or other interface. Also use when the user says verify, looks good, check the browser, screenshot, or that they had to review it themselves. Exercise the feature, save screenshots with scripts/see.mjs, and read those image files. A DOM query, a CSS diff, or "the element exists" is not this look. Skip it for a change with no visible or operable surface.

FluxCD GitOps work. Use for GitHub Actions to GHCR to Flux image automation: ImageRepository, ImagePolicy, ImageUpdateAutomation, Docker metadata tags, mutable latest tags, digest updates, or Kubernetes pods not rolling after an image push (flux-ghcr-image-automation). Use for FluxCD and Kustomize repo layouts: GitOps structure, kustomization scaffolds, base/overlay setup, or dev/prod environment overlays (flux-kustomize-layout).

Design, build, restyle, or review polished frontend interfaces for web apps, dashboards, tools, landing pages, components, and responsive workflows. Use whenever a request involves frontend visual design, layout, styling, UI hierarchy, interface polish, design systems, color palettes, typography, color schemes, prefers-color-scheme, dark and light themes, responsive behavior, navigation and wayfinding, or making an existing web experience more usable and distinctive. Also use for motion, elevation, accessibility, and design critique. Apply it to both new screens and focused UI improvements, even when the user asks only for code. Avoid templated AI aesthetics. When designing or reviewing UI, visually inspect the running interface with the eyes-on skill, in both dark and light themes.

Git commits, worktrees, and releases. Use when the user asks to commit, split work into commits, write a commit message, or stage files, and after each completed phase of sequenced work (git-commit-workflow). Use when the user asks to work in a worktree, isolate a change on a branch, clone or fork a repo, or clean up merged worktrees, or says "make sure its in a worktree" or "in a new worktree / branch" (git-worktree). Use when preparing, publishing, or correcting a release, changelog, release notes, version, or tag (release).

Run a relentless interview to sharpen a plan or design while creating and updating domain docs (GLOSSARY.md, ADRs) as decisions crystallise. Use when starting or refining a feature/design and the project should leave durable terminology and decisions behind — not only a chat transcript.

Use before starting ambiguous or multi-step work, when the user says "in your own words" or "restate my goal", or when intent is unclear. Restate the goal, the problem being solved, the constraints, and what done looks like in plain words; flag assumptions and open questions; wait for a correction if anything looks off.

Use when fixing a bug, the user corrects the same mistake twice or says "you missed some", a review comment or gotcha recurs, or you are about to write a "don't do X"/"always do Y" into AGENTS.md, docs, a skill or a comment: the default answer is a repo-local lint rule. Also use when setting up or tightening linting, or contributing a rule back. Detects languages, wires shared rules into the linter and CI, and turns patterns into custom rules with failing examples.

Keep a project's verification skill and feature map honest. Use when the user asks to maintain, audit, or update the verify skill, or when that map may have drifted from the app. Cover every feature from source and with one live drive. Edit only that skill directory.

Use when you are about to read logs, screenshots, diffs, timings, or benchmark numbers to decide whether something passed; when writing a "check", "verify", "retest", or "looks right" brief for another agent; when a manual check sits in AGENTS.md, a PR template, or a review comment; when about to sleep, wait, or poll for a result; or when re-checking a commit or re-running an A/B that was already judged. Turn the check into a deterministic script that prints PASS, FAIL, or UNSURE with exit codes and keeps the full evidence on disk for review.

Security guidance and vulnerability review for codebases, APIs, services, CLI tools, libraries, and daemons. Use for security questions, focused reviews, vulnerability research, security audits, or pen tests. Run the complete workflow only for explicit codebase audit or pen-test requests, full/comprehensive/end-to-end reviews, or requested report artifacts.

Use when adding, changing, comparing, or troubleshooting an agent skill and you need evidence that it changes agent behaviour. Evaluate triggering and task outcomes with realistic prompts, a shared rubric, and blinded review.

Decide whether a proposed or existing test should exist. Activate alongside the coding skill whenever writing, changing, reviewing, or removing tests, including a test an agent is about to add for a small edit. Gate new tests before they land. Audit low-value, duplicative, implementation-coupled, or assertion-free tests and the test-only production seams they require. This skill rejects and deletes tautology tests: tests that restate the production code and only confirm that the code which was written was written. Also use when asked to prune, sweep, delete, or cut tests, or to remove useless tests while keeping real behavior covered.

Apply when you write, change, or keep a test. Call the code as its users do and assert the exact result they see. Rewrite or delete a test that would pass if every imported function returned undefined.

Use whenever you write a reply, a document, a skill, AGENTS.md, a comment, a commit message, or other prose for a person, in ASD-STE100 Simplified Technical English (asd-ste100). Also use when writing or reviewing documentation, READMEs, tutorials, how-to guides, RFCs, architecture notes, PR descriptions, or release notes (technical-writing), or when the user asks for a simple explanation or says simplified English, STE, or ASD-STE100.