All authors
Claude Skills by EnsoDynamics
github.com/EnsoDynamics24 skills0 installs28 views
- autonomous-design-refinementMulti-pass workflow that refines PRD, Technical Design, and Assumptions documents to implementation-ready state, run once the user has reviewed the PRD and design, before implement-from-requirements; the design-stage counterpart of autonomous-prd-refinement, which refines a draft PRD before any design exists — small ranked batches, each answer folded into the documents as soon as it is known, progress checkpointed to an on-disk state file so an interrupted run resumes instead of restarting.Votes: 0GitHub stars: 5
- assumptions-document-feedbackProcess stakeholder feedback on assumptions documents — incorporate corrections, validations, and partial answers while keeping the project moving forward.Votes: 0GitHub stars: 4
- assumptions-document-writingStandards for writing business assumptions documents — specific implementable statements, plain English, confidence levels, and stakeholder validation format.Votes: 0GitHub stars: 4
- autonomous-requirements-refinementMulti-pass workflow that refines PRD, Technical Design, and Assumptions documents to implementation-ready state, run once the user has reviewed the PRD and design, before implement-from-requirements — small ranked batches, each answer folded into the documents as soon as it is known, progress checkpointed to an on-disk state file so an interrupted run resumes instead of restarting.Votes: 0GitHub stars: 4
- continuation-promptProduce the copy-paste prompt that starts the next chat. Line one is a short chat name; then the lineage block (the PRD and phase this chat serves, or an honest \"no lineage found\"); then the skill to use, the goal, where to work, pointers into the governing documents, and the single first action. Before writing the prompt it moves every fact the repo should own out of the prompt and into the governing document, so the prompt stays a pointer. Use whenever the user asks for \"a prompt for a n...Votes: 0GitHub stars: 4
- deliverable-reviewVerify completed work accomplishes what was intended — fresh-eyes sub-agent re-reads output files, traces requirements, checks for gaps and omissions, and reports findings for the main agent to fix.Votes: 0GitHub stars: 4
- engineering-principlesThe engineering principles the Enso Method depends on — no silent fallbacks, the testing evidence standard (every acceptance criterion proved at the boundary it is about), never hacking a failing test green, questioning the first correct fix, production data (dev and sandbox first, read-only and only where allowed), git safety when several sessions share one clone, bounded and visible scheduled jobs, and the judgment calls for ambiguous moments (finish what you started, don't dismiss failures...Votes: 0GitHub stars: 4
- implement-from-discoveryImplement a fix or improvement identified during research, investigation, or development, or raised in a bug report — not from a PRD authored ahead of time. Verifies alignment with the affected component's PRD/Technical Design, applies the technical-vs-business confidence gate, then implements, tests, commits, runs the refactor pass, and pushes a feature branch.Votes: 0GitHub stars: 4
- implement-from-requirementsDefault implementation skill — load full PRD and Technical Design context, size the work for a single AI session, split it into phases if too large (via phase-split, without stopping to ask) and carry on with the first leaf phase in the same chat, then implement, test, run deliverable review, harden the tests, commit, run the refactor pass, and push a feature branch. The "go build it" skill that runs after the requirements are ready.Votes: 0GitHub stars: 4
- implementation-lifecycleThe umbrella skill for the implementation methodology — how PRDs, technical designs, assumptions, and phase documents work together, plus the No Loose Ends session discipline every implementation session runs under. Covers the assumptions philosophy, confidence thresholds, decision flow, the materiality gate that keeps discoveries from becoming scope, the disposition rule for loose ends, the no-hollow-promises rule, the lineage gate, session markers, the done-means-done completion standard, a...Votes: 0GitHub stars: 4
- implementation-readiness-checkPre-implementation validation gate — surface gaps and unclear assumptions before writing code, with proposed answers, confidence levels, and impact assessments.Votes: 0GitHub stars: 4
- investigate-questionThorough deep-dive investigation of a single question — read code, query data, test APIs, and explore to answer the question or significantly refine a proposed answer with updated confidence.Votes: 0GitHub stars: 4
- phase-chainCarry an authorized implementation plan through sequential fresh Codex tasks, one phase per task, with reviewed commits, pushes, and actual successor creation. Use when the user asks to keep implementing all planned phases without babysitting each handoff; not for a single-phase request or a prompt-only handoff.Votes: 0GitHub stars: 4
- phase-splitDecide whether a PRD, or any phase of one, is too large to implement in a single AI session and, if so, split it into independently shippable phases. Decides the cut itself and proceeds without stopping for confirmation. Produces one lightweight phase document per phase at every depth (phase 2, phase 2a, phase 2a1), all flat in the PRD directory, referencing the PRD and the single technical design without duplicating them. The planning step between requirements-ready and implementation — it d...Votes: 0GitHub stars: 4
- prd-roadmapCut an idea that is bigger than one PRD — a brief, a context package, a pile of design notes, or a draft PRD that outgrew itself — into an ordered PRD roadmap of right-sized planned PRDs, each one finishing with something that can be promoted to production. Consolidates the input documents (whatever they are called) into one full brief that stays whole, renames and moves it to docs/roadmaps/{name}/, writes the PRD roadmap beside it, and hands off to prd-writing-standards for the first planned...Votes: 0GitHub stars: 4
- prd-writing-standardsWrite or check a PRD (Product Requirements Document), the requirements a technical design is then built from. Skimmable — clear business context and testable outcomes without implementation details, invented responsibilities, or step-by-step instructions. Use when the user describes something to build and no PRD exists yet, or to bring an existing PRD up to this standard.Votes: 0GitHub stars: 4
- pre-commit-validationCommit-boundary validation ("git police") — verify the staged changeset is clean, coherent, and safe on a shared multi-session workstation. Expected-changeset staging hygiene, secrets scan, diff sanity, concurrent-commit detection, and committing on the local branch (never building on the remote and pushing around it). Loaded by the implement skills at commit time, before presenting or creating any commit.Votes: 0GitHub stars: 4
- refactor-passPost-commit step of the implementation chain — judge whether the work just implemented warrants refactoring and, when it does, perform the refactoring in the same invocation: structure-only changes, tests stay green, committed as its own refactor(scope) commit unless the user's instructions say not to. Strongly decline-biased; the most common outcome is a one-line \"no refactor warranted\" with zero artifacts. Runs only on a committed feature baseline — run by the implement chain after the fe...Votes: 0GitHub stars: 4
- review-technical-designOptional senior review of a technical design before refinement — make an independent would-I-build-it-this-way architecture pass, verify the design's load-bearing claims against the real codebase and infrastructure (read-only), test proposed data-model changes against the current ecosystem and future evolution, evaluate the design against the project's house engineering standards, and produce a triage the human can act on without reading the whole document: verdict, ranked findings with propo...Votes: 0GitHub stars: 4
- technical-design-writing-standardsStandards and process for writing technical design documents — architecture decisions, interfaces, data models, and integration points, including designs for changes to an existing system. Use to write a design from a PRD the user has reviewed, or to check one; autonomous-requirements-refinement follows the user's review of the design. Not implementation instructions.Votes: 0GitHub stars: 4
- test-auditIndependent audit, once a phase or a whole PRD is finished, of how well its tests prove each acceptance criterion, then fixing what it finds in the same chat. Grades every criterion's evidence Missing, Weak, Adequate or Strong by one question (would the suite notice if this broke?), breaks the code on purpose to see which tests notice, and writes the map to test-audit.md in the PRD directory. Then fills the gaps in a fixed order, missing before weak, until every criterion is at least Adequate...Votes: 0GitHub stars: 4
- test-hardeningFinal pre-commit pass that strengthens the tests for the work just implemented — verify every acceptance criterion has credible test evidence, upgrade weak or mock-reliant tests to prove real behavior, add what's missing, and leave the full suite green. Bounded strictly by the acceptance criteria of the work being hardened — it never grows tests for behavior outside them. Runs after deliverable-review as the third step of the implement → review → harden chain. An action skill, not an audit — ...Votes: 0GitHub stars: 4
- wall-clock-awarenessMeasure and reduce waiting time in implementation, tests, builds, CI and delayed acceptance. Identify genuine blockers, trigger equivalent interval work early when cadence is not itself under test, prepare long prerequisites, and continue authorized independent work without risky shortcuts or weakened proof. Preserve one owner for deferred checks and shared writes. Keep active CI and deployment waits in the turn; use a verified scheduled continuation only for unavoidable elapsed-time windows ...Votes: 0GitHub stars: 4
- Using The Enso MethodWhere to start and what comes next in the Enso Method — which skill runs at each stage, in what order, and where the user reviews. Use when the user asks to use the Enso Method, asks "where do I start" or "what's next", or hands over requirements, an idea or a brief without naming a skill. A map only; each skill it names owns its own procedure.Votes: 0GitHub stars: 4