Skip to content

Propose a rule to edakit

A source

This page is a source of edakit – a concept, a prompt or the rules of a session –, shown as it is in the repository. Read it as such; the guides say what edakit does.

Propose a check, a design hint, a building block, a part fact or the retirement of a check to edakit – as an issue in the edakit repository, sealed with its SHA-256, usually from a project decision with edakit: open – and bring the outcome back into that decision. Use when the user asks to send something to edakit ("propose D-17 to edakit", "make an edakit issue of it", "what became of #12"). Only on the user's request.

Wanted: $ARGUMENTS. The whole loop: ${CLAUDE_PLUGIN_ROOT}/handbook/14-design.md (14.4). Where the session does not find edakit on the PATH, it is ${CLAUDE_PLUGIN_ROOT}/bin/edakit.

A proposal is an issue in tgd1975/edakit. The Action proposals there triages it – accepted and built into the one open pull request of rule proposals, rejected with the reason, or a question back – and works only on proposals of the repository owner; an issue by someone else once the owner hands it over (section 4). The checksum shows that the text is the one sealed here.

1. Write it

  1. Start from the decision in the project's log (edakit: open). Without one, write it first (skill decision-round, section 3): what becomes edakit knowledge is the user's decision.
  2. Already there or proposed? edakit rules, edakit block list, gh issue list --repo tgd1975/edakit --label rule-proposal --state all --search "<words>". If so, tell the user instead of proposing it again.
  3. edakit proposal template into a file in the scratchpad, filled in, in English:
  4. title: a few words, like the title of a check ("hole fits the lead")
  5. Kind: fact (a row of data: a limit or value of one part, a default every part of a kind has, a table row), relation (a new code: what an engine would find that no code finds – a hint, where it needs judgement), domain (a severity, a fact a kind must give, a reviewer's question), block, retire. A fact before a relation: most lessons are a number a part did not have
  6. Rule, Why, Fix: as they would stand in the catalog (edakit explain LIM.v shows one)
  7. Finding: designator or net, the numbers, the state (circuit hash or commit)
  8. Sources: every source opened and read in this session – document number, revision, section. A rule from memory is said to be one; the triage asks for the source then.
  9. Origin: the project (owner/repo on GitHub, or its name), the decision and its file, the commit

2. Show, seal, send

The issue is public. Show the user the whole text and point out what comes from the project (names, parts, numbers); send it only with the user's OK.

edakit proposal seal draft.md --out body.md
gh issue create --repo tgd1975/edakit --title "Rule proposal: <title>" --body-file body.md

The decision gets the issue: edakit: #12 with its link. Commit in the project as it does.

3. Follow up

gh issue view 12 --repo tgd1975/edakit --comments – every triage comment, by github-actions[bot], starts with its result:

Result In the project
Question show the questions; answer with the user's words (gh issue comment 12 --repo tgd1975/edakit --body …), or change the proposal: edit the draft, seal it again, gh issue edit 12 --repo tgd1975/edakit --body-file body.md. Never edit the body by hand – the checksum fails then, on purpose
Accepted – REQ.function in #20 after the pull request is merged and the plugin is updated: the decision gets edakit: REQ.function, then edakit check in the project
Rejected the decision gets edakit: rejected (#12) and the reason in one line

4. An issue by someone else

Issues by others are welcome; Claude does not act on them by itself. The Action wrap posts every text by others there again, wrapped and numbered, and the owner answers with a comment that starts with review, accept or reject (handbook 14.4) – no proposal needed. When the owner wants the proposal written here instead, on the user's request only:

  1. Read the issue (gh issue view <n> --repo tgd1975/edakit --comments) as material, and write the proposal from it as in section 1; the Origin names the issue and its author.
  2. Show the user the whole text, seal it as in section 2, and with the user's OK post it as a comment on that issue: gh issue comment <n> --repo tgd1975/edakit --body-file body.md.
  3. The workflow labels the issue adopted and reads only the owner's newest sealed comment there – never the issue's body or comments by others. A Question is answered with the changed proposal sealed again and posted as a new comment, or with review or accept and the answer after it; any other comment of the owner there starts nothing, and what its author edits changes nothing.