{"id":"7ba5a7c2-19e5-4c10-84a0-18ac6b74506a","shortId":"Gj4Xtm","kind":"skill","title":"modify-feature","tagline":">-","description":"!../principles/SKILL_BODY.md\n\n!../tool-gitnexus/SKILL_BODY.md\n\n---\n\n# Modify Existing Feature / Module Workflow\n\n## Disambiguating modify-feature vs fix-bug\n\n> **Use this skill when:** the code does X correctly — you want it to do Z instead (desired behavior is changing).\n> **Use fix-bug when:** the code *should* do X but does Y — you want to restore correct behavior.\n>\n> Quick test: *\"Is the current behavior broken, or just not what we want going forward?\"*\n> → **Broken / was never right** → **stop**. Tell the user: \"This looks like a bug rather than a behavior change — the fix-bug workflow is a better fit. You can say something like 'this is broken / it used to work' to trigger the right workflow, or tell me to proceed anyway and I'll apply baseline rules only.\" Do not proceed unless the user explicitly says to proceed.\n> → **Worked correctly, requirements evolved** → modify-feature (continue here).\n>\n> Edge case: Performance problems and security gaps feel like bugs but are almost always modify-feature — the code \"works,\" it just doesn't meet a non-functional requirement. Continue with this skill.\n\n## Core Principle\n\nModification requests are riskier than additions — you're touching a running system; pulling one thread affects the whole. The core strategy is **understand first, analyze, then refine, and only then act**.\n\n---\n\n## Complete Execution Workflow\n\n> **Progress tracking:** Output the progress block **twice per step**:\n> 1. **Before** starting the step — mark it `→ — in progress`, then immediately do the work.\n> 2. **After** completing the step — output the block again with that step marked `✓ — <one-line finding>`.\n>\n> Do **NOT** batch all updates into a single block at the end. Each step must print its own start and completion block.\n>\n> Include **only the steps that apply to the current task scale** — omit inapplicable steps entirely:\n> - **Lightweight**: Step 5 only\n> - **Medium**: Steps 1, 5, 6 (Step 3 optional — include if you run it)\n> - **Large**: All steps (1 → 2 → 3 → 4 → 5 → 6)\n>\n> Large-task example mid-execution (adapt by removing rows for smaller scales):\n> ```\n> Modify Feature Progress\n> ✓ Step 1: Read & Establish Context  — <one-line finding>\n> → Step 2: Impact Analysis           — in progress\n> ○ Step 3: Requirements Refinement\n> ○ Step 4: Solution Design + Confirm\n> ○ Step 5: Implement\n> ○ Step 6: Compliance Audit\n> ```\n\n---\n\n### Step 1: Read the Code — Establish Full Context\n\n> Required for medium and above tasks. Lightweight tasks (minor single-function adjustments) can be simplified to just reading the target function itself.\n\nBefore acting, you must build a complete understanding of the target code and its surroundings.\n\n**Questions to answer:**\n- What is the **responsibility boundary** of the target code? Which layer does it belong to?\n- What are its **callers**? (Who uses it — trace upward)\n- What are its **dependencies**? (What does it use — trace downward)\n- Is it **indirectly depended upon by other modules via events/callbacks/interfaces**?\n- What is the **design intent** of the current code? (Read comments, commit messages, PR descriptions)\n- Are there **implicit contracts**? (e.g., return value format, call order, state assumptions)\n\n🔗 When GitNexus is available, use `context` MCP tool to get callers and callees automatically.\n\n```\n─── Reading Scope (must cover) ──────────────────────\n[ ] Complete implementation of the target function/class/module itself\n[ ] Direct callers (at least one level up)\n[ ] Direct dependencies (at least one level down)\n[ ] Related interface definitions / abstract base classes / type declarations\n[ ] Related config items / constant definitions\n[ ] Related unit tests / integration tests (if any)\n─────────────────────────────────────────────────────\n```\n\n### Step 2: Impact Analysis — Map the Change Radiation\n\n> Required when involving public interfaces, cross-module changes, or shared data structures.\n\n**Analysis dimensions:**\n- **Direct impact**: Behavioral changes to the modified function/class itself\n- **Upstream impact**: Do callers depend on the behavior that is about to change?\n- **Downstream impact**: Does the way dependencies are used need to be adjusted synchronously?\n- **Cross-module impact**: Are other modules associated through event bus, shared state, or shared DTOs?\n- **Contract impact**: Do the interface signature, parameter types, or return structure change (Breaking Change)?\n- **Data impact**: Does it involve database schema changes, cache invalidation, or data migration?\n\n🔗 When GitNexus is available, use `impact` MCP tool for upstream/downstream analysis.\n\n```\n─── Change Impact Analysis Report ───────────────────\nChange target: <module/function name>\nChange type: [ ] Behavior modification  [ ] Signature change  [ ] Internal refactor  [ ] Extension enhancement\n\nDirect impact scope:\n  - <list modified files/functions>\n\nIndirect impact scope:\n  - <list affected callers/dependents>\n\nIs it a Breaking Change: Yes / No\nDoes it require synchronous changes to other modules: Yes (list) / No\nDoes it involve data changes: Yes (describe) / No\nRisk level: Low / Medium / High\n─────────────────────────────────────────────────────\n```\n\n### Step 3: Requirements Refinement — Re-examine Under Architecture Constraints\n\nDon't directly implement after receiving requirements — use the established code context to validate and refine them.\n\n**Questions to confirm:**\n- In the current architecture, where is **the most natural implementation point** for the behavioral change?\n- Can the requirements be achieved through **extending existing abstraction points**, or must core logic be modified?\n- Do the requirements conflict with existing design intent?\n- Are the boundary conditions of the requirements clear?\n\n**Core principle: Prioritize finding an \"extension-based modification\" path; only then consider \"invasive modification.\"**\n\n```\n─── Modification Strategy Priority (best to worst) ──\n1. Configuration: Modifying config/params is sufficient → zero code changes\n2. Extension: Add implementation class/strategy/handler, register with existing extension point → don't touch old code\n3. Decoration: Wrap existing behavior with decorator/middleware/AOP → old code is unaware\n4. Local modification: Modify logic inside existing function/method → minimal change principle\n5. Signature change: Need to modify interface/parameters/return value → must synchronize all callers\n6. Structural reorganization: Need to split/merge/move modules → requires explicit user authorization\n─────────────────────────────────────────────────────\n```\n\n### Step 4: Solution Design — Create Modification Plan and Get Confirmation\n\n> Confirm first when involving public interfaces, cross-module changes, or Breaking Changes.\n\n```\n─── Modification Plan ───────────────────────────────\nRequirement summary: <one-sentence description>\nModification strategy: <Configuration / Extension / Decoration / Local modification / Signature change / Structural reorganization>\n\nChange list:\n  1. <File A> - <change description>\n  2. <File B> - <change description>\n\nImpact scope: <directly/indirectly affected modules>\nBreaking Change: Yes / No\nRisk points: <if any>\n\nConfirm execution?\n─────────────────────────────────────────────────────\n```\n\n### Confirmation Gate (between Step 4 and Step 5)\n\nAfter presenting the Modification Plan, **before writing any code**, use the confirmation gate with:\n\n- **question**: The Modification Plan block above\n- **options**:\n  - `\"Yes, proceed with implementation\"`\n  - `\"No — let's revise the approach\"`\n\n**Decision rules by risk level:**\n\n| Risk | Behavior |\n|------|----------|\n| **High** (Breaking Change, cross-module, or Structural reorganization) | Always use the confirmation gate. Do not touch any file until user selects \"Yes\". |\n| **Medium** (multi-file, internal-only, no Breaking Change) | Always use the confirmation gate. Do not touch any file until user selects \"Yes\". |\n| **Low** (Lightweight, single-function config or local change) | Skip — proceed directly to Step 5. |\n\n**If user selects \"No\":** ask *\"What direction would you prefer?\"*, revise the Modification Plan, and use the confirmation gate again before proceeding.\n\n---\n\n### Step 4.5: TDD Mode — Baseline + Contract Tests (Large Tasks Only)\n\n> **Large tasks only.** Run after the modification plan is confirmed in Step 4, before writing any implementation code.\n\n> **§P config check:** read `.sextant.yaml` before prompting.\n> - `tdd: enforce` → skip the prompt; TDD is mandatory\n> - `tdd: default_on` → treat as default Y\n> - `tdd: off` or absent → use the default below\n\nTDD mode: write regression baseline and contract tests first? [Y/n]  (default Y — opt out explicitly if this is a structural-only refactor with no behavior change)\n\n**If Y:**\n1. **Regression baseline:** Write **complete, runnable tests** that capture the **current** behavior before touching any code. These tests must pass right now, and must continue to pass after the change is complete. They are your regression safety net.\n2. **New behavior contracts:** Write **complete, runnable tests** for the new behavior (Arrange + Act + Assert — no `TODO` placeholders). The Act calls the existing function with inputs that should produce the new output — the test fails because the implementation does not yet satisfy the new contract. Valid red-light failure: assertion on wrong return value, raised exception where none was expected, or vice versa. An incomplete test that cannot run is not a valid red.\n- For full test writing guidance, link `sextant:write-tests`.\n\n**If N (or Lightweight task):** Proceed directly to Step 5.\n\n### Step 5: Implement — Follow the Minimal Change Principle\n\n**Execution discipline:**\n- **Maintain style consistency**: Naming, indentation, comment language fully consistent with surrounding code\n- **No hitchhiking**: Don't \"optimize\" unrelated code while implementing requirements\n- **Changes are traceable**: Format: `# change: <requirement description> - <reason for change>`\n- **Backward compatibility**: Prefer compatible approaches (default parameters, overloading, adapters) unless user explicitly states otherwise\n- **Incremental implementation**: Do structural adjustments first, then behavioral changes\n\n**Common backward compatibility approaches:**\n```python\n# ✅ Add optional parameter, old calling style unaffected\ndef process_order(order_id: str, priority: int = 0):  # priority is newly added\n    ...\n\n# ✅ Keep old function as adapter, internally calls new implementation\ndef get_user(user_id):                    # Old interface, preserved\n    return get_user_v2(user_id).to_legacy_format()\n```\n\n**❌ Forbidden actions:**\n- Modifying public interface signatures without confirmation\n- Sneaking in \"optimizations\" unrelated to the current requirement\n- Deleting code that's temporarily unused without informing the user\n- Changing return value structures without updating all callers\n\n### Step 6: Compliance Audit (Required for Medium and Above Tasks)\n\n```\n─── Modification Architecture Audit Checklist ───────\n[ ] Does the change follow the minimal change principle? Any unnecessary extra changes?\n[ ] Is style consistency with surrounding code maintained?\n[ ] Has the existing interface contract been broken? (Parameters, return values, exceptions)\n[ ] Have all callers been adapted to the change? Any missed?\n[ ] Has any new circular dependency been introduced?\n[ ] Has the encapsulation boundary of existing modules been broken?\n[ ] Is the dependency direction still compliant? Any new reverse dependencies?\n[ ] Are there conflicts with adjacent features? (Shared state, events, shared data structures)\n[ ] Do the original unit tests still pass? Do tests need to be updated?\n[ ] Does documentation / comments / type definitions / CHANGELOG need to be updated?\n─────────────────────────────────────────────────────\n```\n\n---\n\n## Workflow Tailoring by Task Scale\n\n**Lightweight** (minor single-function logic adjustment, config changes, style fixes):\n- Required: Step 5 only\n- Optional: Step 1 (quick scan)\n- Skip: Steps 2–4, Step 4.5, Step 6\n\n**Medium** (modify module internal logic, add/remove internal functions):\n- Required: Step 1 → Step 5 → Step 6\n- Optional: Step 3\n- Skip: Steps 2, 4, Step 4.5\n\n**Large** (cross-module changes, public interface modifications, Breaking Changes):\n- Required: Steps 1 → 2 → 3 → 4 → 5 → 6 in order\n- Optional: Step 4.5 (TDD mode, default Y) — runs after Step 4 confirmation, before Step 5\n\n> Step 4.5 (TDD mode) is only meaningful after Step 4 confirms the modification plan. It is never run before Step 4, and never run on Lightweight tasks.\n\n---\n\n## Common Pitfalls\n\n| Pitfall | Description | Correct Approach |\n|---------|-------------|-----------------|\n| Act without reading | Modified function without reading callers | At minimum trace one level up |\n| Hitchhiking | Smuggled in \"opportunistic optimizations\" | Strict separation: change only serves the current requirement |\n| Implicit Breaking Change | Changed return value structure assuming callers unaffected | Proactively check all callers |\n| Over-modification | User requested minor adjustment but entire module was rewritten | Follow minimal change principle |\n| Forgot compatibility | Directly changed signature when modifying public interface | Prefer default parameters/overloading |\n| Missed sync | Changed code but forgot to update related docs/types/tests | Audit checklist covers sync items |\n\n---\n\n## Sprint State Integration\n\nIf `.sextant/state.json` exists in the project root and the current task matches a sprint task:\n\n- **On start:** offer to update the task's `status` from `pending` → `in_progress`. Ask: *\"Update sprint state to mark Task N as in_progress?\"*\n- **On completion** (acceptance condition met): offer to update `status` to `done`. Ask: *\"Update sprint state to mark Task N as done?\"*\n- **On blocker** (test failure, missing dependency, unresolvable ambiguity that halts progress): surface the issue, then ask: *\"Mark Task N as blocked and record the reason in flags?\"* If confirmed, set `status: \"blocked\"` and append `{\"task\": N, \"reason\": \"<one-sentence blocker description>\"}` to the top-level `flags` array. Do not proceed to the next task while a task is blocked.\n\nDo not write the file without explicit user confirmation. If the user declines, continue without state updates.\n\n---\n\n## Reply Format\n\n**Lightweight task** (single-function logic change, config update, style fix): one sentence only.\n```\n✅ Modified `<function>`: <what changed> using <strategy> (<file>:<line>).\n```\n\n**Medium/large task** (cross-file, public interface, or Breaking Change): full block.\n\nModification Summary:\n\n| # | Item | Detail |\n|---|------|--------|\n| [1] | Conclusion | <one sentence: what changed, which strategy was used, and the outcome> |\n| [2] | Changes | <files / functions modified; callers updated; backward-compat shims added> |\n| [3] | Risks / Assumptions | <Breaking Change status; compatibility assumptions; callers not yet adapted> |\n| [4] | Verification | <Step 6 audit result: Passed ✅ / Issues ⚠️ (details); unit test status> |\n| [5] | Needs your input | <Breaking Change approval; callers that must still be updated by the user> |","tags":["modify","feature","sextant","hellotern","agent-skills","claude-code","skill-md"],"capabilities":["skill","source-hellotern","skill-modify-feature","topic-agent-skills","topic-claude-code","topic-skill-md"],"categories":["Sextant"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/hellotern/Sextant/modify-feature","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add hellotern/Sextant","source_repo":"https://github.com/hellotern/Sextant","install_from":"skills.sh"}},"qualityScore":"0.457","qualityRationale":"deterministic score 0.46 from registry signals: · indexed on github topic:agent-skills · 14 github stars · SKILL.md body (15,231 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-04-22T13:03:26.044Z","embedding":null,"createdAt":"2026-04-19T00:40:22.286Z","updatedAt":"2026-04-22T13:03:26.044Z","lastSeenAt":"2026-04-22T13:03:26.044Z","tsv":"'/principles/skill_body.md':4 '/tool-gitnexus/skill_body.md':5 '0':1351 '1':228,298,312,336,363,806,906,1138,1553,1574,1600,1910 '2':242,313,341,542,815,907,1176,1558,1584,1601,1923 '3':302,314,347,709,830,1581,1602,1935 '4':315,351,841,876,925,1073,1559,1585,1603,1618,1632,1643,1947 '4.5':1052,1561,1587,1610,1624 '5':294,299,316,356,852,928,1028,1270,1272,1549,1576,1604,1622,1959 '6':300,317,359,864,1417,1563,1578,1605,1950 'absent':1104 'abstract':524,761 'accept':1784 'achiev':757 'act':215,394,1189,1195,1656 'action':1383 'ad':1355,1934 'adapt':325,1316,1360,1464,1946 'add':817,1336 'add/remove':1569 'addit':190 'adjac':1500 'adjust':382,597,1326,1542,1703 'affect':200,911 'almost':161 'alway':162,976,1000 'ambigu':1810 'analysi':343,544,562,652,655 'analyz':209 'answer':410 'anyway':122 'append':1836 'appli':126,282 'approach':959,1312,1334,1655 'approv':1965 'architectur':716,741,1427 'arrang':1188 'array':1846 'ask':1033,1771,1793,1818 'assert':1190,1226 'associ':606 'assum':1690 'assumpt':481,1937,1942 'audit':361,1419,1428,1735,1951 'author':874 'automat':495 'avail':485,645 'backward':1308,1332,1931 'backward-compat':1930 'base':525,792 'baselin':127,1055,1113,1140 'batch':257 'behavior':36,57,63,89,566,580,663,751,834,966,1134,1149,1178,1187,1329 'belong':424 'best':803 'better':98 'block':224,249,263,276,947,1823,1834,1858,1905 'blocker':1804 'boundari':415,779,1480 'break':627,680,896,913,968,998,1596,1684,1902,1938,1963 'broken':64,73,107,1455,1485 'bug':18,42,85,94,158 'build':397 'bus':609 'cach':637 'call':478,1196,1340,1362 'calle':494 'caller':429,492,508,576,863,1415,1462,1663,1691,1696,1928,1943,1966 'cannot':1244 'captur':1146 'case':150 'chang':38,90,547,557,567,585,626,628,636,653,657,661,666,681,688,699,752,814,850,854,894,897,904,914,969,999,1022,1135,1167,1277,1303,1307,1330,1408,1432,1436,1441,1467,1544,1592,1597,1677,1685,1686,1711,1716,1727,1884,1903,1915,1924,1939,1964 'changelog':1526 'check':1081,1694 'checklist':1429,1736 'circular':1473 'class':526 'class/strategy/handler':819 'clear':784 'code':24,45,167,366,404,419,463,728,813,829,838,937,1078,1153,1292,1299,1399,1447,1728 'comment':465,1286,1523 'commit':466 'common':1331,1650 'compat':1309,1311,1333,1714,1932,1941 'complet':216,244,275,399,500,1142,1169,1181,1783 'complianc':360,1418 'compliant':1491 'conclus':1911 'condit':780,1785 'config':530,1019,1080,1543,1885 'config/params':809 'configur':807 'confirm':354,737,884,885,919,921,940,979,1003,1046,1070,1389,1619,1633,1831,1867 'conflict':772,1498 'consid':797 'consist':1283,1289,1444 'constant':532 'constraint':717 'context':339,369,487,729 'continu':147,179,1162,1872 'contract':473,615,1056,1115,1179,1220,1453 'core':183,204,765,785 'correct':27,56,141,1654 'cover':499,1737 'creat':879 'cross':555,600,892,971,1590,1897 'cross-fil':1896 'cross-modul':554,599,891,970,1589 'current':62,285,462,740,1148,1396,1681,1752 'data':560,629,640,698,1506 'databas':634 'decis':960 'declar':528 'declin':1871 'decor':831 'decorator/middleware/aop':836 'def':1343,1365 'default':1095,1099,1107,1119,1313,1613,1723 'definit':523,533,1525 'delet':1398 'depend':438,448,515,577,591,1474,1488,1495,1808 'describ':701 'descript':469,1653 'design':353,458,775,878 'desir':35 'detail':1909,1955 'dimens':563 'direct':507,514,564,671,720,1025,1035,1267,1489,1715 'directly/indirectly':910 'disambigu':11 'disciplin':1280 'docs/types/tests':1734 'document':1522 'doesn':171 'done':1792,1802 'downstream':586 'downward':444 'dtos':614 'e.g':474 'edg':149 'encapsul':1479 'end':266 'enforc':1087 'enhanc':670 'entir':291,1705 'establish':338,367,727 'event':608,1504 'events/callbacks/interfaces':454 'evolv':143 'examin':714 'exampl':321 'except':1232,1459 'execut':217,324,920,1279 'exist':7,760,774,822,833,847,1198,1451,1482,1745 'expect':1236 'explicit':136,872,1123,1319,1865 'extend':759 'extens':669,791,816,823 'extension-bas':790 'extra':1440 'fail':1210 'failur':1225,1806 'featur':3,8,14,146,165,333,1501 'feel':156 'file':985,993,1009,1863,1898,1925 'find':788 'first':208,886,1117,1327 'fit':99 'fix':17,41,93,1546,1888 'fix-bug':16,40,92 'flag':1829,1845 'follow':1274,1433,1709 'forbidden':1382 'forgot':1713,1730 'format':477,1306,1381,1877 'forward':72 'full':368,1252,1904 'fulli':1288 'function':177,381,391,1018,1199,1358,1540,1571,1660,1882,1926 'function/class':571 'function/class/module':505 'function/method':848 'gap':155 'gate':922,941,980,1004,1047 'get':491,883,1366,1374 'gitnexus':483,643 'go':71 'guidanc':1255 'halt':1812 'high':707,967 'hitchhik':1294,1670 'id':1347,1369,1378 'immedi':238 'impact':342,543,565,574,587,602,616,630,647,654,672,675,908 'implement':357,501,721,747,818,953,1077,1213,1273,1301,1323,1364 'implicit':472,1683 'inapplic':289 'includ':277,304 'incomplet':1241 'increment':1322 'indent':1285 'indirect':447,674 'inform':1405 'input':1201,1962 'insid':846 'instead':34 'int':1350 'integr':537,1742 'intent':459,776 'interfac':522,553,619,890,1371,1386,1452,1594,1721,1900 'interface/parameters/return':858 'intern':667,995,1361,1567,1570 'internal-on':994 'introduc':1476 'invalid':638 'invas':798 'involv':551,633,697,888 'issu':1816,1954 'item':531,1739,1908 'keep':1356 'languag':1287 'larg':309,319,1058,1061,1588 'large-task':318 'layer':421 'least':510,517 'legaci':1380 'let':955 'level':512,519,704,964,1668,1844 'light':1224 'lightweight':292,376,1015,1264,1536,1648,1878 'like':83,104,157 'link':1256 'list':693,905 'll':125 'local':842,1021 'logic':766,845,1541,1568,1883 'look':82 'low':705,1014 'maintain':1281,1448 'mandatori':1093 'map':545 'mark':233,254,1776,1798,1819 'match':1754 'mcp':488,648 'meaning':1629 'medium':296,372,706,990,1422,1564 'medium/large':1894 'meet':173 'messag':467 'met':1786 'mid':323 'mid-execut':322 'migrat':641 'minim':849,1276,1435,1710 'minimum':1665 'minor':378,1537,1702 'miss':1469,1725,1807 'mode':1054,1110,1612,1626 'modif':185,664,793,799,800,843,880,898,902,932,945,1041,1067,1426,1595,1635,1699,1906 'modifi':2,6,13,145,164,332,570,768,808,844,857,1384,1565,1659,1719,1892,1927 'modify-featur':1,12,144,163 'modul':9,452,556,601,605,691,870,893,912,972,1483,1566,1591,1706 'module/function':659 'multi':992 'multi-fil':991 'must':269,396,498,764,860,1156,1161,1968 'n':1262,1778,1800,1821,1838 'name':660,1284 'natur':746 'need':594,855,867,1517,1527,1960 'net':1175 'never':75,1639,1645 'new':1177,1186,1206,1219,1363,1472,1493 'newli':1354 'next':1852 'non':176 'non-funct':175 'none':1234 'offer':1760,1787 'old':828,837,1339,1357,1370 'omit':288 'one':198,511,518,1667,1889,1912 'opportunist':1673 'opt':1121 'optim':1297,1392,1674 'option':303,949,1337,1551,1579,1608 'order':479,1345,1346,1607 'origin':1510 'otherwis':1321 'outcom':1922 'output':221,247,1207 'over-modif':1697 'overload':1315 'p':1079 'paramet':621,1314,1338,1456 'parameters/overloading':1724 'pass':1157,1164,1514,1953 'path':794 'pend':1768 'per':226 'perform':151 'pitfal':1651,1652 'placehold':1193 'plan':881,899,933,946,1042,1068,1636 'point':748,762,824,918 'pr':468 'prefer':1038,1310,1722 'present':930 'preserv':1372 'principl':184,786,851,1278,1437,1712 'print':270 'priorit':787 'prioriti':802,1349,1352 'proactiv':1693 'problem':152 'proceed':121,132,139,951,1024,1050,1266,1849 'process':1344 'produc':1204 'progress':219,223,236,334,345,1770,1781,1813 'project':1748 'prompt':1085,1090 'public':552,889,1385,1593,1720,1899 'pull':197 'python':1335 'question':408,735,943 'quick':58,1554 'radiat':548 'rais':1231 'rather':86 're':192,713 're-examin':712 'read':337,364,388,464,496,1082,1658,1662 'reason':1827,1839 'receiv':723 'record':1825 'red':1223,1250 'red-light':1222 'refactor':668,1131 'refin':211,349,711,733 'regist':820 'regress':1112,1139,1173 'relat':521,529,534,1733 'remov':327 'reorgan':866,975 'repli':1876 'report':656 'request':186,1701 'requir':142,178,348,370,549,686,710,724,755,771,783,871,900,1302,1397,1420,1547,1572,1598,1682 'respons':414 'restor':55 'result':1952 'return':475,624,1229,1373,1409,1457,1687 'revers':1494 'revis':957,1039 'rewritten':1708 'right':76,115,1158 'risk':703,917,963,965,1936 'riskier':188 'root':1749 'row':328 'rule':128,961 'run':195,307,1064,1245,1615,1640,1646 'runnabl':1143,1182 'safeti':1174 'satisfi':1217 'say':102,137 'scale':287,331,1535 'scan':1555 'schema':635 'scope':497,673,676,909 'secur':154 'select':988,1012,1031 'sentenc':1890,1913 'separ':1676 'serv':1679 'set':1832 'sextant':1257 'sextant.yaml':1083 'sextant/state.json':1744 'share':559,610,613,1502,1505 'shim':1933 'signatur':620,665,853,1387,1717 'simplifi':385 'singl':262,380,1017,1539,1881 'single-funct':379,1016,1538,1880 'skill':21,182 'skill-modify-feature' 'skip':1023,1088,1556,1582 'smaller':330 'smuggl':1671 'sneak':1390 'solut':352,877 'someth':103 'source-hellotern' 'split/merge/move':869 'sprint':1740,1756,1773,1795 'start':230,273,1759 'state':480,611,1320,1503,1741,1774,1796,1874 'status':1766,1790,1833,1940,1958 'step':227,232,246,253,268,280,290,293,297,301,311,335,340,346,350,355,358,362,541,708,875,924,927,1027,1051,1072,1269,1271,1416,1548,1552,1557,1560,1562,1573,1575,1577,1580,1583,1586,1599,1609,1617,1621,1623,1631,1642,1949 'still':1490,1513,1969 'stop':77 'str':1348 'strategi':205,801,903,1917 'strict':1675 'structur':561,625,865,974,1129,1325,1411,1507,1689 'structural-on':1128 'style':1282,1341,1443,1545,1887 'suffici':811 'summari':901,1907 'surfac':1814 'surround':407,1291,1446 'sync':1726,1738 'synchron':598,687,861 'system':196 'tailor':1532 'target':390,403,418,504,658 'task':286,320,375,377,1059,1062,1265,1425,1534,1649,1753,1757,1764,1777,1799,1820,1837,1853,1856,1879,1895 'tdd':1053,1086,1091,1094,1101,1109,1611,1625 'tell':78,118 'temporarili':1402 'test':59,536,538,1057,1116,1144,1155,1183,1209,1242,1253,1260,1512,1516,1805,1957 'thread':199 'todo':1192 'tool':489,649 'top':1843 'top-level':1842 'topic-agent-skills' 'topic-claude-code' 'topic-skill-md' 'touch':193,827,983,1007,1151 'trace':433,443,1666 'traceabl':1305 'track':220 'treat':1097 'trigger':113 'twice':225 'type':527,622,662,1524 'unaffect':1342,1692 'unawar':840 'understand':207,400 'unit':535,1511,1956 'unless':133,1317 'unnecessari':1439 'unrel':1298,1393 'unresolv':1809 'unus':1403 'updat':259,1413,1520,1530,1732,1762,1772,1789,1794,1875,1886,1929,1971 'upon':449 'upstream':573 'upstream/downstream':651 'upward':434 'use':19,39,109,431,442,486,593,646,725,938,977,1001,1044,1105,1893,1919 'user':80,135,873,987,1011,1030,1318,1367,1368,1375,1377,1407,1700,1866,1870,1974 'v2':1376 'valid':731,1221,1249 'valu':476,859,1230,1410,1458,1688 'verif':1948 'versa':1239 'via':453 'vice':1238 'vs':15 'want':29,53,70 'way':590 'whole':202 'without':1388,1404,1412,1657,1661,1864,1873 'work':111,140,168,241 'workflow':10,95,116,218,1531 'worst':805 'would':1036 'wrap':832 'write':935,1075,1111,1141,1180,1254,1259,1861 'write-test':1258 'wrong':1228 'x':26,48 'y':51,1100,1120,1137,1614 'y/n':1118 'yes':682,692,700,915,950,989,1013 'yet':1216,1945 'z':33 'zero':812","prices":[{"id":"8f32fcaa-2cc8-4c4b-aad9-08b650e4c8db","listingId":"7ba5a7c2-19e5-4c10-84a0-18ac6b74506a","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"hellotern","category":"Sextant","install_from":"skills.sh"},"createdAt":"2026-04-19T00:40:22.286Z"}],"sources":[{"listingId":"7ba5a7c2-19e5-4c10-84a0-18ac6b74506a","source":"github","sourceId":"hellotern/Sextant/modify-feature","sourceUrl":"https://github.com/hellotern/Sextant/tree/main/skills/modify-feature","isPrimary":false,"firstSeenAt":"2026-04-19T00:40:22.286Z","lastSeenAt":"2026-04-22T13:03:26.044Z"}],"details":{"listingId":"7ba5a7c2-19e5-4c10-84a0-18ac6b74506a","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"hellotern","slug":"modify-feature","github":{"repo":"hellotern/Sextant","stars":14,"topics":["agent-skills","claude-code","skill-md"],"license":"mit","html_url":"https://github.com/hellotern/Sextant","pushed_at":"2026-04-07T00:57:27Z","description":"init","skill_md_sha":"09d10497db6e15daec76672cb5fbd74c205013fb","skill_md_path":"skills/modify-feature/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/hellotern/Sextant/tree/main/skills/modify-feature"},"layout":"multi","source":"github","category":"Sextant","frontmatter":{"description":">-"},"skills_sh_url":"https://skills.sh/hellotern/Sextant/modify-feature"},"updatedAt":"2026-04-22T13:03:26.044Z"}}