as

Plugin as from marketplace absolut-skills in AbsolutSystems/absolut-skills. Commands read from the repo's manifest — yesterday.

Skills (23)

• agent-docs

  Build or update minimal documentation for coding agents that holds only what the code cannot tell: a short repo-root AGENTS.md, per-application AGENTS.md (commands, unenforced rules, internal libraries, target vs legacy) with an index of the app's .guidelines/, and module AGENTS.md only where a modu

• deliver

  Deliver unattended (for example overnight) a whole documented feature, or the known problems saved in docs/issues/: after one round of start-up checks and questions, loops without asking — plans each feature phase with as:tech-lead, implements it with as:implement, wraps it up with as:finish, fixes

• docs-check

  Audit the documentation against the code without changing it: the AGENTS.md/CLAUDE.md hierarchy and .guidelines/ (drift, lines the code already shows, missing facts), the Markdown spec in docs/spec/ (drift, missing scenarios, legacy HTML, known bugs parked as open questions), and feature pages in do

• doctor

  Quick read-only check of how a repository stands against the as plugin: the working principles block version, AGENTS.md/CLAUDE.md pairs and symlinks, the .guidelines/ index, copied stylesheet versions, spec and feature page lint, stale change proposals, open issues, the last health check, the CLI to

• estimate

  Analyse a client's feature request and estimate it in hours: reads the request, grounds it in the code, AGENTS.md and the docs/spec contracts, reviews the request for gaps, conflicts with current behaviour, better alternatives and worthwhile additions, breaks the work into implementation steps (no c

• explain

  Explain code to a person who did not write it, as an HTML page with Mermaid diagrams in docs/explain/: a change (the current branch or a pull request) for a reviewer or stakeholder — what changed and why, before and after, how it works, data, tests, risks; a module or a question (\"how is the invoic

• feature

  Create and maintain a feature's living documentation in docs/features/<slug>/: why it exists, users and goals, non-goals, user-level acceptance criteria linked to the module scenarios that realise them, a roadmap of phases (one change proposal each), decisions and the sources they came from — client

• finish

  Wrap up a delivered feature on the current branch: simplify the changed code, review it with the clones the branch added to the codebase as evidence, check the touched modules against the Markdown spec (intended change vs regression), write missing contract tests tagged with scenario IDs, and refres

• fix

  Work through the known problems in docs/issues/ (saved by as:issue, as:health, as:finish, as:spec-docs, as:tech-lead): lists open issues by priority and effort, recommends what to fix next, or takes one by name or a request like \"the 10 most important bugs\". Re-checks each issue's evidence against

• guidelines

  Write or improve an application's .guidelines/<topic>-guideline.md (testing, architecture, api, data, frontend, libraries, code-style, security) from the conventions its existing code actually follows: counts how consistently each convention is followed and which variant recent changes use, settles

• health

  Periodic health check of the whole project (or a subtree): hotspots (churn x complexity), structural and change coupling, test coverage and test quality (missing, excessive or weak tests), dead code, duplication, dependencies and docs drift. Uses tools the project already has, runs missing ones ephe

• help

  Show how to work with Claude Code (or Codex) using the as: commands, the recommended Anthropic plugins and plan mode: confirms the plugin is installed, lists as: skills, and walks through the task workflow from onboarding to planning, building (implementing an approved plan), review, finishing a fea

• implement

  Implement the approved plan of a change proposal (docs/spec/changes/<slug>.md, written by as:tech-lead), resuming in any session: finds the branch's proposal, takes the first unticked step of its ## Plan, writes tests first for error and edge scenarios, implements, runs the checks, ticks the step an

• init

  Onboard a repository (greenfield or brownfield) in one run: build or update the AGENTS.md hierarchy with as:agent-docs, then the Markdown module specification with as:spec-docs for a chosen scope, then link the spec from AGENTS.md, and finally check (and, with consent, install) the recommended Anthr

• issue

  Save known problems to docs/issues/ so they survive the session: one Markdown file per problem with priority (p1-p4) in the file name, kind, effort, evidence and a suggested fix. Takes a description, or collects the problems found earlier in the conversation (for example by /code-review, /claude-sec

• qa-docs

  Create and maintain docs/qa/, what as:qa checks in a browser for a web application: environments and how to start them, test accounts (environment variable names, never secrets) and data, roles, app-wide UI rules (viewports, empty, error and loading states), and journeys — cross-feature user paths J

• qa

  Check a running web application in a real browser the way a user does: executes the acceptance criteria of a feature page and the journeys in docs/qa/ (or the ones the branch's changes touch), one executor subagent per scenario in sequence collecting screenshots, console errors and failed requests a

• review

  Review a change for real defects with few false positives: your own branch before the PR (diff from base), or someone else's pull request (number or URL, checked out in a separate worktree against the PR's real base branch). Three read-only reviewers with disjoint scopes — correctness and security,

• spec-docs

  Build or update a human-readable Markdown specification of the application in docs/spec/: a system overview, per-application pages and per-module contract pages with requirements and Given/When/Then scenarios (happy, error and edge paths) with stable IDs, formatted to read well rendered and in diffs

• spec-tests

  Report which contract scenarios of the Markdown spec in docs/spec/ are verified by tests: maps every scenario ID to the tests that check it through the module's public entry points (COVERED / PARTIAL / MISSING), with unhappy paths counted separately, and offers to save the important gaps to docs/iss

• tech-lead

  Act as a tech lead when the user wants to discuss, design or plan a new feature, investigate a bug or unexpected behaviour, weigh technical options (\"how should we…\", \"I want to add…\", \"why does X break\", \"A or B?\"), work through the known problems saved in docs/issues/ (\"fix the most impor

• worktree-close

  Close a git worktree: check that its changes are committed (offering to commit them if not), then remove the worktree folder and its git registration while keeping the branch. Use only when the user explicitly invokes as:worktree-close.

• worktree-create

  Create a new git branch and a worktree for it next to the repository, in ../<repo>-worktrees/<name>, branched from the current branch or from a given branch; optionally copies ignored local .env files into it and installs dependencies. Use only when the user explicitly invokes as:worktree-create.

Similar plugins