asimov-plugin

How to write or change a D101 feature-design file (documentation/features/D101-*.html and its mockups under documentation/features/mockups/d101-*/) so it still meets the D101 contract — the definition's bars and the HTML template's structure. Use whenever you create, render, edit, or fix any part of a D101, whether or not a slash command is running — "update §4.4 of this D101", "add a decision row", "render this as a D101", "fix the side-nav" — and inside /d101-feature-design and /d101-convert-to-html when they draft. Carries the rendering procedure and the authoring invariants; the contract itself is read from the plugin at run-time.

Bootstrap a product repo to use the Asimov toolkit from Codex — writes the Asimov context into an AGENTS.md managed region, delivers the Codex subagent shells to .codex/agents/, scaffolds detected-stack convention read-lists, and generates the documentation/ landing site. Read-only on every other file. Codex counterpart of /asimov-init.

Review a document as Athena — a pragmatic architect who has shipped systems like this one and reads the design, including the technical section, for whether the approach is sound and buildable. Use before committing to a design, to catch the assumptions the business quietly lays on the technology. Triggers on "review as Athena", "read this as Athena", "would Athena's approach hold".

Review a document as Hermes — a budget-minded sponsor who decides where the money goes and asks whether the value justifies the spend. Use before taking a design or proposal to sign-off, to find the scope that isn't paid for by its return. Triggers on "review as Hermes", "read this as Hermes", "is this worth it to Hermes".

Review a document as Poseidon — a frontline operator who runs the work every day, knows how it really happens and where it breaks, and has never opened the codebase. Use before taking a design, analysis, or proposal to sign-off, to find where it describes a tidy process no one actually follows. Triggers on "review as Poseidon", "read this as Poseidon", "would Poseidon recognise this".

Advises on the Delivery Model — the four fixed phases (Proposal, Scoping, Development, Operations), the approach catalogue (Scrum, Kanban, use-case delivery, prototyping, launch/hyper care), the discipline catalogue and the selection guide. Use when choosing how to run an engagement, picking an approach for a phase, setting up cadence or roles, exercising a discipline (estimation, risk, status reporting, change handling, handover, kick-off), or asking what the delivery model says about a topic. Also on explicit request — "ask pm-advisor", "what does the delivery model say".

The Angular builder method — write or modify frontend TypeScript/Angular code so it conforms to the active product repo's own Angular conventions, read at run-time from documentation/conventions/angular/README.md, never a generic default. Use for frontend implementation work that must match house style — component structure, naming, RxJS idioms — and when asked to "build this the Asimov way", "as the Angular builder", or "follow the angular conventions". Flags gaps and conflicts instead of guessing.

The code-reviewer method — review the current branch's diff against its base for conformance to the active product repo's own conventions (read at run-time from documentation/conventions/<stack>/README.md for the stacks the diff touches) plus correctness and safety, and emit a structured pass/flag/fail finding report. Read-only, verdict-free — reports findings, never edits code, never approves. Use for an automated first-pass code review before a human reviewer opens the diff, and when asked to "review this the Asimov way", "as the code reviewer", or "check the diff against the conventions".

The .NET builder method — write or modify production C#/.NET backend code so it conforms to the active product repo's own .NET conventions, read at run-time from documentation/conventions/dotnet/README.md, never a generic default. Use for backend implementation work that must match house style — naming, layering, service patterns — and when asked to "build this the Asimov way", "as the .NET builder", or "follow the dotnet conventions". Flags gaps and conflicts instead of guessing.

The .NET tester method — author unit tests for production code touched by the current branch so they conform to the active product repo's own test conventions, read at run-time from documentation/conventions/test/README.md, never a generic default. Use to add or extend .NET test coverage in house style — test naming, arrange-act-assert, coverage thinking — and when asked to "test this the Asimov way", "as the tester", or "follow the test conventions". Flags gaps, conflicts, weak coverage nearby, and hard-to-test production code instead of guessing or forcing a brittle test.