critical-thinking

critical-thinking

A skill for examining and revising the "thinking" in work documents through the eyes of the decision-maker. The basic entry point is the single command "look at it through the decision-maker's eyes and fix it," which runs from examination through revision in one pass and asks the writer up to three questions that only a person can answer. Examination is divided into two parts: whether the document is internally coherent (logic) and whether its premises hold when viewed from outside the document (somosomo); each can be invoked separately when you want to use the steps separately. Whereas natural-japanese fixes the Japanese, this skill looks at the substance.

Commitments

Leave the original document as it is. Examination returns YAML and findings, and the writer decides whether to revise. When revising, write the revised body and the items to confirm in separate files (so the writer can compare them with the original)
Use only the facts and figures contained in the document. For somosomo, write only the kind of "what materials would close the question," and leave the materials themselves and the conclusions to the writer. Adding things not in the document makes things the writer did not say become the writer's words
Write findings in the form of questions to the writer. Do not write how to fix things, such as "should be softened" or "a condition should be added." The writer decides how to fix them
Link every finding to the document by line number. Do not write findings that cannot be pointed to by line number, because the writer cannot find them

How to invoke

/critical-thinking full <ファイル>、/critical-thinking <ファイル>(no mode), or "look at it through the decision-maker's eyes and fix it": runs all steps. Examine, ask the writer up to three questions, incorporate the answers and revise, and from the revised document also create "more concise" and "restructure from the organization" versions. The procedure is in "When asked to examine and revise through the decision-maker's eyes (all steps)." Use this when in doubt

The following three are advanced invocation methods that use the steps separately.

/critical-thinking logic <ファイル>: examines whether the document is internally coherent. Writes out the logical structure as YAML and points out correspondences between claims and grounds, contradictions, mixing of fact and inference, omissions and distortions in parallel structure, and sentences that correspond to nothing. First read references/logic.md . Find and fill gaps in the YAML with scripts/coverage.py find and fill in
"More concise" / "More polite": decides to what depth of the logic YAML tree becomes the main text and rewrites. The procedure is in "When asked for more concise / more polite"
/critical-thinking somosomo <ファイル>: questions premises from outside the document. Using the main conclusion and issues as footholds, questions the premises, the question itself, other options, conditions under which it would be overturned, and interests and execution.<ファイル>.logic.yaml If is nearby, use it; if not, first create the logic YAML. First read references/somosomo.md read
/critical-thinking fix <ファイル>, or "reflect the findings and fix it": reflect the inspection report into the body. For the procedure, see "When asked to reflect the findings and fix it"
/critical-thinking short <ファイル>, or "more concisely"./critical-thinking detail <ファイル>, or "more politely": for the procedure, see "When asked to make it more concise or more polite"
/critical-thinking rebuild <ファイル>, or "restructure it from the structure": for the procedure, see "When asked to restructure it from the structure"

The procedure is the same whether it is invoked as a subcommand or requested in natural language.

If no mode is specified, choose based on the wording of the request. If only inspection is requested, as in "Are there any contradictions?", "Is the logic sound?", "Check the evidence", or "The logic is weak", use logic. "In the first place", "question the premises", "is that really true", "what other options are there", and "look for holes" are somosomo. "Reflect the findings and fix it" is the fixing step, and "restructure it from the structure" is the restructuring step. If it is unclear whether only inspection is wanted or fixing is also wanted, review it with the eyes of the decision-maker and fix it.

Common output form

One line on the nature of the document (what it decides, who reads it. If it is a retrospective or a record of background, say so)
The main conclusion in 1–2 sentences. If it seems to diverge from the writer's intent, add that
Findings by type. Each finding consists of the line number, the wording in the body, and a question to the writer. Arrange them starting with those that affect the whole document, and indicate minor ones by count
YAML save location
Closing: "Whether to fix it is for the writer to decide. If fixing, you can refine it with /natural-japanese <ファイル> "

Inspecting the same document twice produces variation in the number and wording of findings (this is an inspection that relies on LLM reading, and does not have lint-like reproducibility). Add a note to that effect to the results.

When asked to reflect the findings and fix it

"Reflect the findings and fix it" is a different step from inspection, and the promise to "leave it as is" applies to the inspection side. Answering every question and adding it to the body increases the amount the decision-maker has to read. Fix it in the following order.

Settle on one issue for the decision-maker. What is to be decided by reading this document (e.g., "whether to approve the PoC budget"). Take it from the 決裁事項 field in the logic YAML. Build the main text from only the sections needed for that decision. Keep headings as the same short noun phrases as in the original document (e.g., "Cost-effectiveness"), and do not put sentences, numbers, or 【To be confirmed】 into headings. Write the conclusion in the first sentence of each section, so that the argument makes sense by reading only the heading and the first sentence
For questions that can be answered, correct the relevant part of the text and answer. Align contradictions to one side, and fix calculations. Do not invent facts not in the document. Match the strength of wording to the evidence. Sentences that assert something without evidence should be turned into hypothetical or provisional form; sentences that are weak even though the evidence is in the document should be returned to assertion. Change only the wording, not the facts or evidence. Do not put parenthetical supplements in sentences you write or rewrite ("reference value (30 minutes saved per case)" becomes "reference value of 30 minutes saved per case"; "can be canceled (confirmed with the dealer)" becomes "confirmed with the dealer that it can be canceled"). Parentheses in the original document should also be opened if they are supplements to the sentence. What may remain are only references to appendices or chapters, units in tables, and full forms of abbreviations. What may be cited as grounds for a conclusion is only what the document states as grounds for that conclusion; do not connect facts elsewhere in the document to the conclusion as new grounds (that would change the writer's line of judgment).
For questions that cannot be answered (sources, actual data, things not yet decided), do not add them to the main text; instead, list them one per line in a file separate from the document <元の文書名>.確認事項.md(appended to the name without the extension.稟議書.md If it is 稟議書.確認事項.md). Do not create a confirmation-items section inside the corrected document. Return the document in a state that can be issued as is, and place the questions outside the document. This is because if the writer forgets to delete the confirmation items and submits it, the approver will end up reading the list of questions. In an environment where you cannot write a file, write the same list in the response. In the main text, only change assertions into hypothetical form ("assuming 3 hours per month"). However, when values or wording conflict within the document and only the writer can know which is correct (for example, the target is 12 people but the cost is for 15 people), merely moving it to confirmation items means readers still see the original as is. In the main text as well, line up both values and show the discrepancy, such as "for 15 people (target is 12 people. The difference of 3 people is under confirmation)". Then readers can tell it is under confirmation, and you are not deciding on the writer's behalf. Write "under confirmation" only when there are different values or wordings in two places in the document (12 people and 15 people's worth), once per discrepancy, at the first place it appears. From the second place onward, write the same value as the first place as is. Things the document does not yet answer (when to judge the effect, by what number to measure, sources) are not discrepancies but undecided; leave the main text as the original document's sentences (or in hypothetical form) and write them only in the confirmation-items file. Attaching it to undecided items like "the timing for judging the effect is under confirmation" makes readers recount what is undecided. Do not embed marks like [Needs confirmation] in the main text. A place where you want to put a mark becomes one line of confirmation items as is. All questions in the inspection report, except those answered in the main text, must be included in the confirmation items. Similar questions may be grouped, but do not drop any. Arrange the confirmation items in two groups: "Questions to answer first" (those identified in the somosomo report as "questions that could overturn decision items"; up to 3) and "Others".
Do not decide on the writer's behalf. Do not newly set dates, deadlines, owners, amounts, or target values. Do not add new measures or assignments. Do not write values that are "estimated to be." Where you cannot write without deciding, keep it in provisional form and pass it to the confirmation-items file. When reconciling a contradiction, choose one of the two values present in the document and do not create a third value. YAML's 制約(upper limit, timing, scope) are lines the writer set themselves, so do not move the values
Things that support a judgment but can be decided without reading them—such as calculation premises, method comparison tables, functional requirements, and sensitivity tables for estimates—go in the appendix
Do not write the history of revisions. This covers not only body text such as "In the first edition, it was stated that—" but also version numbers, revision dates, and notes like "reflecting comments" on the cover or at the beginning. Readers do not know the pre-revision version
When you have finished revising, compare the character count of the main text (excluding the appendix) with the original document. If it has grown longer, return to 1 and look for sections that can be removed from the main text or moved to the appendix. A main text longer than the original is not finished being revised. Confirmation items are for the writer to read and do not count toward the decider's volume
Finally, polish with natural-japanese. Sentences added to answer questions tend to accumulate parenthetical supplements and rephrasings. In an environment where subagents are available, have a separate subagent given only the revised document apply natural-japanese, and have it write out the paragraph-by-paragraph checks to the end (if continued in the same context, they are omitted at the end of a long process). If unavailable, call it directly; if natural-japanese itself is unavailable, note in the response that polishing was not done

In the response, write the revised locations, the questions passed to the confirmation-items file (the list as-is), what you chose on the writer's behalf (which side you aligned to in a contradiction), and the character counts of the main text before and after.

When asked to revise from a decider's perspective (full process)

If asked to "revise from a decider's perspective," "review before submission," or "make it submission-ready," run everything from inspection to revision in a single request, and also create a condensed version and a restructured version from the revised document. A person who delegated the draft to AI reads only the returned document and a few lines of explanation. Therefore, revise to answer what can be answered within the document without asking, and limit asking people to only what only people can answer.

Run logic and somosomo in order. Leave the report next to the target file as report-logic.md と report-somosomo.md (if it already exists, read and use it; do not rerun). Also leave the YAML
From somosomo's "questions that could overturn the decision items," select up to three questions that only the writer can answer. Eligible ones are facts not in the document (counts, unit prices, contract terms, sources), readings of the decider's points of debate ("I read that what you are being asked to decide is X. Is that wrong?"), and judgment of the scope of the request (YAML's 決裁事項 (change the target, amount, or period), three types. Questions whose answers emerge from cross-checking numbers or lines within the document (contradictions, calculations, strength of assertions) are not asked but instead fixed by the writer using the "fix" procedure. If there are fewer than three, leaving them as is is fine
Ask. In an environment where dialogue is possible, before revising the body text, gather the three questions and ask them all at once in a single turn, adding "It is fine to say you don't know for anything you don't know." In an environment where dialogue is not possible (instructions to proceed without confirming,-p execution), write the questions next to the target file in questions.md in the form "1. Questions" and stop there. If there is answers.md next to it, read it as the writer's answers and continue
Revise to reflect the answers. The method is the same as steps 1 through 8 of "revise to reflect the points raised." The writer's answers are the writer's facts, so they may be written in the body text. Put the content of the answers in as is (do not strengthen, do not weaken, do not add numbers or conditions not in the answers). The main text grows longer by the amount of answers put into it, so cut or move to an appendix the same number of characters' worth of caveats that the answers made unnecessary ("~ is under confirmation," "~ is not yet known") or explanations not needed for approval, and do not make the main text longer than the original. After finishing the revision, compare the character counts (step 7 of "revise to reflect the points raised"). Questions answered with "I don't know" or "I haven't looked into it yet" are split into two. Things that can be looked into by oneself before submission (internal rules or unit prices, things known by asking the responsible department, numbers measurable from records on hand) are not written in the body text as "not yet confirmed," "under confirmation," or "unknown," but left as the original text (or in hypothetical form) and sent to the homework in 8. Approvers send back documents that have not looked into things that could be looked into, so writing confessions in the body text increases the reasons for sending it back oneself. Things that cannot be known without trying (numbers first learned through tests or diagnoses, the other party's reaction) are left in the body text in hypothetical form as test conditions and written in the confirmation items file. When something remains for the writer to decide (which value to use as the guideline, where to set the passing line), also do not write "under confirmation" in the body text but leave the original value and send it to homework. "Under confirmation" can be written in the body text only when there are different values in two places in the document (step 3 of "revise to reflect the points raised"). In both cases, use as is the sentences in which the original document itself states how to verify (such as "we will confirm in the current-state diagnosis"), and if the original document has no verification method, stay in hypothetical form. Writing new steps or work ("verify from the ledger," "measure with 〇〇") means deciding the work on the writer's behalf. Narrowing the questions to ask people to three is separate from narrowing the scope to revise; points that can be fixed within the document (contradictions, calculations, strength of assertions, twisted order, treatment of unsupported examples) are all fixed without asking. Confirmation items are divided into "questions to answer first" (questions that were asked but not understood, and among questions not asked, those requiring the writer's judgment; up to 3) and "others"(the remaining questions one per line. Do not drop any)
Only when the answer undermines the premises of the decision item (the issue is small, the cause is different, or the cost is not justified), present a scaled-down proposal. "The cost is not justified" is read as: the upper limit of the effect derived from the numbers in the answer (the amount if all issues were resolved) falls below the cost for the period the document itself sets (the contract or test period; if none, one year). The absence in the document of a yardstick for how many years it takes to recover the cost does not count as a reason the premise has not been undermined (write the absence of a yardstick itself in the confirmation items). When it has been undermined, add in one line the "proposal to reduce the scope of what is requested" from "restructure". Write the same one line also at the top of the confirmation items file (before the questions to answer first) as the "proposal to reduce the scope of what is requested" (the reply flows, but the writer rereads the file before submitting). The writer chooses, and the main text is revised while preserving the scope of what is requested. On top of that, also submit the version written as the scaled-down proposal separately to <名前>.review.縮小.md (change only the decision item and the scope of what is requested to match the scaled-down proposal, keeping the facts and figures as they are. The writing method is the same as "revise reflecting the points raised"). The writer looks at the two and chooses. The confirmation items for the scaled-down version are written in <名前>.review.縮小.確認事項.md write in
Save the revised document to <名前>.review.md , and write the confirmation items in <名前>.確認事項.md .稟議書.md If 稟議書.review.md と 稟議書.確認事項.md . Do not change the original file
Run "more concise" on the revised document and save it to<名前>.review.short.md . The procedure is as in "when asked to make it more concise or more polite", and rebuild the logic YAML from the revised document. Then run "restructure from the structure" and save the structure proposal to <名前>.review.plans.md and the restructured main text to <名前>.review.rebuild.md . The procedure is as in "when asked to restructure from the structure"; in an environment where dialogue is not possible, choose one from the proposals that preserve the scope of what is requested. Both are based on the revised document, and if confirmation items arise, write them in <名前>.review.short.確認事項.md と <名前>.review.rebuild.確認事項.md . What the writer reads is the revised document, and the concise version and the restructured version are laid out so they can be chosen according to the submission destination and length
Write the judgment at the beginning of the reply. Send it back only when one of the following three applies. Among things the document itself says it has "not confirmed," "is confirming," "is tallying," or "will confirm before contracting," those that can be checked before submission. Something that the writer's answer shows has "not been checked yet" and that can be checked before submission. The premise of the decision item has collapsed because of the answer (not worth the cost, the cause is different, the scale of the issue is different). If any applies, say "As it stands, this will be sent back"; if none apply, say "This can be submitted as it stands." Do not turn something you have newly thought of that the reader might care about into homework (write that under "Other" in the confirmation items). This is so that things converge to a state where it can be submitted once the homework is done. If sending it back, write 1–2 lines giving the reason in the decision-maker's words ("Checking the regulations and the two-week measurement are things you can do yourself before approval") and, before that, the things to do before submission in order starting with those that overturn the decision item. In the reply, write up to the first three; if there are more, add only the number of remaining items. In the confirmation-items file, write all the things that would be reasons for sending it back (if you narrow it to three and drop the rest, it will be sent back again next time even after the homework is done). For each one, write three points: what to check, whom to ask or what to look at, and where and how in the main text to rewrite once the answer comes in ("Ask the Accounting Department about the tax category of the unit price → redo the table in Chapter 3 with tax included and decide the guideline as either 39 minutes or 43 minutes"). The writer does the checking, and the rewriting method is prepared here in advance. Write the same homework at the beginning of the confirmation-items file as "Things to do before submission" (before the reduced proposal). After that, write the list of submitted files, the character count of each main text, whether the questions asked were reflected or made into assumptions, and, if there is a narrowing proposal, its one line and the save location of the reduced version. Leave the inspection report as a file for those who want to read it. If it stops at question 3, write the save location of the question and that the rest can be run by writing the answer in answers.md , and the rest can be run by writing the answer in

When asked to rebuild from the structure

If asked to "rebuild it from the structure," "use a different composition," or "shape it so the decision-maker will approve," do not fix the points one by one; replace the backbone of the argument. People who leave the drafting to AI often do not hold the structure in their own heads, and showing them a changed structure is something only this step can do.

First decide what to keep and what to discard.

Keep: facts, numbers, sources, the main conclusion, the items for which a decision or approval is requested (what you are asking for), and the writer's constraints (upper limit amount, timing, scope of target). Use the sentences from the original document as they are for these. In the logic YAML, 決裁事項 と 制約 the sentences from the main text are copied into the field, so take them from there
May be discarded: which reason to put first, what to keep in the main body and what to move to an appendix, how to frame the request or report (e.g., reinterpreting "a proposal to introduce a tool" as "a proposal for a trial that answers three questions in six months"). "How to ask" may change; "what to ask for" must not change. The exception is the next item, "a proposal to shrink what is being asked for"; only there may what is being asked for be reduced

Proceed in the following order.

If there is no report of the inspection (logic and somosomo), run logic first. The somosomo questions provide material for reframing, so read them too if available
Produce two or three structural proposals. For each proposal, give the claim (what this document says to the decision-maker) in one sentence, the skeleton of the main body's headings, the inspection questions the proposal answers (by number), and its weakness in one line. Distinguish the proposals by their backbone, not by differences in material. Build the proposals only from facts in the document and from what is being asked for
- Make one of the proposals "a proposal to shrink what is being asked for." When an inspection question casts doubt on the very premise of the decision item (the size of the problem, the cause, the expected effect), merely changing the sequence while keeping what is being asked for does not answer the question. In this proposal, either shrink the decision item (reduce the period, amount, or scope; ask only for the first stage; split the request into two), or first place what should come before the request (first verify what can be verified with the material at hand for the reader or writer), or withdraw the request itself. Build it using only shrinking, splitting, doing first, or withdrawing, and do not use measures or facts not in the document. State which inspection question's answer, if obtained, would overturn the original decision item, by question number and line number. Write the shrunk decision item in the original document's words
- Include this proposal even when the inspection questions do not cast doubt on the premise of the decision item. In that case, write in the weakness: "The answers to the questions are already available, so the reason to shrink is weak."
Have the writer choose one. Write the main text only after the writer has chosen. When told to proceed without checking, leave the proposals in the reply, choose one from the proposals that keep what is being asked for, and state the reason for the choice. Only the writer can choose the proposal that shrinks what is being asked for, so put it at the beginning of the reply and add, "If you choose this proposal, which question's answer should be looked at first?"
Write the main text using the chosen proposal. The method of writing is the same as steps 2 through 8 of "revise by reflecting the comments." In the main text and the checklist file, write the content of the questions in words (numbers like L1 and S3 are for inspection work and will not be understood by readers)
When finished writing, read and compare whether the main conclusion and the decision item have the same content as in the original document. If they have changed, you are deciding on the writer's behalf rather than restructuring, so revert them. Only when the writer has chosen "a proposal to shrink what is being asked for" does the decision item intentionally change. In that case, write the original decision item's sentence and the shrunk sentence side by side in the reply

In the reply, write the options you presented (with the option to reduce what is being asked for first), the option you chose, what you kept (the sentences of the main conclusion and decision items), the spine you discarded, the questions moved to the confirmation items, and the character counts before and after the main text.

When asked to make it more concise or more polite

When asked to "make it more concise," "shorten it," "make it more polite," or "make the grounds thicker," do not cut or inflate the text; instead, decide how deep into the logic YAML tree to render as the main text and rewrite accordingly. AI-written documents are long because they line up grounds by quantity; by looking at the claims, grounds, and weights in the YAML, you can decide in advance how much is needed.

What to keep is the same as "rebuild from the structure." Facts, numbers, sources, the main conclusion, items requiring decision or approval, and the writer's constraints use the sentences of the original document as-is in either direction. Even when making it more polite, you may write only what is in the YAML. Contradictions or numerical discrepancies in the document are left as-is in this step (fixing them is the job of "revise by reflecting the feedback"). Keep both conflicting values and write them in one line in the confirmation items file.

<ファイル>.logic.yaml If there is no , run logic first. If the YAML has no 論拠・重み・決裁事項 If it is an old form without , rerun logic
When making it concise. What remains in the main text is the main conclusion, each issue's claim and 重み: 決裁に要る grounds,決裁事項 と 制約(as the sentences in the YAML fields).比べた案 If the main text contains , keep the grounds for why that option was not chosen as "needed for decision."裏づけ と 補足 Move the grounds for and "limitations and conditions" to the appendix. Facts, numbers, and examples must remain somewhere in the document even when made concise (so that going concise → polite → concise returns to the same document). Among the issues, those not included in the main conclusion's 依存 are removed from the main text and moved to the appendix. Write each section with one sentence of claim and one sentence or one table of grounds needed for decision. For issues that no longer have grounds left in the main text, move the entire section to the appendix (a section with only a pointer such as "see Appendix D" does not serve as decision material)
When making it polite. Return the grounds for裏づけ and "limitations and conditions" to the main text, and for each issue write 論拠 in one sentence. For grounds that are "not in the main text," do not supplement them on the writer's behalf; move that issue to the confirmation items file (the same form as 3 in "revise by reflecting the feedback"). Use only grounds that are in the YAML. Even when made polite, the main text is normally no longer than the original document; if it becomes longer, check whether you have added anything not in the YAML
In either direction, the writing method is the same as 4 through 8 in "revise by reflecting the feedback" (do not decide on the writer's behalf, do not write the revision history, use short noun phrases for headings, and polish with natural-japanese at the end)
When finished, compare the main conclusion, decision items, and numbers with the original document; if they differ, restore the original sentences. Each sentence in the main text of the concise document must be traceable to a specific line in the original document. Sentences that cannot be traced must be restored to the original sentences or deleted

In the response, write the character counts before and after the main text, the number of grounds left in the main text and grounds moved to the appendix, and the points sent to the confirmation items because their arguments are not in the main text.

Frameworks referenced

Vertical logic (is it really so) and horizontal logic (is that all), and the three causes of leaps are borrowed from Takahisa Takada's "Logical Presentation"; the perspective of questioning the question itself is borrowed from Kazunari Uchida's "Issue Thinking". I do not borrow the wording, only the question patterns. The key points of the two books, where they correspond in this skill, and what is still missing are summarized in references/foundations.md .