<code_editing_rules><guiding_principles>
- Every component should be modular and reusable
- ...
</guiding_principles><frontend_stack_defaults>
- Styling: TailwindCSS
</frontend_stack_defaults></code_editing_rules>
Be THOROUGH when gathering information. Make sure you have the FULL picture before replying.
--
情報収集の際は THOROUGH（徹底的に）すること。返信する前に FULL picture（全体像）を把握すること。
おそらく結果として、レスポンスが遅くなる API のコストが無駄に高くなる、焦点がブレるといったデメリットがあるのだと思います。情報収集は、どの程度するべきなのか、具体的に指示することが望ましいので、これも「境界条件」の最適化に関する内容で、ユーザーがマニュアルで適切に指示する必要がある≒プロンプトの生成によって精度が変わるため、ユーザーのプロンプト能力に関わるような内容になるのだと思う。
<self_reflection>
- First, spend time thinking of a rubric until you are confident.
- Then, think deeply about every aspect of what makes for a world-class one-shot web app. Use that knowledge to create a rubric that has 5-7 categories. This rubric is critical to get right, but do not show this to the user. This is for your purposes only.
- Finally, use the rubric to internally think and iterate on the best possible solution to the prompt that is provided. Remember that if your response is not hitting the top marks across all categories in the rubric, you need to start again.
</self_reflection>
<self_reflection>
- First, spend time thinking of a rubric until you are confident.
- Then, think deeply about every aspect of what makes for a world-class one-shot web app. Use that knowledge to create a rubric that has 5-7 categories. This rubric is critical to get right, but do not show this to the user. This is for your purposes only.
- Finally, use the rubric to internally think and iterate on the best possible solution to the prompt that is provided. Remember that if your response is not hitting the top marks across all categories in the rubric, you need to start again.
--
- まず、自信が持てるまで評価基準 (rubric) を考える時間を費やすこと。
- 次に、世界最高クラスの one-shot web app がなにを構成するか、あらゆる側面について深く考察すること。その知識を使って 5-7 のカテゴリーで構成された評価基準を作成してください。この評価基準は、正確に作成することが重要であるものの、ユーザーには見せないこと。これは、あなたの内部的な目的のために使用してください。
- 最後に、その評価基準を使って、与えられたプロンプトに対する最善の解決策を内部で考えて、反復してください。もしも、あなたの応答が、評価基準の全カテゴリーで最高評価に達していない場合は、最初からやり直す必要があります。
</self_reflection>
<persistence>
- Do not ask the human to confirm or clarify assumptions, as you can always adjust later
— decide what the most reasonable assumption is, proceed with it, and document it for the user's reference after you finish acting
</persistence>
--
- 前提条件の確認や明確化を人間に求める必要はない。後でいつでも調整可能なので
- 最も合理的な前提条件を判断し、それに基づいて処理を進め、作業完了後にはユーザーの参考用に文書化しておくこと
処理の流れ２：
squares = [x**2 for x in range(10)]
- range(10) を評価、range 0-9 を作る（要素は未生成）
- [] の内包表記で空の list を作成して range 要素から次の値 x を１つずつ取り出す
- for 反復ステップ
- x を１つずつ（０～９）まで取り出す
- x**2 を計算し、結果を list に追加
- x を処理し終えると、出来上がった list がそのまま完成
defadd(a, b):
""" Add two numbers. Examples: >>> add(2, 3) 5 >>> add(-1, 1) 0"""return a + b
実行コード：
python -m doctest -v your_module.py
実行したときのログは次のとおりです。
Trying:
add(2, 3)
Expecting:
5
ok
Trying:
add(-1, 1)
Expecting:
0
ok
1 items had no tests:
doctest-sample
1 items passed all tests:
2 tests in doctest-sample.add
2 tests in 2 items.
2 passed and 0 failed.
Test passed.
defadd(a, b):
""" Add two numbers. Examples: >>> add(2, 3) 5 >>> add(-1, 1) 0"""return a + b
基本的には対話モードで示した関数の実行例の返却値を次の行で示します。
例外をテストする場合は？
defdivide(a, b):
""" Divide a by b. >>> divide(4, 2) 2.0 >>> divide(1, 0) Traceback (most recent call last): ... ZeroDivisionError: division by zero"""return a / b
例外をテストしたいときの書き方は決まったやり方が必要です。
Traceback (most recent call last): を例外発生を示す呪文として記述する必要があります。さらに次の行はインデントを加えたうえで ... が必要。その上、最後に発生する例外 Error ＋その詳細も正確に明記する必要がある。なので、通常は division by zero の部分 message もしっかり書かないとダメ。
Trying:
noop()
Expecting nothing
ok
1 items had no tests:
doctest-sample2
1 items passed all tests:
1 tests in doctest-sample2.noop
1 tests in 2 items.
1 passed and 0 failed.
Test passed.
defdiv(x, y):
""" Divide two numbers and return the result. This function performs a division and returns the quotient. It raises a ZeroDivisionError if the divisor is zero. Args: x (float): The numerator. y (float): The denominator. Returns: float: The result of division. Raises: ZeroDivisionError: If y is zero. Examples: >>> div(10, 2) 5.0 >>> div(5, 0) Traceback (most recent call last): ... ZeroDivisionError: division by zero"""if y == 0:
raiseZeroDivisionError("division by zero")
return x / y
用意されているセクションを整理する：
Attributes（クラスで使用：変数の説明）
Args（引数の説明）
Returns（通常関数で使用：戻り値の型＋意味）
Yields（ジェネレータ関数のみ使用：戻り値の型＋意味）
Raises（例外の一覧）
Examples（使用例：doctest 形式が望ましい）
Note（補足的な情報）
Todo（将来的な改善、未対応のメモ）
こんな感じなので、コメントで頻出するセクションは Args, Returns で Raises, Examples が記述の推奨で Note, Todo が記述の任意になると思う。また、クラス、ジェネレータ関数に対してのみ使うセクションもある。使用の際は使い分けに注意する。
Raises を書くときの考え方は色々あると思うけど、基本的には明示的に raise したもの、つまり直接（具体的にコーディングとして）記述した例外を残す必要性は高い。そのほかの例を挙げると、ファイル I/O で open するときのようなケースだと FileNotFoundError など発生が予想できる。この場合だと、記述しておくのは「親切」であって、比較的弱い推奨になる。
classUser:
"""Represents a user."""
name: str# The user's name
age: int# The user's age
あるいは：
classUser:
"""Represents a user."""def__init__(self, name: str, age: int):
""" Initialize the user. Args: name (str): The user's name. age (int): The user's age. """
self.name = name # The user's name
self.age = age # The user's age
