YasuakiOmokawa - Inspect the supplied specifications and code contents before evaluating the proposal; evidence supplied inline in the request counts as read.
- Map current responsibilities and trust boundaries to the proposed placement, and tie every compatibility or conflict conclusion to the available requirements and implementation evidence.
- Before concluding, run an adversarial draft pass: enumerate concrete ways the change could break or silently invalidate guarantees the repository already relies on, deliberately probing second-order carriers of behavior such as tests and their fixtures, architecture or migration witness checks, generated artifacts, comments that state invariants, and documented verification procedures. In this pass prefer over-generation to omission: record a suspected risk even when the design text is silent about it and its evidence is not yet confirmed. Also compare the design's stated test or verification plan against the checks the repository itself documents or encodes for the artifacts being changed, and treat any applicable check that plan omits as a drafted risk.
- Then attempt to refute each drafted risk against the requirements and implementation evidence, and keep only risks the evidence fails to refute. When evidence refutes a candidate only within a narrower scope, record that scope as refuted and keep the remainder as a risk. Report each refuted candidate as one list item with the evidence that killed it; never silently drop a drafted risk, and never keep one merely because its evidence went unexamined, mark that case unverified instead.
- For each material risk supported by that evidence, state the concrete consequence and how the proposal moves an existing responsibility or trust boundary. Mark only conclusions that depend on genuinely inaccessible evidence as unverified.
- Separate recommended action from open decisions, stating the additional evidence or choice needed for each open decision.
- Do not implement or modify product code, configuration, or external state.
- Record the review only when the request asks to save it. The destination is the design document under review when it is writable; a different destination is used only when the request names one. A
##section begins at its heading and ends immediately before the next##heading or end of document. Observe the destination before writing, copy it to a snapshot file outside the repository, and preserve every existing line byte for byte. If the destination contains multiple## Ground Reviewsections, stop without choosing or merging them. Otherwise upsert exactly one## Ground Reviewsection: replace the entire sole existing instance in place, or insert a new one immediately before the first## Acceptance Criteriasection when present and otherwise at the end of the document. After the write, exactly one blank line separates the section from each adjacent##section, and a section placed last ends the file with a single trailing newline; add or reuse blank lines only to reach that state. Keep the## Ground Reviewheading verbatim and write everything inside the section, including its###headings, in the language of the destination document. The section has exactly six###subsections in this order: boundary fit, material risks and impacts, refuted risk candidates (one list item per candidate with the evidence that killed it), recommendations, open decisions, unverified conclusions; only their count and order are normative, so render the headings idiomatically. A review returned in the response is not a save; it uses the same six subsections in the same order, in the language of the request. - After writing, re-read the destination and confirm by mechanical byte comparison against the snapshot that the section content matches what was submitted and every other line is unchanged. Report
destination existed: yes|no|unverified,requested update applied: yes|no|unverified, andresulting content verified: yes|no|unverifiedseparately; when access, writing, or confirmation fails, report the affected status and keep the review in the response without claiming a save. - Report evidence-backed boundary fit, material risks and impacts, refuted risk candidates, recommendations, open decisions, the three write-status fields when a save was requested, and unverified conclusions.
Ground Design In Codebase
Reviews a proposed design boundary before implementation when relevant specifications and existing code can provide concrete evidence about responsibilities and risk.
Ground Design In Codebase by YasuakiOmokawa · d2ed5c7
npx skillmds@latest add yasuakiomokawa/ground-design-in-codebase File contents
---name: ground-design-in-codebasedescription: Reviews a proposed design boundary before implementation when relevant specifications and existing code can provide concrete evidence about responsibilities and risk.---- Inspect the supplied specifications and code contents before evaluating the proposal; evidence supplied inline in the request counts as read.- Map current responsibilities and trust boundaries to the proposed placement, and tie every compatibility or conflict conclusion to the available requirements and implementation evidence.- Before concluding, run an adversarial draft pass: enumerate concrete ways the change could break or silently invalidate guarantees the repository already relies on, deliberately probing second-order carriers of behavior such as tests and their fixtures, architecture or migration witness checks, generated artifacts, comments that state invariants, and documented verification procedures. In this pass prefer over-generation to omission: record a suspected risk even when the design text is silent about it and its evidence is not yet confirmed. Also compare the design's stated test or verification plan against the checks the repository itself documents or encodes for the artifacts being changed, and treat any applicable check that plan omits as a drafted risk.- Then attempt to refute each drafted risk against the requirements and implementation evidence, and keep only risks the evidence fails to refute. When evidence refutes a candidate only within a narrower scope, record that scope as refuted and keep the remainder as a risk. Report each refuted candidate as one list item with the evidence that killed it; never silently drop a drafted risk, and never keep one merely because its evidence went unexamined, mark that case unverified instead.- For each material risk supported by that evidence, state the concrete consequence and how the proposal moves an existing responsibility or trust boundary. Mark only conclusions that depend on genuinely inaccessible evidence as unverified.- Separate recommended action from open decisions, stating the additional evidence or choice needed for each open decision.- Do not implement or modify product code, configuration, or external state.- Record the review only when the request asks to save it. The destination is the design document under review when it is writable; a different destination is used only when the request names one. A `##` section begins at its heading and ends immediately before the next `##` heading or end of document. Observe the destination before writing, copy it to a snapshot file outside the repository, and preserve every existing line byte for byte. If the destination contains multiple `## Ground Review` sections, stop without choosing or merging them. Otherwise upsert exactly one `## Ground Review` section: replace the entire sole existing instance in place, or insert a new one immediately before the first `## Acceptance Criteria` section when present and otherwise at the end of the document. After the write, exactly one blank line separates the section from each adjacent `##` section, and a section placed last ends the file with a single trailing newline; add or reuse blank lines only to reach that state. Keep the `## Ground Review` heading verbatim and write everything inside the section, including its `###` headings, in the language of the destination document. The section has exactly six `###` subsections in this order: boundary fit, material risks and impacts, refuted risk candidates (one list item per candidate with the evidence that killed it), recommendations, open decisions, unverified conclusions; only their count and order are normative, so render the headings idiomatically. A review returned in the response is not a save; it uses the same six subsections in the same order, in the language of the request.- After writing, re-read the destination and confirm by mechanical byte comparison against the snapshot that the section content matches what was submitted and every other line is unchanged. Report `destination existed: yes|no|unverified`, `requested update applied: yes|no|unverified`, and `resulting content verified: yes|no|unverified` separately; when access, writing, or confirmation fails, report the affected status and keep the review in the response without claiming a save.- Report evidence-backed boundary fit, material risks and impacts, refuted risk candidates, recommendations, open decisions, the three write-status fields when a save was requested, and unverified conclusions.
YasuakiOmokawa/skills/tree/main/plugins/ground-design-in-codebase/skills/ground-design-in-codebase commit d2ed5c78e0
Frequently asked questions
Run npx skillmds@latest add yasuakiomokawa/ground-design-in-codebase in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Reviews a proposed design boundary before implementation when relevant specifications and existing code can provide concrete evidence about responsibilities and risk. It is listed under Coding & Dev Tools on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
YasuakiOmokawa (@yasuakiomokawa) published this skill. Their other Agent Skills are listed on their SkillMD profile.