jason810496 commented on issue #62500:
URL: https://github.com/apache/airflow/issues/62500#issuecomment-4060207948

   First, I would like to thank everyone who joined the discussion. All the 
above points of view are valid. From the technical depth discussed, the 
trade-offs between different approaches, and the innovative new implementation 
details that still align with the core concepts, it is clear that you are all 
capable of contributing to OSS projects at Airflow-scale with this level of 
mindset, thinking, and quality. I’m looking forward to seeing contributions 
from new faces!
   
   Back to the project, the "executable document" idea mentioned in 
https://github.com/apache/airflow/issues/62500#issuecomment-4028494629 is more 
aligned with what I expected and what I had imaged. It seems like a good 
direction.
   
   Among all the approaches above, whether the block format is like ‎`.. 
agent-skills-code-block` (RST style) or ‎`id: skill-name`, and whether or not 
there are intermediate results (e.g. workflow definitions, generators, YAML, 
JSON), they all still share the concept of an “executable document.” The main 
differences between these approaches are likely long-term maintainability and 
readability.
   
   The direction here is clear, and I don’t see any pitfalls (though I would 
still welcome any suggestions or opinions from @potiuk or @sjyangkevin). There 
is definitely room to dive deeper into the implementation details, for example 
by building a local PoC, benchmarking it, and evaluating the approach yourself. 
You could also verify the impact of using (or not using) the agent skills you 
created to contribute, in order to see the actual value, differences, and 
potential improvements from a real developer-experience perspective. (Please be 
responsible for the PR: make sure to follow [the 
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions),
 understand the context of the issue, and be clear about what you are actually 
solving.)
   
   Here are some Breeze modules that might be helpful for gaining more insight 
or for the implementation:
   - `dev/breeze/src/airflow_breeze/commands/developer_commands_config.py` 
defines all the available commands/ flags 
   - 
https://github.com/apache/airflow/blob/25f614df96fa1c709a8cd07fef0bb9eb63f9ec25/.pre-commit-config.yaml#L909
 an example of "make Breeze CLI in sync with doc"
   
   To answer the questions:
   
   > This would keep Breeze as the single source of truth while still giving AI 
tools a structured interface for common contributor workflows (running static 
checks, tests, starting services, etc.).
   
   Just a small reminder that we agreed that contributor doc will be the source 
of truth instead of solely depending on Breeze CLI: 
https://github.com/apache/airflow/issues/62500#issuecomment-4028191936
   
   > One question I had while exploring this: should the skills system aim to 
cover all Breeze commands, or only a curated subset representing typical 
contributor workflows?
   
   Instead of focusing on full coverage, it is more important to decide what 
the actual approach should look like and why we should design it that way. Once 
the final approach is stable, implementing the remaining commands is almost 
“copy & paste” in the AI era, so quality over quantity IMHO.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to