GitHub user justinmclean created a discussion: In security-issue-fix should Step 0 probe common clone locations, or require explicit config?
While looking at security-issue-fix/SKILL.md, I found a contradiction between two sections. Step 0 (pre-flight check) tells the agent to probe common locations if no path is supplied: "probe the usual locations (the input path if supplied, else ~/code/airflow, ~/src/airflow, ~/airflow, or a sibling of the current working directory) for a directory whose origin remote points at <upstream>" Prerequisites section and Step 3 state the opposite policy explicitly: "The skill does not guess filesystem layouts — there is no hard-coded search path." "Do not probe hard-coded paths like ~/code/airflow — filesystem layouts vary per user and a wrong guess masks a misconfigured clone." Git history confirms both were present from the initial commit. The possible positions: A — Keep the probe (Step 3 is too strict): Probing with remote-URL validation is safe enough in practice. If ~/code/airflow exists and its origin points at <upstream>, it's almost certainly the right clone. B — Keep the prohibition (Step 0 is the bug): The prohibition exists because a directory can pass remote-URL validation and still be the wrong clone (e.g. an old/stale clone the user no longer uses). C - This is intentional for reasons I can't work out. Which approach should the skill take? GitHub link: https://github.com/apache/airflow-steward/discussions/160 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
